In this session, we compiled 10 horror Dockerfiles don'ts, a.k.a “Dockerfails”. To end on an optimistic note, we will showcase the maximum good practices in some popular CI/CD tools (github/gitlab/jenkins) with a touch of GitOps.

This talk will cover, From our experiences, the worst 9 “fails” that developers from all languages could benefit from and put those “Dockerfails” in 3 main areas: 1 — “Code” Area Dockerfail #1 — throw everything in it and mix. (good practice: use linter, syntaxt checker) Dockerfail #2 — rebuild it and then test the app by hand (good practice: write container unit tests) Dockerfail #3 — the production-like misunderstanding (good practice: leverage multi stage including debug tooling) 2 — “Build” Area Dockerfail #4 — ignore cache and download internet at your own risk (aggressively optimize for caching) Dockerfail #5 — blindly include secrets and vulnerabilities (good practice: scan and sign) Dockerfail #6 — tags are mutable, changes get lost (good practice: push diffs in git) 3 — “Run” Area Dockerfail #7 — health checks can kill your production (good practice: take time to design a real world healthcheck) Dockerfail #8 — multiple processes in same contanier/pod do not scale (good practice: split services) Dockerfail #9 — security as a second thought (good practice: collect and track SBOM on each deploy) A bonus 10th tip will highlight that there are other options on building container images (Buildpack, JIB, ...) Demo : a sample pipeline fixing all previous “fails” using a gitops approach

Mohammed is a community catalyst, a true open source believer, Google developer expert and has contributed to various open-source projects. He currently works at Spotify as a Backend engineer