2 ms·

> How do you do this without containers? So I'm mostly in the "dev" rather than "ops" space (without containers I can stay out of it), but I believe our (non-c

> How do you do this without containers? So I'm mostly in the "dev" rather than "ops" space (without containers I can stay out of it), but 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. Alternately, perhaps you deploy to heroku, where you hope [right or wrong] "that's heroku's responsibility, I'm not sure how they deal with it, but i assume they do" Of course, the more "modern" alternative to heroku is some kind of k8 host (or using heroku's docker-based instead of traditional process)... which I gets puts the "patch vulnerabilities in OS" back in your lane again, even if you are paying for hosted K8 of some kind? That's among what I'm trying to get out of paying for PaaS! Looking at other comments in this HN post discussion (I confess I asked versions of this question a couple times)... it seems there is some controversy over how people actually do this with container-based infrastructure, especially on small teams...

omginternets 5y ago
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.

omginternets 5y ago

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.