3

I have just changed a Dockerfile with a RUN git clone ... instruction such that it now can notice changes in the Git repository and rebuild accordingly. This has required working around Docker's normal caching mechanism.

I've chosen a mechanism that introduces an ARG that holds Git commit hash of the repository's head, as suggested here. I've also taken notice of an alternative mechanism that copies a similar version "hash" by means of an ADD instruction, as suggested here.

The same Dockerfile also installs several (Debian) packages by means of RUN apt-get install -y .... Therefore I am wondering: Are there similar workarounds for (partially) rebuilding a Docker image if any of the packages received (security) updates? Based on the aforementioned ADD-based workaround I could e.g. imagine something based on a web service that receives key/value pairs consisting of package names/version numbers and that returns an eligible "hash" in the case of pending (security) updates. Does such a specific component exist or are there more general best practices for covering such a use case?

rookie099
  • 2,201
  • 2
  • 26
  • 52

1 Answers1

3

I would say this is the biggest weakness that docker has not solved at all.

The usual workaround afaik is to rebuild the image from scratch nightly (on a build server?) and then auto promote it to production if the your tests run fine against it.

dwt
  • 128
  • 1
  • 7
  • Yes, that's what I ultimately had to adopt as well. – rookie099 Mar 04 '22 at 14:40
  • 1
    On some servers, I actually took the route that I pulled the image nightly and just add a layer with the latest security updates and then restart the app. That all packages up nicely in a systemd.unit and a cron job. See here for details: https://issues.apache.org/jira/browse/SOLR-15967?focusedCommentId=17485758&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17485758 – dwt Mar 05 '22 at 19:43