12 factor applications

Applications that run in container orchestration platforms should meet certain requirements. One discussion of how applications should be written and configured is the 12 factor application

  1. Codebase: One codebase in version control, many deploys

  2. Dependencies: Explicitly declare and isolate dependencies

  3. Config: Store config in the environment

  4. Backing services: Treat backing services as attached resources

  5. Build, release, run: Strictly separate build and run stages

  6. Processes: Execute the app as one or more stateless processes

  7. Port binding: Export services via port binding

  8. Concurrency: Scale out via the process model

  9. Disposability: Maximize robustness with fast startup and graceful shutdown

  10. Dev/prod parity: Keep development, staging, and production as similar as possible

  11. Logs: Treat logs as event streams

  12. Admin processes: Run admin/management tasks as one-off processes

Almost all of these points have direct relevance when deploying container images to Kubernetes. Kubernetes is easiest to use and deploy to when your app explicitly addresses these points.

Docker images

  1. Build your image with specific version tags.

  1. Pipeline should build image, test image, push to docker repository, trigger deployment of new version to kubernetes.

  1. One process per image if possible. You can side-load secondary containers into Pods, but only do this if necessary.

  2. Expose your app via a known port on the image.

  1. Application MUST be running on PID 1 in the container.

  2. By externalising all configuration, running in a container automatically supplies this.

Application design

  1. Have your application read configuration from environment variables. If a config file is necessary, have this read from a fixed volume endpoint on the image so you can use a ConfigMap (See Container Configuration)

  2. Read service connection parameters from environment. These can be mapped from the env variables that Kubernetes creates with each service resource.

  1. Do not use or assume session affinity exists in your application. Session state must be explicitly managed and stored in a backing service.

  2. Application should shutdown gracefully on receiving a SIGTERM signal. Applications should expose a health endpoint, or have other means of detecting a process in an unhealthy state. See Detection of unhealthy containers for more information.

  1. Application MUST output logs to stdout only. Using some kind of structured log library, and/or exposing the logs as json will allow easy parsing and splitting of log data into categories.

  2. Write separate docker images or container commands for performing admin tasks. Run these using a Job controller