3 ms·

"Since all workstations ran Ubuntu and all servers ran Ubuntu" Admittedly our company is small (~5 fulltime devs), but we have: mac osx catalina, debian buster

"Since all workstations ran Ubuntu and all servers ran Ubuntu" Admittedly our company is small (~5 fulltime devs), but we have: mac osx catalina, debian buster, debian bullseye, and ubuntu bionic beaver. So precompiling .debs won't work here. Docker gives us all a common ground, minus some wonky mac docker issues with DNS. Also, this assumes that one is using a server in the first place. We run our own kubernetes cluster that we automatically provision and deploy pods to, so there is no server to upload files to. "You aren't relying on some guy with a blog post to keep his server up. <...> And it makes you very directly consider what your dependencies are. Do you really need that unmaintained library written in an esoteric language that requires a SPARC to compile? Docker allows you to hide bad dependencies behind the idea that they are inside a container so the harm they can cause is limited and the headache is localized." Again, this is a strawman. You can butcher things with docker, or without docker. The same can happen with i.e. Ansible & Terraform (which we also use). I can, and do, analyze our images to see what we can reduce to. Most of our images are either on Scratch or Alpine Linux, thanks to multi-stage builds. Since each build is localized to a container, we can independently update images and not have to worry about dependency mismatches, or random directories being modified, etc. My opinion will be biased because I've written at least ~120 docker images in the last two months and spend a good bit of time tweaking and optimizing them.

IgorPartola 6y ago
> Admittedly our company is small (~5 fulltime devs), but we have: mac osx catalina, debian buster, debian bullseye, and ubuntu bionic beaver. So precompiling .debs won't work here. Docker gives us all a common ground, minus some wonky mac docker issues with DNS. That does make it more difficult. Docker does sound like the common ground then. > Again, this is a strawman. You can butcher things with docker, or without docker. The same can happen with i.e. Ansible & Terraform (which we also use). I can, and do, analyze our images to see what we can reduce to. Most of our images are either on Scratch or Alpine Linux, thanks to multi-stage builds. It's a related argument. My point is that Docker allows you to take shortcuts too easily compared to other methods. And when you are faced with figuring out how to make your software work with widgetlib 1.0.4 provided by the system instead of widgetlib 1.0.5 which is what you originally built it for, you have a choice of packaging 1.0.5 yourself and potentially doing that improperly (make && make install inside a Docker container, paying no attention to dependencies or upgrades), or properly (by creating a standard reproducible build you can track). Docker allows you to take the shortcut easily. It's a powerful tool and it does allow you to create good images, but I have also seen some terrible ones (just like I've seen bad examples of .deb packages, but a lot fewer of them). Regardless, it's about how you work and how you structure things. I am coming around to Docker as a workflow, but I doubt I'll be creating 120 microservices to run one project anytime soon. Too many things to keep track of and update.

IgorPartola 6y ago

> Admittedly our company is small (~5 fulltime devs), but we have: mac osx catalina, debian buster, debian bullseye, and ubuntu bionic beaver. So precompiling .debs won't work here. Docker gives us all a common ground, minus some wonky mac docker issues with DNS. That does make it more difficult. Docker does sound like the common ground then. > Again, this is a strawman. You can butcher things with docker, or without docker. The same can happen with i.e. Ansible & Terraform (which we also use). I can, and do, analyze our images to see what we can reduce to. Most of our images are either on Scratch or Alpine Linux, thanks to multi-stage builds. It's a related argument. My point is that Docker allows you to take shortcuts too easily compared to other methods. And when you are faced with figuring out how to make your software work with widgetlib 1.0.4 provided by the system instead of widgetlib 1.0.5 which is what you originally built it for, you have a choice of packaging 1.0.5 yourself and potentially doing that improperly (make && make install inside a Docker container, paying no attention to dependencies or upgrades), or properly (by creating a standard reproducible build you can track). Docker allows you to take the shortcut easily. It's a powerful tool and it does allow you to create good images, but I have also seen some terrible ones (just like I've seen bad examples of .deb packages, but a lot fewer of them). Regardless, it's about how you work and how you structure things. I am coming around to Docker as a workflow, but I doubt I'll be creating 120 microservices to run one project anytime soon. Too many things to keep track of and update.