3 ms·
> Uh, no, you don't ever overwrite a release. You build new versions, test them, deploy them, and if you find a bug along the way, you roll back. No, not reall
by rumanator 6y ago
> Uh, no, you don't ever overwrite a release. You build new versions, test them, deploy them, and if you find a bug along the way, you roll back.
No, not really. You pull from image:latest, or debian, or debian:stable, or debian:stretch, or debian:stretch-slim. That's what you use as base images. The reason you do that is security. You need to incorporate security updates in your Docker images, and in order to ensure your images always incorporate the latest bug fixes and security updates you simply pull from the default base images expecting them to be continuously updated.
- peterwwillis 6y agoYou absolutely should not ship updates by pulling from an unversioned tag; it's bad for a number of reasons. There's some simple ways to avoid it: # In your CI pipeline, something like this: $ cat Dockerfile ARG release_tag FROM baseimg:${release_tag} # etc; i think the container metadata keeps the base version, or you can store it in the container with a RUN line $ base_version_tag=$(./get-latest-versioned-tag.sh some-docker-repo:my_prefix/my_image:stable) $ new_container_version=$(./make-new-version.sh) $ docker build -t my_img:${new_container_version} --build-arg release_tag=${base_version_tag} Then you run your tests on the new image, maybe do a gradual deployment, and can quickly roll back to the last base image or skip broken versions. Your own container version is always rolling-forward, and you can revert the base image version at any time. If you do this with a specific stable tree (like debian:8-stable or something) you should only get security updates, but if you use :latest, that's a total nightmare.