Slide 1

Slide 1 text

Twelve-Factor app with Docker Posobota 107. @ujovlado

Slide 2

Slide 2 text

whoami Developer at Keboola interested in infrastructure/devops and UI/UX building data platform Keboola Connection writing about it at 500.keboola.com Occasional speaker, geek and blogger twitter.com/ujovlado medium.com/@ujovlado ujovlado.dev 2

Slide 3

Slide 3 text

What is Twelve-Factor app? https://12factor.net 3

Slide 4

Slide 4 text

I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment 4

Slide 5

Slide 5 text

IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes 5

Slide 6

Slide 6 text

VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown 6

Slide 7

Slide 7 text

X. Dev/prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes 7

Slide 8

Slide 8 text

Twelve-Factor app with Docker 8

Slide 9

Slide 9 text

I. Codebase, II. Dependencies Doesn't matter if you have Docker or not 9

Slide 10

Slide 10 text

III. Config Environment variables passed to container Typical example: APPLICATION_ENV=dev/prod Then decide if debug mode, extended logging is turned off/on or if there will be more verbose output You can use configuration file and pass it to app at "startup" phase File downloaded from some storage (e.g. AWS S3) Use "credentials storage" and create file manually 10

Slide 11

Slide 11 text

IV. Backing services Everything outside of an app is a resource for you Container has to be ready to use different "provider" in seconds Typical examples: Local MySQL in other container vs. RDS SMTP configuration 11

Slide 12

Slide 12 text

V. Build, release, run Copy whole code to image, install dependencies Push image to image repository Run container (optionally override ENTRYPOINT and CMD) There are no symlinks, when you need to deploy new version you start container with different image 12

Slide 13

Slide 13 text

VI. Processes You should never run more services in one container If there are more processes, these processes should be child processes of main service (e.g. Apache) Workers has typically one process If main process (PID: 1) ends, container should end too 13

Slide 14

Slide 14 text

VII. Port binding Your service should be a "black box" exposing only a port (and load balancer will forward traffic to this port) Very easy with Docker FROM php:7.3-apache Image with PHP and Apache which already exposing port 80 14

Slide 15

Slide 15 text

VIII. Concurrency If processes are stateless there should'n be problem with concurrency You just start more containers 15

Slide 16

Slide 16 text

IX. Disposability Docker image is pulled before first deploy, start will be fast More important is SIGTERM handling Example: Worker is processing messages from queue and after SIGTERM signal it will stop requesting more, process last message and end with 0 code 16

Slide 17

Slide 17 text

X. Dev/prod parity Local build of image and code mounted as volume 17

Slide 18

Slide 18 text

XI. Logs App should not care how its logs will be processed Log everything to stdout Other service will process your logs Other container with mounted Docker socket sending logs to other service Orchestration service will send logs to other service Syslog is overhead 18

Slide 19

Slide 19 text

XII. Admin processes Same as other services, container ends after processing Example: DB migrations, Garbage Collection 19

Slide 20

Slide 20 text

Questions?