Twelve-Factor app with Docker Posobota 107. @ujovlado 

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 

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

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 

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 

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 

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 

Twelve-Factor app with Docker 8 

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

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 

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 

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 

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 

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 

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

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 

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

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 

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

Questions?