14 ms·

The Curse of Docker

204 points by sklargh 3y ago

leonheld 3y ago
> Anyway, what I really wanted to complain a bit about is the realm of software intended to be run on servers. Okay. > I'm not sure that Docker has saved me more hours than it's cost I'm not sure what's the alternative for servers here. Containers have certainly saved me of a lot of headache and created very little overhead. N=1 (as it seems to be the OP). > The problem is the use of Docker as a lowest common denominator [...] approach to distributing software to end users. Isn't the issue specific for server use? Are you running random images from the internet on your servers? > In the worst case, some Docker images provide no documentation at all Well, in the same vein as my last comment, Docker is not a silver bullet for everything. You still have to take care of what you're actually running. Honestly the discussion is valid, but I think the OP aimed at "the current state of things" and hit a very valuable tool that doesn't deserve some of the targeted cristicism I read here. edit: my two cents for those who cannot bother and expect just because it's a container, everything will magically be solved: use official images and those from Bitnami. There, you're set.
- viraptor 3y ago
  > I'm not sure what's the alternative for servers here. Nixos/nixpkgs: isolated dependencies / services, easy to override if needed, configs follow relatively consistent pattern (main options exposed, others can be passed as text), service files can do isolation by whitelisting paths without going full-blown self-contained-os container. > Are you running random images from the internet on your servers? Many home server users do this. In business use, unless you invest lots of time into this, a part of your services is still effectively a random image from the internet. > and those from Bitnami Yes, that's a random image from the internet.
  - blackoil 3y ago
    > Yes, that's a random image from the internet. By that definition, you are running it on a random OS, random processor with some random network infra.
    - viraptor 3y ago
      Kinda. It depends what your risk tolerance is. But seriously, what's your business relationship to bitnami? What are the guarantees about keeping those images up to date? What are the guarantees about the feature set provided? How long will the specific image be available publicly/free? Is the base system guaranteed to stay the same? What about architecture support?
    - TeMPOraL 3y ago
      I mostly agree with GGP, but GP has a point. I'm a semi-frequent users of Docker at work and personally, and I still don't know what the fuck "Bitnami" is. I'm gonna guess now (and check later) they're probably some corporate body that fell out of whatever kerfuffle happened with Docker licensing a year or so ago; but otherwise, "Bitnami" sounds to me like "Bincrafters" from Conan/C++ world - no fucking clue who they are (the name doesn't help), but everyone sure likes to depend on what sounds like a random third party.
  - patrick451 3y ago
    It's always been surprising to me how little people seem to care about the provenance of their images. It's even more surprising that infosec isn't forcing developing to start their images `FROM scratch`.
    - w-ll 3y ago
      Are you compiling you os distro's `FROM scratch`? Ther's always a certin level of trust, and for many, docker containers are just as trusty as distros from trusty orgs or volunteers.
      - patrick451 3y ago
        > Are you compiling you os distro's `FROM scratch`? As a matter of fact, yes.
      - rnimmer 3y ago
        There once was a man named Terry Davis...
        w-ll 3y ago
        I imagine anyone with a BA in CS has wrote a OS from scratch. How many systems on chips are in a moderen computer, not the main system and cpu, but every little chip and controller, the boot system, every board seems to have a little OS. In regards to security, its all about analysing risk and trade-offs. For me using containers from known vendors is a risk im willing to take.
        viraptor 3y ago
        > I imagine anyone with a BA in CS has wrote a OS from scratch. Not even close. Very few courses require anything that advanced and only some of those are non-optional.
        jdwithit 3y ago
        Or for a less out-there example, Ken Thompson's classic "Reflections on Trusting Trust". At some point unless you are literally producing all of the hardware and software yourself you have to trust someone. The challenge is figuring out where that line of acceptable risk lies for you. It's going to be very different for an indie game dev vs a FinTech company vs the US DoD.
- alexey-salmin 3y ago
  > Isn't the issue specific for server use? Are you running random images from the internet on your servers? Well exactly, there's what the author is writing about. The whole article is dedicated to the problem of Docker being used as a distribution method, that is as a replacement for say Debian package. So in order to use that software you need to run a Docker image from the internet which is open poorly made and incompatible with your infrastructure. Had a package been available you'd simply do "apt-get install" inside your own image built with your infrastructure in mind.
- pointlessone 3y ago
  > use official images and those from Bitnami In other words, random images from the internet. > You still have to take care of what you’re actually running. This is the central thesis of OP, though. Pre-made/official images are not very good and docker in general doesn’t provide any means to improve/control quality.
owyn 3y ago
There are a lot of use cases for docker, I think this is complaining about a few specific things in more complex applications that probably shouldn't be deployed that way because you're not just exposing port 80, it's a whole tool deployed to end users, like an appliance. But that's not my primary use case for Docker. For me, the best thing about Docker is that it's brought the average developer experience from "oh, I think I have an install.sh for that around somewhere" to mostly repeatable builds that are mostly self documenting. Any time a tool is self documenting it's a win. If you want the cake, you have to write down the recipe. That's huge. It's forcing lazy devs (which we all are) to just write it down. At this point the amount of "weird bearded guy tribal knowledge" that is now documented in a Dockerfile somewhere is a treasure trove. Things still break all the time for a million dumb reasons but as a least common denominator it's a great place to start. It's not a solution for everything and it sounds like that's what this article is about. Docker+Compose is not great for everything, so don't use it for those situations. But it's so much better than what was before.
- Onawa 3y ago
  Without reading the article, I would also agree that Docker has made things better for me rather than worse. If someone else spent the effort to create a Dockerfile for their app, it will reduce the amount of issues I have trying to deploy it greatly. At least at that point they have figured out the majority of dependencies required to run their app, then I only have to troubleshoot the details rather than starting from scratch for whatever server distribution that I'm running it on.
- __MatrixMan__ 3y ago
  > mostly repeatable builds that are mostly self documenting "Mostly" is going a bit far there. If you want those things you should use nix to build your docker images, but you're going to have to want them pretty badly.
ycombinatrix 3y ago
>Doing anything non-default with networks in Docker Compose will often create stacks that don't work correctly on machines with complex network setups. I run into this often. Docker networking is a mess.
- j45 3y ago
  Depending on the load and use case, encapsulating docker itself in an lxc container or a standalone vm can be a semi maintainable and separated solution.
  - heatmiser 3y ago
    I like this approach for running multiple services on customer servers/clouds. for my own cloud though, i'll use some orchestrator that makes sense
    - j45 3y ago
      Thanks. I'd be interested to learn what direction your orchestrator search goes in. My thought usually is how to make any environment the equivalent of an appliance and require as little upkeep as possible. I have been contemplating how Terraform may be able to sit in a private/hybrid cloud design, but haven't looked into it much.
  - NorwegianDude 3y ago
    Docker in lxc is also a huge mess when it comes to storage drivers with some backends...
    - j45 3y ago
      I appreciate the heads up on this in case I run into it. If you have any examples of what to look out for it would be great to know if it hits my use case
- kobalsky 3y ago
  you are not using podman right? the only implementation to give me headaches on the networking side
Timber-6539 3y ago
While the article makes some good valid points about docker's shortcomings, it is full of strong assertions made entirely from the author's blind spots. Comes off as a boomer rant more than anything.
- henriquez 3y ago
  How’s this for a boomer rant. I never used Docker because in my day we didn’t use virtual machines. We FTP’ed files to the PHP server, on port 21. Somewhere along the way all these Gen-Z kids started writing GraphQL APIs in TypeScript transpiled Cofee’node and pushing the Docker VMs to the Nomad Kubernetes Azure. I didn’t read the article but the curse of Docker is that kids think they’re better than me. After all I’ve accomplished! I had to buy a 165hz monitor to keep up with them in Counter Strike: Go, and my cholesterol is at an all time max.
  - Timber-6539 3y ago
    What those kids probably did that you few admins couldn't while using "your" FTP and other antiquated tools, was to reduce the friction for anyone who wanted to maintain a server. Embrace new technology or be left behind. I can't think of anything in the past decade that has made more strides in software distribution than docker has.
    - otabdeveloper4 3y ago
      Administering a server full of random docker-compose.yml's downloaded from the Internet is a nightmare. We got rid of Docker from all our production servers. Docker is technical debt in box.
      - seec 3y ago
        My experience exactly. I honestly don't know how someone can think that Docker is a solution to anything. At best it's a shortcut for the lazy and incompetent but it doesn't lead to a bright future. Of course, the people setting up this kind of crap are never really responsible for actually maintaining the thing properly so they don't have to care. Of and it creates a lot of job positions that are kind of interchangeable regardless of actual competency. The whole thing is a poor attempt at Fordism for software development.
cyrnel 3y ago
> Making things worse, a lot of Docker images try to make configuration less painful by providing some sort of entry-point shell script that generates the full configuration from some simpler document provided to the container. I see this as the container world reinventing the wheel of reasonable defaults for software that has long since lost sight of that. Nginx and Apache are two of the worst offenders, which won't just serve files out of a directory without a few dozens lines of config.
teddyh 3y ago
In the old days, the age-old cry of the beleaguered developer was “My code isn’t buggy, it works on my machine!”, to which the response was “We’re not shipping your machine to the customer!”. Well, science marches on, and we’ve invented a way to do exactly that. Instead of, you know, writing actually robust and simple-to-deploy software. See also: <https://blog.brixit.nl/developers-are-lazy-thus-flatpak/ https://blog.brixit.nl/developers-are-lazy-thus-flatpak/>
- viraptor 3y ago
  > Instead of, you know, writing actually robust and simple-to-deploy software. This is unfortunately much harder to do than doing docker images. If you're trying to ship a robust and simple to deploy app, you will fail at some point - you just haven't seen a system where that happens yet. You can't be robust vs unknown unknowns and what a system will look like in a couple of years (next LTS) can be very surprising.
  - teddyh 3y ago
    Hacking on some code and making random changes until it works (”It works! Ship it!”) is much easier (or at least feels easier) than designing the code carefully and using tests to verify the correctness of our code. Yet for good reasons we do it the harder way. For mostly the same reasons, I’m very wary of a system image of some pre-installed software instead of packaged software which is meant to run in a variety of environments, and to be easily configured to do so. Note also that a system which is robust and adaptive to different environments today is also robust to different future environments. And nobody can escape the march of time. Everybody needs updates. TLS updates. Time zone updates. Security fixes. I’d rather have a system designed with robustness against differences as a primary concern than a system where it’s assumed that it will run in an unchanging static universe.
    - pas 3y ago
      but it is much easier to test something in a container, and even to update everything in a container "fearlessly". simply considering that we had untouchable, unreproducible and totally undocumented servers running for years in basements/cabinets as a meme (classic anecdote, common experience) can allow us to infer that laziness is not inherent to containerization
chasil 3y ago
The original method to distribute library- independent software was "cc --static" née "cc -s"... The world was a much simpler place so long ago.
- mianos 3y ago
  Or use applications in golang. Not a user myself, but all the stuff like vault and such are just an executable. What is even funnier is go apps tend to have the simplest containers, for example kaniko seems to be a go app kaniko as init and nothing else. One could also argue that apps that mandate running in docker probably have some ridiculous dependency issues or too clever by half runtime.
- imtringued 3y ago
  It wasn't because the C compiler has to generate the dependency tree for every compilation unit which then needs to be included into the Makefile.
linuxrebe1 3y ago
99.9% of the problems you spoke to, which are very real. Could be solved if people building the software would just understand one thing. A container is not a mini VM. It is not in any way shape or form a virtual machine. If what you need is a lightweight virtual machine. Build that. Do not build a container because it's the latest and greatest buzzword. But instead I see large monolithic applications, shoved into a container, and then I hear a multitude of complaints about performance issues ETC. You may be able to drive a nail with a screwdriver but it's not a good idea.
- v3ss0n 3y ago
  Only applies to docker. LXC for example designed container like a VM
theden 3y ago
>One of the great sins of Docker is having normalized running software as root. Yes, Docker provides a degree of isolation, but from a perspective of defense in depth running anything with user exposure as root continues to be a poor practice. >Perhaps one of the problems with Docker is that it's too easy to use If you've ever had to make a nonroot docker image (or an image that runs properly with the `--read-only` flag), it's not as trivial and fast to get things going—if it was default, perhaps docker wouldn't have been so successful in getting engineers of all types and levels to adopt it? It's rare to find tooling in the DevOps/SRE world that's easy to just get started with productively, so docker's low barrier to entry is an exception IMO. Yes, the downside is you get a lot of poorly-made `Dockerfiles` in the wild, but it's also easy to iterate and improve them, given that there's a common ground. It's a curse I suppose, but I'd rather have a well-understood curse than the alternative being an arbitrary amount of bespoke curses.
- numbsafari 3y ago
  Running all your software as root is the IT equivalent of sales guys slapping themselves on the back for selling something for free. It’s all fun and games until the bills come due.
charcircuit 3y ago
>Consider Windows: the operating system's most alarming defect in the eyes of many "Linux people" is its lack of package management Windows has WinGet.
- Xeamek 3y ago
  WinGet isn't really a package manager. Package manager role is, well, managing packages. WinGet is just a repo with installers of the programs listed, but dependency managing and installation it self is handled by the installers, not winget. (Don't know if the ms-store package format isn't exception to that, but still)
  - charcircuit 3y ago
    >WinGet isn't really a package manager. Microsoft literally calls it along with some complementary services the "Windows Package Manager" >Package manager role is, well, managing packages. Which is what it refers to what it is managing. >but dependency managing and installation it self is handled by the installers The package manifest is allows for dependencies on other packages.
    - Xeamek 3y ago
      That's great that microsoft calls it that, but that doesn't really matter. Winget is just as much a package manager, as the "add or uninstall apps" tab in windows settings is. It's just a interface. But the actual act of installing is done by different program.
jrm4 3y ago
Did the author say anything actually negative about Docker? All I saw was "Docker can be suboptimal" but nothing to suggest that it has been anything other than at least a partial improvement?
kapitanjakc 3y ago
Docker containers and images have saved me a lot of shipping pain in web part. I haven't come across them being used as package manager or distributors yet.
isoprophlex 3y ago
Clearly we need another layer between the host and the docker-compose spaghetti. Some lightweight (true, no docker-in-docker bs) VM that exists to lock up & let whatever is in those yamls kick and scream around. I wish I knew if I am being sarcastic here...
Xeamek 3y ago
The curse of docker is that it allows devs to be lazy and rather then making sure their configuration and deployment are straightforward, they get to keep all their mess working (longer). Ofcourse, if you have really complex setup docker is invaluable. But if all you are using it is to make the depreciation warnings go away on your single executable app, that's just abuse of the tool for the wrong reasons
patrick451 3y ago
His points about networking and the file system are spot on. It still blows my mind that the default user in a container is root and that dealing with the UID issue is such a pain. The only solutions I have seen can only be described as hacks.
notatoad 3y ago
Dockerfiles are really really simple. they do essentially three things: set a base image, set environment variables, and run scripts. and then as sort of a meta-thing, they prove that the steps in the dockerfile actually work, when you start the docker container and see that it works. if you don't want to run in docker, a dockerfile is still a perfect setup script. open it up and see what it does, and use that as install instructions.
- jamesgeck0 3y ago
  I’ve debugged project Dockerfiles to discover that they were pulling dependencies from URLS with “LATEST” in them. A Dockerfile isn’t really proof that anything currently works.
carl_sandland 3y ago
what about AWX then? it moved from shipping as a simple docker compose to a kubernetes operator! I'd much rather it didn't.
eviks 3y ago
Has any great design been invented that isn't tied to hardcoded paths preventing multiple versions of the same library and would allow easy linking to any version? Nix? Anything else?
- colordrops 3y ago
  Yes, Nix. And it works great.
deleted 3y ago
[deleted]
eviks 3y ago
Has any great design been invented that isn't tied to hardcoded paths preventing multiple versions of the same library etc and would allow easy linking to any version? Nix? Anything else?
- nusmella 3y ago
  I don't know if this is normal or if anyone else does it but I usually either download binaries or compile from source and move the executable to /usr/local/bin/ and create a symlink. Lets me easily switch between versions. I avoid using a package manager for anything where I want control over the version and installation. - curl -fSLJO $RELEASE - tar xvf $DOWNLOAD.tar.gz && cd $DOWNLOAD` - make . - mv $EXECUTABLE /usr/local/bin/$EXECUTABLE-$VERSION` - ln -s /usr/local/bin/$EXECUTABLE-$VERSION /usr/local/bin/$EXECUTABLE - # chmod 750, chown root:$appuser, etc Works great for everything I've tried thus far. Redis, HAproy, Prometheus exporters, and many more.
- oddmiral 3y ago
  Yes, these "great designs" are invented at a constant rate. I saw about 30 of them, or 1 per year at average. For example, Fedora invented and then abandoned modular design recently.
zaptheimpaler 3y ago
Nah docker is excellent and far far preferable to the standard way of doing things for most people. All the traditional distribution methods have barely even figured out how to uninstall a piece of software. `apt remove` will often leave other things lying around. He complains about configuration being more complex because its not a file? Except it is, and its so much simpler to just have a compose file that tells you EXACTLY which files are used for configuration and where they are. This is still not easy in normal linux packages. You have to google or dig through a list of 10-15 places that may be used for config.. The other brilliant opinion is that docker makes the barrier to entry for packaging too low.. but the alternative is not those things being packaged well in apt or whatever, its them not being packaged at all.. this is not a win. Whats the alternative to running a big project like say Sourcegraph through a docker compose instance? You have to get set up ~10 services yourself including Redis, Postgres, some logging thing blah blah. I do not believe this is ever easier than `docker compose up -d`. And if you want to run it without docker, the docker images are basically a self-documenting system for how to do that. This is strictly a win over previous systems, where there generally just is no documentation for that. Personally docker lowers the activation energy to deploy something that I can now try/run so many complex pieces of software so easily. I run sourcegraph, nginx, postgres, redis on my machine easily. A week ago I wanted to learn more about data engineering - got a whole Apache Airflow cluster setup with a single compose file, took a few minutes. That would have been at least an hour of following some half-outdated deploy guide before so I just wouldn't have done it. --- The beginning of the post is most revealing though: > The fact that I have multiple times had to unpack flatpaks and modify them to fix dependencies reveals ... Still, these systems work reasonably well, well enough that they continue to proliferate... Basically you are okay with opening up flatpaks to modify them but not opening up docker images.. it just comes down to familiarity.
- hinkley 3y ago
  I just found about a half a gigabyte of files from programs I uninstalled two laptops ago on my machine, and files from a Steam game I got a refund for because it would crash after fifteen minutes. It’s frustrating.
- angarg12 3y ago
zubairq 3y ago
Having worked at Red Hat and worked on many Docker / Kubernetes systems I agree with some parts of the article, but my view is that the wrold is going through a transition phase right now of moving to containerised systems. Take for example running something like 3Scale (an internet gateway) in Docker or Kubernete. It can be a nightmare to configure and run 3Scale using containers with the multiple memory limits and other container specific issues. Far easier to get 3Scale running without containers. So many software systems were not designed in the Docker era, and going forward many container applications will be designed to be easier to configure/use in the Container world due to a "Container/Docker native" mindset when designing the system in the first place
defanor 3y ago
Docker keeps reminding me of people in the past shipping VM images, or sometimes physical machines, often with rather inappropriate desktop hardware and software. So do these points: > The problem is the use of Docker as a lowest common denominator, or perhaps more accurately lowest common effort, approach to distributing software to end users. Shipping physical machines probably is even lower than that though. Or even the VMs. > One of the great sins of Docker is having normalized running software as root. I am not as familiar with Docker practices, but unfortunately, AFAICT, people did that frequently on regular systems as well, just to not bother with permissions. (Edit: now I recalled people also not following the FHS and storing things in the root directory inside Docker images, but sometimes it was/is similar without containers as well, and inside a container it does not clutter the host system, at least). > Having "pi" in the name of a software product is a big red flag in my mind, it immediately makes me think "they will not have documented how to run this on a shared device." This approach is similar to shipping physical machines. Or at least maintaining odd legacy software on a dedicated machine. I think a rather pessimistic view is that proper packaging switched to Docker or single-purpose machines, but an optimistic one is that those are the unnecessary VMs and larger single-purpose machines that were replaced by Docker and RPi. Maybe there is a little of both going on.
- ungamedplayer 3y ago
  >AFAICT, people did that frequently on regular systems as well, just to not bother with permissions. This was an easy way to tell if you were dealing with a Muppet. If you saw this you would know that the software was going to be a problem.
alexey-salmin 3y ago
I think most of the comments here largely miss the point of the article. The guy doesn't complain about docker as a whole and doesn't criticise it's usage for software deployment which normally is the main application. He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. So in order to use that software you need to run a Docker image from the internet which is often poorly made and is incompatible with your infrastructure. Had a package been available you'd simply do "install" inside your own image built with your infrastructure in mind. With that I agree completely. Docker and worse even docker-compose are terrible ways of software distribution and should never be used except for demos and for rare cases where software is not distributed to the customer in the normal sense but rather directly deployed into his system. Docker and docker-compose are still very good methods of software deployment.
- turtlebits 3y ago
  I have rarely seen end user software being distributed as a docker image, only server applications. Occasionally I see CLI tools that are hard to package available as docker images, but those are generally done because the maintainer hasn't provided precompiled binaries.
- solatic 3y ago
  This, but I want to add, I think the root cause is less due to the ease of writing a Dockerfile vs writing a deb, rpm, etc. and more due to the low cost of hosting. Whatever low-quality Dockerfile you write, you can sign up on Docker Hub, build and push there, and you're done. GitHub Packages doesn't support deb or rpm, and anyway for better or for worse, packages are tightly coupled to the distribution they're packaged for. That means either getting your package into the package repository of each distribution you want to target, or hosting your own package repository, which is non-trivial in both financial and labor cost. Docker has a lot more crap, but it did dramatically lower the barrier of entry, which is a good thing. The proper response isn't to bemoan the lower barrier of entry, but to attempt to lower the barrier of entry of traditional packaging.
- cderpz 3y ago
  >He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. If that is a valid complaint, why does he choose two examples where that is not the case? Nextcloud AIO is just one option among many and certainly not the "standard way" of hosting your nextcloud instance. Coincidentally I came from hosting nextcloud the "standard way" and I'm really glad AIO exists and I don't have to manage nonsense like nextcloud ending support for the latest Debian php version. And Home Assistant is mainly distributed as the OS variant with the docker version being the step child afterthought that barely functions.
bakugo 3y ago
I sympathize with pretty much everything in this article, in particular the configuration/filesystem pains. I can't remember the last time I tried to get a file or folder into or out of a container without running into some sort of issue, usually involving permissions, and I feel like there really should be a better solution for this.
what-the-grump 3y ago
These sorts of things usually take longer to get working than equivalent software distributed as a conventional Linux package or to be built from source. Yes, but they are done once, and forced to ship the docker image. The stupid amount of time we've spent looking for that one package dependency because someone forgot that they installed something to make a project work... Or the classic we setup SSL, no one knows how they setup SSL once they are done, etc. Docker forces a lot of the infrastructure decisions that devs make in their sandbox to be actually well defined. Not that it makes their choices any more sane, safer, secure. At least someone can take a look at the mess and replicate it, as many time as they want, quickly, break it, fix it, upgrade it, without ever requesting a dev VM build, having sysops install preqs, etc. Is docker work? Everything is work. Do I think docker should be the default go to? No I'd like for people to use app services and simply perform the build on the app node, but that magic is even harder to debug and troubleshoot.
steve1977 3y ago
It seems to me that many of the points in the article are not really problems with Docker, but problems with Linux. I.e. the way Linux handles multiple versions of libraries and of course the fragmentation hell that is Linux distributions. Docker then is just a bandaid for these problems.
- oddmiral 3y ago
  Linux (kernel) can run any libraries in any combination. You are talking about distributions. Support for multiple versions of a library is not a goal for a typical distribution. Typically, this is necessary for commercial software vendors, which have money to throw at the problem. If commercial software vendors needs this so badly, they can sign a support contract with distributor, so a dedicated team of maintainers will care about this problem with libraries for them. In the open-source world, it's an order of magnitude easier to patch the source, than introduce two versions of a same library. In rare cases, a -compat package is created, which then abandoned as soon as possible.
GabeIsko 3y ago
I can't believe what I am reading. It took you more time to set up nextcloud with docker compose? What? For my hobby stuff, I can usually try something out really quickly by giving a compose a quick read and pasting it into portainer for a test. I have my gripes with docker - especially for my professional work, and I am not a fan about how much it obscures images, nor its shibboleth approach to using a CLI-daemon interface (should be a `dockerctl` command in my mind) but I really can't believe that you would want to manually set up multi process platforms manually. When you want to connect to a data base, and have it be ephemeral? I have rooted around in enough application servers to understand that docker-compose and dockerfiles is a very sane approach. The real issue I am seeing in the comments are that people are complaining that they would prefer getting a maintained package for software. Would rather use `apt install` or `dnf install` than mess with containers. That has been discussed to death and we get the same answer is the same every time - yes that would be a nice world to live in, but it is a fantasy to imagine anyone doing that much maintenance work for packages.
rkagerer 3y ago
You know who really knows how to package software? Mark Russinovich, Nir Sofer, and all the others who gave us beautiful utililies in standalone EXE's that don't require any dependencies. For the longest time I stayed on older versions of .NET so any version of Windows since 2003 could run my software out of the box. Made use of ILMerge or a custom AssemblyResolve handler to bundle support DLL's right into my single-file tools - it wasn't hard. I have no complaints about Docker, but I do find where I used to be able to download simple zip files and place their contents into my project I now just get a black box Docker link with zero documentation and that makes me sad.
- tux2bsd 3y ago
  [dead]
- seec 3y ago
  Exactly my thoughts. The Linux guys have been discussing the merits of package management and various related systems since I started getting interested in computers. Yet after all this time they have not come close to something as simple as the double click to run .exe or self-installing binary you can find on windows (macOS also has completely self-contained apps). So having managed linux servers and relatives I'm a bit confused that we are still there, discussing the merits of stupid packaging software, that follow some sort of ideal but never actually work properly (at least, scale very badly and react poorly to changes). Everything he said about docker is true but it also applies to the regular package management in various linux distros. In the age of very fast upload bandwidth and very affordable storage, docker is even more suspicious against a regular lightweight VM. Doesn't have as good of security separation, more annoying to reproduce and required more setup; VM bit for bit copy is also extremely simple. I believe one reason we got docker is because they couldn't figure out how to partition hardware at the machine level efficiently so instead, they partitioned CPUs. Easier to manage in hardware, more of a pain in software... But the reason no user facing operating system ever uses this kind of software management is that it never works, no matter the ideals, a lot like communism. What a waste of time, I guess at least it makes for some fun discussion from time to time.
- tinus_hn 3y ago
INTPenis 3y ago
The curse of that website, it made me dizzy just scrolling. Containers are amazing, they're bigger than docker, end of story.
jillesvangurp 3y ago
I remember how things were before docker. Better is not a word I'd use for that. It sucked. Deploying software meant dealing with lots of operating system and distribution specific configuration, issues, bugs, etc. All of that had to be orchestrated with complicated scripts. First those were hand written, and later we got things like chef and puppet. Docker wiped most of that out and replaced it with simple build time tools that eliminate the need for having a lot of deploy time tools that take ages to run, are very complex to maintain, etc. I also love to use it for development a lot. It allows me to use lots of different things that I need without having to bother installing those things. Saves a lot of time. Docker gives us a nice standard way to run and configure whatever. Mostly configuration only gets hard when the underlying software is hard to configure. That's usually a problem with the software, not with docker. These days if you are building something that requires fiddling with some configuration file, it kind of is broken by design. You should design your configuration with docker in mind and not force people to have to mount volumes just so they can set some properties. The reason docker is so widespread is that it is so obviously a good idea and there hasn't been anyone that came along with something better that actually managed to get any traction worth talking about. Most of the docker alternatives tend to be compatible with docker to the point that the differences are mostly in how they run dockerized software. And while I like docker, I think Kubernetes is a hopelessly over engineered and convoluted mess.
- peanut-walrus 3y ago
  How is writing those complicated scripts but in a dockerfile or docker-compose file any better? Software written with docker in mind is easier to manage because it generally follows better design principles, such as separating configuration from state, being failure tolerant, treating the network as opaque, etc. This software would be easy to deploy without using docker as well. If you're trying to deploy some complex piece of software which doesn't follow these principles, it's exactly as hard or even harder with docker. Unless you outsource the work to random people on the internet, but then you are not building production systems. Containers are great for lots of things and containerization in general has forced developers to write better software, but there really isn't a lot of difference in difficulty in running that webapp in a container vs just running it on the machine directly.
devjab 3y ago
I think a lot of your comments here are very true. I don’t think docker made my world worse and I certainly don’t think it cost me more time, but I also sort of agree with the author. I came into Typescript late, and to “tame” the wildness of the ecosystem I set up a lot of opinionated systems for our developers. I didn’t dictate them, it was a collaborative process where we worked long and hard go agree on how we would utilise the Node ecosystem as well as the 10ish rules that we’ve changed as opposed to the “global” strict eslint rules. Rules which have themselves been born out of a decade of different rulesets like the Airbnb ones most people in the JS community will have heard of. My approach to containers has been similar. We don’t use docker-compose and never have as an example, we went with Terraform, though today we’re using Bicep, and we make heavy use of dapr side cars. Which makes working with infrastructure sort of easy. Easy to lock down and opinionate at least. You can get most templates directly from Azures GitHub, but you can obviously also build your own, and then it’s simply a matter of having some decent template projects so that your developers can be up and running in a few minutes whenever they need to start a new project. Obviously there is a cost when you’re moving legacy projects into this sort of infrastructure, but it’s not like it’s really that resource consuming if it was already containerised, and it’s not too bad even if it wasn’t. Now, that’s how we do it. It’s also how I think everyone should do it, but it’s not how you “have” to do it. In many ways, you’re as free to utilize the container ecosystems as freely as you can with the Node ecosystem. Well maybe not as free as that, but still free enough to create a lot of horror stories. Which is exactly what has happened with containers in many organisations. As such I think the author has a valid point. I’m not sure where we would go without the freedom though. Our exact setup works for us, you might not agree with our choices and neither of us would be wrong. So while some opinionated processes might be compatible with container infrastructure, others will need to remain “free”. I’m certainly with a lot of you in that it was worse before containers. I’ve also done work with organisations where container deployments worked so poorly that it was clearly not better, however, and I suspect those pipelines are far more common than given credit in this comment section.
forrestthewoods 3y ago
Unpopular Opinion: Linux got it wrong and Windows got it right. (Or at least closer to right.) Programs shouldn't use centralized dependencies. Programs should ship ALL of their dependencies. Running a program should be as simple as downloading a zip, extracting, and clicking/typing run. Docker exists because building and running software is so outrageously complex that it requires a full system image. And it turns out Docker didn't actually solve it after all!
- oddmiral 3y ago
  It's much easier to ship more than one program, with all their dependencies packaged, because of lower cost of maintenance per program/library. It is also easier to automate downloading and unpacking than do that manually for every package. If you want to try this idea, just download a Linux distribution.
  - seec 3y ago
    Doesn't that fail the minute one of your programs decides he needs a different package version or one that doesn't exist all together? It looks more efficient and easier at first, but ultimately it becomes less and less maintenable and the "dumb" inefficient approach of shipping all the things at once becomes better. It's like in real life, the more you are dependent on different peoples/incomes, the more your life becomes complicated and unlivable. Just ask someone who needs multiple jobs to survive. But we went ahead and implemented just that into software. Kinda madness...
smitty1e 3y ago
Great read. If I had to quibble, it would be with > Even if 90-day ephemeral TLS certificates and a general atmosphere of laziness have deteriorated our discipline in this regard, private key material should be closely guarded. It should be stored in only one place and accessible to only one principal. You don't even have to get into these types of lofty security concerns, though. TLS is also sort of complicated to configure. Any time there is complexity and only the One True Priest can manage it, there will be tears. There had better be a break glass solution backed by Righteous Documentation (a hypothetical substance I heard about this one time) if we are boxed in to a One True Priest situation.
- pas 3y ago
  piggybacking on this, due to the ease of getting a cert for a subdomain, basically one cert per app ... just have one cert per "compose stack" and it's perfect acceptable to run them with rootless docker-in-docker or on separate VMs to get security. the one true sacred nginx in front of everything is nice, but also has access to everything. of course, the lack of public IPv4 addresses in many homelab/selfhosted/hobbyist situations is the true forcing factor. (an gettting a wildcard cert is very easy with certbot nowdays, so I understand the lure.)
wg0 3y ago
There's no merit to this complaint about Docker that it complicates configuration. Actually it simplifies a great deal. Author should consider how configuration is at different locations and sometimes even further split differently in different distributions for the same software package (apache, PostgreSQL etc) while a docker Image has it all at a very well known location within image and it doesn't matter where you use that image.
PreInternet01 3y ago
> distributing an application only as a Docker image is often evidence of a relatively immature project Or, you know, a contractual requirement. And, as far as those go, I actually kind of like it: you ship a well-tested container, and the only thing the infra dept at the customer site has to configure-via-the-environment is the URL for (or path to, via any kind of supported file system mounted into the container, which most IT shops can still just about manage) the instance configuration file. This reduces most initial troubleshooting to "well, what does the instance log say about retrieving and parsing the configuration file?", which, trust me, is way preferable over what you get with most other deployment methods I've been involved with...
saidinesh5 3y ago
Obligatory Hitler uses Docker post: https://www.youtube.com/watch?v=PivpCKEiQOQ https://www.youtube.com/watch?v=PivpCKEiQOQ Lol @ "I'm moving everyone to Windows! Don't cry, you can run bash on Windows 10 now."
acje 3y ago
We are probably going to go around the packaging wheel until we come up with one that does first class sandboxing. Any bets on webassembly?
vortegne 3y ago
I'm a developer with pretty limited "serious" DevOps experience. I can do tweaks here and there, create some simple cloud pipelines, etc. I'm definitely not fit to set up any enterprise-grade DevOps or manage a server. I run a home server just for fun, with quite a lot of applications. Docker and images from linuxserver.io are the best thing that happened to me in this realm. I can try out new applications very quickly, I can reinstall the OS on my server and get all my things up and running in no time. Linuxserver.io images have a standardised configuration which is great. There is no way in hell I could manage to set up this many applications without Docker, set up SSL for all of this, have fancy 2FA and SSO and have it so quickly redeployable. Guess I'm the target audience for this, it has been a lot of fun tinkering in a low-friction environment that Docker has provided me with.
xg15 3y ago
> One of the basic concepts shared by most Linux systems is centralization of dependencies. Libraries should be declared as dependencies, and the packages depended on should be installed in a common location for use of the linker. This can create a challenge: different pieces of software might depend on different versions of a library, which may not be compatible. This is the central challenge of maintaining a Linux distribution, in the classical sense: providing repositories of software versions that will all work correctly together. Maybe someone with more knowledge of Linux history can explain this for me, because I never understood it: Why is it so important that there must always only be one single version of a library installed on the entire system? What keeps a distribution from identifying a library by its name and version and allowing application A to use v1.1 and application B to use v1.2 at the same time? Instead the solution of distros seems to be to enforce a single version and then to bend the entire world around this restriction - which then leads to unhappy developers that try to sidestep distro package management altogether and undermine the (very reasonable) "all software in a distro is known to work together" invariant. So, why?
- rwmj 3y ago
  For security (and general bug fixing). If a security issue is found you want to only fix it in one place. The container alternative is searching down how all the containers were built, which might be very varied and some not even reproducible, and fixing them all.
  - xg15 3y ago
    Indeed, containers suck for this: Not just do you have to look into each container separately, there is also no requirement all containers use the same structure at all, as you said. Yet this is exactly what happens in practice if the one-version-for-all paradigm is impractical for developers. So it would be in the interest of distros to give some way in that regard: Keep the centralised dependency dogma in place, but allow multiple independent versions and configurations be stored. Then bug fixing might be slightly harder than with a single version, because you might have to fix 3 versions instead of one, but still much easier than monkey-patching half a dozen containers. (It would still be good to "nudge" developers towards a canonical version, i.e. by sending them reminders when the software uses a lower version or a different configuration - or if you want even a warning that everything below a certain minimum version will be rejected)
rwmj 3y ago
One problem he doesn't mention is with the libraries / dependencies themselves. They should offer stable APIs and ABIs so that you don't have to have software that needs to depend on specific versions in the first place. Poor software development practices in certain ecosystems encourage this churn.
totallywrong 3y ago
I do DevOps and never once used Compose in my entire career. Single containers in my machine (in userspace with Podman) and Kubernetes in servers. 99% of the time there's an official Helm chart that installs any dependencies and has sane default, which you just tweak to your needs. This guy is doing it wrong.
T3RMINATED 3y ago
[dead]
CR007 3y ago
I distribute server-side software and it was a pain to provide the infra requirements. At higher level users easily miss what is yours and what's another tech, they just don't care to tell the difference. Is not a matter of documenting, is just not their concern. That drives many issues and it becomes a snowball soon as inexperienced users start to vent bad practices. In a effort to help other users they often spread more damage. With Docker I was able to take charge of the infra, which erased all the uncertainties on my next layer but it spawned the uncomfortable need of learning Docker to use my stuff, which users took very reluctant. The best distribution method is to pack a binary release. Not only the package is lightweight, it doesn't need any fancy instruction. You can keep Docker for your internal use, don't ship it to end users.
syrusakbary 3y ago
It's funny how WebAssembly can help overcome most of the issues mentioned on the blogpost (packaging, configuration, portability) if addressed properly. That's the main reason Wasmer [1] was created :) [1] https://wasmer.io https://wasmer.io
MongoTheMad 3y ago
The author needs to look into confd. I wrote about it in 2017: https://andrewwippler.com/2017/11/28/reusable-containers-with-confd/ https://andrewwippler.com/2017/11/28/reusable-containers-wit...
camgunz 3y ago
I hate Docker (honestly I can't believe the MacOS version requires a Linux emulator :rolleyes:), but it basically is the best way to run server software. The only major alternative is Nix, which might actually work out.

204 points by sklargh 3y ago

> Anyway, what I really wanted to complain a bit about is the realm of software intended to be run on servers. Okay. > I'm not sure that Docker has saved me more hours than it's cost I'm not sure what's the alternative for servers here. Containers have certainly saved me of a lot of headache and created very little overhead. N=1 (as it seems to be the OP). > The problem is the use of Docker as a lowest common denominator [...] approach to distributing software to end users. Isn't the issue specific for server use? Are you running random images from the internet on your servers? > In the worst case, some Docker images provide no documentation at all Well, in the same vein as my last comment, Docker is not a silver bullet for everything. You still have to take care of what you're actually running. Honestly the discussion is valid, but I think the OP aimed at "the current state of things" and hit a very valuable tool that doesn't deserve some of the targeted cristicism I read here. edit: my two cents for those who cannot bother and expect just because it's a container, everything will magically be solved: use official images and those from Bitnami. There, you're set.

viraptor 3y ago
> I'm not sure what's the alternative for servers here. Nixos/nixpkgs: isolated dependencies / services, easy to override if needed, configs follow relatively consistent pattern (main options exposed, others can be passed as text), service files can do isolation by whitelisting paths without going full-blown self-contained-os container. > Are you running random images from the internet on your servers? Many home server users do this. In business use, unless you invest lots of time into this, a part of your services is still effectively a random image from the internet. > and those from Bitnami Yes, that's a random image from the internet.
- blackoil 3y ago
  > Yes, that's a random image from the internet. By that definition, you are running it on a random OS, random processor with some random network infra.
  - viraptor 3y ago
    Kinda. It depends what your risk tolerance is. But seriously, what's your business relationship to bitnami? What are the guarantees about keeping those images up to date? What are the guarantees about the feature set provided? How long will the specific image be available publicly/free? Is the base system guaranteed to stay the same? What about architecture support?
  - TeMPOraL 3y ago
    I mostly agree with GGP, but GP has a point. I'm a semi-frequent users of Docker at work and personally, and I still don't know what the fuck "Bitnami" is. I'm gonna guess now (and check later) they're probably some corporate body that fell out of whatever kerfuffle happened with Docker licensing a year or so ago; but otherwise, "Bitnami" sounds to me like "Bincrafters" from Conan/C++ world - no fucking clue who they are (the name doesn't help), but everyone sure likes to depend on what sounds like a random third party.
- patrick451 3y ago
  It's always been surprising to me how little people seem to care about the provenance of their images. It's even more surprising that infosec isn't forcing developing to start their images `FROM scratch`.
  - w-ll 3y ago
    Are you compiling you os distro's `FROM scratch`? Ther's always a certin level of trust, and for many, docker containers are just as trusty as distros from trusty orgs or volunteers.
    - patrick451 3y ago
      > Are you compiling you os distro's `FROM scratch`? As a matter of fact, yes.
    - rnimmer 3y ago
      There once was a man named Terry Davis...
      - w-ll 3y ago
        I imagine anyone with a BA in CS has wrote a OS from scratch. How many systems on chips are in a moderen computer, not the main system and cpu, but every little chip and controller, the boot system, every board seems to have a little OS. In regards to security, its all about analysing risk and trade-offs. For me using containers from known vendors is a risk im willing to take.
        viraptor 3y ago
        > I imagine anyone with a BA in CS has wrote a OS from scratch. Not even close. Very few courses require anything that advanced and only some of those are non-optional.
      - jdwithit 3y ago
        Or for a less out-there example, Ken Thompson's classic "Reflections on Trusting Trust". At some point unless you are literally producing all of the hardware and software yourself you have to trust someone. The challenge is figuring out where that line of acceptable risk lies for you. It's going to be very different for an indie game dev vs a FinTech company vs the US DoD.
alexey-salmin 3y ago
> Isn't the issue specific for server use? Are you running random images from the internet on your servers? Well exactly, there's what the author is writing about. The whole article is dedicated to the problem of Docker being used as a distribution method, that is as a replacement for say Debian package. So in order to use that software you need to run a Docker image from the internet which is open poorly made and incompatible with your infrastructure. Had a package been available you'd simply do "apt-get install" inside your own image built with your infrastructure in mind.
pointlessone 3y ago
> use official images and those from Bitnami In other words, random images from the internet. > You still have to take care of what you’re actually running. This is the central thesis of OP, though. Pre-made/official images are not very good and docker in general doesn’t provide any means to improve/control quality.

owyn 3y ago

There are a lot of use cases for docker, I think this is complaining about a few specific things in more complex applications that probably shouldn't be deployed that way because you're not just exposing port 80, it's a whole tool deployed to end users, like an appliance. But that's not my primary use case for Docker. For me, the best thing about Docker is that it's brought the average developer experience from "oh, I think I have an install.sh for that around somewhere" to mostly repeatable builds that are mostly self documenting. Any time a tool is self documenting it's a win. If you want the cake, you have to write down the recipe. That's huge. It's forcing lazy devs (which we all are) to just write it down. At this point the amount of "weird bearded guy tribal knowledge" that is now documented in a Dockerfile somewhere is a treasure trove. Things still break all the time for a million dumb reasons but as a least common denominator it's a great place to start. It's not a solution for everything and it sounds like that's what this article is about. Docker+Compose is not great for everything, so don't use it for those situations. But it's so much better than what was before.

Onawa 3y ago
Without reading the article, I would also agree that Docker has made things better for me rather than worse. If someone else spent the effort to create a Dockerfile for their app, it will reduce the amount of issues I have trying to deploy it greatly. At least at that point they have figured out the majority of dependencies required to run their app, then I only have to troubleshoot the details rather than starting from scratch for whatever server distribution that I'm running it on.
__MatrixMan__ 3y ago
> mostly repeatable builds that are mostly self documenting "Mostly" is going a bit far there. If you want those things you should use nix to build your docker images, but you're going to have to want them pretty badly.

ycombinatrix 3y ago

>Doing anything non-default with networks in Docker Compose will often create stacks that don't work correctly on machines with complex network setups. I run into this often. Docker networking is a mess.

j45 3y ago
Depending on the load and use case, encapsulating docker itself in an lxc container or a standalone vm can be a semi maintainable and separated solution.
- heatmiser 3y ago
  I like this approach for running multiple services on customer servers/clouds. for my own cloud though, i'll use some orchestrator that makes sense
  - j45 3y ago
    Thanks. I'd be interested to learn what direction your orchestrator search goes in. My thought usually is how to make any environment the equivalent of an appliance and require as little upkeep as possible. I have been contemplating how Terraform may be able to sit in a private/hybrid cloud design, but haven't looked into it much.
- NorwegianDude 3y ago
  Docker in lxc is also a huge mess when it comes to storage drivers with some backends...
  - j45 3y ago
    I appreciate the heads up on this in case I run into it. If you have any examples of what to look out for it would be great to know if it hits my use case
kobalsky 3y ago
you are not using podman right? the only implementation to give me headaches on the networking side

Timber-6539 3y ago

While the article makes some good valid points about docker's shortcomings, it is full of strong assertions made entirely from the author's blind spots. Comes off as a boomer rant more than anything.

henriquez 3y ago
How’s this for a boomer rant. I never used Docker because in my day we didn’t use virtual machines. We FTP’ed files to the PHP server, on port 21. Somewhere along the way all these Gen-Z kids started writing GraphQL APIs in TypeScript transpiled Cofee’node and pushing the Docker VMs to the Nomad Kubernetes Azure. I didn’t read the article but the curse of Docker is that kids think they’re better than me. After all I’ve accomplished! I had to buy a 165hz monitor to keep up with them in Counter Strike: Go, and my cholesterol is at an all time max.
- Timber-6539 3y ago
  What those kids probably did that you few admins couldn't while using "your" FTP and other antiquated tools, was to reduce the friction for anyone who wanted to maintain a server. Embrace new technology or be left behind. I can't think of anything in the past decade that has made more strides in software distribution than docker has.
  - otabdeveloper4 3y ago
    Administering a server full of random docker-compose.yml's downloaded from the Internet is a nightmare. We got rid of Docker from all our production servers. Docker is technical debt in box.
    - seec 3y ago
      My experience exactly. I honestly don't know how someone can think that Docker is a solution to anything. At best it's a shortcut for the lazy and incompetent but it doesn't lead to a bright future. Of course, the people setting up this kind of crap are never really responsible for actually maintaining the thing properly so they don't have to care. Of and it creates a lot of job positions that are kind of interchangeable regardless of actual competency. The whole thing is a poor attempt at Fordism for software development.

cyrnel 3y ago

> Making things worse, a lot of Docker images try to make configuration less painful by providing some sort of entry-point shell script that generates the full configuration from some simpler document provided to the container. I see this as the container world reinventing the wheel of reasonable defaults for software that has long since lost sight of that. Nginx and Apache are two of the worst offenders, which won't just serve files out of a directory without a few dozens lines of config.

teddyh 3y ago

In the old days, the age-old cry of the beleaguered developer was “My code isn’t buggy, it works on my machine!”, to which the response was “We’re not shipping your machine to the customer!”. Well, science marches on, and we’ve invented a way to do exactly that. Instead of, you know, writing actually robust and simple-to-deploy software. See also: <https://blog.brixit.nl/developers-are-lazy-thus-flatpak/ https://blog.brixit.nl/developers-are-lazy-thus-flatpak/>

viraptor 3y ago
> Instead of, you know, writing actually robust and simple-to-deploy software. This is unfortunately much harder to do than doing docker images. If you're trying to ship a robust and simple to deploy app, you will fail at some point - you just haven't seen a system where that happens yet. You can't be robust vs unknown unknowns and what a system will look like in a couple of years (next LTS) can be very surprising.
- teddyh 3y ago
  Hacking on some code and making random changes until it works (”It works! Ship it!”) is much easier (or at least feels easier) than designing the code carefully and using tests to verify the correctness of our code. Yet for good reasons we do it the harder way. For mostly the same reasons, I’m very wary of a system image of some pre-installed software instead of packaged software which is meant to run in a variety of environments, and to be easily configured to do so. Note also that a system which is robust and adaptive to different environments today is also robust to different future environments. And nobody can escape the march of time. Everybody needs updates. TLS updates. Time zone updates. Security fixes. I’d rather have a system designed with robustness against differences as a primary concern than a system where it’s assumed that it will run in an unchanging static universe.
  - pas 3y ago
    but it is much easier to test something in a container, and even to update everything in a container "fearlessly". simply considering that we had untouchable, unreproducible and totally undocumented servers running for years in basements/cabinets as a meme (classic anecdote, common experience) can allow us to infer that laziness is not inherent to containerization

chasil 3y ago

The original method to distribute library- independent software was "cc --static" née "cc -s"... The world was a much simpler place so long ago.

mianos 3y ago
Or use applications in golang. Not a user myself, but all the stuff like vault and such are just an executable. What is even funnier is go apps tend to have the simplest containers, for example kaniko seems to be a go app kaniko as init and nothing else. One could also argue that apps that mandate running in docker probably have some ridiculous dependency issues or too clever by half runtime.
imtringued 3y ago
It wasn't because the C compiler has to generate the dependency tree for every compilation unit which then needs to be included into the Makefile.

linuxrebe1 3y ago

99.9% of the problems you spoke to, which are very real. Could be solved if people building the software would just understand one thing. A container is not a mini VM. It is not in any way shape or form a virtual machine. If what you need is a lightweight virtual machine. Build that. Do not build a container because it's the latest and greatest buzzword. But instead I see large monolithic applications, shoved into a container, and then I hear a multitude of complaints about performance issues ETC. You may be able to drive a nail with a screwdriver but it's not a good idea.

v3ss0n 3y ago
Only applies to docker. LXC for example designed container like a VM

theden 3y ago

>One of the great sins of Docker is having normalized running software as root. Yes, Docker provides a degree of isolation, but from a perspective of defense in depth running anything with user exposure as root continues to be a poor practice. >Perhaps one of the problems with Docker is that it's too easy to use If you've ever had to make a nonroot docker image (or an image that runs properly with the `--read-only` flag), it's not as trivial and fast to get things going—if it was default, perhaps docker wouldn't have been so successful in getting engineers of all types and levels to adopt it? It's rare to find tooling in the DevOps/SRE world that's easy to just get started with productively, so docker's low barrier to entry is an exception IMO. Yes, the downside is you get a lot of poorly-made `Dockerfiles` in the wild, but it's also easy to iterate and improve them, given that there's a common ground. It's a curse I suppose, but I'd rather have a well-understood curse than the alternative being an arbitrary amount of bespoke curses.

numbsafari 3y ago
Running all your software as root is the IT equivalent of sales guys slapping themselves on the back for selling something for free. It’s all fun and games until the bills come due.

charcircuit 3y ago

>Consider Windows: the operating system's most alarming defect in the eyes of many "Linux people" is its lack of package management Windows has WinGet.

Xeamek 3y ago
WinGet isn't really a package manager. Package manager role is, well, managing packages. WinGet is just a repo with installers of the programs listed, but dependency managing and installation it self is handled by the installers, not winget. (Don't know if the ms-store package format isn't exception to that, but still)
- charcircuit 3y ago
  >WinGet isn't really a package manager. Microsoft literally calls it along with some complementary services the "Windows Package Manager" >Package manager role is, well, managing packages. Which is what it refers to what it is managing. >but dependency managing and installation it self is handled by the installers The package manifest is allows for dependencies on other packages.
  - Xeamek 3y ago
    That's great that microsoft calls it that, but that doesn't really matter. Winget is just as much a package manager, as the "add or uninstall apps" tab in windows settings is. It's just a interface. But the actual act of installing is done by different program.

jrm4 3y ago

Did the author say anything actually negative about Docker? All I saw was "Docker can be suboptimal" but nothing to suggest that it has been anything other than at least a partial improvement?

kapitanjakc 3y ago

Docker containers and images have saved me a lot of shipping pain in web part. I haven't come across them being used as package manager or distributors yet.

isoprophlex 3y ago

Clearly we need another layer between the host and the docker-compose spaghetti. Some lightweight (true, no docker-in-docker bs) VM that exists to lock up & let whatever is in those yamls kick and scream around. I wish I knew if I am being sarcastic here...

Xeamek 3y ago

The curse of docker is that it allows devs to be lazy and rather then making sure their configuration and deployment are straightforward, they get to keep all their mess working (longer). Ofcourse, if you have really complex setup docker is invaluable. But if all you are using it is to make the depreciation warnings go away on your single executable app, that's just abuse of the tool for the wrong reasons

patrick451 3y ago

His points about networking and the file system are spot on. It still blows my mind that the default user in a container is root and that dealing with the UID issue is such a pain. The only solutions I have seen can only be described as hacks.

notatoad 3y ago

Dockerfiles are really really simple. they do essentially three things: set a base image, set environment variables, and run scripts. and then as sort of a meta-thing, they prove that the steps in the dockerfile actually work, when you start the docker container and see that it works. if you don't want to run in docker, a dockerfile is still a perfect setup script. open it up and see what it does, and use that as install instructions.

jamesgeck0 3y ago
I’ve debugged project Dockerfiles to discover that they were pulling dependencies from URLS with “LATEST” in them. A Dockerfile isn’t really proof that anything currently works.

carl_sandland 3y ago

what about AWX then? it moved from shipping as a simple docker compose to a kubernetes operator! I'd much rather it didn't.

eviks 3y ago

Has any great design been invented that isn't tied to hardcoded paths preventing multiple versions of the same library and would allow easy linking to any version? Nix? Anything else?

colordrops 3y ago
Yes, Nix. And it works great.

deleted 3y ago

[deleted]

eviks 3y ago

Has any great design been invented that isn't tied to hardcoded paths preventing multiple versions of the same library etc and would allow easy linking to any version? Nix? Anything else?

nusmella 3y ago
I don't know if this is normal or if anyone else does it but I usually either download binaries or compile from source and move the executable to /usr/local/bin/ and create a symlink. Lets me easily switch between versions. I avoid using a package manager for anything where I want control over the version and installation. - curl -fSLJO $RELEASE - tar xvf $DOWNLOAD.tar.gz && cd $DOWNLOAD` - make . - mv $EXECUTABLE /usr/local/bin/$EXECUTABLE-$VERSION` - ln -s /usr/local/bin/$EXECUTABLE-$VERSION /usr/local/bin/$EXECUTABLE - # chmod 750, chown root:$appuser, etc Works great for everything I've tried thus far. Redis, HAproy, Prometheus exporters, and many more.
oddmiral 3y ago
Yes, these "great designs" are invented at a constant rate. I saw about 30 of them, or 1 per year at average. For example, Fedora invented and then abandoned modular design recently.

zaptheimpaler 3y ago

Nah docker is excellent and far far preferable to the standard way of doing things for most people. All the traditional distribution methods have barely even figured out how to uninstall a piece of software. `apt remove` will often leave other things lying around. He complains about configuration being more complex because its not a file? Except it is, and its so much simpler to just have a compose file that tells you EXACTLY which files are used for configuration and where they are. This is still not easy in normal linux packages. You have to google or dig through a list of 10-15 places that may be used for config.. The other brilliant opinion is that docker makes the barrier to entry for packaging too low.. but the alternative is not those things being packaged well in apt or whatever, its them not being packaged at all.. this is not a win. Whats the alternative to running a big project like say Sourcegraph through a docker compose instance? You have to get set up ~10 services yourself including Redis, Postgres, some logging thing blah blah. I do not believe this is ever easier than `docker compose up -d`. And if you want to run it without docker, the docker images are basically a self-documenting system for how to do that. This is strictly a win over previous systems, where there generally just is no documentation for that. Personally docker lowers the activation energy to deploy something that I can now try/run so many complex pieces of software so easily. I run sourcegraph, nginx, postgres, redis on my machine easily. A week ago I wanted to learn more about data engineering - got a whole Apache Airflow cluster setup with a single compose file, took a few minutes. That would have been at least an hour of following some half-outdated deploy guide before so I just wouldn't have done it. --- The beginning of the post is most revealing though: > The fact that I have multiple times had to unpack flatpaks and modify them to fix dependencies reveals ... Still, these systems work reasonably well, well enough that they continue to proliferate... Basically you are okay with opening up flatpaks to modify them but not opening up docker images.. it just comes down to familiarity.

hinkley 3y ago
I just found about a half a gigabyte of files from programs I uninstalled two laptops ago on my machine, and files from a Steam game I got a refund for because it would crash after fifteen minutes. It’s frustrating.
angarg12 3y ago

zubairq 3y ago

Having worked at Red Hat and worked on many Docker / Kubernetes systems I agree with some parts of the article, but my view is that the wrold is going through a transition phase right now of moving to containerised systems. Take for example running something like 3Scale (an internet gateway) in Docker or Kubernete. It can be a nightmare to configure and run 3Scale using containers with the multiple memory limits and other container specific issues. Far easier to get 3Scale running without containers. So many software systems were not designed in the Docker era, and going forward many container applications will be designed to be easier to configure/use in the Container world due to a "Container/Docker native" mindset when designing the system in the first place

defanor 3y ago

Docker keeps reminding me of people in the past shipping VM images, or sometimes physical machines, often with rather inappropriate desktop hardware and software. So do these points: > The problem is the use of Docker as a lowest common denominator, or perhaps more accurately lowest common effort, approach to distributing software to end users. Shipping physical machines probably is even lower than that though. Or even the VMs. > One of the great sins of Docker is having normalized running software as root. I am not as familiar with Docker practices, but unfortunately, AFAICT, people did that frequently on regular systems as well, just to not bother with permissions. (Edit: now I recalled people also not following the FHS and storing things in the root directory inside Docker images, but sometimes it was/is similar without containers as well, and inside a container it does not clutter the host system, at least). > Having "pi" in the name of a software product is a big red flag in my mind, it immediately makes me think "they will not have documented how to run this on a shared device." This approach is similar to shipping physical machines. Or at least maintaining odd legacy software on a dedicated machine. I think a rather pessimistic view is that proper packaging switched to Docker or single-purpose machines, but an optimistic one is that those are the unnecessary VMs and larger single-purpose machines that were replaced by Docker and RPi. Maybe there is a little of both going on.

ungamedplayer 3y ago
>AFAICT, people did that frequently on regular systems as well, just to not bother with permissions. This was an easy way to tell if you were dealing with a Muppet. If you saw this you would know that the software was going to be a problem.

alexey-salmin 3y ago

I think most of the comments here largely miss the point of the article. The guy doesn't complain about docker as a whole and doesn't criticise it's usage for software deployment which normally is the main application. He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. So in order to use that software you need to run a Docker image from the internet which is often poorly made and is incompatible with your infrastructure. Had a package been available you'd simply do "install" inside your own image built with your infrastructure in mind. With that I agree completely. Docker and worse even docker-compose are terrible ways of software distribution and should never be used except for demos and for rare cases where software is not distributed to the customer in the normal sense but rather directly deployed into his system. Docker and docker-compose are still very good methods of software deployment.

turtlebits 3y ago
I have rarely seen end user software being distributed as a docker image, only server applications. Occasionally I see CLI tools that are hard to package available as docker images, but those are generally done because the maintainer hasn't provided precompiled binaries.
solatic 3y ago
This, but I want to add, I think the root cause is less due to the ease of writing a Dockerfile vs writing a deb, rpm, etc. and more due to the low cost of hosting. Whatever low-quality Dockerfile you write, you can sign up on Docker Hub, build and push there, and you're done. GitHub Packages doesn't support deb or rpm, and anyway for better or for worse, packages are tightly coupled to the distribution they're packaged for. That means either getting your package into the package repository of each distribution you want to target, or hosting your own package repository, which is non-trivial in both financial and labor cost. Docker has a lot more crap, but it did dramatically lower the barrier of entry, which is a good thing. The proper response isn't to bemoan the lower barrier of entry, but to attempt to lower the barrier of entry of traditional packaging.
cderpz 3y ago
>He complains about Docker being used as a software distribution method, that is as a replacement for say Debian package, pip package, npm package etc. If that is a valid complaint, why does he choose two examples where that is not the case? Nextcloud AIO is just one option among many and certainly not the "standard way" of hosting your nextcloud instance. Coincidentally I came from hosting nextcloud the "standard way" and I'm really glad AIO exists and I don't have to manage nonsense like nextcloud ending support for the latest Debian php version. And Home Assistant is mainly distributed as the OS variant with the docker version being the step child afterthought that barely functions.

bakugo 3y ago

I sympathize with pretty much everything in this article, in particular the configuration/filesystem pains. I can't remember the last time I tried to get a file or folder into or out of a container without running into some sort of issue, usually involving permissions, and I feel like there really should be a better solution for this.

what-the-grump 3y ago

These sorts of things usually take longer to get working than equivalent software distributed as a conventional Linux package or to be built from source. Yes, but they are done once, and forced to ship the docker image. The stupid amount of time we've spent looking for that one package dependency because someone forgot that they installed something to make a project work... Or the classic we setup SSL, no one knows how they setup SSL once they are done, etc. Docker forces a lot of the infrastructure decisions that devs make in their sandbox to be actually well defined. Not that it makes their choices any more sane, safer, secure. At least someone can take a look at the mess and replicate it, as many time as they want, quickly, break it, fix it, upgrade it, without ever requesting a dev VM build, having sysops install preqs, etc. Is docker work? Everything is work. Do I think docker should be the default go to? No I'd like for people to use app services and simply perform the build on the app node, but that magic is even harder to debug and troubleshoot.

steve1977 3y ago

It seems to me that many of the points in the article are not really problems with Docker, but problems with Linux. I.e. the way Linux handles multiple versions of libraries and of course the fragmentation hell that is Linux distributions. Docker then is just a bandaid for these problems.

oddmiral 3y ago
Linux (kernel) can run any libraries in any combination. You are talking about distributions. Support for multiple versions of a library is not a goal for a typical distribution. Typically, this is necessary for commercial software vendors, which have money to throw at the problem. If commercial software vendors needs this so badly, they can sign a support contract with distributor, so a dedicated team of maintainers will care about this problem with libraries for them. In the open-source world, it's an order of magnitude easier to patch the source, than introduce two versions of a same library. In rare cases, a -compat package is created, which then abandoned as soon as possible.

GabeIsko 3y ago

I can't believe what I am reading. It took you more time to set up nextcloud with docker compose? What? For my hobby stuff, I can usually try something out really quickly by giving a compose a quick read and pasting it into portainer for a test. I have my gripes with docker - especially for my professional work, and I am not a fan about how much it obscures images, nor its shibboleth approach to using a CLI-daemon interface (should be a `dockerctl` command in my mind) but I really can't believe that you would want to manually set up multi process platforms manually. When you want to connect to a data base, and have it be ephemeral? I have rooted around in enough application servers to understand that docker-compose and dockerfiles is a very sane approach. The real issue I am seeing in the comments are that people are complaining that they would prefer getting a maintained package for software. Would rather use `apt install` or `dnf install` than mess with containers. That has been discussed to death and we get the same answer is the same every time - yes that would be a nice world to live in, but it is a fantasy to imagine anyone doing that much maintenance work for packages.

rkagerer 3y ago

You know who really knows how to package software? Mark Russinovich, Nir Sofer, and all the others who gave us beautiful utililies in standalone EXE's that don't require any dependencies. For the longest time I stayed on older versions of .NET so any version of Windows since 2003 could run my software out of the box. Made use of ILMerge or a custom AssemblyResolve handler to bundle support DLL's right into my single-file tools - it wasn't hard. I have no complaints about Docker, but I do find where I used to be able to download simple zip files and place their contents into my project I now just get a black box Docker link with zero documentation and that makes me sad.

tux2bsd 3y ago
[dead]
seec 3y ago
Exactly my thoughts. The Linux guys have been discussing the merits of package management and various related systems since I started getting interested in computers. Yet after all this time they have not come close to something as simple as the double click to run .exe or self-installing binary you can find on windows (macOS also has completely self-contained apps). So having managed linux servers and relatives I'm a bit confused that we are still there, discussing the merits of stupid packaging software, that follow some sort of ideal but never actually work properly (at least, scale very badly and react poorly to changes). Everything he said about docker is true but it also applies to the regular package management in various linux distros. In the age of very fast upload bandwidth and very affordable storage, docker is even more suspicious against a regular lightweight VM. Doesn't have as good of security separation, more annoying to reproduce and required more setup; VM bit for bit copy is also extremely simple. I believe one reason we got docker is because they couldn't figure out how to partition hardware at the machine level efficiently so instead, they partitioned CPUs. Easier to manage in hardware, more of a pain in software... But the reason no user facing operating system ever uses this kind of software management is that it never works, no matter the ideals, a lot like communism. What a waste of time, I guess at least it makes for some fun discussion from time to time.
tinus_hn 3y ago

INTPenis 3y ago

The curse of that website, it made me dizzy just scrolling. Containers are amazing, they're bigger than docker, end of story.

jillesvangurp 3y ago

I remember how things were before docker. Better is not a word I'd use for that. It sucked. Deploying software meant dealing with lots of operating system and distribution specific configuration, issues, bugs, etc. All of that had to be orchestrated with complicated scripts. First those were hand written, and later we got things like chef and puppet. Docker wiped most of that out and replaced it with simple build time tools that eliminate the need for having a lot of deploy time tools that take ages to run, are very complex to maintain, etc. I also love to use it for development a lot. It allows me to use lots of different things that I need without having to bother installing those things. Saves a lot of time. Docker gives us a nice standard way to run and configure whatever. Mostly configuration only gets hard when the underlying software is hard to configure. That's usually a problem with the software, not with docker. These days if you are building something that requires fiddling with some configuration file, it kind of is broken by design. You should design your configuration with docker in mind and not force people to have to mount volumes just so they can set some properties. The reason docker is so widespread is that it is so obviously a good idea and there hasn't been anyone that came along with something better that actually managed to get any traction worth talking about. Most of the docker alternatives tend to be compatible with docker to the point that the differences are mostly in how they run dockerized software. And while I like docker, I think Kubernetes is a hopelessly over engineered and convoluted mess.

peanut-walrus 3y ago
How is writing those complicated scripts but in a dockerfile or docker-compose file any better? Software written with docker in mind is easier to manage because it generally follows better design principles, such as separating configuration from state, being failure tolerant, treating the network as opaque, etc. This software would be easy to deploy without using docker as well. If you're trying to deploy some complex piece of software which doesn't follow these principles, it's exactly as hard or even harder with docker. Unless you outsource the work to random people on the internet, but then you are not building production systems. Containers are great for lots of things and containerization in general has forced developers to write better software, but there really isn't a lot of difference in difficulty in running that webapp in a container vs just running it on the machine directly.

devjab 3y ago

I think a lot of your comments here are very true. I don’t think docker made my world worse and I certainly don’t think it cost me more time, but I also sort of agree with the author. I came into Typescript late, and to “tame” the wildness of the ecosystem I set up a lot of opinionated systems for our developers. I didn’t dictate them, it was a collaborative process where we worked long and hard go agree on how we would utilise the Node ecosystem as well as the 10ish rules that we’ve changed as opposed to the “global” strict eslint rules. Rules which have themselves been born out of a decade of different rulesets like the Airbnb ones most people in the JS community will have heard of. My approach to containers has been similar. We don’t use docker-compose and never have as an example, we went with Terraform, though today we’re using Bicep, and we make heavy use of dapr side cars. Which makes working with infrastructure sort of easy. Easy to lock down and opinionate at least. You can get most templates directly from Azures GitHub, but you can obviously also build your own, and then it’s simply a matter of having some decent template projects so that your developers can be up and running in a few minutes whenever they need to start a new project. Obviously there is a cost when you’re moving legacy projects into this sort of infrastructure, but it’s not like it’s really that resource consuming if it was already containerised, and it’s not too bad even if it wasn’t. Now, that’s how we do it. It’s also how I think everyone should do it, but it’s not how you “have” to do it. In many ways, you’re as free to utilize the container ecosystems as freely as you can with the Node ecosystem. Well maybe not as free as that, but still free enough to create a lot of horror stories. Which is exactly what has happened with containers in many organisations. As such I think the author has a valid point. I’m not sure where we would go without the freedom though. Our exact setup works for us, you might not agree with our choices and neither of us would be wrong. So while some opinionated processes might be compatible with container infrastructure, others will need to remain “free”. I’m certainly with a lot of you in that it was worse before containers. I’ve also done work with organisations where container deployments worked so poorly that it was clearly not better, however, and I suspect those pipelines are far more common than given credit in this comment section.

forrestthewoods 3y ago

Unpopular Opinion: Linux got it wrong and Windows got it right. (Or at least closer to right.) Programs shouldn't use centralized dependencies. Programs should ship ALL of their dependencies. Running a program should be as simple as downloading a zip, extracting, and clicking/typing run. Docker exists because building and running software is so outrageously complex that it requires a full system image. And it turns out Docker didn't actually solve it after all!

oddmiral 3y ago
It's much easier to ship more than one program, with all their dependencies packaged, because of lower cost of maintenance per program/library. It is also easier to automate downloading and unpacking than do that manually for every package. If you want to try this idea, just download a Linux distribution.
- seec 3y ago
  Doesn't that fail the minute one of your programs decides he needs a different package version or one that doesn't exist all together? It looks more efficient and easier at first, but ultimately it becomes less and less maintenable and the "dumb" inefficient approach of shipping all the things at once becomes better. It's like in real life, the more you are dependent on different peoples/incomes, the more your life becomes complicated and unlivable. Just ask someone who needs multiple jobs to survive. But we went ahead and implemented just that into software. Kinda madness...

smitty1e 3y ago

Great read. If I had to quibble, it would be with > Even if 90-day ephemeral TLS certificates and a general atmosphere of laziness have deteriorated our discipline in this regard, private key material should be closely guarded. It should be stored in only one place and accessible to only one principal. You don't even have to get into these types of lofty security concerns, though. TLS is also sort of complicated to configure. Any time there is complexity and only the One True Priest can manage it, there will be tears. There had better be a break glass solution backed by Righteous Documentation (a hypothetical substance I heard about this one time) if we are boxed in to a One True Priest situation.

pas 3y ago
piggybacking on this, due to the ease of getting a cert for a subdomain, basically one cert per app ... just have one cert per "compose stack" and it's perfect acceptable to run them with rootless docker-in-docker or on separate VMs to get security. the one true sacred nginx in front of everything is nice, but also has access to everything. of course, the lack of public IPv4 addresses in many homelab/selfhosted/hobbyist situations is the true forcing factor. (an gettting a wildcard cert is very easy with certbot nowdays, so I understand the lure.)

wg0 3y ago

There's no merit to this complaint about Docker that it complicates configuration. Actually it simplifies a great deal. Author should consider how configuration is at different locations and sometimes even further split differently in different distributions for the same software package (apache, PostgreSQL etc) while a docker Image has it all at a very well known location within image and it doesn't matter where you use that image.

PreInternet01 3y ago

> distributing an application only as a Docker image is often evidence of a relatively immature project Or, you know, a contractual requirement. And, as far as those go, I actually kind of like it: you ship a well-tested container, and the only thing the infra dept at the customer site has to configure-via-the-environment is the URL for (or path to, via any kind of supported file system mounted into the container, which most IT shops can still just about manage) the instance configuration file. This reduces most initial troubleshooting to "well, what does the instance log say about retrieving and parsing the configuration file?", which, trust me, is way preferable over what you get with most other deployment methods I've been involved with...

saidinesh5 3y ago

Obligatory Hitler uses Docker post: https://www.youtube.com/watch?v=PivpCKEiQOQ https://www.youtube.com/watch?v=PivpCKEiQOQ Lol @ "I'm moving everyone to Windows! Don't cry, you can run bash on Windows 10 now."

acje 3y ago

We are probably going to go around the packaging wheel until we come up with one that does first class sandboxing. Any bets on webassembly?

vortegne 3y ago

I'm a developer with pretty limited "serious" DevOps experience. I can do tweaks here and there, create some simple cloud pipelines, etc. I'm definitely not fit to set up any enterprise-grade DevOps or manage a server. I run a home server just for fun, with quite a lot of applications. Docker and images from linuxserver.io are the best thing that happened to me in this realm. I can try out new applications very quickly, I can reinstall the OS on my server and get all my things up and running in no time. Linuxserver.io images have a standardised configuration which is great. There is no way in hell I could manage to set up this many applications without Docker, set up SSL for all of this, have fancy 2FA and SSO and have it so quickly redeployable. Guess I'm the target audience for this, it has been a lot of fun tinkering in a low-friction environment that Docker has provided me with.

xg15 3y ago

> One of the basic concepts shared by most Linux systems is centralization of dependencies. Libraries should be declared as dependencies, and the packages depended on should be installed in a common location for use of the linker. This can create a challenge: different pieces of software might depend on different versions of a library, which may not be compatible. This is the central challenge of maintaining a Linux distribution, in the classical sense: providing repositories of software versions that will all work correctly together. Maybe someone with more knowledge of Linux history can explain this for me, because I never understood it: Why is it so important that there must always only be one single version of a library installed on the entire system? What keeps a distribution from identifying a library by its name and version and allowing application A to use v1.1 and application B to use v1.2 at the same time? Instead the solution of distros seems to be to enforce a single version and then to bend the entire world around this restriction - which then leads to unhappy developers that try to sidestep distro package management altogether and undermine the (very reasonable) "all software in a distro is known to work together" invariant. So, why?

rwmj 3y ago
For security (and general bug fixing). If a security issue is found you want to only fix it in one place. The container alternative is searching down how all the containers were built, which might be very varied and some not even reproducible, and fixing them all.
- xg15 3y ago
  Indeed, containers suck for this: Not just do you have to look into each container separately, there is also no requirement all containers use the same structure at all, as you said. Yet this is exactly what happens in practice if the one-version-for-all paradigm is impractical for developers. So it would be in the interest of distros to give some way in that regard: Keep the centralised dependency dogma in place, but allow multiple independent versions and configurations be stored. Then bug fixing might be slightly harder than with a single version, because you might have to fix 3 versions instead of one, but still much easier than monkey-patching half a dozen containers. (It would still be good to "nudge" developers towards a canonical version, i.e. by sending them reminders when the software uses a lower version or a different configuration - or if you want even a warning that everything below a certain minimum version will be rejected)

rwmj 3y ago

One problem he doesn't mention is with the libraries / dependencies themselves. They should offer stable APIs and ABIs so that you don't have to have software that needs to depend on specific versions in the first place. Poor software development practices in certain ecosystems encourage this churn.

totallywrong 3y ago

I do DevOps and never once used Compose in my entire career. Single containers in my machine (in userspace with Podman) and Kubernetes in servers. 99% of the time there's an official Helm chart that installs any dependencies and has sane default, which you just tweak to your needs. This guy is doing it wrong.

T3RMINATED 3y ago

[dead]

CR007 3y ago

I distribute server-side software and it was a pain to provide the infra requirements. At higher level users easily miss what is yours and what's another tech, they just don't care to tell the difference. Is not a matter of documenting, is just not their concern. That drives many issues and it becomes a snowball soon as inexperienced users start to vent bad practices. In a effort to help other users they often spread more damage. With Docker I was able to take charge of the infra, which erased all the uncertainties on my next layer but it spawned the uncomfortable need of learning Docker to use my stuff, which users took very reluctant. The best distribution method is to pack a binary release. Not only the package is lightweight, it doesn't need any fancy instruction. You can keep Docker for your internal use, don't ship it to end users.

syrusakbary 3y ago

It's funny how WebAssembly can help overcome most of the issues mentioned on the blogpost (packaging, configuration, portability) if addressed properly. That's the main reason Wasmer [1] was created :) [1] https://wasmer.io https://wasmer.io

MongoTheMad 3y ago

The author needs to look into confd. I wrote about it in 2017: https://andrewwippler.com/2017/11/28/reusable-containers-with-confd/ https://andrewwippler.com/2017/11/28/reusable-containers-wit...

camgunz 3y ago

I hate Docker (honestly I can't believe the MacOS version requires a Linux emulator :rolleyes:), but it basically is the best way to run server software. The only major alternative is Nix, which might actually work out.