2 回答
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.
The answer is, as for many other docker-related issues, to ditch docker and switch to buildah. Both the buildah bud, which is drop-in replacement for docker build, and the buildah commit, which is for scripting the build by other means, have a --timestamp option that forces both the timestamp written to the manifest and the timestamps of files in the new layers to specified value. That seems to be the only nondeterminism from the tool itself; standard deterministic build techniques still need to be applied to the build of the application itself, but that's obviously out of buildah scope.