时间戳

首页 > 解决方案 > 需要时重建容器

docker - 需要时重建容器

问题描述

标签： dockerkubernetescontinuous-integrationjibbuildah

解决方案

Running docker build --pull --no-cache once a week or so is a reasonable compromise. It's highly likely there will be some fix in the OS-level packages in that time frame, so you're going to be restarting the container with a new image to get security updates, which is reasonable. Depending on how often you deploy to production, "on every production deploy" may or may not be a good time to do this as well.

If consistency across environments is important to you, consider using a date-stamped version of the debian image (FROM debian:stable-20200422), or building your own base image that you can store in a registry. You can then use a Dockerfile ARG to specify the date stamp, and if you do that, you never need --no-cache. (But, you will have to manually discover the current version.)

# Build with
#   docker build --build-arg DATE_STAMP=-20200422
# This must have a leading hyphen
ARG DATE_STAMP

FROM debian:stable${DATE_STAMP:-}

For language packages, also consider that most package managers have a lock file that specifies an exact version of packages to use (NPM package-lock.json, yarn.lock, Ruby Bundler Gemfile.lock, Python requirements.txt or Pipfile.lock). In these cases you have to run some sort of "update" operation to update the lock file; doing that generates a commit, which triggers the CI system, and a file change, which will invalidate the Docker build cache.

推荐阅读