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` resolvable on any client daemons that are running in `insecure-registry`
mode. 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 ```json
{
On Ubuntu 14.04 LTS, customize the Docker daemon configuration with the "insecure-registries": ["dtr.yourdomain.com"]
`/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"
``` ```
Then restart the Docker daemon with `sudo service docker restart`. Restart Docker for the change to take effect.
#### 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`.
### Docker Machine and Boot2Docker ### Docker Machine and Boot2Docker
@ -221,7 +202,7 @@ setting as follows:
EXTRA_ARGS="--insecure-registry dtr.yourdomain.com" 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 ## 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 > **Note**: The [Docker networks feature](../index.md) allows you to
create user-defined networks in addition to the default bridge network. 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 You can set up your own bridge before starting Docker and configure Docker to
`--bridge=BRIDGE` to tell Docker to use your bridge instead. If you already use your bridge instead of the default `docker0` bridge.
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:
``` 1. Configure the new bridge.
# Stopping Docker and removing docker0
$ 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 ```bash
whatever configuration you want. Here we will create a simple enough bridge $ ip addr show bridge0
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.
``` 4: bridge0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state UP group default
# Create our own bridge 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 ```bash
link/ether 66:38:d0:0d:76:18 brd ff:ff:ff:ff:ff:ff $ sudo iptables -t nat -L -n
inet 192.168.5.1/24 scope global bridge0
valid_lft forever preferred_lft forever
# 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
```
... 5. Create a new container, and verify that it is in the new IP address range.
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.5.0/24 0.0.0.0/0
```
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 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 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 route` inside a container to confirm that it has an address in the bridge's IP
bridge's IP address range and has been told to use the Docker host's IP address address range and uses the Docker host's IP address on the bridge as its default
on the bridge as its default gateway to the rest of the Internet. 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 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 You can configure the default bridge network's settings using flags to the
CIDR notation. For example: `192.168.1.5/24`. `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. ```json
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 "bip": "192.168.1.5/24",
`--fixed-cidr=192.168.1.0/25`, IPs for your containers will be chosen from the first half of addresses "fixed-cidr": "10.20.0.0/16",
included in the`192.168.1.0/24` subnet. "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`. - `--mtu=BYTES`: override the maximum packet length on `docker0`.
- `--default-gateway=Container default Gateway IPV4 address`: designates the default gateway for - `--default-gateway=Container default Gateway IPV4 address` and
containers connected to the `docker0` bridge, which controls where they route traffic by default. `--default-gateway-v6=Container default gateway IPV6 address`: designates the
Applicable for addresses set with `--bip` and `--fixed-cidr` flags. For instance, you can configure 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`. `--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 - `--dns=[]`: The DNS servers to use. For example: `--dns=172.17.2.10`.
when starting the Docker daemon, by adding the values to `/etc/docker/daemon.json` (recommended) or using
the `--dns` flag when starting `dockerd` manually.
Once you have one or more containers up and running, you can confirm that Docker has properly connected Once you have one or more containers up and running, you can confirm that Docker
them to the `docker0` bridge by running the `brctl` command on the host machine and looking at the has properly connected them to the `docker0` bridge by running the `brctl`
`interfaces` column of the output. This example shows a `docker0` bridge with two containers command on the host machine and looking at the `interfaces` column of the
connected: output. This example shows a `docker0` bridge with two containers connected:
```bash ```bash
$ sudo brctl show $ sudo brctl show
@ -45,11 +83,17 @@ docker0 8000.3a1d7362b4ee no veth65f9
vethdda6 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 # The network, as seen from a container
$ docker run --rm -it alpine /bin/ash $ docker run --rm -it alpine /bin/ash
@ -71,4 +115,8 @@ default via 172.17.42.1 dev eth0
root@f38c87f2a42d:/# exit 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` | |VFS |`vfs` |
|ZFS |`zfs` | |ZFS |`zfs` |
To find out which storage driver is set on the daemon, you use the To find out which storage driver is set on the daemon, look for the
`docker info` command: **Storage Driver** line in the output of `docker info`:
$ docker info ```bash
$ docker info
Containers: 0 Containers: 0
Images: 0 Images: 0
Storage Driver: overlay Storage Driver: overlay
Backing Filesystem: extfs Backing Filesystem: extfs
Execution Driver: native-0.2 Execution Driver: native-0.2
Logging Driver: json-file Logging Driver: json-file
Kernel Version: 3.19.0-15-generic Kernel Version: 3.19.0-15-generic
Operating System: Ubuntu 15.04 Operating System: Ubuntu 15.04
... output truncated ... <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 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 means that the `overlay` storage driver is operating on top of an `ext2fs` or
(ext) filesystem. The backing filesystem refers to the filesystem that was used `ext3fs` filesystem, which is common on Linux. The backing filesystem refers to
to create the Docker host's local storage area under `/var/lib/docker`. 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 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 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 > "Disabled on" means some storage drivers can not run over certain backing
> filesystem. > filesystem.
You can set the storage driver by passing the `--storage-driver=<name>` option You can set the storage driver by setting the option in the `daemon.json`
to the `dockerd` command line, or by setting the option on the file, which is located in `/etc/docker/` on Linux and
`DOCKER_OPTS` line in the `/etc/default/docker` file. `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 If the `daemon.json` file does not exist, create it. Assuming there are no other
`devicemapper` storage driver using the `dockerd` command: 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 > **Note**: Docker for Mac and Docker for Windows only support `overlay2`
Images: 0 > `aufs`, `overlay`, or `vfs`. The last two are **not** recommended. Currently,
Storage Driver: devicemapper > `aufs` is the default in stable releases and `overlay2` is the default in
Pool Name: docker-252:0-147544-pool > Edge releases.
Pool Blocksize: 65.54 kB > In addition, before you change the default storage driver on Docker for Mac or
Backing Filesystem: extfs > Docker for Windows, it is recommended to do a factory reset to wipe the
Data file: /dev/loop0 > old storage location, since you will not be able to access it after you change
Metadata file: /dev/loop1 > the storage driver. If you need to save any containers, use `docker save`
Data Space Used: 1.821 GB > before doing the reset.
Data Space Total: 107.4 GB
Data Space Available: 3.174 GB Restart Docker for the changes to take effect.
Metadata Space Used: 1.479 MB
Metadata Space Total: 2.147 GB Alternatively, you can run the `dockerd` command manually and pass the
Metadata Space Available: 2.146 GB `--storage-driver=<name>` option to try the setting without making it persistent.
Thin Pool Minimum Free Space: 10.74 GB
Udev Sync Supported: true After Docker starts, look for the **Storage Driver** line in the output of
Deferred Removal Enabled: false `docker info` to verify your configuration.
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata ```bash
Library Version: 1.02.90 (2014-09-01) $ docker info
Execution Driver: native-0.2
Logging Driver: json-file Containers: 0
Kernel Version: 3.19.0-15-generic Images: 0
Operating System: Ubuntu 15.04 Storage Driver: devicemapper
<output truncated> 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 Your choice of storage driver can affect the performance of your containerized
applications. So it's important to understand the different storage driver applications, and the supported storage drivers depend on your operating system
options available and select the right one for your application. Later, in this and distribution. It's important to understand the different storage driver
page you'll find some advice for choosing an appropriate driver. options available and choose the best one for your situation.
## Shared storage systems and the storage driver ## 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 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 issued by a known CA, you can choose to use self-signed certificates, or use
certificates, or even use your registry over plain http. your registry over an unencrypted HTTP connection. Either of these choices
involves security trade-offs and additional configuration steps.
You have to understand the downsides in doing so, and the extra burden in
configuration.
## Deploying a plain HTTP registry ## Deploying a plain HTTP registry
@ -17,31 +15,40 @@ configuration.
> it's not possible to use an insecure registry with basic authentication. > it's not possible to use an insecure registry with basic authentication.
{:.warning} {:.warning}
This basically tells Docker to entirely disregard security for your registry. This procedure configures Docker to entirely disregard security for your
While this is relatively easy to configure the daemon in this way, it is registry. This is **very** insecure and is not recommended. It exposes your
**very** insecure. It does expose your registry to trivial MITM. Only use this registry to trivial man-in-the-middle (MITM) attacks. Only use this solution for
solution for isolated testing or in a tightly controlled, air-gapped isolated testing or in a tightly controlled, air-gapped environment.
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. 2. Restart Docker for the changes to take effect.
For example, on Ubuntu, this is usually the `service docker stop` and `service
docker start` command.
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 ## 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) > 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} {:.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 \ ```bash
-newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \ $ mkdir -p certs
-x509 -days 365 -out certs/domain.crt
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 ## 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 To ensure best performance and guarantee correctness the Registry cache should
be configured to use the `filesystem` driver for storage. 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 The easiest way to run a registry as a pull through cache is to run the official
Registry image. 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, registry cache will ensure that concurrent requests do not pull duplicate data,
but this property will not hold true for a registry cache cluster. 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 To configure a Registry to run as a pull through cache, the addition of a
`proxy` section is required to the config file. `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 In order to access private images on the Docker Hub, a username and password can
be supplied. be supplied.
proxy: ```yaml
remoteurl: https://registry-1.docker.io proxy:
username: [username] remoteurl: https://registry-1.docker.io
password: [password] 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 Either pass the `--registry-mirror` option when starting `dockerd` manually,
startup: 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: Save the file and restart Docker for the change to take effect.
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`.

24
swarm/configure-tls.md
View File

@ -335,20 +335,22 @@ On `node1` and `node2` (your Swarm nodes), do the following:
$ sudo su $ 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 ```json
LTS, the configuration file is `/etc/default/docker`. The Docker Engine {
configuration file may be different depending on the Linux distribution you "hosts": ["tcp://0.0.0.0:2376"],
are using. "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. 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 ## 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"` 4. Log out of the host.
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`.
#### Troubleshooting #### Troubleshooting