4 ms·

I used docker for a while last year and attended Dockercon. I was really excited about it and thought it was going to solve many of my problems. But with how

I used docker for a while last year and attended Dockercon. I was really excited about it and thought it was going to solve many of my problems. But with how complicated my stack is, it just didn't make sense to use ultimately. I loved the idea of it, but in the end good old virtual machines and configuration management can basically do most of the same stuff. I guess if you want to pack your servers to the brim with processes and shave off whatever performance hit you get from KVM or XEN, I get it. But the idea of the filesystem layers and immutable images just kindof turned to a nightmare for me when I asked myself "how the hell am I going to update/patch this thing" Maybe I'm crazy, but after a lot of excitement it seemed more like an extra layer of tools to deal with more than anything.

icelancer 9y ago
This is unfortunately the conclusion I came to. Virtual machines locally and in the cloud just don't seem to be that much worse in any facet, and Docker (containers in general) seem to be far more complicated. I dunno.
- locusofself 9y ago
  Learning Ansible really well proved far more valuable to my work life. I integrate lots stuff, stuff like OpenVPN, Asterisk, Freeswitch, stuff that can hardly be "contained" and still even work. Some stuff does not work in containers, and even if it does work, dealing with the weird filesystem mounts, "statelessness", locations of logs and other persistent data, and the ethos of just using 1 process per container and so on and so forth. Then think about deploying some complex legacy apps that have upgrade paths that involve changing database schemas and running shell scripts to migrate data. How are you going to reasonably do that with docker? It just hurt my brain to think about it. If you have the luxury of designing your app from the ground up and its not too complicated of a stack then I see how it is cool. But mostly if it saves you money on AWS bills or something...
- auspex 9y ago
  See my comment above
auspex 9y ago
The big thing with Docker containers is that you don't patch or update them. You include patches in the build process that produces a patched image. You then tear down your containers and deploy the new image. One of the main benefits is once you have a proper pipeline setup you just modify your Dockerfile commit it to git, the build happens automatically and then it's automatically deployed once the new image is checked in to the repo. Now the all your containers are "magically" patched. Imagine having to patch a CVE in each of your VMs. Quite different. VMs are pets. Containers are cattle.
- scarlac 9y ago
  > VMs are pets. Containers are cattle. That's the funniest yet most accurate down-to-earth analogy I've heard so far that explains the mentality of Docker/containers. While funny, it's actually practical to have an analogy when explaining newcomers what Docker does to the mentality of server/service management. Thanks.
adictator 9y ago
I'm guessing you did not have somebody to guide you & help you on the dockerization journey. Being a developer myself, I wish I had docker or something similar all the years since 2005. It would have hugely simplified everything I was doing then. So, about update / patching - the answer is you simply don't. You get a new image that already has your desired state of the application and you replace your running application stack with the new images for one or all of the components. With this rollback simply becomes going back to the previous image & not uninstalling the patch/update. It is a radical shift and it is succinctly captured in parts of the 12-factor app - aka "Treat your apps like cattle, not like pets"

icelancer 9y ago

This is unfortunately the conclusion I came to. Virtual machines locally and in the cloud just don't seem to be that much worse in any facet, and Docker (containers in general) seem to be far more complicated. I dunno.

locusofself 9y ago
Learning Ansible really well proved far more valuable to my work life. I integrate lots stuff, stuff like OpenVPN, Asterisk, Freeswitch, stuff that can hardly be "contained" and still even work. Some stuff does not work in containers, and even if it does work, dealing with the weird filesystem mounts, "statelessness", locations of logs and other persistent data, and the ethos of just using 1 process per container and so on and so forth. Then think about deploying some complex legacy apps that have upgrade paths that involve changing database schemas and running shell scripts to migrate data. How are you going to reasonably do that with docker? It just hurt my brain to think about it. If you have the luxury of designing your app from the ground up and its not too complicated of a stack then I see how it is cool. But mostly if it saves you money on AWS bills or something...
auspex 9y ago
See my comment above

auspex 9y ago

The big thing with Docker containers is that you don't patch or update them. You include patches in the build process that produces a patched image. You then tear down your containers and deploy the new image. One of the main benefits is once you have a proper pipeline setup you just modify your Dockerfile commit it to git, the build happens automatically and then it's automatically deployed once the new image is checked in to the repo. Now the all your containers are "magically" patched. Imagine having to patch a CVE in each of your VMs. Quite different. VMs are pets. Containers are cattle.

scarlac 9y ago
> VMs are pets. Containers are cattle. That's the funniest yet most accurate down-to-earth analogy I've heard so far that explains the mentality of Docker/containers. While funny, it's actually practical to have an analogy when explaining newcomers what Docker does to the mentality of server/service management. Thanks.

adictator 9y ago

I'm guessing you did not have somebody to guide you & help you on the dockerization journey. Being a developer myself, I wish I had docker or something similar all the years since 2005. It would have hugely simplified everything I was doing then. So, about update / patching - the answer is you simply don't. You get a new image that already has your desired state of the application and you replace your running application stack with the new images for one or all of the components. With this rollback simply becomes going back to the previous image & not uninstalling the patch/update. It is a radical shift and it is succinctly captured in parts of the 12-factor app - aka "Treat your apps like cattle, not like pets"