> 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.
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.