docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #26343 from sfsmithcha/2016-09-06-1.12.1-engine-docs-updates 

2016 09 06 1.12.1 engine docs updates
This commit is contained in:
Sven Dowideit 2016-09-07 22:15:21 +10:00 committed by GitHub
parent e98eafcc3c 11330bf048
commit 359f8fe426
54 changed files with 476 additions and 102 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/admin/ambassador_pattern_linking.md
View File

@ -70,7 +70,7 @@ On the Docker host (192.168.1.52) that Redis will run on:
# start actual redis server
$ docker run -d --name redis crosbymichael/redis
# get a redis-cli container for connection testing
# get a redis-cli image for connection testing
$ docker pull relateiq/redis-cli
# test the redis server by talking to it directly

8
docs/admin/index.md
View File

@ -25,7 +25,7 @@ or `systemd` to manage the `docker` daemon's start and stop.
### Running the docker daemon directly
The `docker` daemon can be run directly using the `dockerd` command. By default it listens on
The Docker daemon can be run directly using the `dockerd` command. By default it listens on
the Unix socket `unix:///var/run/docker.sock`
$ dockerd
@ -38,9 +38,9 @@ the Unix socket `unix:///var/run/docker.sock`
### Configuring the docker daemon directly
If you're running the `docker` daemon directly by running `docker daemon` instead
If you're running the Docker daemon directly by running `dockerd` instead
of using a process manager, you can append the configuration options to the `docker` run
command directly. Other options can be passed to the `docker` daemon to configure it.
command directly. Other options can be passed to the Docker daemon to configure it.
Some of the daemon's options are:
@ -51,7 +51,7 @@ Some of the daemon's options are:
| `--tls=false` | Enable or disable TLS. By default, this is false. |
Here is an example of running the `docker` daemon with configuration options:
Here is an example of running the Docker daemon with configuration options:
$ dockerd -D --tls=true --tlscert=/var/docker/server.pem --tlskey=/var/docker/serverkey.pem -H tcp://192.168.59.3:2376

2
docs/admin/logging/awslogs.md
View File

@ -22,7 +22,7 @@ and Command Line Tools](http://docs.aws.amazon.com/cli/latest/reference/logs/ind
You can configure the default logging driver by passing the `--log-driver`
option to the Docker daemon:
docker daemon --log-driver=awslogs
dockerd --log-driver=awslogs
You can set the logging driver for a specific container by using the
`--log-driver` option to `docker run`:

4
docs/admin/logging/fluentd.md
View File

@ -39,7 +39,7 @@ Some options are supported by specifying `--log-opt` as many times as needed:
Configure the default logging driver by passing the
`--log-driver` option to the Docker daemon:
docker daemon --log-driver=fluentd
dockerd --log-driver=fluentd
To set the logging driver for a specific container, pass the
`--log-driver` option to `docker run`:
@ -107,7 +107,7 @@ aggregate store.
2. Launch Fluentd container with this configuration file:
$ docker run -it -p 24224:24224 -v /path/to/conf/test.conf:/fluentd/etc -e FLUENTD_CONF=test.conf fluent/fluentd:latest
$ docker run -it -p 24224:24224 -v /path/to/conf/test.conf:/fluentd/etc/test.conf -e FLUENTD_CONF=test.conf fluent/fluentd:latest
3. Start one or more containers with the `fluentd` logging driver:

2
docs/admin/logging/gcplogs.md
View File

@ -18,7 +18,7 @@ Logging</a>.
You can configure the default logging driver by passing the `--log-driver`
option to the Docker daemon:
docker daemon --log-driver=gcplogs
dockerd --log-driver=gcplogs
You can set the logging driver for a specific container by using the
`--log-driver` option to `docker run`:

1
docs/admin/logging/index.md
View File

@ -21,3 +21,4 @@ weight=9
* [Amazon CloudWatch Logs logging driver](awslogs.md)
* [Splunk logging driver](splunk.md)
* [ETW logging driver](etwlogs.md)
* [Google Cloud Logging driver](gcplogs.md)

2
docs/admin/logging/journald.md
View File

@ -30,7 +30,7 @@ driver stores the following metadata in the journal with each message:
You can configure the default logging driver by passing the
`--log-driver` option to the Docker daemon:
docker daemon --log-driver=journald
dockerd --log-driver=journald
You can set the logging driver for a specific container by using the
`--log-driver` option to `docker run`:

2
docs/admin/logging/overview.md
View File

@ -45,7 +45,7 @@ to manually start the daemon with the `json-file` driver, and include additional
attributes in the output, run the following command:
```bash
$ docker daemon \
$ dockerd \
--log-driver=json-file \
--log-opt labels=foo \
--log-opt env=foo,fizz

2
docs/admin/logging/splunk.md
View File

@ -20,7 +20,7 @@ in Splunk Enterprise and Splunk Cloud.
You can configure the default logging driver by passing the `--log-driver`
option to the Docker daemon:
docker daemon --log-driver=splunk
dockerd --log-driver=splunk
You can set the logging driver for a specific container by using the
`--log-driver` option to `docker run`:

8
docs/admin/systemd.md
View File

@ -53,7 +53,7 @@ following:
EnvironmentFile=-/etc/sysconfig/docker-storage
EnvironmentFile=-/etc/sysconfig/docker-network
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// $OPTIONS \
ExecStart=/usr/bin/dockerd -H fd:// $OPTIONS \
$DOCKER_STORAGE_OPTIONS \
$DOCKER_NETWORK_OPTIONS \
$BLOCK_REGISTRY \
@ -90,7 +90,7 @@ In this example, we'll assume that your `docker.service` file looks something li
[Service]
Type=notify
ExecStart=/usr/bin/docker daemon -H fd://
ExecStart=/usr/bin/dockerd -H fd://
LimitNOFILE=1048576
LimitNPROC=1048576
TasksMax=1048576
@ -104,7 +104,7 @@ directory:
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// --graph="/mnt/docker-data" --storage-driver=overlay
ExecStart=/usr/bin/dockerd -H fd:// --graph="/mnt/docker-data" --storage-driver=overlay
You can also set other environment variables in this file, for example, the
`HTTP_PROXY` environment variables described below.
@ -114,7 +114,7 @@ by a new configuration as follows:
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// --bip=172.17.42.1/16
ExecStart=/usr/bin/dockerd -H fd:// --bip=172.17.42.1/16
If you fail to specify an empty configuration, Docker reports an error such as:

276
docs/extend/index.md
View File

@ -1,22 +1,272 @@
<!--[metadata]>
+++
title = "Extend Engine"
description = "How to extend Docker Engine with plugins"
keywords = ["extend, plugins, docker, documentation, developer"]
aliases = [
"/engine/extend/"
]
title = "Managed plugin system"
description = "How develop and use a plugin with the managed plugin system"
keywords = ["API, Usage, plugins, documentation, developer"]
advisory = "experimental"
[menu.main]
identifier = "engine_extend"
parent = "engine_use"
weight = 6
parent = "engine_extend"
weight=1
+++
<![end-metadata]-->
# Docker Engine managed plugin system
## Extending Docker Engine
This document describes the plugin system available today in the **experimental
build** of Docker 1.12:
Currently, you can extend Docker Engine by adding a plugin. This section contains the following topics:
* [How to operate an existing plugin](#how-to-operate-a-plugin)
* [How to develop a plugin](#how-to-develop-a-plugin)
* [Understand Docker plugins](plugins.md)
* [Write a volume plugin](plugins_volume.md)
* [Write a network plugin](plugins_network.md)
* [Write an authorization plugin](plugins_authorization.md)
* [Docker plugin API](plugin_api.md)
Unlike the legacy plugin system, you now manage plugins using Docker Engine:
* install plugins
* start plugins
* stop plugins
* remove plugins
The current Docker Engine plugin system only supports volume drivers. We are
adding more plugin driver types in the future releases.
For information on Docker Engine plugins generally available in Docker Engine
1.12 and earlier, refer to [Understand legacy Docker Engine plugins](legacy_plugins.md).
## How to operate a plugin
Plugins are distributed as Docker images, so develpers can host them on Docker
Hub or on a private registry.
You install the plugin using a single command: `docker plugin install <PLUGIN>`.
The `plugin install` command pulls the plugin from the Docker Hub or private
registry. If necessary the CLI prompts you to accept any privilige requriements.
For example the plugin may require access to a device on the host system.
Finally it enables the plugin.
Run `docker plugin ls` to check the status of installed plugins. The Engine
markes plugins that are started without issues as `ENABLED`.
After you install a plugin, the plugin behavior is the same as legacy plugins.
The following example demonstrates how to install the `sshfs` plugin and use it
to create a volume.
1. Install the `sshfs` plugin.
```bash
$ docker plugin install vieux/sshfs
Plugin "vieux/sshfs" is requesting the following privileges:
- network: [host]
- capabilities: [CAP_SYS_ADMIN]
Do you grant the above permissions? [y/N] y
vieux/sshfs
```
The plugin requests 2 privileges, the `CAP_SYS_ADMIN` capability to be able
to do mount inside the plugin and `host networking`.
2. Check for a value of `true` the `ENABLED` column to verify the plugin
started without error.
```bash
$ docker plugin ls
NAME TAG ENABLED
vieux/sshfs latest true
```
3. Create a volume using the plugin.
```bash
$ docker volume create \
-d vieux/sshfs \
--name sshvolume \
-o sshcmd=user@1.2.3.4:/remote
sshvolume
```
4. Use the volume `sshvolume`.
```bash
$ docker run -v sshvolume:/data busybox ls /data
<content of /remote on machine 1.2.3.4>
```
5. Verify the plugin successfully created the volume.
```bash
$ docker volume ls
DRIVER NAME
vieux/sshfs sshvolume
```
You can stop a plugin with the `docker plugin disable`
command or remove a plugin with `docker plugin remove`.
See the [command line reference](../reference/commandline/index.md) for more
information.
## How to develop a plugin
Plugin creation is currently a manual process. We plan to add automation in a
future release with a command such as `docker plugin build`.
This section describes the format of an existing enabled plugin. You have to
create and format the plugin files by hand.
Plugins are stored in `/var/lib/docker/plugins`. For instance:
```bash
# ls -la /var/lib/docker/plugins
total 20
drwx------ 4 root root 4096 Aug 8 18:03 .
drwx--x--x 12 root root 4096 Aug 8 17:53 ..
drwxr-xr-x 3 root root 4096 Aug 8 17:56 cd851ce43a403
-rw------- 1 root root 2107 Aug 8 18:03 plugins.json
```
`plugins.json` is an inventory of all installed plugins. For example:
```bash
# cat plugins.json
{
"cd851ce43a403": {
"plugin": {
"Manifest": {
"Args": {
"Value": null,
"Settable": null,
"Description": "",
"Name": ""
},
"Env": null,
"Devices": null,
"Mounts": null,
"Capabilities": [
"CAP_SYS_ADMIN"
],
"ManifestVersion": "v0.1",
"Description": "sshFS plugin for Docker",
"Documentation": "https://docs.docker.com/engine/extend/plugins/",
"Interface": {
"Socket": "sshfs.sock",
"Types": [
"docker.volumedriver/1.0"
]
},
"Entrypoint": [
"/go/bin/docker-volume-sshfs"
],
"Workdir": "",
"User": {},
"Network": {
"Type": "host"
}
},
"Config": {
"Devices": null,
"Args": null,
"Env": [],
"Mounts": []
},
"Active": true,
"Tag": "latest",
"Name": "vieux/sshfs",
"Id": "cd851ce43a403"
}
}
}
```
Each folder represents a plugin. For example:
```bash
# ls -la /var/lib/docker/plugins/cd851ce43a403
total 12
drwx------ 19 root root 4096 Aug 8 17:56 rootfs
-rw-r--r-- 1 root root 50 Aug 8 17:56 plugin-config.json
-rw------- 1 root root 347 Aug 8 17:56 manifest.json
```
`rootfs` represents the root filesystem of the plugin. In this example, it was
created from a Dockerfile as follows:
>**Note:** `/run/docker/plugins` is mandatory for docker to communicate with
the plugin._
```bash
$ git clone https://github.com/vieux/docker-volume-sshfs
$ cd docker-volume-sshfs
$ docker build -t rootfs .
$ id=$(docker create rootfs true) # id was cd851ce43a403 when the image was created
$ mkdir -p /var/lib/docker/plugins/$id/rootfs
$ docker export "$id" | tar -x -C /var/lib/docker/plugins/$id/rootfs
$ docker rm -vf "$id"
$ docker rmi rootfs
```
`manifest.json` describes the plugin and `plugin-config.json` contains some
runtime parameters. For example:
```bash
# cat manifest.json
{
"manifestVersion": "v0.1",
"description": "sshFS plugin for Docker",
"documentation": "https://docs.docker.com/engine/extend/plugins/",
"entrypoint": ["/go/bin/docker-volume-sshfs"],
"network": {
"type": "host"
},
"interface" : {
"types": ["docker.volumedriver/1.0"],
"socket": "sshfs.sock"
},
"capabilities": ["CAP_SYS_ADMIN"]
}
```
In this example, you can see the plugin is a volume driver, requires the
`CAP_SYS_ADMIN` capability, `host networking`, `/go/bin/docker-volume-sshfs` as
entrypoint and is going to use `/run/docker/plugins/sshfs.sock` to communicate
with the Docker Engine.
```bash
# cat plugin-config.json
{
"Devices": null,
"Args": null,
"Env": [],
"Mounts": []
}
```
This plugin doesn't require runtime parameters.
Both `manifest.json` and `plugin-config.json` are part of the `plugins.json`.
`manifest.json` is read-only and `plugin-config.json` is read-write.
To summarize, follow the steps below to create a plugin:
0. Choose a name for the plugin. Plugin name uses the same format as images,
for example: `<repo_name>/<name>`.
1. Create a rootfs in `/var/lib/docker/plugins/$id/rootfs`.
2. Create manifest.json file in `/var/lib/docker/plugins/$id/`.
3. Create a `plugin-config.json` if needed.
4. Create or add a section to `/var/lib/docker/plugins/plugins.json`. Use
`<user>/<name>` as “Name” and `$id` as “Id”.
5. Restart the Docker Engine.
6. Run `docker plugin ls`.
* If your plugin is listed as `ENABLED=true`, you can push it to the
registry.
* If the plugin is not listed or if `ENABLED=false`, something went wrong.
Check the daemon logs for errors.
7. If you are not already logged in, use `docker login` to authenticate against
a registry.
8. Run `docker plugin push <repo_name>/<name>` to push the plugin.

17
docs/extend/plugins.md → docs/extend/legacy_plugins.md
View File

@ -1,15 +1,20 @@
<!--[metadata]>
+++
title = "Extending Engine with plugins"
aliases = "/engine/extend/plugins/"
title = "Use Docker Engine plugins"
description = "How to add additional functionality to Docker with plugins extensions"
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
[menu.main]
parent = "engine_extend"
weight=-1
weight=3
+++
<![end-metadata]-->
# Understand Engine plugins
# Use Docker Engine plugins
This document describes the Docker Engine plugins generally available in Docker
Engine. To view information on plugins managed by Docker Engine currently in
experimental status, refer to [Docker Engine plugin system](index.md).
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
@ -17,7 +22,7 @@ volume and network plugins for Docker.
## Types of plugins
Plugins extend Docker's functionality. They come in specific types. For
Plugins extend Docker's functionality. They come in specific types. For
example, a [volume plugin](plugins_volume.md) might enable Docker
volumes to persist across multiple Docker hosts and a
[network plugin](plugins_network.md) might provide network plumbing.
@ -51,7 +56,7 @@ Plugin
----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Azure File Storage plugin](https://github.com/Azure/azurefile-dockervolumedriver) | Lets you mount Microsoft [Azure File Storage](https://azure.microsoft.com/blog/azure-file-storage-now-generally-available/) shares to Docker containers as volumes using the SMB 3.0 protocol. [Learn more](https://azure.microsoft.com/blog/persistent-docker-volumes-with-azure-file-storage/).
[Blockbridge plugin](https://github.com/blockbridge/blockbridge-docker-volume) | A volume plugin that provides access to an extensible set of container-based persistent storage options. It supports single and multi-host Docker environments with features that include tenant isolation, automated provisioning, encryption, secure deletion, snapshots and QoS.
[Contiv Volume Plugin](https://github.com/contiv/volplugin) | An open source volume plugin that provides multi-tenant, persistent, distributed storage with intent based consumption using ceph underneath.
[Contiv Volume Plugin](https://github.com/contiv/volplugin) | An open source volume plugin that provides multi-tenant, persistent, distributed storage with intent based consumption. It has support for Ceph and NFS.
[Convoy plugin](https://github.com/rancher/convoy) | A volume plugin for a variety of storage back-ends including device mapper and NFS. It's a simple standalone executable written in Go and provides the framework to support vendor-specific extensions such as snapshots, backups and restore.
[DRBD plugin](https://www.drbd.org/en/supported-projects/docker) | A volume plugin that provides highly available storage replicated by [DRBD](https://www.drbd.org). Data written to the docker volume is replicated in a cluster of DRBD nodes.
[Flocker plugin](https://clusterhq.com/docker-plugin/) | A volume plugin that provides multi-host portable volumes for Docker, enabling you to run databases and other stateful containers and move them around across a cluster of machines.
@ -72,7 +77,7 @@ Plugin
### Authorization plugins
Plugin | Description
Plugin | Description
------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Twistlock AuthZ Broker](https://github.com/twistlock/authz) | A basic extendable authorization plugin that runs directly on the host or inside a container. This plugin allows you to define user policies that it evaluates during authorization. Basic authorization is provided if Docker daemon is started with the --tlsverify flag (username is extracted from the certificate common name).

15
docs/extend/menu.md Normal file
View File

@ -0,0 +1,15 @@
<!--[metadata]>
+++
title = "Implement plugins"
description = "Develop plugins and use existing plugins for Docker Engine"
keywords = ["extend, plugins, docker, documentation, developer"]
type="menu"
[menu.main]
identifier = "engine_extend"
parent="engine_use"
weight = 0
+++
<![end-metadata]-->
<!--menu page not rendered-->

8
docs/extend/plugin_api.md
View File

@ -5,7 +5,7 @@ description = "How to write Docker plugins extensions "
keywords = ["API, Usage, plugins, documentation, developer"]
[menu.main]
parent = "engine_extend"
weight=1
weight=7
+++
<![end-metadata]-->
@ -14,9 +14,13 @@ weight=1
Docker plugins are out-of-process extensions which add capabilities to the
Docker Engine.
This document describes the Docker Engine plugin API. To view information on
plugins managed by Docker Engine currently in experimental status, refer to
[Docker Engine plugin system](index.md).
This page is intended for people who want to develop their own Docker plugin.
If you just want to learn about or use Docker plugins, look
[here](plugins.md).
[here](legacy_plugins.md).
## What plugins are

8
docs/extend/plugins_authorization.md
View File

@ -6,13 +6,17 @@ keywords = ["security, authorization, authentication, docker, documentation, plu
aliases = ["/engine/extend/authorization/"]
[menu.main]
parent = "engine_extend"
weight = -1
weight = 4
+++
<![end-metadata]-->
# Create an authorization plugin
This document describes the Docker Engine plugins generally available in Docker
Engine. To view information on plugins managed by Docker Engine currently in
experimental status, refer to [Docker Engine plugin system](index.md).
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
@ -106,7 +110,7 @@ Enable the authorization plugin with a dedicated command line flag in the
value. This value can be the plugin’s socket or a path to a specification file.
```bash
$ docker daemon --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
$ dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
```
Docker's authorization subsystem supports multiple `--authorization-plugin` parameters.

7
docs/extend/plugins_network.md
View File

@ -5,11 +5,16 @@ description = "Network driver plugins."
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
[menu.main]
parent = "engine_extend"
weight=5
+++
<![end-metadata]-->
# Engine network driver plugins
This document describes Docker Engine network driver plugins generally
available in Docker Engine. To view information on plugins
managed by Docker Engine, refer to [Docker Engine plugin system](index.md).
Docker Engine network plugins enable Engine deployments to be extended to
support a wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN
or something completely different. Network driver plugins are supported via the
@ -41,7 +46,7 @@ commands. For example,
$ docker network create --driver weave mynet
Some network driver plugins are listed in [plugins](plugins.md)
Some network driver plugins are listed in [plugins](legacy_plugins.md)
The `mynet` network is now owned by `weave`, so subsequent commands
referring to that network will be sent to the plugin,

5
docs/extend/plugins_volume.md
View File

@ -5,6 +5,7 @@ description = "How to manage data with external volume plugins"
keywords = ["Examples, Usage, volume, docker, data, volumes, plugin, api"]
[menu.main]
parent = "engine_extend"
weight=6
+++
<![end-metadata]-->
@ -12,8 +13,8 @@ parent = "engine_extend"
Docker Engine volume plugins enable Engine deployments to be integrated with
external storage systems, such as Amazon EBS, and enable data volumes to persist
beyond the lifetime of a single Engine host. See the [plugin
documentation](plugins.md) for more information.
beyond the lifetime of a single Engine host. See the
[plugin documentation](legacy_plugins.md) for more information.
## Changelog

2
docs/getstarted/step_four.md
View File

@ -185,7 +185,7 @@ In this step, you verify the new images is on your computer and then you run you
This command, you might remember, lists the images you have locally.
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
REPOSITORY TAG IMAGE ID CREATED SIZE
docker-whale latest 7d9495d03763 4 minutes ago 273.7 MB
docker/whalesay latest fb434121fc77 4 hours ago 247 MB
hello-world latest 91c95931e552 5 weeks ago 910 B

2
docs/getstarted/step_one.md
View File

@ -64,7 +64,7 @@ If you have an earlier Windows system that doesn't meet the Docker for Windows p
See [Docker Toolbox Overview](/toolbox/overview.md) for help on installing Docker with Toolbox.
### Docker for Linux
Docker Engine runs navitvely on Linux distributions.
Docker Engine runs natively on Linux distributions.
For full instructions on getting Docker for various Linux distributions, see [Install Docker Engine](/engine/installation/index.md).

6
docs/getstarted/step_six.md
View File

@ -31,7 +31,7 @@ If you don't already have a terminal open, open one now:
2. At the prompt, type `docker images` to list the images you currently have:
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
REPOSITORY TAG IMAGE ID CREATED SIZE
docker-whale latest 7d9495d03763 38 minutes ago 273.7 MB
<none> <none> 5dac217f722c 45 minutes ago 273.7 MB
docker/whalesay latest fb434121fc77 4 hours ago 247 MB
@ -61,7 +61,7 @@ If you don't already have a terminal open, open one now:
7. Type the `docker images` command again to see your newly tagged image.
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
REPOSITORY TAG IMAGE ID CREATED SIZE
maryatdocker/docker-whale latest 7d9495d03763 5 minutes ago 273.7 MB
docker-whale latest 7d9495d03763 2 hours ago 273.7 MB
<none> <none> 5dac217f722c 5 hours ago 273.7 MB
@ -116,7 +116,7 @@ from the hub &mdash; why would it? The two images are identical.
2. At the prompt, type `docker images` to list the images you currently have on your local machine.
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
REPOSITORY TAG IMAGE ID CREATED SIZE
maryatdocker/docker-whale latest 7d9495d03763 5 minutes ago 273.7 MB
docker-whale latest 7d9495d03763 2 hours ago 273.7 MB
<none> <none> 5dac217f722c 5 hours ago 273.7 MB

2
docs/getstarted/step_three.md
View File

@ -99,7 +99,7 @@ Make sure Docker is running. On Docker for Mac and Docker for Windows, this is i
`docker/whalesay` in the list.
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
REPOSITORY TAG IMAGE ID CREATED SIZE
docker/whalesay latest fb434121fc77 3 hours ago 247 MB
hello-world latest 91c95931e552 5 weeks ago 910 B

2
docs/reference/api/docker_remote_api_v1.20.md
View File

@ -2357,4 +2357,4 @@ To set cross origin requests to the remote api please give values to
`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
default or blank means CORS disabled
$ docker daemon -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
$ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"

2
docs/reference/api/docker_remote_api_v1.21.md
View File

@ -2923,4 +2923,4 @@ To set cross origin requests to the remote api please give values to
`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
default or blank means CORS disabled
$ docker daemon -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
$ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"

2
docs/reference/api/docker_remote_api_v1.22.md
View File

@ -3258,4 +3258,4 @@ To set cross origin requests to the remote api please give values to
`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
default or blank means CORS disabled
$ docker daemon -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
$ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"

2
docs/reference/api/docker_remote_api_v1.23.md
View File

@ -3374,4 +3374,4 @@ To set cross origin requests to the remote api please give values to
`--api-cors-header` when running Docker in daemon mode. Set * (asterisk) allows all,
default or blank means CORS disabled
$ docker daemon -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"
$ dockerd -H="192.168.1.9:2375" --api-cors-header="http://foo.bar"

12
docs/reference/api/docker_remote_api_v1.24.md
View File

@ -2405,7 +2405,7 @@ Get container events from docker, in real time via streaming.
Docker containers report the following events:
attach, commit, copy, create, destroy, detach, die, exec_create, exec_detach, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
attach, commit, copy, create, destroy, detach, die, exec_create, exec_detach, exec_start, export, health_status, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
Docker images report the following events:
@ -4142,7 +4142,7 @@ Inspect swarm
`POST /swarm/init`
Initialize a new swarm
Initialize a new swarm. The body of the HTTP response includes the node ID.
**Example request**:
@ -4164,8 +4164,12 @@ Initialize a new swarm
**Example response**:
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Content-Length: 28
Content-Type: application/json
Date: Thu, 01 Sep 2016 21:49:13 GMT
Server: Docker/1.12.0 (linux)
"7v2t30z9blmxuhnyo6s4cpenp"
**Status codes**:

2
docs/reference/api/hub_registry_spec.md
View File

@ -12,7 +12,7 @@ parent="smn_hub_ref"
# The Docker Hub and the Registry v1
This API is deprecated as of 1.7. To view the old version, see the [go
here](hub_registry_spec.md) in
here](https://docs.docker.com/v1.7/docker/reference/api/hub_registry_spec/) in
the 1.7 documentation. If you want an overview of the current features in
Docker Hub or other image management features see the [image management
overview](../../userguide/eng-image/image_management.md) in the current documentation set.

2
docs/reference/builder.md
View File

@ -1068,7 +1068,7 @@ user 0m 0.03s
sys 0m 0.03s
```
> **Note:** you can over ride the `ENTRYPOINT` setting using `--entrypoint`,
> **Note:** you can override the `ENTRYPOINT` setting using `--entrypoint`,
> but this can only set the binary to *exec* (no `sh -c` will be used).
> **Note**:

1
docs/reference/commandline/create.md
View File

@ -90,6 +90,7 @@ Options:
--read-only Mount the container's root filesystem as read only
--restart string Restart policy to apply when a container exits (default "no")
Possible values are: no, on-failure[:max-retry], always, unless-stopped
--rm Automatically remove the container when it exits
--runtime string Runtime to use for this container
--security-opt value Security Options (default [])
--shm-size string Size of /dev/shm, default value is 64MB.

12
docs/reference/commandline/dockerd.md
View File

@ -574,7 +574,7 @@ options for `zfs` start with `zfs` and options for `btrfs` start with `btrfs`.
**size** cannot be smaller than **btrfs.min_space**.
Example use:
$ docker daemon -s btrfs --storage-opt btrfs.min_space=10G
$ dockerd -s btrfs --storage-opt btrfs.min_space=10G
#### Overlay2 options
@ -594,6 +594,14 @@ The Docker daemon relies on a
(invoked via the `containerd` daemon) as its interface to the Linux
kernel `namespaces`, `cgroups`, and `SELinux`.
By default, the Docker daemon automatically starts `containerd`. If you want to
control `containerd` startup, manually start `containerd` and pass the path to
the `containerd` socket using the `--containerd` flag. For example:
```bash
$ dockerd --containerd /var/run/dev/docker-containerd.sock
```
Runtimes can be registered with the daemon either via the
configuration file or using the `--add-runtime` command line argument.
@ -1212,7 +1220,7 @@ The `--tls*` options enable use of specific certificates for individual daemons.
Example script for a separate “bootstrap” instance of the Docker daemon without network:
```bash
$ docker daemon \
$ dockerd \
-H unix:///var/run/docker-bootstrap.sock \
-p /var/run/docker-bootstrap.pid \
--iptables=false \

2
docs/reference/commandline/events.md
View File

@ -24,7 +24,7 @@ Options:
Docker containers report the following events:
attach, commit, copy, create, destroy, detach, die, exec_create, exec_detach, exec_start, export, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
attach, commit, copy, create, destroy, detach, die, exec_create, exec_detach, exec_start, export, health_status, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
Docker images report the following events:

3
docs/reference/commandline/login.md
View File

@ -38,9 +38,6 @@ You can log into any public or private repository for which you have
credentials. When you log in, the command stores encoded credentials in
`$HOME/.docker/config.json` on Linux or `%USERPROFILE%/.docker/config.json` on Windows.
> **Note**: When running `sudo docker login` credentials are saved in `/root/.docker/config.json`.
>
## Credentials store
The Docker Engine can keep user credentials in an external credentials store,

2
docs/reference/commandline/network_create.md
View File

@ -11,7 +11,7 @@ parent = "smn_cli"
# network create
```markdown
Usage: docker network create [OPTIONS]
Usage: docker network create [OPTIONS] NETWORK
Create a network

4
docs/reference/commandline/plugin_inspect.md Normal file → Executable file
View File

@ -12,9 +12,9 @@ parent = "smn_cli"
# plugin inspect (experimental)
```markdown
Usage: docker plugin inspect PLUGIN
Usage: docker plugin inspect [OPTIONS] PLUGIN [PLUGIN...]
Inspect a plugin
Display detailed information on one or more plugins
Options:
--help Print usage

2
docs/reference/commandline/run.md
View File

@ -657,7 +657,7 @@ network namespace, run this command:
$ docker run --sysctl net.ipv4.ip_forward=1 someimage
> **Note**: Not all sysctls are namespaced. docker does not support changing sysctls
> **Note**: Not all sysctls are namespaced. Docker does not support changing sysctls
> inside of a container that also modify the host system. As the kernel
> evolves we expect to see more sysctls become namespaced.

6
docs/reference/commandline/service_create.md
View File

@ -140,9 +140,9 @@ metadata](../../userguide/labels-custom-metadata.md).
### Set service mode
Is this a replicated service or a global service. A replicated service runs as
many tasks as specified, while a global service runs on each active node in the
swarm.
You can set the service mode to "replicated" (default) or to "global". A
replicated service runs as many tasks as specified, while a global service
runs on each active node in the swarm.
The following command creates a "global" service:

4
docs/reference/commandline/swarm_join.md
View File

@ -87,10 +87,6 @@ name, the default port 2377 will be used.
This flag is generally not necessary when joining an existing swarm.
### `--manager`
Joins the node as a manager
### `--token string`
Secret value required for nodes to join the swarm

2
docs/reference/run.md
View File

@ -645,7 +645,7 @@ allows you to share the same content between containers.
> **Note**: Automatic translation of MLS labels is not currently supported.
To disable the security labeling for this container versus running with the
`--permissive` flag, use the following command:
`--privileged` flag, use the following command:
$ docker run --security-opt label=disable -it fedora bash

2
docs/security/https.md
View File

@ -136,7 +136,7 @@ prevent accidental damage:
Now you can make the Docker daemon only accept connections from clients
providing a certificate trusted by our CA:
$ docker daemon --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem \
$ dockerd --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem \
-H=0.0.0.0:2376
To be able to connect to Docker and validate its certificate, you now

2
docs/security/https/Makefile
View File

@ -13,7 +13,7 @@ cert: build
certs: cert
run:
sudo docker daemon -D --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:6666 --pidfile=$(pwd)/docker.pid --graph=$(pwd)/graph
sudo dockerd -D --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=0.0.0.0:6666 --pidfile=$(pwd)/docker.pid --graph=$(pwd)/graph
client:
sudo docker --tls --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=$(HOST):6666 version

2
docs/swarm/admin_guide.md
View File

@ -32,7 +32,7 @@ This article covers the following swarm administration tasks:
* [Forcefully removing a node](#force-remove-a-node)
* [Recovering from disaster](#recover-from-disaster)
Refer to [How swarm mode nodes work](how-swarm-mode-works/nodes.md)
Refer to [How nodes work](how-swarm-mode-works/nodes.md)
for a brief overview of Docker Swarm mode and the difference between manager and
worker nodes.

3
docs/swarm/how-swarm-mode-works/nodes.md
View File

@ -86,6 +86,7 @@ You can also demote a manager node to a worker node. See
[node demote](../../reference/commandline/node_demote.md).
## What's Next
## Learn More
* Read about how swarm mode [services](services.md) work.
* Learn how [PKI](pki.md) works in swarm mode

72
docs/swarm/how-swarm-mode-works/pki.md Normal file
View File

@ -0,0 +1,72 @@
<!--[metadata]>
+++
title = "How PKI works"
description = "How PKI works in swarm mode"
keywords = ["docker", "container", "cluster", "swarm mode", "node", "tls", "pki"]
[menu.main]
identifier="how-pki-work"
parent="how-swarm-works"
weight="5"
+++
<![end-metadata]-->
# How PKI works in swarm mode
The swarm mode public key infrastructure (PKI) system built into Docker Engine
makes it simple to securely deploy a container orchestration system. The nodes
in a swarm use mutual Transport Layer Security (TLS) to authenticate, authorize,
and encrypt the communications between themselves and other nodes in the swarm.
When you create a swarm by running `docker swarm init`, the Docker Engine
designates istself as a manager node. By default, the manager node generates
itself a new root Certificate Authority (CA) along with a key pair to secure
communications with other nodes that join the swarm. If you prefer, you can pass
the `--external-ca` flag to specify a root CA external to the swarm. Refer to
the [docker swarm init](../../reference/commandline/swarm_init.md) CLI
reference.
The manager node also generates two tokens to use when you join additional nodes
to the swarm: one worker token and one manager token. Each token includes the
digest of the root CA's certificate and a randomly generated secret. When a node
joins the swarm, it uses the digest to validate the root CA certificate from the
remote manager. It uses the secret to ensure the node is an approved node.
Each time a new node joins the swarm, the manager issues a certificate to the
node that contains a randomly generated node id to identify the node under the
certificate common name (CN) and the role under the organizational unit (OU).
The node id serves as the cryptographically secure node identity for the
lifetime of the node in the current swarm.
The diagram below illustrates how worker manager nodes and worker nodes encrypt
communications using a minimum of TLS 1.2.
![tls diagram](../images/tls.png)
The example below shows the information from a certificate from a worker node:
```bash
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
3b:1c:06:91:73:fb:16:ff:69:c3:f7:a2:fe:96:c1:73:e2:80:97:3b
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=swarm-ca
Validity
Not Before: Aug 30 02:39:00 2016 GMT
Not After : Nov 28 03:39:00 2016 GMT
Subject: O=ec2adilxf4ngv7ev8fwsi61i7, OU=swarm-worker, CN=dw02poa4vqvzxi5c10gm4pq2g
...snip...
```
By default, each node in the swarm renews its certificate every three months.
You can run `docker swarm update --cert-expiry <TIME PERIOD>` to configure the
frequency for nodes to renew their certificates. The minimum rotation value is 1
hour. Refer to the [docker swarm update](../../reference/commandline/swarm_update.md)
CLI reference.
## Learn More
* Read about how [nodes](nodes.md) work.
* Learn how swarm mode [services](services.md) work.

5
docs/swarm/how-swarm-mode-works/services.md
View File

@ -95,3 +95,8 @@ The diagram below shows a three-service replica in yellow and a global service
in gray.
![global vs replicated services](../images/replicated-vs-global.png)
## Learn More
* Read about how swarm mode [nodes](services.md) work.
* Learn how [PKI](pki.md) works in swarm mode.

1
docs/swarm/images/src/tls.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 123 KiB

BIN
docs/swarm/images/tls.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

8
docs/swarm/swarm-tutorial/create-swarm.md
View File

@ -25,6 +25,12 @@ node. For example, the tutorial uses a machine named `manager1`.
docker swarm init --advertise-addr <MANAGER-IP>
```
>**Note:** If you are using Docker for Mac or Docker for Windows to test
single-node swarm, simply run `docker swarm init` with no arguments. There is no
need to specify ` --advertise-addr` in this case. To learn more, see the topic
on how to [Use Docker for Mac or Docker for
Windows](index.md#use-docker-for-mac-or-docker-for-windows) with Swarm.
In the tutorial, the following command creates a swarm on the `manager1`
machine:
@ -45,7 +51,7 @@ node. For example, the tutorial uses a machine named `manager1`.
address as `192.168.99.100`. The other nodes in the swarm must be able
to access the manager at the IP address.
The output incudes the commands to join new nodes to the swarm. Nodes will
The output includes the commands to join new nodes to the swarm. Nodes will
join as managers or workers depending on the value for the `--token`
flag.

15
docs/tutorials/dockerimages.md
View File

@ -89,14 +89,13 @@ download the `centos` image.
$ docker pull centos
Pulling repository centos
b7de3133ff98: Pulling dependent layers
5cc9e91966f7: Pulling fs layer
511136ea3c5a: Download complete
ef52fb1fe610: Download complete
. . .
Status: Downloaded newer image for centos
Using default tag: latest
latest: Pulling from library/centos
f1b10cd84249: Pull complete
c852f6d61e65: Pull complete
7322fbe74aa5: Pull complete
Digest: sha256:90305c9112250c7e3746425477f1c4ef112b03b4abe78c612e092037bfecc3b7
Status: Downloaded newer image for centos:latest
You can see that each layer of the image has been pulled down and now you
can run a container from this image and you won't have to wait to

6
docs/tutorials/dockervolumes.md
View File

@ -134,7 +134,7 @@ docker run -v /Users/<path>:/<container path> ...
On Windows, mount directories using:
```bash
docker run -v /c/Users/<path>:/<container path> ...`
docker run -v c:\<path>:/c:\<container path>
```
All other paths come from your virtual machine's filesystem, so if you want
@ -203,7 +203,7 @@ The following example also creates the `my-named-volume` volume, this time
using the `docker volume create` command.
```bash
$ docker volume create -d flocker --name my-named-volume -o size=20GB
$ docker volume create -d flocker -o size=20GB my-named-volume
$ docker run -d -P \
-v my-named-volume:/opt/webapp \
@ -211,7 +211,7 @@ $ docker run -d -P \
```
A list of available plugins, including volume plugins, is available
[here](../extend/plugins.md).
[here](../extend/legacy_plugins.md).
### Volume labels

8
docs/tutorials/usingdocker.md
View File

@ -73,9 +73,11 @@ To see usage for a specific command, specify the command with the `--help` flag:
Attach to a running container
--help Print usage
--no-stdin Do not attach stdin
--sig-proxy=true Proxy all received signals to the process
Options:
--detach-keys string Override the key sequence for detaching a container
--help Print usage
--no-stdin Do not attach STDIN
--sig-proxy Proxy all received signals to the process (default true)
> **Note:**
> For further details and examples of each command, see the

4
docs/userguide/labels-custom-metadata.md
View File

@ -11,7 +11,7 @@ weight=90
# Apply custom metadata
You can apply metadata to your images, containers, or daemons via
You can apply metadata to your images, containers, volumes, networks, nodes, services 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.
@ -182,7 +182,7 @@ on how to query labels set on a container.
## Daemon labels
docker daemon \
dockerd \
--dns 8.8.8.8 \
--dns 8.8.4.4 \
-H unix:///var/run/docker.sock \

2
docs/userguide/networking/index.md
View File

@ -537,7 +537,7 @@ built-in network drivers. For example:
You can inspect it, add containers to and from it, and so forth. Of course,
different plugins may make use of different technologies or frameworks. Custom
networks can include features not present in Docker's default networks. For more
information on writing plugins, see [Extending Docker](../../extend/index.md) and
information on writing plugins, see [Extending Docker](../../extend/legacy_plugins.md) and
[Writing a network driver plugin](../../extend/plugins_network.md).
### Docker embedded DNS server

2
experimental/docker-stacks-and-bundles.md
View File

@ -41,7 +41,7 @@ A stack is created using the `docker deploy` command:
Usage: docker deploy [OPTIONS] STACK
Create and update a stack
Create and update a stack from a Distributed Application Bundle (DAB)
Options:
--file string Path to a Distributed Application Bundle file (Default: STACK.dab)

3
man/docker-login.1.md
View File

@ -26,9 +26,6 @@ You can log into any public or private repository for which you have
credentials. When you log in, the command stores encoded credentials in
`$HOME/.docker/config.json` on Linux or `%USERPROFILE%/.docker/config.json` on Windows.
> **Note**: When running `sudo docker login` credentials are saved in `/root/.docker/config.json`.
>
# OPTIONS
**--help**
Print usage statement