In today’s world, the basic unit of deployment is a container image. Once you build a container image, it can’t be changed; if you want to update the image you need to rebuild a new version.
When you start a container running, it’s instantiated from a container image, with the file system starting up a duplicate of that image’s contents. It’s certainly possible — in theory — to treat that container as if it were a server in the old-fashioned way of doing things: You could set things up so you could SSH into a container, and apply patches to it. But it’s a much, much better idea to build a new image with the patches and restart the container, for several reasons:
- Build once, and run as many instances as you want. You don’t need to patch each container individually; you only need to rebuild the image once, including the patched version of any packages that need to be updated, and then you can re-deploy the same code to all your container instances. Kubernetes and other orchestrators make it easy to do this with rolling upgrades.
Read more at The New Stack
