Dockerfile best practices
0 likes122 views
This document discusses best practices for writing Dockerfiles. It recommends writing Dockerfiles that produce smaller image sizes for better security, performance and efficiency. Specific tips include using slimmer base images like Alpine Linux, removing unnecessary files and dependencies, leveraging multistage builds, and optimizing build time through caching and parallelization with Buildkit. The document also stresses security practices like avoiding the root user, consistency through version pinning and official images, and reducing attack surface through minimal images.
Dockerfile best practices
- 1. Dockerfile Best Practices Bhushan Lodha Tuesday 7th July 2020, 6pm Senior Software Consultant
- 2. Why should I care about writing good dockerfile? ➔ Image size ◆ Smaller image size improves security, performance, efficiency, and maintainability of your containers ➔ Build time ◆ Reducing build time can significantly reduce your app’s development cost ➔ Security ◆ Important to protect your app from external attacks ➔ Consistency ◆ Consistent images are easier to maintain
- 3. Reduce Image Size Faster deploys, smaller attack surface
- 4. Image Variants Image Size ruby:2.7 842mb ruby:2.7-slim 149mb ruby:2.7-alpine 52mb
- 5. Base Image Ubuntu/Debian Alpine Built around GNU C library Built around musl libc More mature Less mature More stable Less stable More 3rd party packages Fewer 3rd party packages Less memory efficient More memory efficient Bigger base image footprint Smaller base image footprint Premature optimization is root of (all) evil
- 6. Remove unnecessary dependencies before 726mb after 692mb
- 7. Remove package manager cache, logs & docs before 692mb after 674mb
- 8. Remove unnecessary application files ➔ Test files ➔ Asset files ➔ Documentation ➔ Application dependency test files ➔ Application cache ➔ Dependency cache
- 9. Use multistage builds to separate build & runtime env before 674mb after 301mb
- 10. Reduce Build Time Leverage build cache
- 11. Order matters! Order from least to most frequently changing content
- 12. Copy specific file to limit cache busts
- 14. Use Buildkit ➔ Second generation image builder ➔ Parallel build execution ➔ Much faster and more accurate caching mechanism
- 15. Enable Buildkit
- 16. Buildkit: Parallel Build Execution 1 2 3 1 2 3 with buildkit without buildkit
- 17. Buildkit performance benchmarking Based on the docker build from scratch, the results are 2.5x faster source: https://www.xenonstack.com/blog/docker-buildkit/
- 18. Buildkit performance benchmarking Rerunning the same build with local cache the speed is 7x faster. source: https://www.xenonstack.com/blog/docker-buildkit/
- 19. Buildkit performance benchmarking Repeatable docker builds with new source code leads to 2.5 fx faster build speed. source: https://www.xenonstack.com/blog/docker-buildkit/
- 20. Security
- 21. Avoid running your application as a root user
- 22. Use --chown when running ADD or COPY
- 23. Consistency Consistent image is easier to maintain
- 24. Pin base image version
- 26. Use official images when possible
- 27. Set Locale Often overlooked but very important
- 28. Questions?