Search code examples
dockerdeploymentcontainersproduction

How to update my app when I deploy it using docker

I'm deployed a nodejs app using docker, I don't know how to update the deploy after my nodejs app updated.

Currently, I have to remove the old docker container and image when updating the nodejs app each time.

I expect that it's doesn't need to remove the old image and container when I nodejs app updated.

Solution

  • You tagged this "production". The standard way I've done this is like so:

    1. Develop locally without Docker. Make all of your unit tests pass. Build and run the container locally and run integration tests.

    2. Build an "official" version of the container. Tag it with a time stamp, version number, or source control tag; but do not tag it with :latest or a branch name or anything else that would change over time.

    3. docker push the built image to a registry.

    4. On the production system, change your deployment configuration to reference the version tag you just built. In some order, docker run a container (or more) with the new image, and docker stop the container(s) with the old image.

    5. When it all goes wrong, change your deployment configuration back to the previous version and redeploy. (...oops.) If the old versions of the images aren't still on the local system, they can be fetched from the registry.

    6. As needed docker rm old containers and docker rmi old images.

    Typically much of this can be automated. A continuous integration system can build software, run tests, and push built artifacts to a registry; cluster managers like Kubernetes or Docker Swarm are good at keeping some number of copies of some version of a container running somewhere and managing the version upgrade process for you. (Kubernetes Deployments in particular will start a copy of the new image before starting to shut down old ones; Kubernetes Services provide load balancers to make this work.)

    None of this is at all specific to Node. As far as the deployment system is concerned there aren't any .js files anywhere, only Docker images. (You don't copy your source files around separately from the images, or bind-mount a source tree over the image contents, and you definitely don't try to live-patch a running container.) After your unfortunate revert in step 5, you can run exactly the failing configuration in a non-production environment to see what went wrong.

    But yes, fundamentally, you need to delete the old container with the old image and start a new container with the new image.