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

Merge pull request #1850 from vikstrous/docs_stuff 

docs stuff; fix #1833; fix #1691; fix #1692; fix #1690; fix #1693; fi…
This commit is contained in:
Viktor Stanchev 2016-04-28 14:27:01 -07:00
parent ebe8b01d26 d80f914a42
commit 81bd90aae0
7 changed files with 76 additions and 95 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
high-availability/backups-and-disaster-recovery.md
View File

@ -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

6
install/install-dtr-offline.md
View File

@ -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

9
install/install-dtr.md
View File

@ -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

2
install/system-requirements.md
View File

@ -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

17
install/uninstall.md
View File

@ -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

23
install/upgrade/upgrade-major.md
View File

@ -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

96
monitor-troubleshoot/troubleshoot.md
View File

@ -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
```