$30 off During Our Annual Pro Sale. View Details »

Twelve-Factor app with Docker

Twelve-Factor app with Docker

Vladimír Kriška

October 26, 2019
Tweet

More Decks by Vladimír Kriška

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. VIII. Concurrency If processes are stateless there should'n be problem

    with concurrency You just start more containers 15
  12. 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
  13. 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
  14. XII. Admin processes Same as other services, container ends after

    processing Example: DB migrations, Garbage Collection 19