The Twelve Factors

In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:

Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
And can scale up without significant changes to tooling, architecture, or development practices.

The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).

Extended Context

Modes and Environment Variables
Secrets

Other resources

Raw

13-Modes-and-Environment-Variables.md

Modes and Environment Variables

You can specify env variables by placing the following files in your project root:

.env                # loaded in all cases
.env.local          # loaded in all cases, ignored by git
.env.[mode]         # only loaded in specified mode
.env.[mode].local   # only loaded in specified mode, ignored by git
.env.production     # will take higher priority than a generic .env

An env file simply contains key=value pairs of environment variables:

FOO=bar
DB_USER=user
DB_PASSWORD=secret

Env Loading Priorities

An env file for a specific mode (e.g. .env.production) will take higher priority than a generic one (e.g. .env).

In addition, environment variables that already exist when the application is executed have the highest priority and will not be overwritten by .env files.

Raw

14-Secrets.md

Secrets

As an alternative to passing sensitive information via environment variables, _FILE may be appended to the listed environment variables, causing the initialization script to load the values for those variables from files present in the container.

e.g. In particular, this can be used to load passwords from Docker/Kubernetes secrets stored files.

Example

Implementations

DB_USER=user
DB_USER_FILE=/run/secrets/mysql-root-user

DB_PASSWORD=secret
DB_PASSWORD_FILE=/run/secrets/mysql-root-passwd

Docker

$ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql-root -d mysql:tag

See more: https://docs.docker.com/engine/swarm/secrets/

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: mysql
spec:
  containers:
  - name: mysql
    image: mysql:tag
    env:
    - name: MYSQL_ROOT_PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysql-credential
          key: mysql-root-password

See more: https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/

socheatsok78/00-README.md