4 ms·
In no way should the advice be taken to be never `yum update`. Perhaps the article could have been clearer, but the advice is more subtle than it first appears
by gtrevorjay 11y ago
In no way should the advice be taken to be never `yum update`.
Perhaps the article could have been clearer, but the advice is more subtle than it first appears. It ties into point 4 ("Don't use a single layer image"). You need to `yum update` at the right time to make good use of layering and to be able to control updates separately from builds.
Imagine you build both Nginx and Apache containers off the same distro image. Rather than having `RUN yum -y update && yum -y clean all` as the first step (which is easy to mess up or forget), you can instead build an "update" layer as a named image with it's own Dockerfile consisting solely of the `yum update`. Now your two application Dockerfiles can simply `from base-update-date`. This means you control when you get updates explicitly orthogonal to the application build and lets you run the two apps off slightly different versions, if there is indeed an issue you need time to resolve regarding backwards compatibility. This also means you get the most out of the caching mechanisms in Docker.
Full disclosure - I am both a hatter and a sec guy.
[edit, spelling, grammar]
- fatherlinnux 11y agoAgreed, that's why I published this: http://rhelblog.redhat.com/2016/02/24/container-tidbits-can-good-supply-chain-hygiene-mitigate-base-image-sizes/ http://rhelblog.redhat.com/2016/02/24/container-tidbits-can-...
- fatherlinnux 11y agoAgain, this is recursion, if the upstream maintainer for the Apache and Nginx images is doing their job, the "yum update" should do nothing. Though, I agree, it's very important to highlight that too much branching can cause massive environment bloat and way too many permutations. If we just tell everyone to do yum updates at their layer this problem goes away. Ahh, recursion...
- gtrevorjay 11y agoThe issue is one of process/collaboration/composition. Even at the largest of distros, package maintainers usually act with pseudo independence. They can change, QA, and push their packages basically at will. Images are collections of those pushes. Even with automation the aggregate nature of images makes them qualitatively different and---especially organizationally---provides a process challenge.
- garethadams 11y agoWell, apart from "6) Don’t use only the “latest” tag". If I'm not using latest, and I don't know that the Apache and Nginx images have been updated, then it's very likely that "yum update" might do something.
- fatherlinnux 11y agoWhich is why I like your rhel7-update-date methodology to solve this....