4 ms·

Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application).

Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application). They're also meant to be mostly immutable. So a vulnerability in a particular library that allows an attacker access to the container won't necessarily allow them to do much. The other benefit of short-lived containers is that any given vulnerability only lasts as long as the container (assuming you're rebuilding your image with the latest & greatest software/libs before each deployment). Whereas with a full OS/VM you have to find down time to patch that sucker and that might take a month or even a quarter or longer.

pmontra 10y ago
I'm not sure I understand this. Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?
- tayo42 10y ago
  Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...
  - riskable 10y ago
    Running a traditional relational DB inside a container is pretty stupid. It can take a while for those suckers to stop & start and they often don't work properly if placed behind a load balancer with random distribution of connections. Also, if a connection gets cut off in the middle of a transactions things can go very, very wrong. On the other hand, if you architect your database usage in such a way as to ensure that cutoff transactions get detected and retried without relying on persistent connections it can be a good idea to use containers for hosting your database(s). Of course, your use case needs to fit this kind of model for it to work. If your use case requires mostly serial transactions and can't work with "eventual consistency" then containers are probably a no-go.
- riskable 10y ago
  > We should build a new container after each apt-get for security patches, right? Yes. That's the idea. Here's when and why you re-deploy: * A new, updated version of software/a package is out. * You've made changes to your app. Even something as simple as a typo. * Your container has been up too long (e.g. 24 hours). Replacing existing containers multiple times a day in a production environment is the norm. "The only constant is change" and the more often things change the more often you'll be swapping out your containers for new ones. The whole point of containers is that they can be brought up and down in an instant without impact (if you architect things correctly). So even a VM that runs "apt-get update ; apt-get -y upgrade" every night may not be as up-to-date or secure as the same software running inside a container.

pmontra 10y ago

I'm not sure I understand this. Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?

tayo42 10y ago
Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...
- riskable 10y ago
  Running a traditional relational DB inside a container is pretty stupid. It can take a while for those suckers to stop & start and they often don't work properly if placed behind a load balancer with random distribution of connections. Also, if a connection gets cut off in the middle of a transactions things can go very, very wrong. On the other hand, if you architect your database usage in such a way as to ensure that cutoff transactions get detected and retried without relying on persistent connections it can be a good idea to use containers for hosting your database(s). Of course, your use case needs to fit this kind of model for it to work. If your use case requires mostly serial transactions and can't work with "eventual consistency" then containers are probably a no-go.
riskable 10y ago
> We should build a new container after each apt-get for security patches, right? Yes. That's the idea. Here's when and why you re-deploy: * A new, updated version of software/a package is out. * You've made changes to your app. Even something as simple as a typo. * Your container has been up too long (e.g. 24 hours). Replacing existing containers multiple times a day in a production environment is the norm. "The only constant is change" and the more often things change the more often you'll be swapping out your containers for new ones. The whole point of containers is that they can be brought up and down in an instant without impact (if you architect things correctly). So even a VM that runs "apt-get update ; apt-get -y upgrade" every night may not be as up-to-date or secure as the same software running inside a container.