3 ms·

I think I might have the complementary partial understanding to yours, so I'm interested in comparing notes. I use containers quite often. In my mind, it's ju

I think I might have the complementary partial understanding to yours, so I'm interested in comparing notes. I use containers quite often. In my mind, it's just like managing a physical server -- I'm responsible for configuration/patching/system upgrades/etc -- but with the significant upside that I obtain a (mostly) reproducible environment in which to run the software. This is the part I really can't live without anymore. I don't have to deal with builds from a colleague that don't work on my machine. >How one is meant to know when a patch is required and how one applies it, what the "conventional" or "best practice" workflow for this is. How do you do this without containers?

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

jrochkind1 5y ago

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