6 ms·
Serious question for you, why use Docker at all? You can just get rid of the clunky overhead. You mentioned Python backend, so literally just replicate build s
by hello0904 2y ago
Serious question for you, why use Docker at all? You can just get rid of the clunky overhead.
You mentioned Python backend, so literally just replicate build script, directly in VPS: "pip install requirements.txt" > python main.py" > nano /etc/systemd/system/myservice.service > systemd start myservice > Tada.
You can scale instances by just throwing those commands in a bash script (build_my_app.sh) = You're new dockerfile...install on any server in xx-xxx seconds.
- ghomem 2y agoI mentioned Docker because it interests many developers but on VMs that I control I do not need Docker at all. Deploying with Docker provides host OS independence which is nice if you are distributing but unnecessary if the host is yours, running a fixed OS. For Python backends I often deploy the code directly with a Puppet resource called VcsRepo which basically places a certain tag of a certain repo on a certain filesystem location. And I also package the systemd scripts for easy start/stop/restart. You can do this with other config management tools, via bash or by hand, depending on how many systems you manage. What bothers me with your question is Pip :-) But perhaps that is off topic...?
- Gud 2y agoNo, you are tied to docker supported operating systems. Will not run on FreeBSD, for example.
- ghomem 2y agoI'll correct myself: s/host OS independence/a certain level of host OS independence And getting containers to run depends on the OS - if you don't control the host, leads to major ping-pongs. Even within Linux (Ubuntu, Debian, RHEL, etc) when you are distributing multiple related containers there are details to care about, not about the container itself but about the base OS configuration. It's not magic.
- ffsm8 2y ago> No, you are tied to docker supported operating systems No, you're tied to operating systems using a Linux kernel that supports the features necessary for running images.
- Gud 2y agoYou can run Linux under FreeBSD using either bhyve, using the Linux emulator and under jails. But you cannot run docker.
- BSDobelix 2y ago>But you cannot run docker. You can -> Podmaaan https://podman.io/docs/installation#installing-on-freebsd-140 https://podman.io/docs/installation#installing-on-freebsd-14... ATM experimental
- deleted 2y ago[deleted]
- dlisboa 2y agoOP is talking about substituting a Kubernetes setup. FreeBSD was never in the cards. 99% of companies in the cloud don’t run or care about anything other than Linux.
- Gud 2y agoThat may be true, but it’s still not “host OS independence”, which was my point
- BSDobelix 2y ago>Will not run on FreeBSD, for example. Not true: https://podman.io/docs/installation#installing-on-freebsd-140 https://podman.io/docs/installation#installing-on-freebsd-14... ATM experimental
- Sammi 2y agoHonestly most people's dockerfile could just as well be a bash script.
- hello0904 2y agoExactly! This person gets it. Oh, and not only build their app, they can take it a step further and setup the entire new vps and app building in one simple script!
- Sammi 2y agoI'm doing it :) I split it into multiple scripts that get called from one, just for my own sanity.
- ghomem 2y agoOnce you do it for long enough it might be worth it to consider configuration management where you declare native structured resources (users, firewall rules, nginx reverse proxies, etc) rather than writing them in shell. I use Puppet for distribution of users, firewall rules, SSH hardening + whitelisting, nginx config (rev proxy, static server, etc), Let's Encrypt certs management + renewal + distribution, PostgreSQL config, etc. The profit from this is huge once you have say 20-30 machines instead of 2-3, user lifecycle in the team that needs to be managed, etc. But the time investment is not trivial - for a couple of machines it is not worth it.
- throwaway894345 2y agoHonestly not having to use Puppet or Ansible are among my reasons for using Docker. I do some basic stuff in cloud-init (which is already frustrating enough) to configure users, ssh, and docker and everything else is just standard Docker tooling.
- pxc 2y ago> I do some basic stuff in cloud-init (which is already frustrating enough) What do you find frustrating about cloud-init? I'm relatively new to it.
- RUnconcerned 2y agoFamously, no one has ever had Python environment problems :D
- ghomem 2y agoIf you really want to open that can of worms, here it goes: Pipy is an informal source of software that has low security levels and was infested with malware many times over the years. It does not provide security updates: it provides updates that might include security-related changes as well as functional changes. Whenever you update a package from there, there is a chain reaction of dependency updates that insert untested code in your product. Due to this, I prefer to target an LTS platform (Ubuntu LTS, Debian, RHEL...) and adapt to whatever python environment exists there, enjoying the fact that I can blindly update a package due to security (ex: Django) without worrying that it will be a new version which could break my app. * Furthermore, with Ubuntu I can get a formal contract with Canonical without changing anything on my setup, and with RHEL it comes built-in with the subscription. Last time I checked Canonical's security team was around 30pax (whereas Pipy recently hired their first security engineer). These things provide supply-chain peace of mind to whoever consumes the software, not only to who maintains it. I really need to write an article about this. * exceptions apply, context is king
- ramses0 2y agoI've just doubled down on "making my own Debian packages". There's tons of examples, you are learning a durable skill, and 90% of the time (for personal stuff), I had to ask myself: would I really ever deploy this on something that wasn't Debian? Boom: debian-lts + my_package-0.3.20240913 ...the package itself doesn't have to be "good" or "portable", just install it, do your junk, and you don't have to worry about any complexity coming from ansible or puppet or docker. However: docker is also super nice! FROM debian:latest ; RUN dpkg -i my_package-*.deb ...it's nearly transparent management.
- throwaway894345 2y agoI don't mean this as a rebuttal, but rather to add to the discussion. While I like the idea of getting rid of the Docker layer, every time I try to I run into things that remind me why I use Docker: 1. Not needing to run my own PPA server (not super hard, it's just a little more friction than using Docker hub or github or whatever) 2. Figuring out how to make a deb package is almost always harder in practice for real world code than building/pushing a Docker container image 3. I really hate reading/writing/maintaining systemd units. I know most of the time you can just copy/paste boilerplate from the Internet or look up the docs in the man pages. Not the end of the world, just another pain point that doesn't exist in Docker. 4. The Docker tooling is sooooo much better than the systemd/debian ecosystem. `docker logs <container>` is so much better than `sudo journalctl --no-pager --reverse --unit <systemd-unit>.service`. It often feels like Linux tools pick silly defaults or otherwise go out of their way to have a counterintuitive UI (I have _plenty_ of criticism for Docker's UI as well, but it's still better than systemd IMHO). This is the biggest issue for me--Docker doesn't make me spend so much time reading man pages or managing bash aliases, and for me that's worth its weight in gold.
- ffsm8 2y agoClunky overhead from Docker? Sorry, but you've got no idea what you're talking about. You can also run OSI images, often called docker images directly via systemds nspawn. Because docker doesn't create an overhead by itself, its at its heart a wrapper around kernel features and iptables. You didn't need docker for deployments, but let's not use completely made up bullshit as arguments, okay?
- hello0904 2y agoI have no idea what I am talking about? Docker is literally adding middleware between your Linux system and app. That doesn't necessarily mean there aren't Pro's to Docker, but one Con to Docker is - it's absolutely overhead and complexity that is not necessary. I think one of the most powerful features of Docker by the way is Docker Compose. This is the real superpower of Docker in my opinion. I can literally run multiple services and apps in one VPS / dedicated server and have it manage my network interface and ports for me? Uhmmm...yes please!!!! :)
- ffsm8 2y agoO rly, pray tell, which middleware? Your most powerful feature is literally a hostfile that docker generates on container start that's saved at /etc/hosts + Iptables rules Edit: and if you don't want them, use Network-Mode: host and voila, none of that is generated
- neilalexander 2y agoDocker's runtime overheads on Linux are tiny. It's pretty much all implemented using namespaces, cgroups and mounts which are native kernel constructs.
- hello0904 2y agoWell designed, written and efficient...middleware. It's a wrapper around linux and a middle between my OS and my app! A spade is a spade. There are cons beyond performance. For example Docker complexity - you need to learn a new filetype, a new set of commands, a new architecture, new configurations, spend hours reading another set of documentation. Buy and read another 300 page O'Reily book to master and grasp something that again has Pro's and Con's. For me? It's not necessary and I even know some Docker Kung-Fu but choose not to use it. I do use Docker Desktop occasionally to run apps and services on my localhost - it's basically a Docker Compose UI, and I really enjoy it.
- darby_nine 2y agoDockerfiles compose and aren't restricted to running on linux. Those two reasons alone basically mean I never need to care about systemd again
- throwaway894345 2y agoYeah, not caring about systemd is a big win for me. And I don't just mean the cryptic systemd unit syntax, but also the absolutely terrible ux of every CLI tool in the suite. I'm tired of having to pass half a dozen flags every time I want to view the logs of a systemd unit (or forgetting to type `sudo` before `systemctl`). I'm tired of having to remember the path to the systemd unit files on each system whenever I need to edit the files (is it `etc/systemd/system/...` or `etc/system/systemd/...`?). Docker is far from perfect, but at least it's intuitive enough that I don't have to constantly reference man pages or manage aliases. I would love to do away with the Docker layer, but first the standard Linux tooling needs to improve a lot.
- authorfly 2y agoBecause it seems unobvious but docker always saves you. It's actually quicker than running pip install requirements.txt once you get a year in. (Trust me, I used to take your approach). Forget about "clunky overhead" - the running costs are < 10%. The dockerfile? You don't even need one. You can just pull from the python version you want e.g. Python1.11 and git pull you files from the container to get up and running. You don't need to use container image saving systems, you don't need to save images, or tag anything, you don't need to write set up scripts in the docker file, you can pass the database credentials through the environment option when launching the container. The problem is after a year or two you get clashes or weird stuff breaking. And modules stopping support of your python version preventing you installing new ones. Case in point, Googles AI module(needed for gemini and lots of their AI API services) only works on 3.10+. What if you started in 2021? Your python - then cutting edge - would not work anymore, it's only 3.5 years later from that release. Yeah you can use loads of curl. Good luck maintaining that for years though. Numpy 1.19 is calling np.warnings but some other dependence is using Numpy 1.20 which removed .warnings and made it .notices or something Your cached model routes for transformers changed default directory You update the dependencies and it seems fine, then on a new machine you try and update them, and bam, wrong python version, you are on 3.9 and remote is 3.10, so it's all breaking. It's also not simple in the following respect: your requirements.txt file will potentially have dependency clashes (despite running code), might take ages to install on a 4GB VM (especially if you need pytorch because some AI module that makes life 10x easier rather needlessly requires it). life with docker is worth it. i was scared of it too, but there are three key benefits for the everyman / solodev: - Literally docker export the running container as a .tar to install it on a new VM. That's one line and guaranteed the exact same VM, no changes. That's what you want, no risks. - Back up is equally simple; shell script to download regular back ups. Update is simple; shell script to update git repo within the container. You can docker export it to investigate bugs without affecting the production running container, giving you an instant local dev environment as needed. - When you inevitably need to update python you can just spin up a new VM with the same port mapping on Python 3.14 or whatever and just create an API internally to communicate, the two containers can share resources but run different python versions. How do you handle this with your solution in 4 years time? - If you need to rapidly scale, your shell script could work fine, I'll give you that. But probably it takes 2 minutes to start on each VM. Do you want a 2 minute wait for your autoscaling? No you want a docker image / AMI that takes 5 seconds for AWS to scale up if you "hit it big".
- bob1029 2y agoI think a lot of (justifiable) Docker use comes out of being forced to use other tools & ecosystems that are fundamentally messy and not really intended for galactic-scale enterprise development. I have found that going all-in with certain language/framework features, such as self-contained deployments, can allow for really powerful sidestepping of this kind of operational complexity. If I was still in a situation where I had to ensure the right combination of runtimes & frameworks are installed every time, I might be reaching for Docker too.
- tcgv 2y ago> why use Docker at all? We have a simple cloud infrastructure. Last year, we moved all our legacy apps to a Docker-based deployment (we were already using Docker for newer stuff). Nothing fancy—just basic Dockerfile and docker-compose.yml. Advantages: - Easy to manage: we keep a repo of docker-compose.yml files for each environment. - Simple commands: most of the time, it’s just "docker-compose pull" and "docker-compose up." - Our CI pipeline builds images after each commit, runs automated tests, and deploys to staging for QA to run manual tests. - Very stable: we deploy the same images that were tested in staging. Our deployment success rate and production uptime improved significantly after the switch—even though stability wasn’t a big issue before! - Common knowledge: everyone on our team is familiar with Docker, and it speeds up onboarding for new hires.
- marcosdumay 2y agoPython, Ruby, and to a much larger extent PHP are the Docker showcase! For example, if you have a program that uses wsgi and runs on python 2.7, and another wsgi program that runs on python 3.16, you will absolutely need 2 different web servers to run them. You can give different ports to both, and install an nginx on port 80 with a reverse proxy. But software tends to come with a lot of assumptions that make ops hard, and they will often not like your custom setup... but they will almost certainly like a normal docker setup.