mirror of https://github.com/docker/docs.git
engine: use relative markdown links
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
parent
cef68d3fa5
commit
777c5d23da
|
@ -10,8 +10,8 @@ redirect_from:
|
|||
---
|
||||
|
||||
After you
|
||||
[install Docker](/get-docker.md), you can
|
||||
[install the Go or Python SDK](/engine/api/sdk/index.md#install-the-sdks) and
|
||||
[install Docker](../../../get-docker.md), you can
|
||||
[install the Go or Python SDK](index.md#install-the-sdks) and
|
||||
also try out the Docker Engine API.
|
||||
|
||||
Each of these examples show how to perform a given Docker operation using the Go
|
||||
|
|
|
@ -167,7 +167,7 @@ hello world
|
|||
</div>
|
||||
</div>
|
||||
|
||||
For more examples, take a look at the [SDK examples](/engine/api/sdk/examples.md).
|
||||
For more examples, take a look at the [SDK examples](examples.md).
|
||||
|
||||
## Unofficial libraries
|
||||
|
||||
|
|
|
@ -6,7 +6,7 @@ title: Dockerize an apt-cacher-ng service
|
|||
|
||||
> **Note**:
|
||||
> - **If you don't like sudo** then see
|
||||
> [*Giving non-root access*](/engine/install/linux-postinstall.md#manage-docker-as-a-non-root-user).
|
||||
> [*Giving non-root access*](../install/linux-postinstall.md#manage-docker-as-a-non-root-user).
|
||||
> - **If you're using macOS or docker via TCP** then you shouldn't use sudo.
|
||||
|
||||
When you have multiple Docker servers, or build unrelated Docker
|
||||
|
|
|
@ -5,7 +5,7 @@ title: Dockerize a CouchDB service
|
|||
---
|
||||
|
||||
> **Note**:
|
||||
> - **If you don't like sudo** then see [*Giving non-root access*](/engine/install/linux-postinstall.md#manage-docker-as-a-non-root-user)
|
||||
> - **If you don't like sudo** then see [*Giving non-root access*](../install/linux-postinstall.md#manage-docker-as-a-non-root-user)
|
||||
|
||||
Here's an example of using data volumes to share the same data between
|
||||
two CouchDB containers. This could be used for hot upgrades, testing
|
||||
|
|
|
@ -36,8 +36,8 @@ tutorial](https://www.asp.net/get-started) to initialize a project or clone our
|
|||
Containers](https://docs.microsoft.com/virtualization/windowscontainers/about/).
|
||||
The tags below are multi-arch meaning they pull either Windows or
|
||||
Linux containers depending on what mode is set in
|
||||
[Docker Desktop for Windows](/docker-for-windows/index.md). Read more on
|
||||
[switching containers](/docker-for-windows/index.md#switch-between-windows-and-linux-containers).
|
||||
[Docker Desktop for Windows](../../docker-for-windows/index.md). Read more on
|
||||
[switching containers](../../docker-for-windows/index.md#switch-between-windows-and-linux-containers).
|
||||
3. The `Dockerfile` assumes that your application is called `aspnetapp`. Change
|
||||
the `Dockerfile` to use the DLL file of your project.
|
||||
|
||||
|
@ -82,7 +82,7 @@ $ docker run -d -p 8080:80 --name myapp aspnetapp
|
|||
## View the web page running from a container
|
||||
|
||||
* Go to [localhost:8080](http://localhost:8080) to access your app in a web browser.
|
||||
* If you are using the Nano [Windows Container](/docker-for-windows/index.md)
|
||||
* If you are using the Nano [Windows Container](../../docker-for-windows/index.md)
|
||||
and have not updated to the Windows Creator Update there is a bug affecting how
|
||||
[Windows 10 talks to Containers via "NAT"](https://github.com/Microsoft/Virtualization-Documentation/issues/181#issuecomment-252671828)
|
||||
(Network Address Translation). You must hit the IP of the container
|
||||
|
|
|
@ -80,7 +80,7 @@ $ docker run --rm -P --name pg_test eg_postgresql
|
|||
```
|
||||
|
||||
There are two ways to connect to the PostgreSQL server. We can use
|
||||
[*Link Containers*](../userguide/networking/default_network/dockerlinks.md),
|
||||
[*Link Containers*](../../network/links.md),
|
||||
or we can access it from our host (or the network).
|
||||
|
||||
> **Note**: The `--rm` removes the container and its image when
|
||||
|
|
|
@ -56,7 +56,7 @@ offers a high-level tool with several powerful functionalities:
|
|||
uploads and downloads, similar to `git pull`, so new versions of a container
|
||||
can be transferred by only sending diffs.
|
||||
|
||||
- *Component re-use.* Any container can be used as a [*parent image*](/glossary.md#parent_image) to
|
||||
- *Component re-use.* Any container can be used as a [*parent image*](../glossary.md#parent_image) to
|
||||
create more specialized components. This can be done manually or as part of an
|
||||
automated build. For example you can prepare the ideal Python environment, and
|
||||
use it as a base for 10 different applications. Your ideal PostgreSQL setup can
|
||||
|
@ -66,7 +66,7 @@ be re-used for all your future projects. And so on.
|
|||
Hub](https://hub.docker.com/){: target="_blank" class="_"} where thousands of
|
||||
people have uploaded useful images: anything from Redis, CouchDB, PostgreSQL to
|
||||
IRC bouncers to Rails app servers to Hadoop to base images for various Linux
|
||||
distros. The [*registry*](/registry/) also includes an official "standard
|
||||
distros. The [*registry*](../registry/index.md) also includes an official "standard
|
||||
library" of useful containers maintained by the Docker team. The registry itself
|
||||
is open-source, so anyone can deploy their own registry to store and transfer
|
||||
private containers, for internal server deployments for example.
|
||||
|
@ -100,37 +100,15 @@ thousands or even millions of containers.
|
|||
|
||||
### How do I connect Docker containers?
|
||||
|
||||
Currently the recommended way to connect containers is via the Docker network feature. You can see details of how to [work with Docker networks here](userguide/networking/work-with-networks.md).
|
||||
Currently the recommended way to connect containers is via the Docker network
|
||||
feature. You can see details of [how to work with Docker networks](../network/bridge.md).
|
||||
|
||||
### How do I run more than one process in a Docker container?
|
||||
|
||||
This approach is discouraged for most use cases. For maximum efficiency and
|
||||
isolation, each container should address one specific area of concern. However,
|
||||
if you need to run multiple services within a single container, see
|
||||
[Run multiple services in a container](admin/multi-service_container.md).
|
||||
|
||||
### What platforms does Docker run on?
|
||||
|
||||
Linux:
|
||||
|
||||
- Any distribution running version 3.10+ of the Linux kernel
|
||||
- Specific instructions are available for most Linux distributions, including
|
||||
[RHEL](installation/linux/rhel.md), [Ubuntu](installation/linux/ubuntulinux.md),
|
||||
[Oracle Linux](installation/linux/oracle.md),
|
||||
[SuSE](installation/linux/suse.md), and many others.
|
||||
|
||||
Microsoft Windows:
|
||||
|
||||
- Windows Server 2016
|
||||
- Windows 10
|
||||
|
||||
Cloud:
|
||||
|
||||
- Amazon EC2
|
||||
- Google Compute Engine
|
||||
- Microsoft Azure
|
||||
- Rackspace
|
||||
- Oracle Cloud Infrastructure
|
||||
[Run multiple services in a container](../config/containers/multi-service_container.md).
|
||||
|
||||
### How do I report a security issue with Docker?
|
||||
|
||||
|
@ -245,11 +223,8 @@ You need to tell Docker to talk to that machine. You can do this with the
|
|||
|
||||
You can find more answers on:
|
||||
|
||||
- [Docker user mailinglist](https://groups.google.com/d/forum/docker-user){: target="_blank" class="_"}
|
||||
- [Docker developer mailinglist](https://groups.google.com/d/forum/docker-dev){: target="_blank" class="_"}
|
||||
- [IRC, docker on freenode](irc://chat.freenode.net#docker)
|
||||
- [Docker community Slack channel](http://dockr.ly/slack)
|
||||
- [Docker Support Forums](https://forums.docker.com)
|
||||
- [GitHub](https://github.com/moby/moby){: target="_blank" class="_"}
|
||||
- [Ask questions on Stackoverflow](http://stackoverflow.com/search?q=docker){: target="_blank" class="_"}
|
||||
- [Join the conversation on Twitter](http://twitter.com/docker){: target="_blank" class="_"}
|
||||
|
||||
Looking for something else to read? Checkout the [User Guide](userguide/index.md).
|
||||
|
|
|
@ -23,12 +23,12 @@ daemon through scripting or direct CLI commands. Many other Docker applications
|
|||
use the underlying API and CLI. The daemon creates and manage Docker objects,
|
||||
such as images, containers, networks, and volumes.
|
||||
|
||||
For more details, see [Docker Architecture](/get-started/overview.md#docker-architecture).
|
||||
For more details, see [Docker Architecture](../get-started/overview.md#docker-architecture).
|
||||
|
||||
## Docker user guide
|
||||
|
||||
To learn about Docker in more detail and to answer questions about usage and
|
||||
implementation, check out the [overview page in "get started"](/get-started/overview.md).
|
||||
implementation, check out the [overview page in "get started"](../get-started/overview.md).
|
||||
|
||||
## Installation guides
|
||||
|
||||
|
|
|
@ -69,10 +69,10 @@ instructions for enabling and configuring AppArmor or SELinux.
|
|||
##### Docker daemon considerations
|
||||
|
||||
- Enable `seccomp` security profiles if possible. See
|
||||
[Enabling `seccomp` for Docker](/engine/security/seccomp.md).
|
||||
[Enabling `seccomp` for Docker](../security/seccomp.md).
|
||||
|
||||
- Enable user namespaces if possible. See the
|
||||
[Daemon user namespace options](/engine/reference/commandline/dockerd.md#daemon-user-namespace-options).
|
||||
[Daemon user namespace options](/engine/reference/commandline/dockerd/#daemon-user-namespace-options).
|
||||
|
||||
### Install static binaries
|
||||
|
||||
|
@ -164,5 +164,5 @@ version.
|
|||
## Next steps
|
||||
|
||||
- Continue to [Post-installation steps for Linux](linux-postinstall.md).
|
||||
- Take a look at the [Get started](/get-started/index.md) training modules to learn how to build an image and run it as a containerized application.
|
||||
- Review the topics in [Develop with Docker](/develop/index.md) to learn how to build new applications using Docker.
|
||||
- Take a look at the [Get started](../../get-started/index.md) training modules to learn how to build an image and run it as a containerized application.
|
||||
- Review the topics in [Develop with Docker](../../develop/index.md) to learn how to build new applications using Docker.
|
||||
|
|
|
@ -262,4 +262,4 @@ You must delete any edited configuration files manually.
|
|||
## Next steps
|
||||
|
||||
- Continue to [Post-installation steps for Linux](linux-postinstall.md).
|
||||
- Review the topics in [Develop with Docker](/develop/index.md) to learn how to build new applications using Docker.
|
||||
- Review the topics in [Develop with Docker](../../develop/index.md) to learn how to build new applications using Docker.
|
||||
|
|
|
@ -287,4 +287,4 @@ You must delete any edited configuration files manually.
|
|||
## Next steps
|
||||
|
||||
- Continue to [Post-installation steps for Linux](linux-postinstall.md).
|
||||
- Review the topics in [Develop with Docker](/develop/index.md) to learn how to build new applications using Docker.
|
||||
- Review the topics in [Develop with Docker](../../develop/index.md) to learn how to build new applications using Docker.
|
||||
|
|
|
@ -269,4 +269,4 @@ You must delete any edited configuration files manually.
|
|||
## Next steps
|
||||
|
||||
- Continue to [Post-installation steps for Linux](linux-postinstall.md).
|
||||
- Review the topics in [Develop with Docker](/develop/index.md) to learn how to build new applications using Docker.
|
||||
- Review the topics in [Develop with Docker](../../develop/index.md) to learn how to build new applications using Docker.
|
||||
|
|
|
@ -21,7 +21,7 @@ toc_max: 2
|
|||
## Supported platforms
|
||||
|
||||
Docker Engine is available on a variety of [Linux platforms](#server),
|
||||
[macOS](/docker-for-mac/install.md) and [Windows 10](/docker-for-windows/install.md)
|
||||
[macOS](../../docker-for-mac/install.md) and [Windows 10](../../docker-for-windows/install.md)
|
||||
through Docker Desktop, and as a [static binary installation](binaries.md). Find
|
||||
your preferred operating system below.
|
||||
|
||||
|
@ -29,10 +29,10 @@ your preferred operating system below.
|
|||
|
||||
{% assign yes = '{: style="height: 14px; margin: 0 auto"}' %}
|
||||
|
||||
| Platform | x86_64 / amd64 |
|
||||
|:-------------------------------------------------------------|:-------------------------------------------:|
|
||||
| [Docker Desktop for Mac (macOS)](/docker-for-mac/install.md) | [{{ yes }}](/docker-for-mac/install.md) |
|
||||
| [Docker Desktop for Windows](/docker-for-windows/install.md) | [{{ yes }}](/docker-for-windows/install.md) |
|
||||
| Platform | x86_64 / amd64 |
|
||||
|:------------------------------------------------------------------|:------------------------------------------------:|
|
||||
| [Docker Desktop for Mac (macOS)](../../docker-for-mac/install.md) | [{{ yes }}](../../docker-for-mac/install.md) |
|
||||
| [Docker Desktop for Windows](../../docker-for-windows/install.md) | [{{ yes }}](../../docker-for-windows/install.md) |
|
||||
|
||||
#### Server
|
||||
|
||||
|
@ -159,4 +159,4 @@ for it.
|
|||
## Get started
|
||||
|
||||
After setting up Docker, you can learn the basics with
|
||||
[Getting started with Docker](/get-started/index.md).
|
||||
[Getting started with Docker](../../get-started/index.md).
|
||||
|
|
|
@ -25,13 +25,13 @@ creates a Unix socket accessible by members of the `docker` group.
|
|||
>
|
||||
> The `docker` group grants privileges equivalent to the `root`
|
||||
> user. For details on how this impacts security in your system, see
|
||||
> [*Docker Daemon Attack Surface*](/engine/security/security.md#docker-daemon-attack-surface).
|
||||
> [*Docker Daemon Attack Surface*](../security/security.md#docker-daemon-attack-surface).
|
||||
{: .warning}
|
||||
|
||||
> **Note**:
|
||||
>
|
||||
> To run Docker without root privileges, see
|
||||
> [Run the Docker daemon as a non-root user (Rootless mode)](/engine/security/rootless.md).
|
||||
> [Run the Docker daemon as a non-root user (Rootless mode)](../security/rootless.md).
|
||||
>
|
||||
> Rootless mode is currently available as an experimental feature.
|
||||
|
||||
|
@ -110,7 +110,7 @@ $ sudo systemctl disable docker
|
|||
|
||||
If you need to add an HTTP Proxy, set a different directory or partition for the
|
||||
Docker runtime files, or make other customizations, see
|
||||
[customize your systemd Docker daemon options](/engine/admin/systemd.md).
|
||||
[customize your systemd Docker daemon options](../../config/daemon/systemd.md).
|
||||
|
||||
### `upstart`
|
||||
|
||||
|
@ -130,13 +130,13 @@ $ sudo chkconfig docker on
|
|||
## Use a different storage engine
|
||||
|
||||
For information about the different storage engines, see
|
||||
[Storage drivers](/engine/userguide/storagedriver/imagesandcontainers.md).
|
||||
[Storage drivers](../../storage/storagedriver/index.md).
|
||||
The default storage engine and the list of supported storage engines depend on
|
||||
your host's Linux distribution and available kernel drivers.
|
||||
|
||||
## Configure default logging driver
|
||||
|
||||
Docker provides the [capability](/config/containers/logging/) to collect and view log data from all containers running on a host via a series of logging drivers. The default logging driver, `json-file`, writes log data to JSON-formatted files on the host filesystem. Over time, these log files expand in size, leading to potential exhaustion of disk resources. To alleviate such issues, either configure an alternative logging driver such as Splunk or Syslog, or [set up log rotation](/config/containers/logging/configure/#configure-the-default-logging-driver) for the default driver. If you configure an alternative logging driver, see [Use `docker logs` to read container logs for remote logging drivers](/config/containers/logging/dual-logging/).
|
||||
Docker provides the [capability](../../config/containers/logging/index.md) to collect and view log data from all containers running on a host via a series of logging drivers. The default logging driver, `json-file`, writes log data to JSON-formatted files on the host filesystem. Over time, these log files expand in size, leading to potential exhaustion of disk resources. To alleviate such issues, either configure an alternative logging driver such as Splunk or Syslog, or [set up log rotation](/config/containers/logging/configure/#configure-the-default-logging-driver) for the default driver. If you configure an alternative logging driver, see [Use `docker logs` to read container logs for remote logging drivers](/config/containers/logging/dual-logging/).
|
||||
|
||||
## Configure where the Docker daemon listens for connections
|
||||
|
||||
|
@ -220,7 +220,7 @@ Configuring Docker to accept remote connections can be done with the `docker.ser
|
|||
## Enable IPv6 on the Docker daemon
|
||||
|
||||
To enable IPv6 on the Docker daemon, see
|
||||
[Enable IPv6 support](/config/daemon/ipv6.md).
|
||||
[Enable IPv6 support](../../config/daemon/ipv6.md).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
@ -503,5 +503,5 @@ and a 10% overall performance degradation, even if Docker is not running.
|
|||
|
||||
## Next steps
|
||||
|
||||
- Take a look at the [Get started](/get-started/index.md) training modules to learn how to build an image and run it as a containerized application.
|
||||
- Review the topics in [Develop with Docker](/develop/index.md) to learn how to build new applications using Docker.
|
||||
- Take a look at the [Get started](../../get-started/index.md) training modules to learn how to build an image and run it as a containerized application.
|
||||
- Review the topics in [Develop with Docker](../../develop/index.md) to learn how to build new applications using Docker.
|
||||
|
|
|
@ -19,15 +19,6 @@ To get started with Docker Engine on Ubuntu, make sure you
|
|||
|
||||
## Prerequisites
|
||||
|
||||
### Docker EE customers
|
||||
|
||||
To install Docker Enterprise Edition (Docker EE), go to
|
||||
[Get Docker EE for Ubuntu](/ee/docker-ee/ubuntu.md)
|
||||
**instead of this topic**.
|
||||
|
||||
To learn more about Docker EE, see
|
||||
[Docker Enterprise Edition](https://www.docker.com/enterprise-edition/){: target="_blank" class="_" }.
|
||||
|
||||
### OS requirements
|
||||
|
||||
To install Docker Engine, you need the 64-bit version of one of these Ubuntu
|
||||
|
@ -60,7 +51,7 @@ Docker Engine on Ubuntu supports `overlay2`, `aufs` and `btrfs` storage drivers.
|
|||
|
||||
Docker Engine uses the `overlay2` storage driver by default. If you need to use
|
||||
`aufs` instead, you need to configure it manually.
|
||||
See [use the AUFS storage driver](/storage/storagedriver/aufs-driver.md)
|
||||
See [use the AUFS storage driver](../../storage/storagedriver/aufs-driver.md)
|
||||
|
||||
## Installation methods
|
||||
|
||||
|
@ -321,4 +312,4 @@ You must delete any edited configuration files manually.
|
|||
## Next steps
|
||||
|
||||
- Continue to [Post-installation steps for Linux](linux-postinstall.md).
|
||||
- Review the topics in [Develop with Docker](/develop/index.md) to learn how to build new applications using Docker.
|
||||
- Review the topics in [Develop with Docker](../../develop/index.md) to learn how to build new applications using Docker.
|
||||
|
|
|
@ -18,4 +18,4 @@ https://github.com/docker/cli
|
|||
|
||||
## More info
|
||||
|
||||
[Store configuration data using Docker Configs](/engine/swarm/configs.md)
|
||||
[Store configuration data using Docker Configs](../../swarm/configs.md)
|
||||
|
|
|
@ -29,6 +29,6 @@ WARNING: No swap limit support
|
|||
```
|
||||
|
||||
You can ignore these warnings unless you actually need the ability to
|
||||
[limit these resources](/engine/admin/resource_constraints.md), in which case you
|
||||
[limit these resources](../../../config/containers/resource_constraints.md), in which case you
|
||||
should consult your operating system's documentation for enabling them.
|
||||
[Learn more](/engine/installation/linux/linux-postinstall.md#your-kernel-does-not-support-cgroup-swap-limit-capabilities).
|
||||
[Learn more](../../install/linux-postinstall.md#your-kernel-does-not-support-cgroup-swap-limit-capabilities).
|
||||
|
|
|
@ -20,7 +20,7 @@ CONFIG_SECCOMP=y
|
|||
|
||||
> **Note**: `seccomp` profiles require seccomp 2.2.1 which is not available on
|
||||
> Ubuntu 14.04, Debian Wheezy, or Debian Jessie. To use `seccomp` on these
|
||||
> distributions, you must download the [latest static Linux binaries](/engine/installation/linux/docker-ce/binaries.md)
|
||||
> distributions, you must download the [latest static Linux binaries](../install/binaries.md)
|
||||
> (rather than packages).
|
||||
|
||||
## Pass a profile for a container
|
||||
|
|
|
@ -35,7 +35,7 @@ of another container. Of course, if the host system is setup
|
|||
accordingly, containers can interact with each other through their
|
||||
respective network interfaces — just like they can interact with
|
||||
external hosts. When you specify public ports for your containers or use
|
||||
[*links*](../userguide/networking/default_network/dockerlinks.md)
|
||||
[*links*](../../network/links.md)
|
||||
then IP traffic is allowed between containers. They can ping each other,
|
||||
send/receive UDP packets, and establish TCP connections, but that can be
|
||||
restricted if necessary. From a network architecture point of view, all
|
||||
|
@ -220,7 +220,7 @@ This feature provides more insight to administrators than previously available w
|
|||
the CLI for enforcing and performing image signature verification.
|
||||
|
||||
For more information on configuring Docker Content Trust Signature Verificiation, go to
|
||||
[Content trust in Docker](../security/trust/content_trust).
|
||||
[Content trust in Docker](trust/content_trust.md).
|
||||
|
||||
## Other kernel security features
|
||||
|
||||
|
@ -275,8 +275,8 @@ pull requests, or comments on the Docker community forums.
|
|||
|
||||
## Related information
|
||||
|
||||
* [Use trusted images](../security/trust/index.md)
|
||||
* [Seccomp security profiles for Docker](../security/seccomp.md)
|
||||
* [AppArmor security profiles for Docker](../security/apparmor.md)
|
||||
* [Use trusted images](trust/index.md)
|
||||
* [Seccomp security profiles for Docker](seccomp.md)
|
||||
* [AppArmor security profiles for Docker](apparmor.md)
|
||||
* [On the Security of Containers (2014)](https://medium.com/@ewindisch/on-the-security-of-containers-2c60ffe25a9e)
|
||||
* [Docker swarm mode overlay network security model](../userguide/networking/overlay-security-model.md)
|
||||
* [Docker swarm mode overlay network security model](../../network/overlay.md)
|
||||
|
|
|
@ -237,7 +237,7 @@ Engine Signature Verification prevents the following:
|
|||
|
||||
> **Note:**
|
||||
> The implicit pulls and runs performed by worker
|
||||
> nodes for a [Swarm service](/engine/swarm/services.md) on `$ docker service create` and
|
||||
> nodes for a [Swarm service](../../swarm/services.md) on `$ docker service create` and
|
||||
> `$ docker service update` are also verified. Tag resolution of services
|
||||
> requires that all nodes in the Swarm including managers have content trust
|
||||
> enabled and similarly configured.
|
||||
|
|
|
@ -4,7 +4,7 @@ keywords: trust, security, notary, deployment
|
|||
title: Deploy Notary Server with Compose
|
||||
---
|
||||
|
||||
The easiest way to deploy Notary Server is by using Docker Compose. To follow the procedure on this page, you must have already [installed Docker Compose](/compose/install.md).
|
||||
The easiest way to deploy Notary Server is by using Docker Compose. To follow the procedure on this page, you must have already [installed Docker Compose](../../../compose/install.md).
|
||||
|
||||
1. Clone the Notary repository.
|
||||
|
||||
|
@ -15,7 +15,7 @@ The easiest way to deploy Notary Server is by using Docker Compose. To follow th
|
|||
docker-compose up -d
|
||||
|
||||
|
||||
For more detailed documentation about how to deploy Notary Server, see the [instructions to run a Notary service](/notary/running_a_service.md) as well as [the Notary repository](https://github.com/theupdateframework/notary) for more information.
|
||||
For more detailed documentation about how to deploy Notary Server, see the [instructions to run a Notary service](../../../notary/running_a_service.md) as well as [the Notary repository](https://github.com/theupdateframework/notary) for more information.
|
||||
3. Make sure that your Docker or Notary client trusts Notary Server's certificate before you try to interact with the Notary server.
|
||||
|
||||
See the instructions for [Docker](../../reference/commandline/cli.md#notary) or
|
||||
|
|
|
@ -12,7 +12,7 @@ This guide follows the steps as described
|
|||
[here](content_trust/#signing-images-with-docker-content-trust) so please read
|
||||
that and understand its prerequisites.
|
||||
|
||||
When working directly with the Notary client, it uses its [own set of environment variables](/notary/reference/client-config.md#environment-variables-optional).
|
||||
When working directly with the Notary client, it uses its [own set of environment variables](../../../notary/reference/client-config.md#environment-variables-optional).
|
||||
|
||||
## Add a delegation private key
|
||||
|
||||
|
|
|
@ -74,10 +74,6 @@ you are not authorized to perform this operation: server returned 401.
|
|||
Failed to add signer to: dtr.example.com/user/repo
|
||||
```
|
||||
|
||||
If you are using DTR and would like to work with a remote UCP's signing policy,
|
||||
you must [register your DTR instance with that remote UCP](/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp/#registering-dtr-with-a-remote-universal-control-plane).
|
||||
See [Using Docker Content Trust with a Remote UCP Cluster](/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp/) for more details.
|
||||
|
||||
## Configuring the Notary Client
|
||||
|
||||
Some of the more advanced features of DCT require the Notary CLI. To install and
|
||||
|
@ -88,7 +84,7 @@ and ensure that it is available on your path.
|
|||
|
||||
2) Create a configuration file at `~/.notary/config.json` with the following content:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"trust_dir" : "~/.docker/trust",
|
||||
"remote_server": {
|
||||
|
@ -108,8 +104,7 @@ Docker Content Trust use cases, refer to the Notary CLI documentation
|
|||
|
||||
A prerequisite to adding your first contributor is a pair of delegation keys.
|
||||
These keys can either be generated locally using `$ docker trust`, generated by
|
||||
a certificate authority, or can be taken from a Universal Control Plane's
|
||||
[Client Bundle](ee/ucp/user-access/cli/#download-client-certificates).
|
||||
a certificate authority.
|
||||
|
||||
### Using Docker Trust to Generate Keys
|
||||
|
||||
|
@ -117,8 +112,9 @@ Docker trust has a built-in generator for a delegation key pair,
|
|||
`$ docker trust generate <name>`. Running this command will automatically load
|
||||
the delegation private key in to the local Docker trust store.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust key generate jeff
|
||||
|
||||
Generating key for jeff...
|
||||
Enter passphrase for new jeff key with ID 9deed25:
|
||||
Repeat passphrase for new jeff key with ID 9deed25:
|
||||
|
@ -134,13 +130,13 @@ cfssl along with a local or company-wide Certificate Authority.
|
|||
Here is an example of how to generate a 2048-bit RSA portion key (all RSA keys
|
||||
must be at least 2048 bits):
|
||||
|
||||
```
|
||||
```bash
|
||||
$ openssl genrsa -out delegation.key 2048
|
||||
|
||||
Generating RSA private key, 2048 bit long modulus
|
||||
....................................................+++
|
||||
............+++
|
||||
e is 65537 (0x10001)
|
||||
|
||||
```
|
||||
|
||||
They should keep `delegation.key` private because it is used to sign tags.
|
||||
|
@ -149,7 +145,7 @@ Then they need to generate an x509 certificate containing the public key, which
|
|||
what you need from them. Here is the command to generate a CSR (certificate
|
||||
signing request):
|
||||
|
||||
```
|
||||
```bash
|
||||
$ openssl req -new -sha256 -key delegation.key -out delegation.csr
|
||||
```
|
||||
|
||||
|
@ -157,7 +153,7 @@ Then they can send it to whichever CA you trust to sign certificates, or they
|
|||
can self-sign the certificate (in this example, creating a certificate that is
|
||||
valid for 1 year):
|
||||
|
||||
```
|
||||
```bash
|
||||
$ openssl x509 -req -sha256 -days 365 -in delegation.csr -signkey delegation.key -out delegation.crt
|
||||
```
|
||||
|
||||
|
@ -166,43 +162,21 @@ by a CA.
|
|||
|
||||
Finally you will need to add the private key into your local Docker trust store.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust key load delegation.key --name jeff
|
||||
|
||||
Loading key from "delegation.key"...
|
||||
Enter passphrase for new jeff key with ID 8ae710e:
|
||||
Repeat passphrase for new jeff key with ID 8ae710e:
|
||||
Successfully imported key from delegation.key
|
||||
```
|
||||
|
||||
### Using Universal Control Plane's Client Bundles
|
||||
|
||||
Universal Control Plane (UCP) manages CLI and API access to its clusters through
|
||||
certificates generated in a Client Bundle. These certificates and keys can be
|
||||
used as a delegation key pair. Within each client bundle there is a unique
|
||||
private key (`key.pem`) and x509 certificate containing a public key
|
||||
(`cert.pem`).
|
||||
|
||||
1) Download a user's client bundle from the
|
||||
[Universal Control Plane](ee/ucp/user-access/cli/#download-client-certificates).
|
||||
|
||||
2) Extract the client bundle into your current directory
|
||||
|
||||
3) Load the private key into your local Docker trust store
|
||||
|
||||
```
|
||||
$ docker trust key load key.pem --name jeff
|
||||
Loading key from "key.pem"...
|
||||
Enter passphrase for new jeff key with ID 9deed25:
|
||||
Repeat passphrase for new jeff key with ID 9deed25:
|
||||
Successfully imported key from key.pem
|
||||
```
|
||||
|
||||
### Viewing local Delegation keys
|
||||
|
||||
To list the keys that have been imported in to the local Docker trust store we
|
||||
can use the Notary CLI.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary key list
|
||||
|
||||
ROLE GUN KEY ID LOCATION
|
||||
|
@ -217,13 +191,13 @@ When the first Delegation is added to the Notary Server using `$ docker trust`,
|
|||
we automatically initiate trust data for the repository. This includes creating
|
||||
the notary target and snapshots keys, and rotating the snapshot key to be
|
||||
managed by the notary server. More information on these keys can be found
|
||||
[here](./trust_key_mng.md)
|
||||
[here](trust_key_mng.md)
|
||||
|
||||
When initiating a repository, you will need the key and the passphrase of a local
|
||||
Notary Canonical Root Key. If you have not initiated a repository before, and
|
||||
therefore don't have a Notary root key, `$ docker trust` will create one for you.
|
||||
|
||||
> Be sure to protect and back up your [Notary Canonical Root Key](./trust_key_mng.md)
|
||||
> Be sure to protect and back up your [Notary Canonical Root Key](trust_key_mng.md)
|
||||
|
||||
### Initiating the Repository
|
||||
|
||||
|
@ -236,8 +210,9 @@ For DCT the name of the second delegation, in the below example
|
|||
`jeff`, is there to help you keep track of the owner of the keys. In more
|
||||
advanced use cases of Notary additional delegations are used for hierarchy.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust signer add --key cert.pem jeff dtr.example.com/admin/demo
|
||||
|
||||
Adding signer "jeff" to dtr.example.com/admin/demo...
|
||||
Initializing signed repository for dtr.example.com/admin/demo...
|
||||
Enter passphrase for root key with ID f6c6a4b:
|
||||
|
@ -250,7 +225,7 @@ Successfully added signer: jeff to dtr.example.com/admin/demo
|
|||
You can see which keys have been pushed to the Notary server for each repository
|
||||
with the `$ docker trust inspect` command.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/admin/demo
|
||||
|
||||
No signatures for dtr.example.com/admin/demo
|
||||
|
@ -270,7 +245,7 @@ Administrative keys for dtr.example.com/admin/demo
|
|||
You could also use the Notary CLI to list delegations and keys. Here you can
|
||||
clearly see the keys were attached to `targets/releases` and `targets/jeff`.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary delegation list dtr.example.com/admin/demo
|
||||
|
||||
ROLE PATHS KEY IDS THRESHOLD
|
||||
|
@ -290,8 +265,9 @@ the `targets/release` role.
|
|||
> Note you will need the passphrase for the repository key; this would have been
|
||||
> configured when you first initiated the repository.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust signer add --key ben.pub ben dtr.example.com/admin/demo
|
||||
|
||||
Adding signer "ben" to dtr.example.com/admin/demo...
|
||||
Enter passphrase for repository key with ID b0014f8:
|
||||
Successfully added signer: ben to dtr.example.com/admin/demo
|
||||
|
@ -299,7 +275,7 @@ Successfully added signer: ben to dtr.example.com/admin/demo
|
|||
|
||||
Check to prove that there are now 2 delegations (Signer).
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/admin/demo
|
||||
|
||||
No signatures for dtr.example.com/admin/demo
|
||||
|
@ -326,8 +302,9 @@ will automatically handle adding this new key to `targets/releases`.
|
|||
> Note you will need the passphrase for the repository key; this would have been
|
||||
> configured when you first initiated the repository.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust signer add --key cert2.pem jeff dtr.example.com/admin/demo
|
||||
|
||||
Adding signer "jeff" to dtr.example.com/admin/demo...
|
||||
Enter passphrase for repository key with ID b0014f8:
|
||||
Successfully added signer: jeff to dtr.example.com/admin/demo
|
||||
|
@ -335,7 +312,7 @@ Successfully added signer: jeff to dtr.example.com/admin/demo
|
|||
|
||||
Check to prove that the delegation (Signer) now contains multiple Key IDs.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust inspect --pretty dtr.example.com/admin/demo
|
||||
|
||||
No signatures for dtr.example.com/admin/demo
|
||||
|
@ -361,7 +338,7 @@ attached to the `targets/releases` role, you can use the
|
|||
> Note tags that were signed by the removed delegation will need to be resigned
|
||||
> by an active delegation
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker trust signer remove dtr.example.com/admin/demo
|
||||
Removing signer "ben" from dtr.example.com/admin/demo...
|
||||
Enter passphrase for repository key with ID b0014f8:
|
||||
|
@ -374,7 +351,7 @@ Successfully removed ben from dtr.example.com/admin/demo
|
|||
will need to add additional delegations using `docker trust signer add` before
|
||||
resigning images.
|
||||
|
||||
```
|
||||
```console
|
||||
WARN[0000] role targets/releases has fewer keys than its threshold of 1; it will not be usable until keys are added to it
|
||||
```
|
||||
|
||||
|
@ -382,13 +359,13 @@ WARN[0000] role targets/releases has fewer keys than its threshold of 1; it will
|
|||
message that there are no valid signatures in `targest/releases`, you will need
|
||||
to resign the `targets/releases` delegation file with the Notary CLI.
|
||||
|
||||
```
|
||||
```console
|
||||
WARN[0000] Error getting targets/releases: valid signatures did not meet threshold for targets/releases
|
||||
```
|
||||
|
||||
Resigning the delegation file is done with the `$ notary witness` command
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary witness dtr.example.com/admin/demo targets/releases --publish
|
||||
```
|
||||
|
||||
|
@ -405,7 +382,7 @@ and the role specific to that signer `targets/<name>`.
|
|||
|
||||
1) We will need to grab the Key ID from the Notary Server
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary delegation list dtr.example.com/admin/demo
|
||||
|
||||
ROLE PATHS KEY IDS THRESHOLD
|
||||
|
@ -418,8 +395,9 @@ targets/releases "" <all paths> 8fb597cbaf196f0781628b2f52bff6b3912e4e8075
|
|||
|
||||
2) Remove from the `targets/releases` delegation
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary delegation remove dtr.example.com/admin/demo targets/targets 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1 --publish
|
||||
|
||||
Auto-publishing changes to dtr.example.com/admin/demo
|
||||
Enter username: admin
|
||||
Enter password:
|
||||
|
@ -429,7 +407,7 @@ Successfully published changes for repository dtr.example.com/admin/demo
|
|||
|
||||
3) Remove from the `targets/<name>` delegation
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary delegation remove dtr.example.com/admin/demo targets/jeff 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1 --publish
|
||||
|
||||
Removal of delegation role targets/jeff with keys [5570b88df0736c468493247a07e235e35cf3641270c944d0e9e8899922fc6f99], to repository "dtr.example.com/admin/demo" staged for next publish.
|
||||
|
@ -443,7 +421,7 @@ Successfully published changes for repository dtr.example.com/admin/demo
|
|||
|
||||
4) Check the remaining delegation list
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary delegation list dtr.example.com/admin/demo
|
||||
|
||||
ROLE PATHS KEY IDS THRESHOLD
|
||||
|
@ -460,7 +438,7 @@ the `$ notary key remove` command.
|
|||
|
||||
1) We will need to get the Key ID from the local Docker Trust store
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary key list
|
||||
|
||||
ROLE GUN KEY ID LOCATION
|
||||
|
@ -473,7 +451,7 @@ targets ...example.com/admin/demo c819f2eda8fba2810ec6a7f95f051c90276c87fd
|
|||
|
||||
2) Remove the key from the local Docker Trust store
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary key remove 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1
|
||||
|
||||
Are you sure you want to remove 1091060d7bfd938dfa5be703fa057974f9322a4faef6f580334f3d6df44c02d1 (role jeff) from /home/ubuntu/.docker/trust/private? (yes/no) y
|
||||
|
@ -489,14 +467,16 @@ snapshot and all delegations keys using the Notary CLI.
|
|||
This is often required by a container registry before a particular repository
|
||||
can be deleted.
|
||||
|
||||
```
|
||||
```bash
|
||||
$ notary delete dtr.example.com/admin/demo --remote
|
||||
|
||||
Deleting trust data for repository dtr.example.com/admin/demo
|
||||
Enter username: admin
|
||||
Enter password:
|
||||
Successfully deleted local and remote trust data for repository dtr.example.com/admin/demo
|
||||
|
||||
$ docker trust inspect --pretty dtr.example.com/admin/demo
|
||||
|
||||
No signatures or cannot access dtr.example.com/admin/demo
|
||||
```
|
||||
|
||||
|
@ -506,4 +486,3 @@ No signatures or cannot access dtr.example.com/admin/demo
|
|||
* [Manage keys for content trust](trust_key_mng.md)
|
||||
* [Automation with content trust](trust_automation.md)
|
||||
* [Play in a content trust sandbox](trust_sandbox.md)
|
||||
* [Using Docker Content Trust with a Remote UCP Cluster](/ee/dtr/user/manage-images/sign-images/trust-with-remote-ucp.md)
|
||||
|
|
|
@ -31,7 +31,7 @@ workflow. They need to be
|
|||
|
||||
**Note**: Prior to Docker Engine 1.11, the snapshot key was also generated and stored
|
||||
locally client-side.
|
||||
Use the Notary CLI to [manage your snapshot key locally again](/notary/advanced_usage.md#rotate-keys)
|
||||
Use the Notary CLI to [manage your snapshot key locally again](../../../notary/advanced_usage.md#rotate-keys)
|
||||
for repositories created with newer versions of Docker.
|
||||
|
||||
## Choose a passphrase
|
||||
|
@ -64,7 +64,7 @@ Docker Content Trust can store and sign with root keys from a Yubikey 4. The
|
|||
Yubikey is prioritized over keys stored in the filesystem. When you initialize a
|
||||
new repository with content trust, Docker Engine looks for a root key locally. If a
|
||||
key is not found and the Yubikey 4 exists, Docker Engine creates a root key in the
|
||||
Yubikey 4. Consult the [Notary documentation](/notary/advanced_usage.md#use-a-yubikey)
|
||||
Yubikey 4. Consult the [Notary documentation](../../../notary/advanced_usage.md#use-a-yubikey)
|
||||
for more details.
|
||||
|
||||
Prior to Docker Engine 1.11, this feature was only in the experimental branch.
|
||||
|
|
|
@ -21,9 +21,9 @@ have privileges to run docker commands on your local machine or in the VM.
|
|||
|
||||
This sandbox requires you to install two Docker tools: Docker Engine >= 1.10.0
|
||||
and Docker Compose >= 1.6.0. To install the Docker Engine, choose from the
|
||||
[list of supported platforms](../../installation/index.md). To install
|
||||
[list of supported platforms](../../install/index.md). To install
|
||||
Docker Compose, see the
|
||||
[detailed instructions here](/compose/install/).
|
||||
[detailed instructions here](../../../compose/install.md).
|
||||
|
||||
## What is in the sandbox?
|
||||
|
||||
|
|
|
@ -11,13 +11,13 @@ for managing the swarm and storing the swarm state. It is important to
|
|||
understand some key features of manager nodes to properly deploy and
|
||||
maintain the swarm.
|
||||
|
||||
Refer to [How nodes work](/engine/swarm/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.
|
||||
|
||||
## Operate manager nodes in a swarm
|
||||
|
||||
Swarm manager nodes use the [Raft Consensus Algorithm](/engine/swarm/raft.md) to manage the
|
||||
Swarm manager nodes use the [Raft Consensus Algorithm](raft.md) to manage the
|
||||
swarm state. You only need to understand some general concepts of Raft in
|
||||
order to manage a swarm.
|
||||
|
||||
|
@ -54,7 +54,7 @@ troubleshooting steps if you do lose the quorum of managers.
|
|||
|
||||
When initiating a swarm, you must specify the `--advertise-addr` flag to
|
||||
advertise your address to other manager nodes in the swarm. For more
|
||||
information, see [Run Docker Engine in swarm mode](/engine/swarm/swarm-mode.md#configure-the-advertise-address). Because manager nodes are
|
||||
information, see [Run Docker Engine in swarm mode](swarm-mode.md#configure-the-advertise-address). Because manager nodes are
|
||||
meant to be a stable component of the infrastructure, you should use a *fixed
|
||||
IP address* for the advertise address to prevent the swarm from becoming
|
||||
unstable on machine reboot.
|
||||
|
@ -99,7 +99,7 @@ swarm becomes unavailable until you reboot the node or restart with
|
|||
`--force-new-cluster`.
|
||||
|
||||
You manage swarm membership with the `docker swarm` and `docker node`
|
||||
subsystems. Refer to [Add nodes to a swarm](/engine/swarm/join-nodes.md) for more information
|
||||
subsystems. Refer to [Add nodes to a swarm](join-nodes.md) for more information
|
||||
on how to add worker nodes and promote a worker node to be a manager.
|
||||
|
||||
### Distribute manager nodes
|
||||
|
@ -143,7 +143,7 @@ assigning tasks to the node.
|
|||
|
||||
## Add worker nodes for load balancing
|
||||
|
||||
[Add nodes to the swarm](/engine/swarm/join-nodes.md) to balance your swarm's
|
||||
[Add nodes to the swarm](join-nodes.md) to balance your swarm's
|
||||
load. Replicated service tasks are distributed across the swarm as evenly as
|
||||
possible over time, as long as the worker nodes are matched to the requirements
|
||||
of the services. When limiting a service to run on only specific types of nodes,
|
||||
|
@ -213,7 +213,7 @@ To cleanly re-join a manager node to a cluster:
|
|||
3. Re-join the node to the swarm with a fresh state using `docker swarm join`.
|
||||
|
||||
For more information on joining a manager node to a swarm, refer to
|
||||
[Join nodes to a swarm](/engine/swarm/join-nodes.md).
|
||||
[Join nodes to a swarm](join-nodes.md).
|
||||
|
||||
## Forcibly remove a node
|
||||
|
||||
|
@ -248,7 +248,7 @@ You can back up the swarm using any manager. Use the following procedure.
|
|||
1. If the swarm has auto-lock enabled, you need the unlock key
|
||||
to restore the swarm from backup. Retrieve the unlock key if necessary and
|
||||
store it in a safe location. If you are unsure, read
|
||||
[Lock your swarm to protect its encryption key](/engine/swarm/swarm_manager_locking.md).
|
||||
[Lock your swarm to protect its encryption key](swarm_manager_locking.md).
|
||||
|
||||
2. Stop Docker on the manager before backing up the data, so that no data is
|
||||
being changed during the backup. It is possible to take a backup while the
|
||||
|
@ -315,7 +315,7 @@ restore the data to a new swarm.
|
|||
`docker service ls` to be sure that all expected services are present.
|
||||
|
||||
7. If you use auto-lock,
|
||||
[rotate the unlock key](/engine/swarm/swarm_manager_locking.md#rotate-the-unlock-key).
|
||||
[rotate the unlock key](swarm_manager_locking.md#rotate-the-unlock-key).
|
||||
|
||||
8. Add manager and worker nodes to bring your new swarm up to operating
|
||||
capacity.
|
||||
|
@ -385,7 +385,7 @@ In Docker 1.13 and higher, you can use the `--force` or `-f` flag with the
|
|||
`docker service update` command to force the service to redistribute its tasks
|
||||
across the available worker nodes. This causes the service tasks to restart.
|
||||
Client applications may be disrupted. If you have configured it, your service
|
||||
uses a [rolling update](/engine/swarm/swarm-tutorial/rolling-update.md).
|
||||
uses a [rolling update](swarm-tutorial/rolling-update.md).
|
||||
|
||||
If you use an earlier version and you want to achieve an even balance of load
|
||||
across workers and don't mind disrupting running tasks, you can force your swarm
|
||||
|
@ -401,5 +401,5 @@ down to the original scale. You can use `docker service ps` to assess the curren
|
|||
balance of your service across nodes.
|
||||
|
||||
See also
|
||||
[`docker service scale`](/engine/reference/commandline/service_scale.md) and
|
||||
[`docker service ps`](/engine/reference/commandline/service_ps.md).
|
||||
[`docker service scale`](../reference/commandline/service_scale.md) and
|
||||
[`docker service ps`](../reference/commandline/service_ps.md).
|
||||
|
|
|
@ -112,10 +112,10 @@ those remaining after a `docker service update --config-rm`.
|
|||
Use these links to read about specific commands, or continue to the
|
||||
[example about using configs with a service](#advanced-example-use-configs-with-a-nginx-service).
|
||||
|
||||
- [`docker config create`](/engine/reference/commandline/config_create.md)
|
||||
- [`docker config inspect`](/engine/reference/commandline/config_inspect.md)
|
||||
- [`docker config ls`](/engine/reference/commandline/config_ls.md)
|
||||
- [`docker config rm`](/engine/reference/commandline/config_rm.md)
|
||||
- [`docker config create`](../reference/commandline/config_create.md)
|
||||
- [`docker config inspect`](../reference/commandline/config_inspect.md)
|
||||
- [`docker config ls`](../reference/commandline/config_ls.md)
|
||||
- [`docker config rm`](../reference/commandline/config_rm.md)
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -130,7 +130,7 @@ Docker configs.
|
|||
|
||||
The `docker stack` command supports defining configs in a Compose file.
|
||||
However, the `configs` key is not supported for `docker compose`. See
|
||||
[the Compose file reference](/compose/compose-file/index.md#configs) for details.
|
||||
[the Compose file reference](../../compose/compose-file/index.md#configs) for details.
|
||||
|
||||
### Simple example: Get started with configs
|
||||
|
||||
|
|
|
@ -17,8 +17,8 @@ There are two types of nodes: [**managers**](#manager-nodes) and
|
|||

|
||||
|
||||
If you haven't already, read through the
|
||||
[swarm mode overview](/engine/swarm/index.md) and
|
||||
[key concepts](/engine/swarm/key-concepts.md).
|
||||
[swarm mode overview](../index.md) and
|
||||
[key concepts](../key-concepts.md).
|
||||
|
||||
## Manager nodes
|
||||
|
||||
|
@ -26,7 +26,7 @@ Manager nodes handle cluster management tasks:
|
|||
|
||||
* maintaining cluster state
|
||||
* scheduling services
|
||||
* serving swarm mode [HTTP API endpoints](/engine/api/index.md)
|
||||
* serving swarm mode [HTTP API endpoints](../../api/index.md)
|
||||
|
||||
Using a [Raft](https://raft.github.io/raft.pdf) implementation, the managers
|
||||
maintain a consistent internal state of the entire swarm and all the services
|
||||
|
@ -66,17 +66,17 @@ gracefully stops tasks on nodes in `Drain` mode and schedules the tasks on an
|
|||
`Active` node. The scheduler does not assign new tasks to nodes with `Drain`
|
||||
availability.
|
||||
|
||||
Refer to the [`docker node update`](/engine/reference/commandline/node_update.md)
|
||||
Refer to the [`docker node update`](../../reference/commandline/node_update.md)
|
||||
command line reference to see how to change node availability.
|
||||
|
||||
## Change roles
|
||||
|
||||
You can promote a worker node to be a manager by running `docker node promote`.
|
||||
For example, you may want to promote a worker node when you
|
||||
take a manager node offline for maintenance. See [node promote](/engine/reference/commandline/node_promote.md).
|
||||
take a manager node offline for maintenance. See [node promote](../../reference/commandline/node_promote.md).
|
||||
|
||||
You can also demote a manager node to a worker node. See
|
||||
[node demote](/engine/reference/commandline/node_demote.md).
|
||||
[node demote](../../reference/commandline/node_demote.md).
|
||||
|
||||
|
||||
## Learn more
|
||||
|
|
|
@ -14,7 +14,7 @@ as a manager node. By default, the manager node generates a new root Certificate
|
|||
Authority (CA) along with a key pair, which are used to secure communications
|
||||
with other nodes that join the swarm. If you prefer, you can specify your own
|
||||
externally-generated root CA, using the `--external-ca` flag of the
|
||||
[docker swarm init](/engine/reference/commandline/swarm_init.md) command.
|
||||
[docker swarm init](../../reference/commandline/swarm_init.md) command.
|
||||
|
||||
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
|
||||
|
@ -55,7 +55,7 @@ By default, each node in the swarm renews its certificate every three months.
|
|||
You can configure this interval by running the `docker swarm update
|
||||
--cert-expiry <TIME PERIOD>` command. The minimum rotation value is 1 hour.
|
||||
Refer to the
|
||||
[docker swarm update](/engine/reference/commandline/swarm_update.md) CLI
|
||||
[docker swarm update](../../reference/commandline/swarm_update.md) CLI
|
||||
reference for details.
|
||||
|
||||
## Rotating the CA certificate
|
||||
|
|
|
@ -5,7 +5,7 @@ title: Swarm mode overview
|
|||
---
|
||||
|
||||
To use Docker in swarm mode, install Docker. See
|
||||
[installation instructions](/get-docker.md) for all operating systems and platforms.
|
||||
[installation instructions](../../get-docker.md) for all operating systems and platforms.
|
||||
|
||||
Current versions of Docker include *swarm mode* for natively managing a cluster
|
||||
of Docker Engines called a *swarm*. Use the Docker CLI to create a swarm, deploy
|
||||
|
|
|
@ -38,8 +38,8 @@ that only swarm managers can manage a swarm, while standalone containers can be
|
|||
started on any daemon. Docker daemons can participate in a swarm as managers,
|
||||
workers, or both.
|
||||
|
||||
In the same way that you can use [Docker Compose](/compose/index.md) to define and run
|
||||
containers, you can define and run [Swarm service](/engine/swarm/services.md) stacks.
|
||||
In the same way that you can use [Docker Compose](../../compose/index.md) to define and run
|
||||
containers, you can define and run [Swarm service](services.md) stacks.
|
||||
|
||||
Keep reading for details about concepts relating to Docker swarm services,
|
||||
including nodes, services, tasks, and load balancing.
|
||||
|
|
|
@ -132,7 +132,7 @@ node-1
|
|||
|
||||
The labels you set for nodes using docker node update apply only to the node
|
||||
entity within the swarm. Do not confuse them with the docker daemon labels for
|
||||
[dockerd](/config/labels-custom-metadata.md#daemon-labels).
|
||||
[dockerd](../../config/labels-custom-metadata.md#daemon-labels).
|
||||
|
||||
Therefore, node labels can be used to limit critical tasks to nodes that meet
|
||||
certain requirements. For example, schedule only on machines where special
|
||||
|
@ -237,5 +237,5 @@ $ docker node rm node-2
|
|||
## Learn more
|
||||
|
||||
* [Swarm administration guide](admin_guide.md)
|
||||
* [Docker Engine command line reference](/engine/reference/commandline/docker.md)
|
||||
* [Docker Engine command line reference](../reference/commandline/docker.md)
|
||||
* [Swarm mode tutorial](swarm-tutorial/index.md)
|
||||
|
|
|
@ -223,7 +223,7 @@ endpoint mode with an external load balancer, or use multiple smaller overlay ne
|
|||
|
||||
Management and control plane data related to a swarm is always encrypted.
|
||||
For more details about the encryption mechanisms, see the
|
||||
[Docker swarm mode overlay network security model](/network/overlay.md).
|
||||
[Docker swarm mode overlay network security model](../../network/overlay.md).
|
||||
|
||||
Application data among swarm nodes is not encrypted by default. To encrypt this
|
||||
traffic on a given overlay network, use the `--opt encrypted` flag on `docker
|
||||
|
@ -363,7 +363,7 @@ order to delete an existing bridge. The package name is `bridge-utils`.
|
|||
|
||||
4. Create or re-create the `docker_gwbridge` bridge with your custom settings.
|
||||
This example uses the subnet `10.11.0.0/16`. For a full list of customizable
|
||||
options, see [Bridge driver options](/engine/reference/commandline/network_create.md#bridge-driver-options).
|
||||
options, see [Bridge driver options](../reference/commandline/network_create.md#bridge-driver-options).
|
||||
|
||||
```bash
|
||||
$ docker network create \
|
||||
|
@ -415,6 +415,6 @@ $ docker swarm join \
|
|||
|
||||
* [Deploy services to a swarm](services.md)
|
||||
* [Swarm administration guide](admin_guide.md)
|
||||
* [Docker CLI reference](/engine/reference/commandline/docker.md)
|
||||
* [Docker CLI reference](../reference/commandline/docker.md)
|
||||
* [Swarm mode tutorial](swarm-tutorial/index.md)
|
||||
* [Docker networking reference architecture](https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Designing_Scalable%2C_Portable_Docker_Container_Networks){: target="_blank" class="_" }
|
||||
|
|
|
@ -123,12 +123,12 @@ the mount point of the secret within a given container.
|
|||
Use these links to read about specific commands, or continue to the
|
||||
[example about using secrets with a service](secrets.md#example-use-secrets-with-a-service).
|
||||
|
||||
- [`docker secret create`](/engine/reference/commandline/secret_create.md)
|
||||
- [`docker secret inspect`](/engine/reference/commandline/secret_inspect.md)
|
||||
- [`docker secret ls`](/engine/reference/commandline/secret_ls.md)
|
||||
- [`docker secret rm`](/engine/reference/commandline/secret_rm.md)
|
||||
- [`--secret`](/engine/reference/commandline/service_create.md#create-a-service-with-secrets) flag for `docker service create`
|
||||
- [`--secret-add` and `--secret-rm`](/engine/reference/commandline/service_update.md#adding-and-removing-secrets) flags for `docker service update`
|
||||
- [`docker secret create`](../reference/commandline/secret_create.md)
|
||||
- [`docker secret inspect`](../reference/commandline/secret_inspect.md)
|
||||
- [`docker secret ls`](../reference/commandline/secret_ls.md)
|
||||
- [`docker secret rm`](../reference/commandline/secret_rm.md)
|
||||
- [`--secret`](../reference/commandline/service_create.md#create-a-service-with-secrets) flag for `docker service create`
|
||||
- [`--secret-add` and `--secret-rm`](../reference/commandline/service_update.md#adding-and-removing-secrets) flags for `docker service update`
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -147,7 +147,7 @@ a similar way, see
|
|||
|
||||
Both the `docker-compose` and `docker stack` commands support defining secrets
|
||||
in a compose file. See
|
||||
[the Compose file reference](/compose/compose-file/index.md#secrets) for details.
|
||||
[the Compose file reference](../../compose/compose-file/index.md#secrets) for details.
|
||||
|
||||
### Simple example: Get started with secrets
|
||||
|
||||
|
@ -1039,5 +1039,5 @@ Each service uses environment variables to specify where the service should look
|
|||
for that secret data.
|
||||
|
||||
More information on short and long syntax for secrets can be found at
|
||||
[Compose file version 3 reference](/compose/compose-file/index.md#secrets).
|
||||
[Compose file version 3 reference](../../compose/compose-file/index.md#secrets).
|
||||
|
||||
|
|
|
@ -205,8 +205,8 @@ define a configuration at service creation, you can also update an existing
|
|||
service's configuration in a similar way.
|
||||
|
||||
See the command-line references for
|
||||
[`docker service create`](/engine/reference/commandline/service_create.md) and
|
||||
[`docker service update`](/engine/reference/commandline/service_update.md), or run
|
||||
[`docker service create`](../reference/commandline/service_create.md) and
|
||||
[`docker service update`](../reference/commandline/service_update.md), or run
|
||||
one of those commands with the `--help` flag.
|
||||
|
||||
### Configure the runtime environment
|
||||
|
@ -296,7 +296,7 @@ updated. This feature is particularly important if you do use often-changing tag
|
|||
such as `latest`, because it ensures that all service tasks use the same version
|
||||
of the image.
|
||||
|
||||
> **Note**: If [content trust](/engine/security/trust/content_trust.md) is
|
||||
> **Note**: If [content trust](../security/trust/content_trust.md) is
|
||||
> enabled, the client actually resolves the image's tag to a digest before
|
||||
> contacting the swarm manager, to verify that the image is signed.
|
||||
> Thus, if you use content trust, the swarm manager receives the request
|
||||
|
@ -422,7 +422,7 @@ The external host does not need to know the IP addresses or internally-used
|
|||
ports of the service tasks to interact with the service. When a user or process
|
||||
connects to a service, any worker node running a service task may respond. For
|
||||
more details about swarm service networking, see
|
||||
[Manage swarm service networks](/engine/swarm/networking.md).
|
||||
[Manage swarm service networks](networking.md).
|
||||
|
||||
##### Example: Run a three-task Nginx service on 10-node swarm
|
||||
|
||||
|
@ -544,7 +544,7 @@ $ docker service update --network-rm my-network my-web
|
|||
|
||||
For more information on overlay networking and service discovery, refer to
|
||||
[Attach services to an overlay network](networking.md) and
|
||||
[Docker swarm mode overlay network security model](/network/overlay.md).
|
||||
[Docker swarm mode overlay network security model](../../network/overlay.md).
|
||||
|
||||
### Grant a service access to secrets
|
||||
|
||||
|
@ -653,7 +653,7 @@ Service constraints let you set criteria for a node to meet before the scheduler
|
|||
deploys a service to the node. You can apply constraints to the
|
||||
service based upon node attributes and metadata or engine metadata. For more
|
||||
information on constraints, refer to the `docker service create`
|
||||
[CLI reference](/engine/reference/commandline/service_create.md).
|
||||
[CLI reference](../reference/commandline/service_create.md).
|
||||
|
||||
#### Reserve memory or CPUs for a service
|
||||
|
||||
|
@ -670,7 +670,7 @@ you may experience an Out Of Memory Exception (OOME) and a container, or the
|
|||
Docker daemon, might be killed by the kernel OOM killer. To prevent this from
|
||||
happening, ensure that your application runs on hosts with adequate memory and
|
||||
see
|
||||
[Understand the risks of running out of memory](/config/containers/resource_constraints.md#understand-the-risks-of-running-out-of-memory).
|
||||
[Understand the risks of running out of memory](../../config/containers/resource_constraints.md#understand-the-risks-of-running-out-of-memory).
|
||||
|
||||
Swarm services allow you to use resource constraints, placement preferences, and
|
||||
labels to ensure that your service is deployed to the appropriate swarm nodes.
|
||||
|
@ -716,7 +716,7 @@ and CPU/memory constraints. Be careful not to use settings that are not
|
|||
possible to fulfill.
|
||||
|
||||
For more information on constraints, refer to the `docker service create`
|
||||
[CLI reference](/engine/reference/commandline/service_create.md).
|
||||
[CLI reference](../reference/commandline/service_create.md).
|
||||
|
||||
#### Placement preferences
|
||||
|
||||
|
@ -937,7 +937,7 @@ $ docker service create \
|
|||
```
|
||||
|
||||
For more information on how to create data volumes and the use of volume
|
||||
drivers, see [Use volumes](/storage/volumes.md).
|
||||
drivers, see [Use volumes](../../storage/volumes.md).
|
||||
|
||||
|
||||
#### Bind mounts
|
||||
|
@ -1040,5 +1040,5 @@ $ docker inspect --format="{{.Config.Hostname}}" hosttempl.1.wo41w8hg8qanxwjwsg4
|
|||
## Learn More
|
||||
|
||||
* [Swarm administration guide](admin_guide.md)
|
||||
* [Docker Engine command line reference](/engine/reference/commandline/docker.md)
|
||||
* [Docker Engine command line reference](../reference/commandline/docker.md)
|
||||
* [Swarm mode tutorial](swarm-tutorial/index.md)
|
||||
|
|
|
@ -6,17 +6,17 @@ title: Deploy a stack to a swarm
|
|||
|
||||
When running Docker Engine in swarm mode, you can use `docker stack deploy` to
|
||||
deploy a complete application stack to the swarm. The `deploy` command accepts
|
||||
a stack description in the form of a [Compose file](/compose/compose-file/index.md).
|
||||
a stack description in the form of a [Compose file](../../compose/compose-file/index.md).
|
||||
|
||||
The `docker stack deploy` command supports any Compose file of version "3.0" or
|
||||
above. If you have an older version, see the [upgrade guide](/compose/compose-file/compose-versioning.md#upgrading).
|
||||
above. If you have an older version, see the [upgrade guide](../../compose/compose-file/compose-versioning.md#upgrading).
|
||||
|
||||
To run through this tutorial, you need:
|
||||
|
||||
1. A Docker Engine of version 1.13.0 or later, running in [swarm mode](/engine/swarm/swarm-mode.md).
|
||||
1. A Docker Engine of version 1.13.0 or later, running in [swarm mode](swarm-mode.md).
|
||||
If you're not familiar with swarm mode, you might want to read
|
||||
[Swarm mode key concepts](/engine/swarm/key-concepts.md)
|
||||
and [How services work](/engine/swarm/how-swarm-mode-works/services.md).
|
||||
[Swarm mode key concepts](key-concepts.md)
|
||||
and [How services work](how-swarm-mode-works/services.md).
|
||||
|
||||
> **Note**: If you're trying things out on a local development environment,
|
||||
> you can put your engine into swarm mode with `docker swarm init`.
|
||||
|
@ -25,7 +25,7 @@ To run through this tutorial, you need:
|
|||
> `docker stack` and `docker service` commands must be run from a manager
|
||||
> node.
|
||||
|
||||
2. [Docker Compose](/compose/install.md) version 1.10 or later.
|
||||
2. [Docker Compose](../../compose/install.md) version 1.10 or later.
|
||||
|
||||
|
||||
## Set up a Docker registry
|
||||
|
@ -64,7 +64,7 @@ a throwaway registry, which you can discard afterward.
|
|||
## Create the example application
|
||||
|
||||
The app used in this guide is based on the hit counter app in the
|
||||
[Get started with Docker Compose](/compose/gettingstarted.md) guide. It consists
|
||||
[Get started with Docker Compose](../../compose/gettingstarted.md) guide. It consists
|
||||
of a Python app which maintains a counter in a Redis instance and increments the
|
||||
counter whenever you visit it.
|
||||
|
||||
|
|
|
@ -82,19 +82,21 @@ Docker allocates subnet addresses from the address ranges specified by the `--de
|
|||
The subnet range comes from the `--default-addr-pool`, (such as `10.10.0.0/16`). The size of 16 there represents the number of networks one can create within that `default-addr-pool` range. The `--default-addr-pool` option may occur multiple times with each option providing additional addresses for docker to use for overlay subnets.
|
||||
|
||||
The format of the command is:
|
||||
```
|
||||
|
||||
```bash
|
||||
$ docker swarm init --default-addr-pool <IP range in CIDR> [--default-addr-pool <IP range in CIDR> --default-addr-pool-mask-length <CIDR value>]
|
||||
```
|
||||
|
||||
To create a default IP address pool with a /16 (class B) for the 10.20.0.0 network looks like this:
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker swarm init --default-addr-pool 10.20.0.0/16
|
||||
```
|
||||
|
||||
To create a default IP address pool with a `/16` (class B) for the `10.20.0.0` and `10.30.0.0` networks, and to
|
||||
create a subnet mask of `/26` for each network looks like this:
|
||||
|
||||
```
|
||||
```bash
|
||||
$ docker swarm init --default-addr-pool 10.20.0.0/16 --default-addr-pool 10.30.0.0/16 --default-addr-pool-mask-length 26
|
||||
```
|
||||
|
||||
|
@ -104,7 +106,6 @@ all the subnets are exhausted.
|
|||
|
||||
Refer to the following pages for more information:
|
||||
- [Swarm networking](./networking.md) for more information about the default address pool usage
|
||||
- [UCP Installation Planning](../../ee/ucp/admin/install/plan-installation.md) for more information about planning the network design before installation
|
||||
- `docker swarm init` [CLI reference](../reference/commandline/swarm_init.md) for more detail on the `--default-addr-pool` flag.
|
||||
|
||||
### Configure the advertise address
|
||||
|
|
|
@ -27,7 +27,7 @@ machines.
|
|||
> 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 Desktop or Mac or Docker Desktop for Windows](/engine/swarm/swarm-tutorial/index.md#use-docker-desktop-for-mac-or-docker-desktop-for-windows)
|
||||
> [Use Docker Desktop or Mac or Docker Desktop for Windows](index.md#use-docker-desktop-for-mac-or-docker-desktop-for-windows)
|
||||
> with Swarm.
|
||||
|
||||
In the tutorial, the following command creates a swarm on the `manager1`
|
||||
|
|
|
@ -131,4 +131,4 @@ drained node to an active state:
|
|||
|
||||
## What's next?
|
||||
|
||||
Learn how to [use a swarm mode routing mesh](/engine/swarm/ingress.md).
|
||||
Learn how to [use a swarm mode routing mesh](../ingress.md).
|
||||
|
|
|
@ -26,7 +26,7 @@ If you are brand new to Docker, see [About Docker Engine](../../index.md).
|
|||
To run this tutorial, you need the following:
|
||||
|
||||
* [three Linux hosts which can communicate over a network, with Docker installed](#three-networked-host-machines)
|
||||
* [Docker Engine 1.12 or later installed](#docker-engine-1-12-or-newer)
|
||||
* [Docker Engine 1.12 or later installed](#docker-engine-112-or-newer)
|
||||
* [the IP address of the manager machine](#the-ip-address-of-the-manager-machine)
|
||||
* [open ports between the hosts](#open-protocols-and-ports-between-the-hosts)
|
||||
|
||||
|
@ -36,7 +36,7 @@ This tutorial requires three Linux hosts which have Docker installed and can
|
|||
communicate over a network. These can be physical machines, virtual machines,
|
||||
Amazon EC2 instances, or hosted in some other way. You can even use Docker Machine
|
||||
from a Linux, Mac, or Windows host. Check out
|
||||
[Getting started - Swarms](/get-started/part4.md#prerequisites)
|
||||
[Getting started - Swarms](../../../get-started/swarm-deploy.md#prerequisites)
|
||||
for one possible set-up for the hosts.
|
||||
|
||||
One of these machines is a manager (called `manager1`) and two of them are
|
||||
|
@ -61,14 +61,14 @@ follows:
|
|||
#### Install Docker Engine on Linux machines
|
||||
|
||||
If you are using Linux based physical computers or cloud-provided computers as
|
||||
hosts, simply follow the [Linux install instructions](/engine/install/index.md)
|
||||
hosts, simply follow the [Linux install instructions](../../install/index.md)
|
||||
for your platform. Spin up the three machines, and you are ready. You can test both
|
||||
single-node and multi-node swarm scenarios on Linux machines.
|
||||
|
||||
#### Use Docker Desktop for Mac or Docker Desktop for Windows
|
||||
|
||||
Alternatively, install the latest [Docker Desktop for Mac](/docker-for-mac/index.md) or
|
||||
[Docker Desktop for Windows](/docker-for-windows/index.md) application on one
|
||||
Alternatively, install the latest [Docker Desktop for Mac](../../../docker-for-mac/index.md) or
|
||||
[Docker Desktop for Windows](../../../docker-for-windows/index.md) application on one
|
||||
computer. You can test both single-node and multi-node swarm from this computer,
|
||||
but you need to use Docker Machine to test the multi-node scenarios.
|
||||
|
||||
|
@ -81,8 +81,8 @@ serve as the single swarm node.
|
|||
|
||||
* Currently, you cannot use Docker Desktop for Mac or Docker Desktop for Windows alone to test a
|
||||
_multi-node_ swarm. However, you can use the included version of
|
||||
[Docker Machine](/machine/overview.md) to create the swarm nodes (see
|
||||
[Get started with Docker Machine and a local VM](/machine/get-started.md)), then
|
||||
[Docker Machine](../../../machine/overview.md) to create the swarm nodes (see
|
||||
[Get started with Docker Machine and a local VM](../../../machine/get-started.md)), then
|
||||
follow the tutorial for all multi-node features. For this scenario, you run
|
||||
commands from a Docker Desktop for Mac or Docker Desktop for Windows host, but that Docker host itself is
|
||||
_not_ participating in the swarm. After you create the nodes, you can run all
|
||||
|
|
|
@ -8,7 +8,7 @@ title: Engine tutorials
|
|||
|
||||
# Learn by example
|
||||
|
||||
* [Network containers](/engine/tutorials/networkingcontainers.md)
|
||||
* [Manage data in containers](/engine/tutorials/dockervolumes.md)
|
||||
* [Samples](/samples/)
|
||||
* [Get Started](/get-started/)
|
||||
* [Network containers](networkingcontainers.md)
|
||||
* [Manage data in containers](../../storage/volumes.md)
|
||||
* [Samples](../../samples/index.md)
|
||||
* [Get Started](../../get-started/index.md)
|
||||
|
|
|
@ -211,4 +211,4 @@ The `ping` shows it is contacting a different IP address, the address on the `my
|
|||
|
||||
## Next steps
|
||||
|
||||
Now that you know how to network containers, see [how to manage data in containers](dockervolumes.md).
|
||||
Now that you know how to network containers, see [how to manage data in containers](../../storage/volumes.md).
|
||||
|
|
Loading…
Reference in New Issue