mirror of https://github.com/docker/docs.git
This commit is contained in:
Viktor Stanchev
parent
95229513b3
commit
d80f914a42
|
|
@ -71,16 +71,16 @@ $ curl https://$UCP_HOST/ca > ucp-ca.pem
|
|||
$ docker run -it --rm docker/dtr backup \
|
||||
--ucp-ca "$(cat ucp-ca.pem)" \
|
||||
--replica-id 8b6174866010 \
|
||||
--username $UCP_ADMIN --password $UCP_PASSWORD \
|
||||
--host $UCP_HOST > /tmp/backup.tar
|
||||
--ucp-username $UCP_ADMIN --ucp-password $UCP_PASSWORD \
|
||||
--ucp-url $UCP_HOST > /tmp/backup.tar
|
||||
```
|
||||
|
||||
Where:
|
||||
|
||||
* --ucp-ca is the certificate used by UCP,
|
||||
* --replica-id is the name of the replica to backup,
|
||||
* --username, and --password are the credentials of a UCP administrator,
|
||||
* --host is the address of UCP.
|
||||
* --ucp-username, and --ucp-password are the credentials of a UCP administrator,
|
||||
* --ucp-url is the address of UCP.
|
||||
|
||||
## Restore DTR data
|
||||
|
||||
|
|
@ -118,16 +118,16 @@ $ docker run -i --rm \
|
|||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
docker/dtr restore \
|
||||
--ucp-ca "$(cat ucp-ca.pem)" \
|
||||
--username $UCP_ADMIN --password $UCP_PASSWORD \
|
||||
--host $UCP_HOST --dtr-host 192.168.10.100 < /tmp/backup.tar
|
||||
--ucp-username $UCP_ADMIN --ucp-password $UCP_PASSWORD \
|
||||
--ucp-url $UCP_HOST --dtr-load-balancer 192.168.10.100 < /tmp/backup.tar
|
||||
```
|
||||
|
||||
Where:
|
||||
|
||||
* --ucp-ca is the certificate used by UCP,
|
||||
* --username, and --password are the credentials of a UCP administrator,
|
||||
* --host is the address of UCP,
|
||||
* --dtr-host is the host to where DTR will be installed.
|
||||
* --ucp-username, and --ucp-password are the credentials of a UCP administrator,
|
||||
* --ucp-url is the address of UCP,
|
||||
* --dtr-load-balancer is the host to where DTR will be installed.
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ whether that node has access to the internet or not.
|
|||
The only difference when installing DTR on an offline node, is that instead
|
||||
of pulling the DTR images from Docker Hub, you use a computer that is connected
|
||||
to the internet to download a single package with all DTR images. Then you
|
||||
copy that package to the node where you’ll install DTR.
|
||||
copy that package to the nodes where you’ll install DTR.
|
||||
|
||||
1. Get the DTR package.
|
||||
|
||||
|
|
@ -51,7 +51,9 @@ copy that package to the node where you’ll install DTR.
|
|||
4. Install DTR.
|
||||
|
||||
Now that the offline node has all the images needed to install UCP,
|
||||
you can [install DTR that machine](install-dtr.md).
|
||||
you can [install DTR that machine](install-dtr.md). Make sure to
|
||||
also copy the images to any other nodes you want to install DTR
|
||||
replicas onto.
|
||||
|
||||
|
||||
## Where to go next
|
||||
|
|
|
|||
|
|
@ -37,12 +37,7 @@ $ docker run --rm -it docker/dtr --help
|
|||
|
||||
To install DTR:
|
||||
|
||||
1. Make your Docker CLI client point to UCP.
|
||||
|
||||
Download a client certificate bundle from UCP, and use it to configure
|
||||
your Docker CLI client to run the docker commands on the UCP cluster.
|
||||
|
||||
2. Run the following command to install DTR:
|
||||
1. Run the following command on any Docker daemon to install DTR:
|
||||
|
||||
```bash
|
||||
$ docker run -it --rm \
|
||||
|
|
@ -53,7 +48,7 @@ To install DTR:
|
|||
prompts for the necessary configuration values.
|
||||
You can also use flags to pass values to the install command.
|
||||
|
||||
3. Check that DTR is running.
|
||||
2. Check that DTR is running.
|
||||
|
||||
In your browser, navigate to the the Docker **Universal Control Plane**
|
||||
web UI, and navigate to the **Applications** screen. DTR should be listed
|
||||
|
|
|
|||
|
|
@ -38,6 +38,8 @@ node:
|
|||
| in | 443 | Web app and API client access to DTR. |
|
||||
| out | 443 | Check if new versions are available, and send anonymous usage reports to Docker. |
|
||||
|
||||
The inbound ports are configurable.
|
||||
|
||||
DTR collects anonymous usage metrics, to help us improve it. These metrics
|
||||
are entirely anonymous, don’t identify your company, users, applications,
|
||||
or any other sensitive information. You can disable this on the DTR settings
|
||||
|
|
|
|||
|
|
@ -24,9 +24,14 @@ To see what options are available in the uninstall command, check the
|
|||
[uninstall command reference](../reference/remove.md), or run:
|
||||
|
||||
```bash
|
||||
$ docker run --rm -it docker/dtr uninstall --help
|
||||
$ docker run --rm -it docker/dtr remove --help
|
||||
```
|
||||
|
||||
To remove a replica safely, you must tell the bootstrapper about one healthy replica
|
||||
using the `--exsting-replica-id` flag and the replica to remove with the
|
||||
`--replica-id` flag. It uses the healthy replica to safely inform your DTR cluster
|
||||
that the replica is about to be removed before it performs the actual removal.
|
||||
|
||||
## Example
|
||||
|
||||
The following example illustrates how use the remove command interactively to
|
||||
|
|
@ -40,15 +45,15 @@ $ docker run --rm -it docker/dtr remove --ucp-ca "$(cat ucp-ca.pem)"
|
|||
|
||||
existing-replica-id (ID of an existing replica in a cluster): 7ae3cb044b70
|
||||
replica-id (Specify the replica Id. Must be unique per replica, leave blank for random): a701a510126c
|
||||
username (Specify the UCP admin username): $UCP_ADMIN
|
||||
password: $UCP_PASSWORD
|
||||
host (Specify the UCP host using the host[:port] format): $UCP_HOST
|
||||
ucp-username (Specify the UCP admin username): $UCP_ADMIN
|
||||
ucp-password: $UCP_PASSWORD
|
||||
ucp-url (Specify the UCP host using the host[:port] format): $UCP_HOST
|
||||
```
|
||||
|
||||
Where:
|
||||
* existing-replica-id: is the id of any DTR replica of that cluster,
|
||||
* existing-replica-id: is the id of any healthy DTR replica of that cluster,
|
||||
* replica-id: is the id of the DTR replica you want to remove,
|
||||
* username and password: are the username and password of a UCP administrator.
|
||||
* ucp-username and ucp-password: are the username and password of a UCP administrator.
|
||||
|
||||
|
||||
Now you can confirm on Docker Universal Control Plane that the DTR replica
|
||||
|
|
|
|||
|
|
@ -60,20 +60,14 @@ To start the migration, on the host running DTR 1.4.3, run:
|
|||
# Get the certificates used by UCP
|
||||
$ curl https://$UCP_HOST/ca > ucpca.crt
|
||||
|
||||
# Get the certificates used by DTR 2.0
|
||||
$ docker run -it --rm \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
docker/dtr dump-certs \
|
||||
--host $UCP_HOST --ucp-ca "$(cat ucpca.crt)" \
|
||||
--pod-id $DTR_POD_ID > dtrca.crt
|
||||
# Get the certificates used by DTR 2.0 from the settings page
|
||||
|
||||
# Migrate configurations, accounts, and repository metadata
|
||||
docker run -it --rm \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
docker/dtr migrate \
|
||||
--host $UCP_HOST --ucp-ca "$(cat ucpca.crt)" \
|
||||
--dtr-host https://$DTR_HOST --dtr-ca "$(cat dtrca.crt)" \
|
||||
--pod-id $DTR_POD_ID
|
||||
--ucp-url $UCP_HOST --ucp-ca "$(cat ucpca.crt)" \
|
||||
--dtr-load-balancer https://$DTR_HOST --dtr-ca "$(cat dtrca.crt)"
|
||||
```
|
||||
|
||||
## Step 3. Test your installation
|
||||
|
|
@ -83,17 +77,20 @@ properly configured.
|
|||
In your browser navigate to the DTR **Settings page**, and check that DTR 2.0:
|
||||
|
||||
* Is correctly licensed,
|
||||
* Has the correct domain name configured,
|
||||
* The storage backend is correctly configured,
|
||||
* User authentication is correctly configured.
|
||||
|
||||
You need to manually transfer the following settings:
|
||||
* Domain name
|
||||
* Certificates
|
||||
|
||||
You should also validate that you can now push and pull images to DTR 2.0.
|
||||
|
||||
## Step 4. Decommission DTR 1.4.3
|
||||
|
||||
Once you've fully tested your new installation, you can uninstall DTR 1.4.3.
|
||||
|
||||
<!-- TODO: include instructions on how to uninstall -->
|
||||
Once you've fully tested your new installation, you can uninstall DTR 1.4.3
|
||||
by deleting `/usr/local/etc/dtr` and `/var/local/dtr` and removing all dtr
|
||||
containers.
|
||||
|
||||
## Where to go next
|
||||
|
||||
|
|
|
|||
|
|
@ -12,81 +12,61 @@ weight=10
|
|||
|
||||
# Troubleshoot DTR
|
||||
|
||||
## Overlay networking
|
||||
|
||||
## Emergency access to the Trusted Registry
|
||||
|
||||
If your authenticated or public access to the Trusted Registry UI has stopped
|
||||
working, but your Trusted Registry admin container is still running, you can add
|
||||
an
|
||||
[ambassador container](https://docs.docker.com/articles/ambassador_pattern_linking/)
|
||||
to get temporary unsecure access to it.
|
||||
|
||||
For Trusted Registry version 1.4.3, run the following command in a Trusted Registry CLI:
|
||||
High availability in DTR depends on having overlay networking working in UCP.
|
||||
To manually test that overlay networking is working in UCP run the following
|
||||
commands on two different UCP machines.
|
||||
|
||||
```
|
||||
docker run --rm -it --net dtr -p 9999:80 svendowideit/ambassador dockertrustedregistry_admin_server_1 80
|
||||
```
|
||||
However, if you are running a version prior to it, 1.4.2 or earlier, then continue to run this command:
|
||||
|
||||
```
|
||||
$ docker run --rm -it --link docker_trusted_registry_admin_server:admin -p 9999:80 svendowideit/ambassador
|
||||
docker run -it --rm --net dtr-ol --name overlay-test1 --entrypoint sh docker/dtr
|
||||
docker run -it --rm --net dtr-ol --name overlay-test2 --entrypoint ping docker/dtr -c 3 overlay-test1
|
||||
```
|
||||
|
||||
Either command gives you access on port `9999` on your Trusted Registry server
|
||||
`http://<dtr-host-ip>:9999`. This guide assumes that you are a member of the `docker` group, or you have root privileges. Otherwise, you may need to add `sudo` to the previous example command.
|
||||
You can create new new overlay network for this test with `docker network create -d overaly network-name`.
|
||||
You can also use any images that contain `sh` and `ping` for this test.
|
||||
|
||||
### SSH access to host
|
||||
If the second command succeeds, overlay networking is working.
|
||||
|
||||
As an extra measure of safety, ensure you have SSH access to the Trusted
|
||||
Registry host before you start using it.
|
||||
## DTR doesn't come up after a Docker restart
|
||||
|
||||
If you are hosting Trusted Registry on an EC2 host launched from the AWS
|
||||
Marketplace AMI, note that the user is `ec2-user`:
|
||||
`/path/to/private_key/id_rsa ec2-user@<dtr-dns-entry>`.
|
||||
This is a known issue with Docker restart policies when DTR is running on the same
|
||||
machine as a UCP controller. If this happens, you can simply restart the DTR replica
|
||||
from the UCP UI under "Applications". The best workaround right now is to not run
|
||||
DTR on the same node as a UCP controller.
|
||||
|
||||
## Etcd refuses to start after a Docker restart
|
||||
|
||||
## Client Docker Daemon diagnostics
|
||||
|
||||
To debug client Docker daemon communication issues with the Trusted Registry,
|
||||
Docker also provides a diagnostics tool to be run on the client Docker daemon.
|
||||
|
||||
> **Warning:** These diagnostics files may contain secrets that you need to remove before passing on, such as raw container log files, Azure storage credentials, or passwords that may be sent to non-Docker Trusted Registry containers using the `docker run -e PASSWORD=asdf` environment variable options.
|
||||
|
||||
If you supply an administrator username and password, then the `diagnostics`
|
||||
tool also downloads additional logs and configuration data from the remote
|
||||
Trusted Registry server. Download and run this tool using the following command:
|
||||
If you see the following log message in etcd's logs after a DTR restart it means that
|
||||
your DTR replicas are on machines that don't have their clocks synchronized. Etcd requires
|
||||
synchronized clocks to function correctly.
|
||||
|
||||
```
|
||||
$ wget https://dhe.mycompany.com/admin/bin/diagnostics && chmod +x diagnostics
|
||||
$ sudo ./diagnostics dhe.mycompany.com > enduserDiagnostics.zip DTR
|
||||
administrator password (provide empty string if there is no admin server
|
||||
authentication):
|
||||
WARN [1.1.0-alpha-001472_g8a9ddb4] Encountered errors running diagnostics
|
||||
errors=[Failed to copy DTR Adminserver's exported settings into ZIP output:
|
||||
"Failed to read next tar header: \"archive/tar: invalid tar header\"" Failed to
|
||||
copy logs from DTR Adminserver into ZIP output: "Failed to read next tar header:
|
||||
\"archive/tar: invalid tar header\"" error running "sestatus": "exit status 127"
|
||||
error running "dmidecode": "exit status 127"]
|
||||
2016-04-27 17:56:34.086748 W | rafthttp: the clock difference against peer aa4fdaf4c562342d is too high [8.484795885s > 1s]
|
||||
```
|
||||
|
||||
The zip file contains the following information:
|
||||
## Accessing the RethinkDB Admin UI
|
||||
|
||||
- your local Docker host's `ca-certificates.crt`
|
||||
- `containers/`: the first 20 running, stopped and paused containers `docker inspect`
|
||||
information and log files.
|
||||
- `dockerEngine/`: the local Docker daemon's `info` and `version` output
|
||||
- `dockerState/`: the local Docker daemon's container states, image states, log file, and daemon configuration file
|
||||
- `dtr/`: Remote Docker Trusted Registry services information. This directory will only be populated if the user enters a Docker Trusted Registry "admin" username and password.
|
||||
- - `dtr/logs/`: the remote Docker Trusted Registry container log files. This directory will only be populated if the user enters a Docker Trusted Registry "admin" username and password.
|
||||
- - `dtr/exportedSettings/`: the Docker Trusted Registry manager container's log files and a backup of the `/usr/local/etc/dtr` Docker Trusted Registry configuration directory. See the [export settings section](#export-settings) for more details.
|
||||
- `sysinfo/`: local Host information
|
||||
- `errors.txt`: errors and warnings encountered while running diagnostics
|
||||
> Warning: This command will expose your database to the internet with no authentication. Use with caution.
|
||||
|
||||
### Starting and stopping the Trusted Registry
|
||||
Run this on the UCP node that has a DTR replica with the given replica id:
|
||||
|
||||
If you need to stop and/or start the Trusted Registry (for example, upgrading, or troubleshooting), use the following commands:
|
||||
```
|
||||
docker run --rm -it --net dtr-br -p 9999:8080 svendowideit/ambassador dtr-rethinkdb-$REPLICA_ID 8080
|
||||
```
|
||||
|
||||
`sudo bash -c "$(docker run docker/trusted-registry stop)"`
|
||||
Options to make this more secure:
|
||||
|
||||
* Use `-p 127.0.0.1:9999:8080` to expose the admin UI only to localhost
|
||||
* Use an SSH tunnel in combination with exposing the port only to localhost
|
||||
* Use a firewall to limit which IPs are allowed to connect
|
||||
* Use a second proxy with TLS and basic auth to provide secure access over the Internet
|
||||
|
||||
`sudo bash -c "$(docker run docker/trusted-registry start)"`
|
||||
## Accessing etcd directly
|
||||
|
||||
You can execute etcd commands on a UCP node hosting a DTR replica using etcdctl
|
||||
via the following docker command:
|
||||
|
||||
```
|
||||
docker run --rm -v dtr-ca-$REPLICA_ID:/ca --net dtr-br -it --entrypoint /etcdctl docker/dtr-etcd:v2.2.4 --endpoint https://dtr-etcd-$REPLICA_ID.dtr-br:2379 --ca-file /ca/etcd/cert.pem --key-file /ca/etcd-client/key.pem --cert-file /ca/etcd-client/cert.pem
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue