3 ms·

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

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.
- deleted 3y ago
  [deleted]
- Too 3y ago
  You don’t get config drift or “Works on my machine” with docker, compared to scripts on the host.
arp242 3y ago
> Deploying software meant dealing with lots of operating system and distribution specific configuration But Docker didn't solve that at all, unless you consider "we only support Linux, so just run Linux or fuck you" as a "solution". And starting a Linux VM on Windows or macOS doesn't really count (and comes with a lot of issues). Containers as a concept are fine. Docker as an implementation is not very good. These are people who released a program in 2014 that can only run as root, which should say a thing or two about the engineering ethos. What is this, 1982? > All of that had to be orchestrated with complicated scripts. Hacking deploy scripts (and configure scripts and Makefiles) wasn't fun either, but at least I could understand it. Hacking on Docker once something goes wrong is pretty much impossible. It really is hugely over-engineered for what it does. You really really don't need a million lines of code to build and run containers on Linux. I've had a number of machines where binary JSON files in /var/lib/docker got corrupted and the only solution I've ever been able to find is "completely wipe away the lot and start from scratch". The entire overlayfs thing they have can really go haywire for reasons I've never been able to reproduce or figure out (and the "solution" is similar: wipe away /var/lib/docker and start from 0), and things like that. It all "works", but it's a hugely untransparent black box where your only solution when things go wrong is to shrug and give up (or spend days or even weeks on figuring it all out). I've had enough issues and outright bugs that I probably spent more time on Docker and docker-compose than I saved. At my last job I just bypassed the "official Docker development environment" with a few small shell scripts to run things locally, because it was a never-ending source of grief. I only had to support my own Linux system so I had it a bit easy, but it wasn't much more than running our programs with the right flags. The platform-specific stuff was "my-pkg-manager install postgres redis", and I don't see what's so hard about that.

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.

deleted 3y ago
[deleted]
Too 3y ago
You don’t get config drift or “Works on my machine” with docker, compared to scripts on the host.

arp242 3y ago

> Deploying software meant dealing with lots of operating system and distribution specific configuration But Docker didn't solve that at all, unless you consider "we only support Linux, so just run Linux or fuck you" as a "solution". And starting a Linux VM on Windows or macOS doesn't really count (and comes with a lot of issues). Containers as a concept are fine. Docker as an implementation is not very good. These are people who released a program in 2014 that can only run as root, which should say a thing or two about the engineering ethos. What is this, 1982? > All of that had to be orchestrated with complicated scripts. Hacking deploy scripts (and configure scripts and Makefiles) wasn't fun either, but at least I could understand it. Hacking on Docker once something goes wrong is pretty much impossible. It really is hugely over-engineered for what it does. You really really don't need a million lines of code to build and run containers on Linux. I've had a number of machines where binary JSON files in /var/lib/docker got corrupted and the only solution I've ever been able to find is "completely wipe away the lot and start from scratch". The entire overlayfs thing they have can really go haywire for reasons I've never been able to reproduce or figure out (and the "solution" is similar: wipe away /var/lib/docker and start from 0), and things like that. It all "works", but it's a hugely untransparent black box where your only solution when things go wrong is to shrug and give up (or spend days or even weeks on figuring it all out). I've had enough issues and outright bugs that I probably spent more time on Docker and docker-compose than I saved. At my last job I just bypassed the "official Docker development environment" with a few small shell scripts to run things locally, because it was a never-ending source of grief. I only had to support my own Linux system so I had it a bit easy, but it wasn't much more than running our programs with the right flags. The platform-specific stuff was "my-pkg-manager install postgres redis", and I don't see what's so hard about that.