5 ms·

I'm just start to play with Docker, it seems like a nice way to build out contained systems that you don't want to change much ... but feels like it could lead

I'm just start to play with Docker, it seems like a nice way to build out contained systems that you don't want to change much ... but feels like it could lead to problems when it comes time to do updates to software inside the container. It feels like Docker offloads alot of responsibility for security updates from the ops to people in development. Or am I missing something ...

chc 12y ago
When you want to do updates, you can just replace the old container with a new one reflecting the updates.
- Leynos 12y ago
  The conceptual leap that I missed initially is the use of volumes, either mapped to data containers or to directories on the host system. These allow the persistent data used by the application in the container to live on, and for the container itself to be seen as immutable and easily replaceable.
vidarh 12y ago
It forces co-operation. As someone doing ops, and with years and years of development: ops teams should not do software upgrades without cooperating with developers and re-testing the full stack anyway. The odds of seemingly "safe" OS upgrades breaking applications are often high. If used properly Docker enforces pushing those upgrades back up the pipeline as far as they should.
- shykes 12y ago
  That's exactly right. Upgrades should be higher up in the process and involve the development and testing team. It doesn't mean the same people who run production can't also participate and offer guidance in the upgrade process upstream.
nubs 12y ago
Docker provides more flexibility. So while you can have developers managing security updates that is definitely not the only way of handling things. I see a process where ops are responsible for the base images (base os images, and layers for different software stacks) and can handle security updates at will. Developers can maintain small dockerfiles that just install their application on top of the ops-managed image. ops can then be in charge of building (and re-building) the images and deploying them. Of course, that can all be fine-tuned to your liking.

chc 12y ago

When you want to do updates, you can just replace the old container with a new one reflecting the updates.

Leynos 12y ago
The conceptual leap that I missed initially is the use of volumes, either mapped to data containers or to directories on the host system. These allow the persistent data used by the application in the container to live on, and for the container itself to be seen as immutable and easily replaceable.

vidarh 12y ago

It forces co-operation. As someone doing ops, and with years and years of development: ops teams should not do software upgrades without cooperating with developers and re-testing the full stack anyway. The odds of seemingly "safe" OS upgrades breaking applications are often high. If used properly Docker enforces pushing those upgrades back up the pipeline as far as they should.

shykes 12y ago
That's exactly right. Upgrades should be higher up in the process and involve the development and testing team. It doesn't mean the same people who run production can't also participate and offer guidance in the upgrade process upstream.

nubs 12y ago

Docker provides more flexibility. So while you can have developers managing security updates that is definitely not the only way of handling things. I see a process where ops are responsible for the base images (base os images, and layers for different software stacks) and can handle security updates at will. Developers can maintain small dockerfiles that just install their application on top of the ops-managed image. ops can then be in charge of building (and re-building) the images and deploying them. Of course, that can all be fine-tuned to your liking.