A sysadmin friend of mine is totally against docker and his reason is that he wants as little complexity as is needed on his systems. Complexity, he says, leads to emergent behavior.
Docker actually helps managing complexity, by putting bits and pieces, scattered on the floor and putting them into a single cardboard box.
- If you throw the box out, you know you did no harm to other boxes.
- If you change your floor, you know you didn't wipe out something useful.
- Aaand you can `git switch` to a well known state
Ofcourse it's not 100% like that, in reality you still have to have some kind of consistency on where you put your docker-compose file, Dockerfiles for all the boxes, where you mount your volumes (in some folder or scattered all over system), maybe dealing with host firewall, dealing with not-commiting secrets into git etc.
But overall, it's very positive - docker-compose is (almost) one-stop file you need to see all your references to volumes, Dockerfile, network configurations, environment files with secrets.
Containers help tame complexity, but the container itself could be run without the docker runtime, using systemd-nspawn, or run as a regular systemd service using podman.
It seems less complex to manage a bunch of systemd services than one pile of systemd services that are managed and logged one way and bunch of docker services that are managed and logged another way.
Deviation from standards is what I find to cause a lot (the most?) of problems. Complexity generally makes things more error-prone, but it tends to become less of a problem when in a well maintained system a lot of people use (someone, maybe yourself, has already had and solved a problem you're having).
If your standard is dealing with systemd units, it may make sense to make your containers conform to that (thereby deviating from the most common way of managing containers). Maybe it's what I'd do in a larger operation. For my personal use I find it the most pragmatic to just use Docker since it's reasonably well documented, has reasonably low friction in usage and is very easy to set up.
Agreed. When I'm picking "the right tool for the job", something I factor in what are the tools and languages my team knows. If my team knows JavaScript, I'm going to weigh that when I'm choosing the choice of coding languages for the next project.
Exactly, you get many of the benefits of separate boxes without some of the added complexity. Docker and containers in general can reduce complexity significantly in a lot of cases.
I can deploy service/app on my local machine, including dependencies, along with other independent services/apps.
So, I can reuse what I have for production. But ofcourse, local development stuff will have different env variables, some docker-compose etc.
But it is a joy, when you can:
1. git clone something
2. set some env variables
3. docker-compose up -d
And your app, along with database, elasticsearch, whatnot - is running
So for development purposes it really helps. For deployment purposes - if that box is dedicated to something, then yeah, many of the good use cases not necessary.
I agree with this. I work on a very large platform and the cost of complexity like this is immense. It’s a not insignificant measurable loss versus not using docker and kubernetes. We’d have been better off using flat EC2 instances for everything and not incurring the packaging complexity, the repository management complexity, the pipeline complexity and the extreme staffing cost to keep multiple large kubernetes clusters running and understood.
Even container security and compliance around it is a measurable loss on its own which is trivially solved if you have bare EC2 instances and a patch cycle.
Although Docker may be another layer, from sysadmin point of view containers are not very complex. What I absolutely love about containers is that it shifts the responsibility of making the software run back to the developers. No more ridiculous installation requirements and long winded instructions just to get something going. Just start container, maybe add some mount volumes and env variables for configuration, boom, done. Way less complicated to set up and manage containers than having to learn what each piece of software does special just to get it going.
Complexity is just another part of natural systems. It's not something to be avoided for it's own sake, in as much as we should avoid having eyeballs, because they are crazily complex. Yet we tend to like ours and find them worth whatever cost they incur.
The emergent behavior of containerization has had an overall positive effect, even if it has annoying costs.
> Many websites were better in 2005 and had greater uptime.
Citation needed. There were a lot less sites, maintenance windows in the hours weren't uncommon, there was no security to speak of (SQL injections, no SSL/TLS, etc.), and sites could do maybe 1% of what today's sites can (not saying that all of it is good or necessary, bit i quite like a non-insignificant amount of those new features like native video, audio, graphics, dynamism, etc.).
It's quite noticeable tbh. Nowadays companies don't care about actual reliability, they only care about "apparent reliability", which is a bullshit statistic, and it shows.
We can now push 15 different apps to prod on the same server with completely different base distributions and dependencies, and they'll run the same as they did on a dev's laptop. The apps & servers don't crash as much as they used to when the app or packages would break on an update, and somebody had to juggle actual dependencies or run separate VMs or physical servers to run all those apps, and the configuration management that used to hose the box when it was misconfigured now no longer exists. The site is much more reliable now, and more dynamic, as it can be updated more frequently with random tech.
When was the last time you saw a weekly "Our website is down for maintenance for the next 2 days" message, other than for some government website still running COBOL on a mainframe? When was the last time you saw 500 errors? Used to be a daily thing.
You would have to be running this specific kernel version and one of your containers has to memory-map a file (not from a volume?), from what I understand.
Docker hasn't solved any problem for me, so I don't see any use in using it. Meanwhile I have multiple junior devs asking me docker stuff so they can run stuff localy. When I ask them why even use docker, they always say that some tutorial told them to.
This is when I introduce them to something called VirtualBox and then their eyes go bright with wonder on how simple that works.
> I introduce them to something called VirtualBox and then their eyes go bright with wonder on how simple that works.
Well, If I'd have a workhorse with loads of RAM... I'd still choose docker, because how FAST it starts/restarts. And because it is easy to recreate everything with docker - a VM may get messy when installing stuff for APP #1, #2, #x, "works on my machine!" etc.
Is it really? Windows have .exe files, macOS has .app files, Linux has .AppImage (or even tarballs with binaries), and that's just on the host level. Java has .jar files, and so on.
Not to mention, if you want to "natively" pack something for Windows and macOS, containers won't even solve that problem, as they only run on Linux. Only reason you can use Docker on macOS is because of virtualization.
Mac .app files are not just binary (MACH-O), they can include libraries, "frameworks", etc that will override what's loaded from the system. AppImage is even worse [1]. .exe are usually setup with an installer that trigger the side-by-side assembly mechanism, pretending that the system is using the version of the libraries that you included (and growing your WinSXS folder forever). JAR files usually include all their required transitive dependencies rather than "dynamic linking" with other JARs.
A software container is a bit more than a binary or a software package. It also includes the dependencies and the required files. It’s not only a .jar but a .jar with a compatible JVM with the compatible dependencies.
I don’t think that it uses virtualisation on windows or Mac is very bad. I think that it’s an advantage for simplicity that everything is Linux (I pretend that windows containers do not exist).
I don't do much by way of containers myself¹ but some teams in DayJob do and some other contact also. Some run containers in VMs² to separate out some of the complexity due to boot bugs like this - there is a little performance hit from the VM but failures in the container parts of the kernel can't cause the whole machine not to boot so it is easier to get in to revert things back to a last-known-good state.
----
[1] I have a couple of bits running via LCX but otherwise use VMs to split services out
[2] One large VM running many containers³, or sometimes a couple of VMs, perhaps separating them performance-wise across drives or with CPU core affinity where that was/seemed easier, or just so in case of disaster they could concentrate on getting the higher priority VM+containers restored and back up first.
[3] Obviously one VM per container would defeat the container benefits, though I've seen this done where docker was the only officially supported install option and they wanted to run a service in a VM.
Interestingly solutions like docker csn also make the system less complex. With CoreOS you get an operating system reduced to the bare bones just for running containers, there‘s a lot less complexity if your os is only designed to run containers and nothing else.
- If you throw the box out, you know you did no harm to other boxes.
- If you change your floor, you know you didn't wipe out something useful.
- Aaand you can `git switch` to a well known state
Ofcourse it's not 100% like that, in reality you still have to have some kind of consistency on where you put your docker-compose file, Dockerfiles for all the boxes, where you mount your volumes (in some folder or scattered all over system), maybe dealing with host firewall, dealing with not-commiting secrets into git etc.
But overall, it's very positive - docker-compose is (almost) one-stop file you need to see all your references to volumes, Dockerfile, network configurations, environment files with secrets.