Using Supervisor with Docker Note: - If you don’t like sudo then see Giving non-root access Traditionally a Docker container runs a single process when it is launched, for example an Apache daemon or a SSH server daemon. Often though you want to run more than one process in a container. There are a number of ways you can achieve this ranging from using a simple Bash script as the value of your container’s CMD instruction to installing a process management tool. In this example you’re going to

Oracle VirtualBox Create machines locally using VirtualBox. This driver requires VirtualBox 5+ to be installed on your host. Using VirtualBox 4.3+ should work but will give you a warning. Older versions will refuse to work. $ docker-machine create --driver=virtualbox vbox-test You can create an entirely new machine or you can convert a Boot2Docker VM into a machine by importing the VM. To convert a Boot2Docker VM, you’d use the following command: $ docker-machine create -d virtualbox --virtual

Google Compute Engine Create machines on Google Compute Engine. You will need a Google account and a project id. See https://cloud.google.com/compute/docs/projects for details on projects. Credentials The Google driver uses Application Default Credentials to get authorization credentials for use in calling Google APIs. So if docker-machine is used from a GCE host, authentication will happen automatically via the built-in service account. Otherwise, install gcloud and get through the oauth2 proc

Legacy container links The information in this section explains legacy container links within the Docker default bridge. This is a bridge network named bridge created automatically when you install Docker. Before the Docker networks feature, you could use the Docker link feature to allow containers to discover each other and securely transfer information about one container to another container. With the introduction of the Docker networks feature, you can still create links but they behave dif

Docker Remote API v1.23 1. Brief introduction The Remote API has replaced rcli. The daemon listens on unix:///var/run/docker.sock but you can Bind Docker to another host/port or a Unix socket. The API tends to be REST. However, for some complex commands, like attach or pull, the HTTP connection is hijacked to transport stdout, stdin and stderr. When the client API version is newer than the daemon’s, these calls return an HTTP 400 Bad Request error message. 2. Endpoints 2.1 Containers List con

join — Create a Swarm node Prerequisite: Before using join, establish a discovery backend as described in this discovery topic. The join command creates a Swarm node whose purpose is to run containers on behalf of the cluster. A typical cluster has multiple Swarm nodes. To create a Swarm node, use the following syntax: $ docker run swarm join [OPTIONS] <discovery> For example, to create a Swarm node in a high-availability cluster with other managers, enter: $ docker run -d swarm join --a

scale Usage: scale [SERVICE=NUM...] Sets the number of containers to run for a service. Numbers are specified as arguments in the form service=num. For example: $ docker-compose scale web=2 worker=3

events Usage: events [options] [SERVICE...] Options: --json Output events as a stream of json objects Stream container events for every container in the project. With the --json flag, a json object will be printed one per line with the format: { "service": "web", "event": "create", "container": "213cf75fc39a", "image": "alpine:edge", "time": "2015-11-20T18:01:03.615550", }

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

Controlling startup order in Compose You can control the order of service startup with the depends_on option. Compose always starts containers in dependency order, where dependencies are determined by depends_on, links, volumes_from and network_mode: "service:...". However, Compose will not wait until a container is “ready” (whatever that means for your particular application) - only until it’s running. There’s a good reason for this. The problem of waiting for a database (for example) to be re