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

Use daemon.json everywhere possible (#3252)

This commit is contained in:
Misty Stanley-Jones 2017-05-15 10:44:40 -07:00 committed by GitHub
parent 4d87b4fc1a
commit 968f76eced
8 changed files with 330 additions and 237 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
datacenter/dtr/2.0/configure/config-security.md
View File

@ -177,37 +177,18 @@ If you enter a "Domain Name" into the Security settings, it needs to be DNS
resolvable on any client daemons that are running in `insecure-registry`
mode.
To set the flag, perform the following directions for your operating system.
To set the flag, edit the `daemon.json` file, which is located in `/etc/docker/`
on Linux or `C:\ProgramData\docker\config\` on Windows Server. If the
file does not yet exist, create it. Assuming the file was empty, it should have
the following contents:
#### Ubuntu
On Ubuntu 14.04 LTS, customize the Docker daemon configuration with the
`/etc/defaults/docker` file.
Open or create the `/etc/defaults/docker` file, and add the
`--insecure-registry` flag to the `DOCKER_OPTS` setting (which may need to be
added or uncommented) as follows:
```
DOCKER_OPTS="--insecure-registry dtr.yourdomain.com"
```json
{
"insecure-registries": ["dtr.yourdomain.com"]
}
```
Then restart the Docker daemon with `sudo service docker restart`.
#### RHEL/Centos
On RHEL/Centos, customize the Docker daemon configuration with the
`/etc/sysconfig/docker` file.
Open or create the `/etc/sysconfig/docker` file, and add the
`--insecure-registry` flag to the `OPTIONS` setting (which may need to be
added or uncommented) as follows:
```
OPTIONS="--insecure-registry dtr.yourdomain.com"
```
Then restart the Docker daemon with `sudo service docker restart`.
Restart Docker for the change to take effect.
### Docker Machine and Boot2Docker
@ -221,7 +202,7 @@ setting as follows:
EXTRA_ARGS="--insecure-registry dtr.yourdomain.com"
```
Then restart the Docker daemon with `sudo /etc/init.d/docker restart`.
Restart Docker for the change to take effect.
## See also

90
engine/userguide/networking/default_network/build-bridges.md
View File

@ -11,70 +11,72 @@ install Docker.
> **Note**: The [Docker networks feature](../index.md) allows you to
create user-defined networks in addition to the default bridge network.
You can set up your own bridge before starting Docker and use `-b BRIDGE` or
`--bridge=BRIDGE` to tell Docker to use your bridge instead. If you already
have Docker up and running with its default `docker0` still configured,
you can directly create your bridge and restart Docker with it or want to begin by
stopping the service and removing the interface:
You can set up your own bridge before starting Docker and configure Docker to
use your bridge instead of the default `docker0` bridge.
```
# Stopping Docker and removing docker0
1. Configure the new bridge.
$ sudo service docker stop
```bash
$ sudo brctl addbr bridge0
$ sudo ip link set dev docker0 down
$ sudo ip addr add 192.168.5.1/24 dev bridge0
$ sudo brctl delbr docker0
$ sudo ip link set dev bridge0 up
```
$ sudo iptables -t nat -F POSTROUTING
```
Confirm the new bridge's settings.
Then, before starting the Docker service, create your own bridge and give it
whatever configuration you want. Here we will create a simple enough bridge
that we really could just have used the options in the previous section to
customize `docker0`, but it will be enough to illustrate the technique.
```bash
$ ip addr show bridge0
```
# Create our own bridge
4: bridge0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state UP group default
link/ether 66:38:d0:0d:76:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.1/24 scope global bridge0
valid_lft forever preferred_lft forever
```
$ sudo brctl addbr bridge0
2. Configure Docker to use the new bridge by setting the option in the
`daemon.json` file, which is located in `/etc/docker/` on
Linux or `C:\ProgramData\docker\config\` on Windows Server. On Docker for
Mac or Docker for Windows, click the Docker icon, choose **Preferences**,
and go to **Daemon**.
$ sudo ip addr add 192.168.5.1/24 dev bridge0
If the `daemon.json` file does not exist, create it. Assuming there
are no other settings in the file, it should have the following contents:
$ sudo ip link set dev bridge0 up
```json
{
"bridge": "bridge0"
}
```
# Confirming that our bridge is up and running
Restart Docker for the changes to take effect.
$ ip addr show bridge0
3. Confirm that the new outgoing NAT masquerade is set up.
4: bridge0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state UP group default
link/ether 66:38:d0:0d:76:18 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.1/24 scope global bridge0
valid_lft forever preferred_lft forever
```bash
$ sudo iptables -t nat -L -n
# Tell Docker about it and restart (on Ubuntu)
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.5.0/24 0.0.0.0/0
```
$ echo 'DOCKER_OPTS="--bridge=bridge0"' >> /etc/default/docker
4. Remove the now-unused `docker0` bridge.
$ sudo service docker start
```bash
$ sudo ip link set dev docker0 down
# Confirming new outgoing NAT masquerade is set up
$ sudo brctl delbr docker0
$ sudo iptables -t nat -L -n
$ sudo iptables -t nat -F POSTROUTING
```
...
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.5.0/24 0.0.0.0/0
```
5. Create a new container, and verify that it is in the new IP address range.
The result should be that the Docker server starts successfully and is now
prepared to bind containers to the new bridge. After pausing to verify the
bridge's configuration, try creating a container -- you will see that its IP
address is in your new IP address range, which Docker will have auto-detected.
You can use the `brctl show` command to see Docker add and remove interfaces
from the bridge as you start and stop containers, and can run `ip addr` and `ip
route` inside a container to see that it has been given an address in the
bridge's IP address range and has been told to use the Docker host's IP address
on the bridge as its default gateway to the rest of the Internet.
route` inside a container to confirm that it has an address in the bridge's IP
address range and uses the Docker host's IP address on the bridge as its default
gateway to the rest of the Internet.

98
engine/userguide/networking/default_network/custom-docker0.md
View File

@ -4,38 +4,76 @@ keywords: docker, bridge, docker0, network
title: Customize the docker0 bridge
---
The information in this section explains how to customize the Docker default bridge. This is a `bridge` network named `bridge` created automatically when you install Docker.
The information in this section explains how to customize the Docker default
bridge. This is a `bridge` network named `bridge` created automatically when you
install Docker.
**Note**: The [Docker networks feature](../index.md) allows you to create user-defined networks in addition to the default bridge network.
> **Note**: The [Docker networks feature](/engine/userguide/networking/index.md)
> allows you to create user-defined networks in addition to the default bridge network.
By default, the Docker server creates and configures the host system's `docker0` interface as an _Ethernet bridge_ inside the Linux kernel that can pass packets back and forth between other physical or virtual network interfaces so that they behave as a single Ethernet network.
By default, the Docker server creates and configures the host system's `docker0`
a network interface called `docker0`, which is an ethernet bridge device. If you
don't specify a different network when starting a container, the container is
connected to the bridge and all traffic coming from and going to the container
flows over the bridge to the Docker daemon, which handles routing on behalf of
the container.
Docker configures `docker0` with an IP address, netmask and IP allocation range. The host machine can both receive and send packets to containers connected to the bridge, and gives it an MTU -- the _maximum transmission unit_ or largest packet length that the interface will allow -- of 1,500 bytes. These options are configurable at server startup:
Docker configures `docker0` with an IP address, netmask and IP allocation range.
Containers which are connected to the default bridge are allocated IP addresses
within this range. Certain default settings apply to the default bridge unless
you specify otherwise. For instance, the default maximum transmission unit (MTU),
or the largest packet length that the container will allow, defaults to 1500
bytes.
- `--bip=CIDR`: supply a specific IP address and netmask for the `docker0` bridge, using standard
CIDR notation. For example: `192.168.1.5/24`.
You can configure the default bridge network's settings using flags to the
`dockerd` command. However, the recommended way to configure the Docker daemon
is to use the `daemon.json` file, which is located in `/etc/docker/` on Linux.
If the file does not exist, create it. You can specify one or more of the
following settings to configure the default bridge network:
- `--fixed-cidr=CIDR`: restrict the IP range from the `docker0` subnet, using standard CIDR notation.
For example: `172.16.1.0/28`. This range must be an IPv4 range for fixed IPs, such as `10.20.0.0/16`,
and must be a subset of the bridge IP range (`docker0` or set using `--bridge`). For example, with
`--fixed-cidr=192.168.1.0/25`, IPs for your containers will be chosen from the first half of addresses
included in the`192.168.1.0/24` subnet.
```json
{
"bip": "192.168.1.5/24",
"fixed-cidr": "10.20.0.0/16",
"fixed-cidr-v6": "2001:db8::/64",
"mtu": "1500",
"default-gateway": "10.20.1.1",
"default-gateway-v6": "2001:db8:abcd::89",
"dns": ["10.20.1.2","10.20.1.3"]
}
```
Restart Docker after making changes to the `daemon.json` file.
The same options are presented as flags to `dockerd`, with an explanation for
each:
- `--bip=CIDR`: supply a specific IP address and netmask for the `docker0`
bridge, using standard CIDR notation. For example: `192.168.1.5/24`.
- `--fixed-cidr=CIDR` and `--fixed-cidr-v6=CIDRv6`: restrict the IP range from
the `docker0` subnet, using standard CIDR notation. For example:
`172.16.1.0/28`. This range must be an IPv4 range for fixed IPs, such as
`10.20.0.0/16`, and must be a subset of the bridge IP range (`docker0` or set
using `--bridge`). For example, with `--fixed-cidr=192.168.1.0/25`, IPs for
your containers will be chosen from the first half of addresses included in
the `192.168.1.0/24` subnet.
- `--mtu=BYTES`: override the maximum packet length on `docker0`.
- `--default-gateway=Container default Gateway IPV4 address`: designates the default gateway for
containers connected to the `docker0` bridge, which controls where they route traffic by default.
Applicable for addresses set with `--bip` and `--fixed-cidr` flags. For instance, you can configure
- `--default-gateway=Container default Gateway IPV4 address` and
`--default-gateway-v6=Container default gateway IPV6 address`: designates the
default gateway for containers connected to the `docker0` bridge, which
controls where they route traffic by default. Applicable for addresses set
with `--bip` and `--fixed-cidr` flags. For instance, you can configure
`--fixed-cidr=172.17.2.0/24` and `default-gateway=172.17.1.1`.
- `--dns=[]`: The DNS servers to use. For example: `--dns=172.17.2.10`. You can also specify DNS servers
when starting the Docker daemon, by adding the values to `/etc/docker/daemon.json` (recommended) or using
the `--dns` flag when starting `dockerd` manually.
- `--dns=[]`: The DNS servers to use. For example: `--dns=172.17.2.10`.
Once you have one or more containers up and running, you can confirm that Docker has properly connected
them to the `docker0` bridge by running the `brctl` command on the host machine and looking at the
`interfaces` column of the output. This example shows a `docker0` bridge with two containers
connected:
Once you have one or more containers up and running, you can confirm that Docker
has properly connected them to the `docker0` bridge by running the `brctl`
command on the host machine and looking at the `interfaces` column of the
output. This example shows a `docker0` bridge with two containers connected:
```bash
$ sudo brctl show
@ -45,11 +83,17 @@ docker0 8000.3a1d7362b4ee no veth65f9
vethdda6
```
If the `brctl` command is not installed on your Docker host, then on Ubuntu you should be able to run `sudo apt-get install bridge-utils` to install it.
If the `brctl` command is not installed on your Docker host, then on Ubuntu you
should be able to run `sudo apt-get install bridge-utils` to install it.
Finally, the `docker0` Ethernet bridge settings are used every time you create a new container. Docker selects a free IP address from the range available on the bridge each time you `docker run` a new container, and configures the container's `eth0` interface with that IP address and the bridge's netmask. The Docker host's own IP address on the bridge is used as the default gateway by which each container reaches the rest of the Internet.
Finally, the `docker0` Ethernet bridge settings are used every time you create a
new container. Docker selects a free IP address from the range available on the
bridge each time you `docker run` a new container, and configures the
container's `eth0` interface with that IP address and the bridge's netmask. The
Docker host's own IP address on the bridge is used as the default gateway by
which each container reaches the rest of the Internet.
```
```bash
# The network, as seen from a container
$ docker run --rm -it alpine /bin/ash
@ -71,4 +115,8 @@ default via 172.17.42.1 dev eth0
root@f38c87f2a42d:/# exit
```
Remember that the Docker host will not be willing to forward container packets out on to the Internet unless its `ip_forward` system setting is `1` -- see the section on [Communicating to the outside world](container-communication.md#communicating-to-the-outside-world) for details.
Remember that the Docker host will not be willing to forward container packets
out on to the Internet unless its `ip_forward` system setting is `1` -- see the
section on
[Communicating to the outside world](container-communication.md#communicating-to-the-outside-world)
for details.

129
engine/userguide/storagedriver/selectadriver.md
View File

@ -36,26 +36,29 @@ driver names:
|VFS |`vfs` |
|ZFS |`zfs` |
To find out which storage driver is set on the daemon, you use the
`docker info` command:
To find out which storage driver is set on the daemon, look for the
**Storage Driver** line in the output of `docker info`:
$ docker info
```bash
$ docker info
Containers: 0
Images: 0
Storage Driver: overlay
Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-15-generic
Operating System: Ubuntu 15.04
... output truncated ...
Containers: 0
Images: 0
Storage Driver: overlay
Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-15-generic
Operating System: Ubuntu 15.04
<output truncated>
```
The `info` subcommand reveals that the Docker daemon is using the `overlay`
In this example, the Docker daemon is using the `overlay`
storage driver with a `Backing Filesystem` value of `extfs`. The `extfs` value
means that the `overlay` storage driver is operating on top of an existing
(ext) filesystem. The backing filesystem refers to the filesystem that was used
to create the Docker host's local storage area under `/var/lib/docker`.
means that the `overlay` storage driver is operating on top of an `ext2fs` or
`ext3fs` filesystem, which is common on Linux. The backing filesystem refers to
the filesystem that was used to create the Docker host's local storage area
under `/var/lib/docker`.
Which storage driver you use, in part, depends on the backing filesystem you
plan to use for your Docker host's local storage area. Some storage drivers can
@ -80,47 +83,71 @@ backing filesystem:
> "Disabled on" means some storage drivers can not run over certain backing
> filesystem.
You can set the storage driver by passing the `--storage-driver=<name>` option
to the `dockerd` command line, or by setting the option on the
`DOCKER_OPTS` line in the `/etc/default/docker` file.
You can set the storage driver by setting the option in the `daemon.json`
file, which is located in `/etc/docker/` on Linux and
`C:\ProgramData\docker\config\` on Windows Server. If you use Docker for Mac or
Docker for Windows, click the Docker icon, choose **Preferences**, and choose
**Daemon** on Docker for Mac or Docker for Windows.
The following command shows how to start the Docker daemon with the
`devicemapper` storage driver using the `dockerd` command:
If the `daemon.json` file does not exist, create it. Assuming there are no other
settings in the file, it should have the following contents:
$ dockerd --storage-driver=devicemapper &
```json
{
"storage-driver": "devicemapper"
}
```
$ docker info
You can specify any valid storage driver in place of `devicemapper`.
Containers: 0
Images: 0
Storage Driver: devicemapper
Pool Name: docker-252:0-147544-pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 1.821 GB
Data Space Total: 107.4 GB
Data Space Available: 3.174 GB
Metadata Space Used: 1.479 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.146 GB
Thin Pool Minimum Free Space: 10.74 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.90 (2014-09-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-15-generic
Operating System: Ubuntu 15.04
<output truncated>
> **Note**: Docker for Mac and Docker for Windows only support `overlay2`
> `aufs`, `overlay`, or `vfs`. The last two are **not** recommended. Currently,
> `aufs` is the default in stable releases and `overlay2` is the default in
> Edge releases.
> In addition, before you change the default storage driver on Docker for Mac or
> Docker for Windows, it is recommended to do a factory reset to wipe the
> old storage location, since you will not be able to access it after you change
> the storage driver. If you need to save any containers, use `docker save`
> before doing the reset.
Restart Docker for the changes to take effect.
Alternatively, you can run the `dockerd` command manually and pass the
`--storage-driver=<name>` option to try the setting without making it persistent.
After Docker starts, look for the **Storage Driver** line in the output of
`docker info` to verify your configuration.
```bash
$ docker info
Containers: 0
Images: 0
Storage Driver: devicemapper
Pool Name: docker-252:0-147544-pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 1.821 GB
Data Space Total: 107.4 GB
Data Space Available: 3.174 GB
Metadata Space Used: 1.479 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.146 GB
Thin Pool Minimum Free Space: 10.74 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.90 (2014-09-01)
<output truncated>
```
Your choice of storage driver can affect the performance of your containerized
applications. So it's important to understand the different storage driver
options available and select the right one for your application. Later, in this
page you'll find some advice for choosing an appropriate driver.
applications, and the supported storage drivers depend on your operating system
and distribution. It's important to understand the different storage driver
options available and choose the best one for your situation.
## Shared storage systems and the storage driver

97
registry/insecure.md
View File

@ -5,11 +5,9 @@ title: Test an insecure registry
---
While it's highly recommended to secure your registry using a TLS certificate
issued by a known CA, you may alternatively decide to use self-signed
certificates, or even use your registry over plain http.
You have to understand the downsides in doing so, and the extra burden in
configuration.
issued by a known CA, you can choose to use self-signed certificates, or use
your registry over an unencrypted HTTP connection. Either of these choices
involves security trade-offs and additional configuration steps.
## Deploying a plain HTTP registry
@ -17,31 +15,40 @@ configuration.
> it's not possible to use an insecure registry with basic authentication.
{:.warning}
This basically tells Docker to entirely disregard security for your registry.
While this is relatively easy to configure the daemon in this way, it is
**very** insecure. It does expose your registry to trivial MITM. Only use this
solution for isolated testing or in a tightly controlled, air-gapped
environment.
This procedure configures Docker to entirely disregard security for your
registry. This is **very** insecure and is not recommended. It exposes your
registry to trivial man-in-the-middle (MITM) attacks. Only use this solution for
isolated testing or in a tightly controlled, air-gapped environment.
1. Open the `/etc/default/docker` file or `/etc/sysconfig/docker` for editing.
1. Edit the `daemon.json` file, whose default location is
`/etc/docker/daemon.json` on Linux or
`C:\ProgramData\docker\config\daemon.json` on Windows Server. If you use
Docker for Mac or Docker for Windows, click the Docker icon, choose
**Preferences**, and choose +**Daemon**.
Depending on your operating system, your Engine daemon start options.
If the `daemon.json` file does not exist, create it. Assuming there are no
other settings in the file, it should have the following contents:
2. Edit (or add) the `DOCKER_OPTS` line and add the `--insecure-registry` flag.
```json
{
"insecure-registries" : ["myregistrydomain.com:5000"]
}
```
This flag takes the URL of your registry, for example.
Substitute the address of your insecure registry for the one in the example.
`DOCKER_OPTS="--insecure-registry myregistrydomain.com:5000"`
With insecure registries enabled, Docker goes through the following steps:
3. Close and save the configuration file.
- First, try using HTTPS.
- If HTTPS is available but the certificate is invalid, ignore the error
about the certificate.
- If HTTPS is not available, fall back to HTTP.
4. Restart your Docker daemon
The command you use to restart the daemon depends on your operating system.
For example, on Ubuntu, this is usually the `service docker stop` and `service
docker start` command.
2. Restart Docker for the changes to take effect.
5. Repeat this configuration on every Engine host that wants to access your registry.
Repeat these steps on every Engine host that wants to access your registry.
## Using self-signed certificates
@ -50,23 +57,51 @@ environment.
> using this along with basic authentication requires to **also** trust the certificate into the OS cert store for some versions of docker (see below)
{:.warning}
This is more secure than the insecure registry solution. You must configure every docker daemon that wants to access your registry
This is more secure than the insecure registry solution.
1. Generate your own certificate:
1. Generate your own certificate:
mkdir -p certs && openssl req \
-newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \
-x509 -days 365 -out certs/domain.crt
```bash
$ mkdir -p certs
2. Be sure to use the name `myregistrydomain.com` as a CN.
$ openssl req \
-newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \
-x509 -days 365 -out certs/domain.crt
```
3. Use the result to [start your registry with TLS enabled](./deploying.md#get-a-certificate)
Be sure to use the name `myregistrydomain.com` as a CN.
4. Instruct every docker daemon to trust that certificate.
2. Use the result to [start your registry with TLS enabled](./deploying.md#get-a-certificate)
This is done by copying the `domain.crt` file to `/etc/docker/certs.d/myregistrydomain.com:5000/ca.crt`.
3. Instruct every Docker daemon to trust that certificate. The way to do this
depends on your OS.
- **Linux**: Copy the `domain.crt` file to
`/etc/docker/certs.d/myregistrydomain.com:5000/ca.crt` on every Docker
host. You do not need to restart Docker.
- **Windows Server**:
1. Open Windows Explorer, right-click the `domain.crt`
file, and choose Install certificate. When prompted, select the following
options:
| Store location | local machine |
| Place all certificates in the following store | selected |
2. Click **Browser** and select **Trusted Root Certificate Authorities**.
3. Click **Finish**. Restart Docker.
- **Docker for Mac**: Follow the instructions on
[Adding custom CA certificates](/docker-for-mac/faqs.md#how-do-i-add-custom-ca-certificates){: target="_blank" class="_"}.
Restart Docker.
- **Docker for Windows**: Follow the instructions on
[Adding custom CA certificates](/docker-for-windows/faqs.md#how-do-i-add-custom-ca-certificates){: target="_blank" class="_"}.
Restart Docker.
5. Don't forget to restart the Engine daemon.
## Troubleshooting insecure registry

44
registry/recipes/mirror.md
View File

@ -54,7 +54,7 @@ remote fetch and local re-caching.
To ensure best performance and guarantee correctness the Registry cache should
be configured to use the `filesystem` driver for storage.
## Running a Registry as a pull through cache
## Run a Registry as a pull-through cache
The easiest way to run a registry as a pull through cache is to run the official
Registry image.
@ -63,7 +63,7 @@ Multiple registry caches can be deployed over the same back-end. A single
registry cache will ensure that concurrent requests do not pull duplicate data,
but this property will not hold true for a registry cache cluster.
### Configuring the cache
### Configure the cache
To configure a Registry to run as a pull through cache, the addition of a
`proxy` section is required to the config file.
@ -71,26 +71,32 @@ To configure a Registry to run as a pull through cache, the addition of a
In order to access private images on the Docker Hub, a username and password can
be supplied.
proxy:
remoteurl: https://registry-1.docker.io
username: [username]
password: [password]
```yaml
proxy:
remoteurl: https://registry-1.docker.io
username: [username]
password: [password]
```
> :warn: if you specify a username and password, it's very important to understand that private resources that this user has access to on the Hub will be made available on your mirror. It's thus paramount that you secure your mirror by implementing authentication if you expect these resources to stay private!
> **Warning**: If you specify a username and password, it's very important to
> understand that private resources that this user has access to Docker Hub will
> be made available on your mirror. **You must secure your mirror** by
> implementing authentication if you expect these resources to stay private!
> :warn: in order for the scheduler to clean up old entries, delete must be enabled in the registry configuration. See the [Registry Configuration Reference](../configuration.md) for more details.
> **Warning**: In order for the scheduler to clean up old entries, `delete` must
> be enabled in the registry configuration. See
> [Registry Configuration](/registry/configuration.md) for more details.
### Configuring the Docker daemon
### Configure the Docker daemon
You will need to pass the `--registry-mirror` option to your Docker daemon on
startup:
Either pass the `--registry-mirror` option when starting `dockerd` manually,
or edit `/etc/docker/daemon.json` and add the `registry-mirrors` key and value,
to make the change persistent.
docker --registry-mirror=https://<my-docker-mirror-host> daemon
```json
{
"registry-mirrors": ["https://<my-docker-mirror-host>"]
}
```
For example, if your mirror is serving on `http://10.0.0.2:5000`, you would run:
docker --registry-mirror=https://10.0.0.2:5000 daemon
> NOTE: Depending on your local host setup, you may be able to add the
`--registry-mirror` option to the `DOCKER_OPTS` variable in
`/etc/default/docker`.
Save the file and restart Docker for the change to take effect.

24
swarm/configure-tls.md
View File

@ -335,20 +335,22 @@ On `node1` and `node2` (your Swarm nodes), do the following:
$ sudo su
```
2. Edit Docker Engine configuration file.
2. Add the following configuration keys to the `/etc/docker/daemon.json`. If the
file does not yet exist, create it.
If you are following along with these instructions and using Ubuntu 14.04
LTS, the configuration file is `/etc/default/docker`. The Docker Engine
configuration file may be different depending on the Linux distribution you
are using.
```json
{
"hosts": ["tcp://0.0.0.0:2376"],
"tlsverify": "true",
"tlscacert": "/home/ubuntu/.certs/ca.pem",
"tlscert": "/home/ubuntu/.certs/cert.pem",
"tlskey": "/home/ubuntu/.certs/key.pem"
}
```
3. Add the following options to the `DOCKER_OPTS` line.
Restart Docker for the changes to take effect. If the file is not valid JSON,
Docker will not start and will emit an error.
-H tcp://0.0.0.0:2376 --tlsverify --tlscacert=/home/ubuntu/.certs/ca.pem --tlscert=/home/ubuntu/.certs/cert.pem --tlskey=/home/ubuntu/.certs/key.pem
2. Restart the Docker Engine daemon.
$ service docker restart
3. Repeat the procedure on `node2` as well.

46
swarm/install-manual.md
View File

@ -109,40 +109,32 @@ To create the instances do the following:
## Step 3. Install Engine on each node
In this step, you install Docker Engine on each node. By installing Engine, you enable the Swarm manager to address the nodes via the Engine CLI and API.
1. [Install Docker](/engine/installation/){: target="_blank" class="_"} on each
host, using the appropriate instructions for your operating system and
distribution.
SSH to each node in turn and do the following.
2. Edit `/etc/docker/daemon.json`. Create it if it does not exist. Assuming the
file was empty, its contents should be:
1. Update the yum packages.
```json
{
"hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]
}
```
Keep an eye out for the "y/n/abort" prompt:
Start or restart Docker for the changes to take effect.
$ sudo yum update
```bash
$ sudo systemctl start docker
```
2. Run the installation script.
3. Give the `ec2-user` root privileges:
$ curl -sSL https://get.docker.com/ | sh
```bash
$ sudo usermod -aG docker ec2-user
```
3. Edit `/etc/sysconfig/docker` and add `"-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"`
to the `OPTIONS` variable.
4. Start Docker.
$ sudo /etc/init.d/docker start
4. Verify that Docker Engine is installed correctly by running a container with the
`hello-world` image.
$ sudo docker run hello-world
The output should display a "Hello World" message and other text without any
error messages.
5. Give the `ec2-user` root privileges:
$ sudo usermod -aG docker ec2-user
6. Enter `logout`.
4. Log out of the host.
#### Troubleshooting