Dockerflow is a specification for automated building, testing and publishing of docker web application images that comply to a common set of behaviours. Compliant images are simpler to deploy, monitor and manage in production.
The specification is this README.md file. This repo contains a reference application that will change with the specification. See the Contribution document for details on suggesting changes and providing feedback.
+-(1)--+ +-(2)-------------+ +-(3)-------+ +-(4)--------+
| Code | | CI builds and | | Docker | | Container |
| Push | ------> | tests container | -----> | Hub | -----> | Deployment |
+------+ +-----------------+ +-----------+ +------------+
The specification has requirements that a container must comply with. Recommendations are optional but encouraged if they are suitable for the application.
Dockerflow requires an automated build and test tool that meets these requirements:
Within Mozilla, we support the use of CircleCI, Taskcluster, or Github Actions.
When the application is ran in the container it must:
$PORT
for HTTP requests./app/version.json
./__version__
with the contents of /app/version.json
./__heartbeat__
with a HTTP 200 or 5xx on error. This should check backing services like a database for connectivity and may respond with the status of backing services and application components as a JSON payload./__lbheartbeat__
with an HTTP 200. This is for load balancer checks and should not check backing services.stdout
or stderr
./app
directory in the container.app
group with a GID of 10001
.app
user with a UID of 10001
and is a member of the app
group.ENTRYPOINT
and CMD
instructions to start the service.USER app
instruction to set the default user.stdout
in the
mozlog json schema.Internal processes for managing DOCKER_USER
and DOCKER_PASS
per-project are documented in hiera-sops/misc/dockerhub/
.