Simplifying the Journey of Your Containerized Application from Dev to Production

Creating a containerized application PoC is deceptively simple. Making it production ready is a lot of work though. This talk will cover what’s necessary to have a production ready containerized application and the steps to get there. We’ll explore the best practices and gotchas containerizing applications. We’ll also compare creating production ready containers the hard way and the easy way.

Video: https://www.youtube.com/watch?v=8iJ_6VUzk1I

Transcript

1. Simplifying the Journey of Your Containerized Application from Dev to Production
2. The Problem
5. What We Need for Production
6. • Ops plane integrations (logging, metrics, monitoring) • Optimized build and deploy time • Security (vulnerabilities and capabilities that can be exploited) • Handling secrets properly • Persisting data • Resource limits for colocated containers
7. Let's Start the Journey
12. What’s Wrong?
14. • Big container image • Problems with build caching • Running as root • Only the major version of node is pinned
15. Common Gotchas
16. • Lack of version pinning turns into reproducibility problems • Cache busting instruction combinations cause slow builds • Large build contexts result in slow builds and bigger images • Not handling signals and not handling orphaned processes • Deleted data is not deleted if...
17. Let’s Improve the Dockerfile
20. Best Practices
21. • Single app/function • Pin versions for dependencies to have reproducible builds • Keep your image as small as possible • Minimize the number of layers • Structure layers for better build time caching • Make sure to handle zombie processes and signals properly • Don’t run as root • Harden container images • Don’t embed secrets or configs in container images • Use available security capabilities • Use container images as ‘promotion’ artifacts*
22. Alpine Gotchas
23. • Many musl libc related problems • Network/DNS problems • Performance problems • Crashes • Lots of package related headaches ◦ Hard to pin package versions ◦ Limited package availability ◦ Disappearing older packages ◦ Building your own packages can be challenging if they include native code • Lag in security updates • Limited vulnerability scanner coverage
24. Doing it the Hard Way
25. • Builder pattern or multi-stage builds • Using a small base image • Manually optimizing Dockerfile instructions* • Manually hardening container images :-(
32. Let’s Simplify
33. • Buildpacks (PaaS roots) • Build tool plugins (to generate Dockerfiles or images) • Project generators (e.g., Yeoman)
35. • Opinionated • Limited ability to customize • Complexity (not a problem when it all works) • Generated Dockerfile quality isn’t always great • Limited/basic optimizations
36. Optimizing with DockerSlim
37. • Keep your Dockerfile simple • No tricks with Dockerfile instructions • No need for multi-stage if you don’t want it • Same base image you are used to • Optimizes alpine, distroless and buildpack based images too
39. Summary
41. Key Takeaways
42. • Use buildpacks or app tool generated Dockerfiles if it works for you • For custom Dockerfiles where you need more control: ◦ Use non-root user in Dockerfiles ◦ Install your app dependencies first and your app code after • Use DockerSlim for advanced optimizations and security