Build a Swarm cluster for production This page teaches you to deploy a high-availability Docker Swarm cluster. Although the example installation uses the Amazon Web Services (AWS) platform, you can deploy an equivalent Docker Swarm cluster on many other platforms. In this example, you do the following: Verify you have the prequisites Establish basic network security Create your nodes Install Engine on each node Configure a discovery backend Create Swarm cluster Communicate with the Swarm Test t

Docker and Btrfs in practice Btrfs is a next generation copy-on-write filesystem that supports many advanced storage technologies that make it a good fit for Docker. Btrfs is included in the mainline Linux kernel and its on-disk-format is now considered stable. However, many of its features are still under heavy development and users should consider it a fast-moving target. Docker’s btrfs storage driver leverages many Btrfs features for image and container management. Among these features are t

Breaking changes and incompatibilities Every Engine release strives to be backward compatible with its predecessors. In all cases, the policy is that feature removal is communicated two releases in advance and documented as part of the deprecated features page. Unfortunately, Docker is a fast moving project, and newly introduced features may sometime introduce breaking changes and/or incompatibilities. This page documents these by Engine version. Engine 1.10 There were two breaking changes in t

Best practices for writing Dockerfiles Docker can build images automatically by reading the instructions from a Dockerfile, a text file that contains all the commands, in order, needed to build a given image. Dockerfiles adhere to a specific format and use a specific set of instructions. You can learn the basics on the Dockerfile Reference page. If you’re new to writing Dockerfiles, you should start there. This document covers the best practices and methods recommended by Docker, Inc. and the D

Automation with content trust Your automation systems that pull or build images can also work with trust. Any automation environment must set DOCKER_TRUST_ENABLED either manually or in a scripted fashion before processing images. Bypass requests for passphrases To allow tools to wrap docker and push trusted content, there are two environment variables that allow you to provide the passphrases without an expect script, or typing them in: DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE DOCKER_CONTENT_TRUST_

Automatically start containers As of Docker 1.2, restart policies are the built-in Docker mechanism for restarting containers when they exit. If set, restart policies will be used when the Docker daemon starts up, as typically happens after a system boot. Restart policies will ensure that linked containers are started in the correct order. If restart policies don’t suit your needs (i.e., you have non-Docker processes that depend on Docker containers), you can use a process manager like upstart,

Docker and AUFS in practice AUFS was the first storage driver in use with Docker. As a result, it has a long and close history with Docker, is very stable, has a lot of real-world deployments, and has strong community support. AUFS has several features that make it a good choice for Docker. These features enable: Fast container startup times. Efficient use of storage. Efficient use of memory. Despite its capabilities and long history with Docker, some Linux distributions do not support AUFS.

Apply custom metadata You can apply metadata to your images, containers, or daemons via labels. Labels serve a wide range of uses, such as adding notes or licensing information to an image, or to identify a host. A label is a <key> / <value> pair. Docker stores the label values as strings. You can specify multiple labels but each <key> must be unique or the value will be overwritten. If you specify the same key several times but with different values, newer labels overwrite pr

AppArmor security profiles for Docker AppArmor (Application Armor) is a Linux security module that protects an operating system and its applications from security threats. To use it, a system administrator associates an AppArmor security profile with each program. Docker expects to find an AppArmor policy loaded and enforced. Docker automatically loads container profiles. The Docker binary installs a docker-default profile in the /etc/apparmor.d/docker file. This profile is used on containers,

Understand the Swarm vs. Engine response codes Docker Engine provides a REST API for making calls to the Engine daemon. Docker Swarm allows a caller to make the same calls to a cluster of Engine daemons. While the API calls are the same, the API response status codes do differ. This document explains the differences. Four methods are included, and they are GET, POST, PUT and DELETE. The comparison is based on api v1.22, and all Docker Status Codes in api v1.22 are referenced from docker-remote-