Twelve-Factor app with Docker

Twelve-Factor app with Docker

1633975316e340c5f24414567a3f3679?s=128

Vladimír Kriška

October 26, 2019
Tweet

Transcript

  1. Twelve-Factor app with Docker Posobota 107. @ujovlado

  2. 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
  3. What is Twelve-Factor app? https://12factor.net 3

  4. 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
  5. 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
  6. 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
  7. 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
  8. Twelve-Factor app with Docker 8

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

    or not 9
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. VIII. Concurrency If processes are stateless there should'n be problem

    with concurrency You just start more containers 15
  16. 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
  17. X. Dev/prod parity Local build of image and code mounted

    as volume 17
  18. 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
  19. XII. Admin processes Same as other services, container ends after

    processing Example: DB migrations, Garbage Collection 19
  20. Questions?