Sorry it took me so long to reply. >I'm mostly in the "dev" rather than "ops" space Same here, for the most part. I'm a freelancer, so I end up having to do

Sorry it took me so long to reply. >I'm mostly in the "dev" rather than "ops" space Same here, for the most part. I'm a freelancer, so I end up having to do a fair amount of cloud management (often with k8s), but it's not the part of the job I particularly like, nor is it what I spend most of my time doing. >I believe our (non-container) machines are running nightly updates of OS and other packages via `apt-get update` etc. That is definitely a pre-immutability world, which certainly has it's own problems. With containers, you would effectively do the same thing. The workflow is: 1. Pick a base image (e.g. debian:latest) and write a Dockerfile based on that. Add any system libraries or other configuration you need here. Run apt-get upgrade. 2. Build your image and give it a version tag. 3. Rebuild the image nightly and bump up the version tag. 4. Perform a rolling upgrade to the new docker image in k8s or whatever. There are more elaborate workflows, but I've never needed anything else. Note also that k8s is not necessary at all (and arguably not worthwhile). >it seems there is some controversy over how people actually do this with container-based infrastructure, especially on small teams... I think this is spot on. Containers are quite general tools, and there are quite a few reasons to use them. Personally -- and I suspect this is where you might benefit as well -- I use Docker to standardize the runtime environment. That's basically it. The benefit of having the same runtime environment across dev machines, and in production has been incalculable. YMMV, of course.