4 ms·
The worst so-called “best practice” for Docker
- carlosf 6y agoKinda agree with the author. I also realized a while ago that pinning Dockerfile dependencies is a terrible practice unless you want to hire people to basically do Dockerfile maintenance. BTW this site is full of gems I had to learn through pain and suffering. Wish I could have read it ~ 3 years ago.
- happymellon 6y agoTo be honest, this is why I always create my own patched base image that I schedule with a regular update mechanism and build my applications on top of those. If my pipeline fails the tests I can always go back to the last successful base build to unblock the current deployment and we have security patches up to a few days ago. I can then investigate what exactly has broken in the last week's set of patches. Please stop using the raw Ubuntu or Alpine images, it doesn't take much to use your favourite CI scheduler to regularly build a patched Ubuntu/Alpine which you can then use as the basis of your application and remove the fear of regular patching.
- philipswood 6y agoUm,the most important rationale isn't mentioned, which is worrying. Part of the original reasoning behind the "best practice" is that it creates bloated images. Since the overlay filesystem captures the deltas from the base image, when you upgrade you create a bigger container than required since it contains both the original base image with un-upgraded files PLUS the deltas with the upgrade differences. If the base isn't being reused with other images on a machine this is wasteful (even if only conceptually). As always the decision to upgrade anyway is an engineering trade-off, but clearly - if possible - starting from an un-upgraded base image would be ideal.