Docker development for web and mobile back ends

Docker suits teams that want one packaged runtime from development to deployment:

• You want the same image to run on a developer machine, in test and CI, and in deployment.
• You need a multi-service environment, such as an app, a database and a queue, described in one Compose file.
• You deploy to a single server or a remote Docker host. Docker's Compose documentation calls a single server the easiest way to deploy.
• You need images for more than one processor architecture, such as amd64 and arm64, from one build.

Docker is not the answer to every deployment need:

• You need to run across several servers. Compose targets one host, and its production guidance points to a Swarm cluster for scaling out; other orchestrators are a different tool.
• Your data must outlive the container. Anything not saved to a volume or other persistent storage is lost when the container is removed.
• You plan to use Docker Desktop in a larger organisation. Docker's terms require a paid subscription for professional use in larger organisations, so check the current terms. Docker Engine's terms are separate.
• The workload is a small script that already runs fine on the host. A container adds a layer you then have to maintain.

Docker's documentation defines an image as a read-only template with the instructions to create a container, and a container as a runnable instance of an image. A Dockerfile lists the commands that assemble the image. Multi-stage builds keep the final image small by leaving build tools behind. Registries, with Docker Hub as the public default, store and distribute images. Docker Compose describes an application of several containers, with their networks and volumes, in one YAML file. BuildKit and buildx can build one image for several platforms.

Volumes are storage managed by Docker that exists independently of any container, and Docker does not remove unused volumes automatically. Networks matter too: the default bridge network does not let containers find each other by name, while user-defined networks do.

• Small, cache-friendly images: a minimal base, multi-stage builds, and update and install commands combined in one step so a stale cached layer cannot hide a change.
• No unnecessary privileges: Docker's guidance is to switch to a non-root user when a service can run without privileges. We create the user explicitly.
• No secrets in images: build arguments and environment variables persist in the final image, so we use build secret or SSH mounts instead.
• Pinned base images: tags can change, so we pin to a digest and set up automated update pull requests for it.
• A clean build context: a .dockerignore file keeps irrelevant files out of the build.
• Production settings apart from development: a separate Compose override file for production changes such as removing code mounts and adding restart policies.

1. Containerise one service first: prove the image builds and runs the same everywhere before adding more
2. Write the environment down: Compose files and a short README so a new developer starts everything with one command
3. Handle data and secrets deliberately: volumes for state, secret mounts for credentials, nothing sensitive in the image
4. Hand over properly: the Dockerfiles and Compose files in your repository, and notes on how images are built, tagged and updated

Technology facts on this page are taken from the official documentation:

• Docker documentation: overview
• Docker documentation: Compose application model
• Docker documentation: Compose in production
• Docker documentation: build best practices
• Docker documentation: multi-platform builds
• Docker documentation: build secrets
• Docker documentation: volumes
• Docker documentation: Docker Desktop license