Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. Twelve-Factor app with Docker
    Posobota 107.
    @ujovlado

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  8. Twelve-Factor app with Docker
    8

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide