Simplifying the Journey of Your Containerized Application from Dev to Production

Slide 1

Slide 1 text

Slide 2

Slide 2 text

The Problem

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

What We Need for Production

Slide 6

Slide 6 text

● 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

Slide 7

Slide 7 text

Let's Start the Journey

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

What’s Wrong?

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

● Big container image ● Problems with build caching ● Running as root ● Only the major version of node is pinned

Slide 15

Slide 15 text

Common Gotchas

Slide 16

Slide 16 text

● 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...

Slide 17

Slide 17 text

Let’s Improve the Dockerfile

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Best Practices

Slide 21

Slide 21 text

● 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*

Slide 22

Slide 22 text

Alpine Gotchas

Slide 23

Slide 23 text

● 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

Slide 24

Slide 24 text

Doing it the Hard Way

Slide 25

Slide 25 text

● Builder pattern or multi-stage builds ● Using a small base image ● Manually optimizing Dockerfile instructions* ● Manually hardening container images :-(

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

Let’s Simplify

Slide 33

Slide 33 text

● Buildpacks (PaaS roots) ● Build tool plugins (to generate Dockerfiles or images) ● Project generators (e.g., Yeoman)

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

● Opinionated ● Limited ability to customize ● Complexity (not a problem when it all works) ● Generated Dockerfile quality isn’t always great ● Limited/basic optimizations

Slide 36

Slide 36 text

Optimizing with DockerSlim

Slide 37

Slide 37 text

● 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

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

Summary

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Key Takeaways

Slide 42

Slide 42 text

● 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