Understand Engine plugins You can extend the capabilities of the Docker Engine by loading third-party plugins. This page explains the types of plugins and provides links to several volume and network plugins for Docker. Types of plugins Plugins extend Docker’s functionality. They come in specific types. For example, a volume plugin might enable Docker volumes to persist across multiple Docker hosts and a network plugin might provide network plumbing. Currently Docker supports authorization, vol

stop Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...] Stop a container by sending SIGTERM and then SIGKILL after a grace period --help Print usage -t, --time=10 Seconds to wait for stop before killing it The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.

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

Run a local registry mirror The original content was deprecated. An archived version is available in the 1.7 documentation. For information about configuring mirrors with the latest Docker Registry version, please file a support request with the Distribution project.

Create an authorization plugin Docker’s out-of-the-box authorization model is all or nothing. Any user with permission to access the Docker daemon can run any Docker client command. The same is true for callers using Docker’s remote API to contact the daemon. If you require greater access control, you can create authorization plugins and add them to your Docker daemon configuration. Using an authorization plugin, a Docker administrator can configure granular access policies for managing access

docker.io accounts API Get a single user GET /api/v1.1/users/:username/ Get profile info for the specified user. Parameters: username – username of the user whose profile info is being requested. Request Headers: Authorization – required authentication credentials of either type HTTP Basic or OAuth Bearer Token. Status Codes: 200 – success, user data returned. 401 – authentication error. 403 – permission error, authenticated user must be the user whose data is being requested, OAuth ac

save Usage: docker save [OPTIONS] IMAGE [IMAGE...] Save one or more images to a tar archive (streamed to STDOUT by default) --help Print usage -o, --output="" Write to a file, instead of STDOUT Produces a tarred repository to the standard output stream. Contains all parent layers, and all tags + versions, or specified repo:tag, for each argument provided. It is used to create a backup that can then be used with docker load $ docker save busybox > busybox.tar $ ls -sh bu

Using certificates for repository client verification In Running Docker with HTTPS, you learned that, by default, Docker runs via a non-networked Unix socket and TLS must be enabled in order to have the Docker client and the daemon communicate securely over HTTPS. TLS ensures authenticity of the registry endpoint and that traffic to/from registry is encrypted. This article demonstrates how to ensure the traffic between the Docker registry (i.e., a server) and the Docker daemon (i.e., a client)

Docker and the Device Mapper storage driver Device Mapper is a kernel-based framework that underpins many advanced volume management technologies on Linux. Docker’s devicemapper storage driver leverages the thin provisioning and snapshotting capabilities of this framework for image and container management. This article refers to the Device Mapper storage driver as devicemapper, and the kernel framework as Device Mapper. Note: The Commercially Supported Docker Engine (CS-Engine) running on RHE

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", }