Remove enterprise content

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2020-04-20 13:42:27 +02:00
parent 59c3d309ca
commit 4977dd2961
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
3276 changed files with 0 additions and 504962 deletions

View File

@ -1,81 +0,0 @@
---
description: Learn about the architecture of Docker Trusted Registry.
keywords: docker, registry, dtr, architecture
redirect_from:
- /docker-trusted-registry/architecture/
title: DTR architecture
---
Docker Trusted Registry (DTR) is a Dockerized application that runs on a Docker
Universal Control Plane cluster.
![](images/architecture-1.png)
## Containers
When you install DTR on a node, the following containers are started:
| Name | Description |
|:---------------------------------|:----------------------------------------------------------------------------------------------------------------------------------|
| dtr-nginx-&lt;replica_id&gt; | Receives http and https requests and proxies them to other DTR components. By default it listens to ports 80 and 443 of the host. |
| dtr-api-&lt;replica_id&gt; | Executes the DTR business logic. It serves the DTR web application, and API. |
| dtr-registry-&lt;replica_id&gt; | Implements the functionality for pulling and pushing Docker images. It also handles how images are stored. |
| dtr-etcd-&lt;replica_id&gt; | A key-value store for persisting DTR configuration settings. Don't use it in your applications, since it's for internal use only. |
| dtr-rethinkdb-&lt;replica_id&gt; | A database for persisting repository metadata. Don't use it in your applications, since it's for internal use only. |
## Networks
To allow containers to communicate, when installing DTR the following networks
are created:
| Name | Type | Description |
|:-------|:--------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| dtr-br | bridge | Allows containers on the same node to communicate with each other in a secure way. |
| dtr-ol | overlay | Allows containers running on different nodes to communicate. This network is used in high-availability installations, to allow Etcd and RethinkDB containers to replicate their data. |
The communication between all DTR components is secured using TLS. Also, when
installing DTR, two Certificate Authorities (CAs) are created. These CAs are
used to create the certificates used by Etcd and RethinkDB when communicating
across nodes.
## Volumes
DTR uses these named volumes for persisting data:
| Volume name | Location on host (/var/lib/docker/volumes/) | Description |
|:--------------------------------|:--------------------------------------------|:-------------------------------------------------------------------------------------------------------------|
| dtr-ca-&lt;replica_id&gt; | dtr-ca/_data | The volume where the private keys and certificates are stored so that containers can use TLS to communicate. |
| dtr-etcd-&lt;replica_id&gt; | dtr-etcd/_data | The volume used by etcd to persist DTR configurations. |
| dtr-registry-&lt;replica_id&gt; | dtr-registry/_data | The volume where images are stored, if DTR is configured to store images on the local filesystem. |
| dtr-rethink-&lt;replica_id&gt; | dtr-rethink/_data | The volume used by RethinkDB to persist DTR data, like users and repositories. |
If you dont create these volumes, when installing DTR they are created with
the default volume driver and flags.
## Image storage
By default, Docker Trusted Registry stores images on the filesystem of the host
where it is running.
You can also configure DTR to using these cloud storage backends:
* Amazon S3
* OpenStack Swift
* Microsoft Azure
For highly available installations, configure DTR to use a cloud storage
backend or a network filesystem like NFS.
## High-availability support
For load balancing and high-availability, you can install multiple replicas of
DTR, and join them to create a cluster.
[Learn more about high availability](high-availability/index.md).
## Where to go next
* [System requirements](install/system-requirements.md)
* [Install DTR](install/index.md)

Binary file not shown.

Before

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

View File

@ -1,50 +0,0 @@
---
description: Configure general settings for Docker Trusted Registry
keywords: docker, documentation, about, technology, understanding, enterprise, hub, general, domain name, HTTP, HTTPS ports, Notary, registry
redirect_from:
- /docker-trusted-registry/configure/config-general/
title: Configure general settings
---
This document describes the general settings you need to configure including
using Trusted Content through setting up your Notary server.
## Configure your domain name and port settings
Each setting on this page is explained in the Docker Trusted Registry UI.
* *Domain Name*: **required**. By default it is an empty string. It is the fully qualified domain name assigned to the Docker Trusted Registry host.
* *HTTP Port*: defaults to 80 and is used as the entry point for the image storage service. To see load balancer status, you can query
http://&lt;dtr-host&gt;/load_balancer_status.
* *HTTPS Port*: defaults to 443, used as the secure entry point for the image storage service.
* *HTTP proxy*: defaults to an empty string, proxy server for HTTP requests.
* *HTTPS proxy*: defaults to an empty string, proxy server for HTTPS requests.
* *No proxy*: defaults to an empty string, proxy bypass for HTTP and HTTPS requests.
* *Upgrade checking*: enables or disables automatic checking for the Trusted Registry software updates.
If you need the Trusted Registry to re-generate a self-signed certificate at
some point, you can change the domain name. Whenever the domain name does not
match the current certificate, a new self-signed certificate is generated
for the new domain. This also works with IP addresses.
## Docker Content Trust
The Trusted Registry's includes integration with of Notary to provide
Content Trust functionality, allowing your organization to push and pull
trusted images. After pushing images in the Trusted Registry, you can see
which image tags were signed by viewing the appropriate repositories through
Trusted Registry's web interface.
To configure your Docker client to push signed images to Docker
Trusted Registry refer to the CLI Reference's
[Environment Variables Section](/engine/reference/commandline/cli.md#environment-variables)
and [Notary Section](/engine/reference/commandline/cli.md#notary).
This requires you to set the `DOCKER_CONTENT_TRUST` variable and configure
your system to trust Docker Trusted Registry's TLS certificate if it doesn't
already.
## See also
* [Configure storage settings](config-storage.md)

View File

@ -1,209 +0,0 @@
---
description: Security configuration for Docker Trusted Registry
keywords: docker, documentation, about, technology, understanding, configuration, security, enterprise, hub, registry
redirect_from:
- /docker-trusted-registry/configure/config-security/
title: Security configuration
---
This document describes the security settings you need to configure.
* *SSL Certificate*: Used to enter the hash (string) from the SSL Certificate.
This cert must be accompanied by its private key, entered below.
* *SSL Private Key*: The hash from the private key associated with the provided
SSL Certificate (as a standard x509 key pair).
The Trusted Registry requires encrypted communications through
HTTPS/SSL between (a) the Trusted Registry and your Docker Engine(s), and (b)
between your web browser and the Trusted Registry admin server. There are a few
options for setting this up:
1. You can use the self-signed certificate Docker Trusted Registry generates by default.
2. You can generate your own certificates using a public service or your enterprise's infrastructure. See the [Generating SSL certificates](config-security.md#generating-ssl-certificates) section for the options available.
If you are generating your own certificates, you can install them by following
the instructions for [Adding your own registry certificates to Docker Trusted Registry](config-security.md#adding-your-own-registry-certificates-to-dtr).
However, if you choose to use the Trusted Registry-generated certificates, or
the certificates you generate yourself are not trusted by your client Docker
hosts, you will need to do one of the following:
* [Install](config-security.md#installing-registry-certificates-on-client-docker-daemons) a registry certificate on all of your client Docker daemons, or
* Set your [client Docker daemons](config-security.md#if-you-can-t-install-the-certificates) to run with an unconfirmed connection to the registry.
### Generate SSL certificates
There are three basic approaches to generating certificates:
1. Most enterprises will have private key infrastructure (PKI) in place to
generate keys. Consult with your security team or whomever manages your private
key infrastructure. If you have this resource available, Docker recommends you
use it.
2. If your enterprise can't provide keys, you can use a public Certificate
Authority (CA) like "InstantSSL.com" or "RapidSSL.com" to generate a
certificate. If your certificates are generated using a globally trusted
Certificate Authority, you don't need to install them on all of your
client Docker daemons.
3. Use the self-signed registry certificate generated by Docker Trusted
Registry, and install it onto the client Docker daemon hosts as seen in the
following section.
### Add your own registry certificates
Whichever method you use to generate certificates, once you have them you can
set up your Trusted Registry server to use them.
1. Navigate to Settings > Security, and put the SSL Certificate text
(including all intermediate Certificates, starting with the host) into the "SSL
Certificate" edit box, and the previously generated Private key into the "SSL
Private Key" edit box.
2. Click Save, and then wait for the Trusted Registry Admin site to restart and
reload. It should now be using the new certificate. Once the Security page has
reloaded, it displays `#` hashes instead of the certificate text you pasted.
If your certificate is signed by a chain of Certificate Authorities that are
already trusted by your Docker daemon servers, you can skip the following
"Install registry certificates" step.
### Install registry certificates on client Docker daemons
If your certificates do not have a trusted Certificate Authority, you will need
to install them on each client Docker daemon host.
The procedure for installing the Trusted Registry certificates on each
Linux distribution has slightly different steps.
You can test this certificate using `curl`:
```
$ curl https://dtr.yourdomain.com/v2/
curl: (60) SSL certificate problem: self signed certificate
```
For details see: http://curl.haxx.se/docs/sslcerts.html
Curl performs SSL certificate verification by default, using a "bundle" of
Certificate Authority (CA) public keys (CA certs). If the default bundle file
isn't adequate, you can specify an alternate file using the `--cacert` option.
If this HTTPS server uses a certificate signed by a CA represented in the
bundle, the certificate verification probably failed due to a problem with the
certificate. For example, it might be expired, or the name might not match the
domain name in the URL.
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
```
$ curl --cacert /usr/local/etc/dtr/ssl/server.pem https://dtr.yourdomain.com/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"access to the requested resource is not authorized","detail":null}]}
```
Continue by following the steps corresponding to your chosen OS. Run the following commands on the Trusted Registry host.
#### Ubuntu/Debian
```
$ export DOMAIN_NAME=dtr.yourdomain.com
$ openssl s_client -connect $DOMAIN_NAME:443 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM | sudo tee /usr/local/share/ca-certificates/$DOMAIN_NAME.crt
$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.
$ sudo service docker restart
docker stop/waiting
docker start/running, process 29291
```
#### RHEL/Centos
```
$ export DOMAIN_NAME=dtr.yourdomain.com
$ openssl s_client -connect $DOMAIN_NAME:443 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM | sudo tee /etc/pki/ca-trust/source/anchors/$DOMAIN_NAME.crt
$ sudo update-ca-trust
$ sudo /bin/systemctl restart docker.service
```
#### Docker Machine and Boot2Docker
You need to make some persistent changes using `bootsync.sh` in your
Boot2Docker-based virtual machine (as documented in [local customization](https://github.com/boot2docker/boot2docker/blob/master/doc/FAQ.md#local-customisation-with-persistent-partition)). To do this:
1. `docker-machine ssh dev` to enter the VM
2. `vi /var/lib/boot2docker/bootsync.sh` creates it if it doesn't exist, or edit it if it does.
3. Install the CA cert (or the auto-generated cert) by adding the following code to your `/var/lib/boot2docker/bootsync.sh`:
```
#!/bin/sh
cat /var/lib/boot2docker/server.pem >> /etc/ssl/certs/ca-certificates.crt
```
4. Next get the certificate from the new Docker Trusted Registry server using:
```
$ openssl s_client -connect dtr.yourdomain.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM | sudo tee -a /var/lib/boot2docker/server.pem
```
If your certificate chain is complicated, you can use the changes in [Pull request 807](https://github.com/boot2docker/boot2docker/pull/807/files)
5. Either reboot your virtual machine, or run the following commands to
install the server certificate. Restart the Docker daemon.
```
$ sudo chmod 755 /var/lib/boot2docker/bootsync.sh
$ sudo /var/lib/boot2docker/bootsync.sh
$ sudo /etc/init.d/docker restart`.
```
### If you can't install the certificates
If for some reason you can't install the certificate chain on a client Docker
host, or your certificates do not have a global CA, you can configure your
Docker daemon to run in "insecure" mode. This is done by adding an extra flag,
`--insecure-registry host-ip|domain-name`, to your client Docker daemon startup
flags. Restart the Docker daemon for the change to take effect.
This flag means that the communications between your Docker client and the
Trusted Registry server are still encrypted, but the client Docker daemon is not
confirming that the Registry connection is not being hijacked or diverted.
If you enter a "Domain Name" into the Security settings, it needs to be DNS
resolvable on any client daemons that are running in `insecure-registry`
mode.
To set the flag, edit the `daemon.json` file, which is located in `/etc/docker/`
on Linux or `C:\ProgramData\docker\config\` on Windows Server. If the
file does not yet exist, create it. Assuming the file was empty, it should have
the following contents:
```json
{
"insecure-registries": ["dtr.yourdomain.com"]
}
```
Restart Docker for the change to take effect.
### Docker Machine and Boot2Docker
In your Boot2Docker-based virtual machine, customize the Docker daemon
configuration with the `/var/lib/boot2docker/profile` file.
Open or create the `/var/lib/boot2docker/profile` file, and add an `EXTRA_ARGS`
setting as follows:
```
EXTRA_ARGS="--insecure-registry dtr.yourdomain.com"
```
Restart Docker for the change to take effect.
## See also
* [Configure storage options](config-storage.md)

View File

@ -1,233 +0,0 @@
---
description: Storage configuration for Docker Trusted Registry
keywords: docker, documentation, about, technology, understanding, configuration, storage, storage drivers, Azure, S3, Swift, enterprise, hub, registry
redirect_from:
- /docker-trusted-registry/configure/config-storage/
title: Storage configuration
---
After installing Docker Trusted Registry, one of your first tasks is to
designate and configure the Trusted Registry storage backend. This document
provides the following:
* Information describing your storage backend options.
* Configuration steps using either the Trusted Registry UI or a YAML file.
While there is a default storage backend, `filesystem`, the Trusted Registry
offers other options that are cloud-based. This flexibility to configure to a
different storage backend allows you to:
* Scale your Trusted Registry
* Leverage storage redundancy
* Store your images anywhere in the cloud
* Take advantage of other features that are critical to your organization
At first, you might have explored Docker Trusted Registry and Docker Engine by
[installing](../install/index.md) them on your system to familiarize
yourself with them. However, for various reasons such as deployment purposes or
continuous integration, it makes sense to think about your long term
organizations needs when selecting a storage backend. The Trusted Registry
natively supports TLS and basic authentication. It also ships with a
[notification system](/registry/notifications.md), calling webhooks in response
to activity. The notification system also provides both extensive logging and
reporting, which is useful for organizations that want to collect metrics.
## Understand the Trusted Registry storage backend
By default, your Trusted Registry data resides as a data volume on the host
`filesystem`. This is where your repositories and images are stored. This
storage driver is the local posix `filesystem` and is configured to use a
directory tree in the local filesystem. It's suitable for development or small
deployments. The `filesystem` can be located on the same computer as the Trusted
Registry, or on a separate system.
Additionally, the Trusted Registry supports these cloud-based storage drivers:
* Amazon Simple Storage Solution **S3**
* OpenStack **Swift**
* Microsoft **Azure** Blob Storage
<!--* **Rados**: A driver storing objects in a Ceph Object Storage pool. -->
### Filesystem
Use of the `filesystem` storage driver is incompatible when deploying DTR in High Availability with multiple replicas.
If you select `filesystem`, then the Trusted Registry uses the local disk to
store registry files. This backend has a single, required `rootdirectory`
parameter which specifies a subdirectory of `/var/local/dtr/imagestorage` in
which all registry files are stored. The default value of `/local` means the
files are stored in `/var/local/dtr/image-storage/local`.
The Trusted Registry stores all its data at this location, so ensure there is
adequate space available. To do so, you can run the following commands:
* To analyze the disk usage: `docker exec -it <container_name> bash` then run `df -h`.
* To see the file size of your containers, use the `-s` argument of `docker ps -s`.
### Amazon S3
S3 stores data as objects within “buckets” where you read, write, and delete
objects in that container. It too, has a `rootdirectory` parameter. If you
select this option, there will be some tasks that you need to first perform [on
AWS](https://aws.amazon.com/s3/getting-started/).
1. You must create an S3 bucket, and write down its name and the AWS zone it
runs on.
2. Determine write permissions for your bucket.
3. S3 flavor comes with DEBUG=false by default. If you need to debug, then you need to add `-e DEBUG=True`.
4. Specify an AWS region, which is dependent on your S3 location, for example, use `-e AWS_REGION=”eu-west-1”`.
5. Ensure your host time is correct. If your host clock is still running on the main computer, but not on the docker host virtual machine, then you will have
time differences. This may cause an issue if you try to authenticate with Amazon
web services.
6. You will also need your AWS access key and secret key. Learn [more about it ](http://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html) here.
Conversely, you can further limit what users access in the Trusted Registry when
you use AW to host your Trusted Registry. Instead of using the UI to enter
information, you can create an [IAM user
policy](http://docs.aws.amazon.com/AmazonS3/latest/dev/example-policies-s3.html)
which is a JSON description of the effects, actions, and resources available to
a user. The advantage of using this method instead of configuring through the
Trusted Registry UI is that you can restrict what users can access. You apply
the policy as part of the process of installing the Trusted Registry on AW. To
set a policy through the AWS command line, save the policy into a file, for
example `TrustedRegistryUserPerms.json`, and pass it to the put-user-policy AWS
command:
```
$ aws iam put-user-policy --user-name MyUser --policy-name TrustedRegistryUserPerms --policy-document file://C:\Temp\TrustedRegistryUserPerms.json
```
You can also set a policy through your AWS console. For more information about
setting IAM policies using the command line or the console, review the AWS
[Overview of IAM
Policies](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
article or visit the console Policies page.
The following example describes the minimum permissions set which allows
Trusted Registry users to access, push, pull, and delete images.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::<INSERT YOUR BUCKET HERE>"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::<INSERT YOUR BUCKET HERE>/*"
}
]
}
```
### OpenStack Swift
OpenStack Swift, also known as OpenStack Object Storage, is an open source
object storage system that is licensed under the Apache 2.0 license. Refer to
[Swift documentation](http://docs.openstack.org/developer/swift/) to get
started.
<!--
### Ceph Rados
**(Details are missing as this is currently being developed for DTR 1.4.3?)**
Ceph implements distributed object storage. The object storage “product”,
service or capabilities, consist of a Ceph Storage Cluster and a Ceph
Object Gateway.
For additional information see the Ceph documentation [here](http://docs.ceph.com/docs/master/rados/) and [here](http://docs.ceph.com/docs/hammer/radosgw/).
-->
### Microsoft Azure
This storage backend uses Microsofts Azure Blob storage. Data is stored within
a paid Windows Azure storage account. Refer to Microsoft's Azure
[documentation](https://azure.microsoft.com/en-us/services/storage/) which
explains how to set up your Storage account.
## Configure your Trusted Registry storage backend
Once you select your driver, you need to configure it through the UI or use a
YAML file (which is discussed further in this document.)
1. From the main Trusted Registry screen, navigate to Settings > Storage.
2. Under Storage Backend, use the drop down menu to select your storage. The screen refreshes to reflect your option.
3. Enter your configuration settings. If you're not sure what a particular parameter does, then find your driver from the following headings so that you can see a detailed explanation.
4. Click Save. The Trusted Registry restarts so that your changes take effect.
>**Note**: Changing your storage backend requires you to restart the Trusted Registry.
See the [Docker Registry storage driver](/registry/storage-drivers/)
documentation for the full options specific to each driver. Storage drivers can
be customized through the
[Docker Registry storage driver API](/registry/storage-drivers/index.md#storage-driver-api).
### Filesystem settings
The [filesystem storage backend](/registry/storage-drivers/filesystem)
has only one setting, the "Storage directory".
### S3 settings
If you select the [S3 storage backend](/registry/storage-drivers/s3), then you
need to set "AWS region", "Bucket name", "Access Key", and "Secret Key".
### Azure settings
Set the "Account name", "Account key", "Container", and "Realm" on the [Azure storage backend](/registry/storage-drivers/azure) page.
### Openstack Swift settings
View the [Openstack Swift settings](/registry/storage-drivers/openstack-swift)
documentation so that you can set up your storage settings: authurl, username,
password, container, tenant, tenantid, domain, domainid, insecureskipverify,
region, chunksize, and prefix.
## Configure using a YAML file
If the previous quick setup options are not sufficient to configure your
Registry options, you can upload a YAML file. The schema of this file is
identical to that used by the [Registry](/registry/configuration.md).
There are several benefits to using a YAML file as it can provide an
additional level of granularity in defining your storage backend. Advantages
include:
* Overriding specific configuration options.
* Overriding the entire configuration file.
* Selecting from the entire list of configuration options.
**To configure**:
1. Navigate to the Trusted Registry UI > Settings > Storage.
2. Select Download to get the text based file. It contains a minimum amount
of information and you're going to need additional data based on your driver and
business requirements.
3. Go [here](/registry/configuration.md#list-of-configuration-options") to see the open source YAML file. Copy the sections you need and paste into your `storage.yml` file. Some settings may contradict others, so
ensure your choices make sense.
4. Save the YAML file and return to the UI.
5. On the Storage screen, upload the file, review your changes, and click Save.
## See also
* [Configure security settings](config-security.md)

View File

@ -1,41 +0,0 @@
---
description: Configuration overview for Docker Trusted Registry
keywords: docker, documentation, about, technology, understanding, enterprise, hub, registry
redirect_from:
- /docker-trusted-registry/configure/configuration/
title: Configuration overview
---
When you first install Docker Trusted Registry, you need to configure it. Use
this overview to see what you can configure.
To start, navigate to the Trusted Registry user interface (UI) > Settings, to
view configuration options. Configuring is grouped by the following:
* [General settings](config-general.md) (ports, proxies, and Notary)
* [Security settings](config-security.md)
* [Storage settings](config-storage.md)
* [License](../install/license.md)
* Updates
Saving changes you've made to settings will restart various services, as follows:
* General settings: full Docker Trusted Registry restart
* License change: full Docker Trusted Registry restart
* SSL change: Nginx reload
* Storage config: only registries restart
## Docker daemon logs
Both the Trusted Registry and the Docker daemon collect and store log messages.
To limit duplication of the Docker daemon logs, add the following parameters in
a Trusted Registry CLI to the Docker daemon and then restart the daemon.
`docker daemon --log-opt max-size 100m max-file=1`
## See also
* [Monitor DTR](../monitor-troubleshoot/index.md)
* [Troubleshoot DTR](../monitor-troubleshoot/troubleshoot.md)

View File

@ -1,12 +0,0 @@
---
description: Trusted Registry configuration options
keywords: docker, documentation, about, technology, install, enterprise, hub, CS engine, Docker Trusted Registry, configure, storage, backend, drivers
title: Configuration of Docker Trusted Registry
---
This section includes the following topics:
* [Configuration overview](configuration.md)
* [Configure general settings](config-general.md)
* [Security configuration](config-security.md)
* [Storage configuration](config-storage.md)

View File

@ -1,136 +0,0 @@
---
description: Learn how to backup your Docker Trusted Registry cluster, and to recover your cluster from an existing backup.
keywords: docker, registry, high-availability, backup, recovery
redirect_from:
- /docker-trusted-registry/high-availability/backups-and-disaster-recovery/
title: Backups and disaster recovery
---
When you decide to start using Docker Trusted Registry on a production
setting, you should [configure it for high availability](index.md).
The next step is creating a backup policy and disaster recovery plan.
## DTR data persistency
Docker Trusted Registry persists:
* Configurations: the cluster configurations are stored on a key-value store
that is replicated through all DTR replicas.
* Repository metadata: the information about the repositories and
images deployed. This information is replicated through all DTR replicas.
* Certificates and keys: the certificates, public keys, and private keys that
are used for mutual TLS communication.
This data is persisted on the host where DTR is running, using named volumes.
[Learn more about DTR named volumes](../architecture.md).
DTR also persists Docker images on the filesystem of the host running DTR, or
on a cloud provider, depending on the way DTR is configured.
## Backup DTR data
To perform a backup of a DTR node, use the `docker/dtr backup` command. This
command creates a backup of DTR:
* Configurations,
* Repository metadata,
* Certificates and keys used by DTR.
These files are added to a tar archive, and the result is streamed to stdout.
The backup command does not create a backup of Docker images. You should
implement a separate backup policy for the Docker images, taking in
consideration whether your DTR installation is configured to store images on the
filesystem or using a cloud provider.
The backup command also doesn't create a backup of the users and organizations.
That data is managed by UCP, so when you create a UCP backup you're creating
a backup of the users and organizations metadata.
When creating a backup, the resulting .tar file contains sensitive information
like private keys. You should ensure the backups are stored securely.
You can check the
[reference documentation](../reference/backup.md), for the
backup command to learn about all the available flags.
As an example, to create a backup of a DTR node, you can use:
```bash
# Get the certificates used by UCP
$ curl https://<ucp-url>/ca > ucp-ca.pem
# Create the backup
$ docker run -i --rm docker/dtr backup \
--ucp-url <ucp-url> \
--ucp-ca "$(cat ucp-ca.pem)" \
--existing-replica-id <replica-id> \
--ucp-username <ucp-admin> \
--ucp-password <ucp-password> > /var/tmp/backup.tar
```
Where:
* `--ucp-url` is the address of UCP,
* `--ucp-ca` is the UCP certificate authority,
* `--existing-replica-id` is the id of the replica to backup,
* `--ucp-username`, and `--ucp-password` are the credentials of a UCP administrator.
To validate that the backup was correctly performed, you can print the contents
of the tar file created:
```bash
$ tar -tf /tmp/backup.tar
```
## Restore DTR data
This command performs a fresh installation of DTR, and reconfigures it with
the configuration created during a backup.
When restoring, make sure you use the same version of the `docker/dtr` image that you've used to create the backup.
The command starts by installing DTR, restores the configurations stored on
etcd, and then restores the repository metadata stored on RethinkDB. You
can use the `--config-only` option, to only restore the configurations stored
on etcd.
This command does not restore Docker images. You should implement a separate
restore procedure for the Docker images stored in your registry, taking in
consideration whether your DTR installation is configured to store images on
the filesystem or using a cloud provider.
You can check the
[reference documentation](../reference/restore.md), for the
restore command to learn about all the available flags.
As an example, to install DTR on the host and restore its
state from an existing backup:
```bash
# Get the certificates used by UCP
$ curl https://<ucp-url>/ca > ucp-ca.pem
# Install and restore configurations from an existing backup
$ docker run -i --rm \
docker/dtr restore \
--ucp-url <ucp-url> \
--ucp-ca "$(cat ucp-ca.pem)" \
--ucp-username <ucp-admin> \
--ucp-password <ucp-password> \
--dtr-external-url <dtr-domain-name> < /var/tmp/backup.tar
```
Where:
* `--ucp-url` is the address of UCP,
* `--ucp-ca` is the UCP certificate authority,
* `--ucp-username`, and `--ucp-password` are the credentials of a UCP administrator,
* `--dtr-external-url` is the domain name or ip where DTR can be reached.
## Where to go next
* [Set up high availability](index.md)
* [DTR architecture](../architecture.md)

View File

@ -1,85 +0,0 @@
---
description: Learn how to set up Docker Trusted Registry for high availability.
keywords: docker, registry, high-availability, backup, recovery
redirect_from:
- /docker-trusted-registry/high-availability/high-availability/
title: Set up high availability
---
Docker Trusted Registry (DTR) is designed for high availability.
When you first install DTR, you create a cluster with a single DTR replica.
Replicas are single instances of DTR that can be joined together to form a
cluster.
When joining new replicas to the cluster, you create new DTR instances
that are running the same set of services. Any change to the state of an
instance is replicated across all other instances.
![](../images/high-availability-1.png)
Having a DTR cluster with multiple replicas, allows you to:
* Load-balance user requests across the DTR replicas,
* Keep the DTR cluster working if a replica fails.
To make a DTR installation tolerant to failures, add additional replicas to
the DTR cluster.
| DTR replicas | Failures tolerated |
|:------------:|:------------------:|
| 1 | 0 |
| 3 | 1 |
| 5 | 2 |
| 7 | 3 |
When sizing your DTR installation for high-availability,
follow these rules of thumb:
* Don't create a DTR cluster with just two replicas. Your cluster
won't tolerate any failures, and it's possible that you experience performance
degradation.
* When a replica fails, the number of failures tolerated by your cluster
decreases. Don't leave that replica offline for long.
* Adding too many replicas to the cluster might also lead to performance
degradation, as data needs to be replicated across all replicas.
## Size your cluster
When installing DTR for production, you should have dedicated nodes for running:
* Docker Universal Control Plane (UCP) controller nodes,
* DTR replicas,
* Your own applications.
Having dedicated nodes ensures all applications will remain performant since
they have dedicated resources for them.
It also makes it easier to implement backup policies and disaster recovery
plans for UCP and DTR.
To have high-availability on UCP and DTR, you need a minimum of:
* 3 dedicated nodes to install UCP with high availability,
* 3 dedicated nodes to install DTR with high availability,
* As many nodes as you want for running your containers and applications.
![](../images/high-availability-2.png)
## Load balancing
DTR does not provide a load balancing service. You can use an on-premises
or cloud-based load balancer to balance requests across multiple DTR replicas.
Make sure you configure your load balancer to:
* Load-balance TCP traffic on ports 80 and 443,
* Use a TCP load balancer that doesn't terminate HTTPS connections,
* Use the `/load_balancer_status` endpoint on each DTR replica, to check if
the replica is healthy and if it should remain on the load balancing pool or
not.
## Where to go next
* [Backups and disaster recovery](backups-and-disaster-recovery.md)
* [DTR architecture](../architecture.md)

View File

@ -1,47 +0,0 @@
SIZE="1280px"
HOST=dtr.domain.com
HOSTIP:=192.168.18.131
HOSTURL=https://$(HOST)
IMAGE=svendowideit/screenshot
#IMAGE=screenshot
RUNOPTS=docker run --rm -v $(CURDIR):/srv --add-host $(HOST):$(HOSTIP)
RUN=$(RUNOPTS) $(IMAGE)
all:
# Needs to be run with no authentication
$(RUN) $(HOSTURL)/admin/ admin-metrics.png $(SIZE)
$(RUN) $(HOSTURL)/admin/logs/ admin-logs.png $(SIZE)
$(RUN) $(HOSTURL)/admin/settings/auth/ admin-settings-authentication.png $(SIZE)
$(RUN) $(HOSTURL)/admin/settings/general admin-settings.png $(SIZE)
$(RUN) $(HOSTURL)/admin/settings/security admin-settings-security.png $(SIZE)
$(RUN) $(HOSTURL)/admin/settings/storage admin-settings-storage.png $(SIZE)
$(RUN) $(HOSTURL)/admin/settings/license admin-settings-license.png $(SIZE)
manual:
# --env-file=passwords.env
$(RUNOPTS) --env-file=passwords.env \
$(IMAGE) \
$(HOSTURL)/admin/settings#auth admin-settings-authentication-basic.png $(SIZE)
#admin-settings-authentication-ldap.png
# TODO: needs manual intervention atm
qs1:
# this requires the hostname to resolve.
echo "$HOST $HOSTIP" >> /etc/hosts
# and requires that host to be added to the docker daemon's insecure registry settings
# maybe use a dind daemon?
docker pull jenkins
docker tag -f jenkins t400s.home.org.au/ci-infrastructure/jnkns-img
docker push t400s.home.org.au/ci-infrastructure/jnkns-img
sleep 1
$(RUN) $(HOSTURL)/admin/ console-push.png $(SIZE)
sleep 10
qs2:
docker rmi jenkins t400s.home.org.au/ci-infrastructure/jnkns-img
docker pull t400s.home.org.au/ci-infrastructure/jnkns-img
sleep 1
$(RUN) $(HOSTURL)/admin/ console-pull.png $(SIZE)

Binary file not shown.

Before

Width:  |  Height:  |  Size: 85 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 65 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 55 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 43 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 75 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.0 KiB

View File

@ -1,90 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="690px" height="282px" viewBox="0 0 690 282" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<!-- Generator: Sketch 3.8.3 (29802) - http://www.bohemiancoding.com/sketch -->
<title>dtr-authorization-1</title>
<desc>Created with Sketch.</desc>
<defs>
<rect id="path-1" x="0" y="0" width="690" height="282"></rect>
<mask id="mask-2" maskContentUnits="userSpaceOnUse" maskUnits="objectBoundingBox" x="0" y="0" width="690" height="282" fill="white">
<use xlink:href="#path-1"></use>
</mask>
</defs>
<g id="Apps" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
<g id="dtr-authorization-1">
<g id="all" transform="translate(175.000000, 62.000000)">
<g id="Group" transform="translate(168.000000, 0.000000)">
<g id="teams">
<g id="billing-team" transform="translate(100.000000, 0.000000)">
<path d="M34.5,26.5 C41.820625,26.5 47.75,20.5540625 47.75,13.25 C47.75,5.929375 41.820625,0 34.5,0 C27.179375,0 21.25,5.929375 21.25,13.25 C21.25,20.5540625 27.179375,26.5 34.5,26.5 L34.5,26.5 Z M34.5,33.125 C25.6721875,33.125 8,37.5471875 8,46.375 L8,53 L61,53 L61,46.375 C61,37.5471875 43.3278125,33.125 34.5,33.125 L34.5,33.125 Z" id="Shape-Copy" fill="#9967FF"></path>
<text font-family="OpenSans-Semibold, Open Sans" font-size="12" font-weight="500" fill="#C0C9CE">
<tspan x="0" y="68">billing team</tspan>
</text>
</g>
<g id="blog-team">
<text font-family="OpenSans-Semibold, Open Sans" font-size="12" font-weight="500" fill="#C0C9CE">
<tspan x="0" y="68">blog team</tspan>
</text>
<path d="M29.5,26.5 C36.820625,26.5 42.75,20.5540625 42.75,13.25 C42.75,5.929375 36.820625,0 29.5,0 C22.179375,0 16.25,5.929375 16.25,13.25 C16.25,20.5540625 22.179375,26.5 29.5,26.5 L29.5,26.5 Z M29.5,33.125 C20.6721875,33.125 3,37.5471875 3,46.375 L3,53 L56,53 L56,46.375 C56,37.5471875 38.3278125,33.125 29.5,33.125 L29.5,33.125 Z" id="Shape-Copy-2" fill="#00CBCA"></path>
</g>
</g>
</g>
<g id="permissions" transform="translate(160.000000, 101.000000)">
<g id="6" transform="translate(105.000000, 84.000000)" fill="#C0C9CE">
<path d="M75,11.3466667 L75,8.65333333 C73.6241667,8.16416667 72.755,8.02666667 72.3175,6.97083333 L72.3175,6.97 C71.8783333,5.91083333 72.4008333,5.19166667 73.0233333,3.88083333 L71.1191667,1.97666667 C69.8183333,2.595 69.0916667,3.1225 68.03,2.6825 L68.0291667,2.6825 C66.9716667,2.24416667 66.8333333,1.36916667 66.3466667,0 L63.6533333,0 C63.1683333,1.3625 63.0291667,2.24333333 61.9708333,2.6825 L61.97,2.6825 C60.9108333,3.1225 60.1933333,2.60083333 58.8808333,1.97666667 L56.9766667,3.88083333 C57.5975,5.1875 58.1225,5.90916667 57.6825,6.97 C57.2433333,8.02916667 56.3625,8.16833333 55,8.65333333 L55,11.3466667 C56.36,11.83 57.2433333,11.9708333 57.6825,13.0291667 C58.1241667,14.0975 57.5875,14.8341667 56.9766667,16.1183333 L58.8808333,18.0233333 C60.1825,17.4041667 60.9091667,16.8775 61.97,17.3175 L61.9708333,17.3175 C63.0291667,17.7558333 63.1675,18.6333333 63.6533333,20 L66.3466667,20 C66.8316667,18.6366667 66.9716667,17.7583333 68.0358333,17.315 L68.0366667,17.315 C69.0883333,16.8783333 69.8033333,17.3991667 71.1183333,18.0241667 L73.0225,16.1191667 C72.4025,14.8166667 71.8766667,14.0916667 72.3158333,13.0308333 C72.755,11.9716667 73.6391667,11.8308333 75,11.3466667 L75,11.3466667 Z M65,13.3333333 C63.1591667,13.3333333 61.6666667,11.8408333 61.6666667,10 C61.6666667,8.15916667 63.1591667,6.66666667 65,6.66666667 C66.8408333,6.66666667 68.3333333,8.15916667 68.3333333,10 C68.3333333,11.8408333 66.8408333,13.3333333 65,13.3333333 L65,13.3333333 Z" id="settings"></path>
<path d="M12.09,1 C4.5,1 0,10 0,10 C0,10 4.5,19 12.09,19 C19.5,19 24,10 24,10 C24,10 19.5,1 12.09,1 L12.09,1 Z M12,16 C8.7,16 6,13.33 6,10 C6,6.7 8.7,4 12,4 C15.33,4 18,6.7 18,10 C18,13.33 15.33,16 12,16 L12,16 Z M15,10 C15,11.665 13.665,13 12,13 C10.335,13 9,11.665 9,10 C9,8.335 10.335,7 12,7 C13.665,7 15,8.335 15,10 L15,10 Z" id="Shape"></path>
<path d="M31,15.0272045 L31,19 L34.9727791,19 L45.5668567,8.40587876 L41.5940776,4.4330833 L31,15.0272045 L31,15.0272045 Z M34.9727791,17.6757348 L32.3242597,17.6757348 L32.3242597,15.0272045 L33.6485194,15.0272045 L33.6485194,16.3514697 L34.9727791,16.3514697 L34.9727791,17.6757348 L34.9727791,17.6757348 Z M48.612654,5.36006891 L46.8911164,7.08161361 L42.9183373,3.10881814 L44.6398749,1.38727344 C44.8873057,1.13933381 45.2231988,1 45.573478,1 C45.9237573,1 46.2596503,1.13933381 46.5070811,1.38727344 L48.612654,3.49285504 C49.1291153,4.00931845 49.1291153,4.8436055 48.612654,5.36006891 L48.612654,5.36006891 Z" id="Shape"></path>
</g>
<g id="5" transform="translate(0.000000, 84.000000)" fill="#C0C9CE">
<path d="M75,11.3466667 L75,8.65333333 C73.6241667,8.16416667 72.755,8.02666667 72.3175,6.97083333 L72.3175,6.97 C71.8783333,5.91083333 72.4008333,5.19166667 73.0233333,3.88083333 L71.1191667,1.97666667 C69.8183333,2.595 69.0916667,3.1225 68.03,2.6825 L68.0291667,2.6825 C66.9716667,2.24416667 66.8333333,1.36916667 66.3466667,0 L63.6533333,0 C63.1683333,1.3625 63.0291667,2.24333333 61.9708333,2.6825 L61.97,2.6825 C60.9108333,3.1225 60.1933333,2.60083333 58.8808333,1.97666667 L56.9766667,3.88083333 C57.5975,5.1875 58.1225,5.90916667 57.6825,6.97 C57.2433333,8.02916667 56.3625,8.16833333 55,8.65333333 L55,11.3466667 C56.36,11.83 57.2433333,11.9708333 57.6825,13.0291667 C58.1241667,14.0975 57.5875,14.8341667 56.9766667,16.1183333 L58.8808333,18.0233333 C60.1825,17.4041667 60.9091667,16.8775 61.97,17.3175 L61.9708333,17.3175 C63.0291667,17.7558333 63.1675,18.6333333 63.6533333,20 L66.3466667,20 C66.8316667,18.6366667 66.9716667,17.7583333 68.0358333,17.315 L68.0366667,17.315 C69.0883333,16.8783333 69.8033333,17.3991667 71.1183333,18.0241667 L73.0225,16.1191667 C72.4025,14.8166667 71.8766667,14.0916667 72.3158333,13.0308333 C72.755,11.9716667 73.6391667,11.8308333 75,11.3466667 L75,11.3466667 Z M65,13.3333333 C63.1591667,13.3333333 61.6666667,11.8408333 61.6666667,10 C61.6666667,8.15916667 63.1591667,6.66666667 65,6.66666667 C66.8408333,6.66666667 68.3333333,8.15916667 68.3333333,10 C68.3333333,11.8408333 66.8408333,13.3333333 65,13.3333333 L65,13.3333333 Z" id="settings"></path>
<path d="M12.09,1 C4.5,1 0,10 0,10 C0,10 4.5,19 12.09,19 C19.5,19 24,10 24,10 C24,10 19.5,1 12.09,1 L12.09,1 Z M12,16 C8.7,16 6,13.33 6,10 C6,6.7 8.7,4 12,4 C15.33,4 18,6.7 18,10 C18,13.33 15.33,16 12,16 L12,16 Z M15,10 C15,11.665 13.665,13 12,13 C10.335,13 9,11.665 9,10 C9,8.335 10.335,7 12,7 C13.665,7 15,8.335 15,10 L15,10 Z" id="Shape"></path>
<path d="M31,15.0272045 L31,19 L34.9727791,19 L45.5668567,8.40587876 L41.5940776,4.4330833 L31,15.0272045 L31,15.0272045 Z M34.9727791,17.6757348 L32.3242597,17.6757348 L32.3242597,15.0272045 L33.6485194,15.0272045 L33.6485194,16.3514697 L34.9727791,16.3514697 L34.9727791,17.6757348 L34.9727791,17.6757348 Z M48.612654,5.36006891 L46.8911164,7.08161361 L42.9183373,3.10881814 L44.6398749,1.38727344 C44.8873057,1.13933381 45.2231988,1 45.573478,1 C45.9237573,1 46.2596503,1.13933381 46.5070811,1.38727344 L48.612654,3.49285504 C49.1291153,4.00931845 49.1291153,4.8436055 48.612654,5.36006891 L48.612654,5.36006891 Z" id="Shape"></path>
</g>
<g id="4" transform="translate(105.000000, 42.000000)">
<path d="M75,11.3466667 L75,8.65333333 C73.6241667,8.16416667 72.755,8.02666667 72.3175,6.97083333 L72.3175,6.97 C71.8783333,5.91083333 72.4008333,5.19166667 73.0233333,3.88083333 L71.1191667,1.97666667 C69.8183333,2.595 69.0916667,3.1225 68.03,2.6825 L68.0291667,2.6825 C66.9716667,2.24416667 66.8333333,1.36916667 66.3466667,0 L63.6533333,0 C63.1683333,1.3625 63.0291667,2.24333333 61.9708333,2.6825 L61.97,2.6825 C60.9108333,3.1225 60.1933333,2.60083333 58.8808333,1.97666667 L56.9766667,3.88083333 C57.5975,5.1875 58.1225,5.90916667 57.6825,6.97 C57.2433333,8.02916667 56.3625,8.16833333 55,8.65333333 L55,11.3466667 C56.36,11.83 57.2433333,11.9708333 57.6825,13.0291667 C58.1241667,14.0975 57.5875,14.8341667 56.9766667,16.1183333 L58.8808333,18.0233333 C60.1825,17.4041667 60.9091667,16.8775 61.97,17.3175 L61.9708333,17.3175 C63.0291667,17.7558333 63.1675,18.6333333 63.6533333,20 L66.3466667,20 C66.8316667,18.6366667 66.9716667,17.7583333 68.0358333,17.315 L68.0366667,17.315 C69.0883333,16.8783333 69.8033333,17.3991667 71.1183333,18.0241667 L73.0225,16.1191667 C72.4025,14.8166667 71.8766667,14.0916667 72.3158333,13.0308333 C72.755,11.9716667 73.6391667,11.8308333 75,11.3466667 L75,11.3466667 Z M65,13.3333333 C63.1591667,13.3333333 61.6666667,11.8408333 61.6666667,10 C61.6666667,8.15916667 63.1591667,6.66666667 65,6.66666667 C66.8408333,6.66666667 68.3333333,8.15916667 68.3333333,10 C68.3333333,11.8408333 66.8408333,13.3333333 65,13.3333333 L65,13.3333333 Z" id="settings" fill="#C0C9CE"></path>
<path d="M12.09,1 C4.5,1 0,10 0,10 C0,10 4.5,19 12.09,19 C19.5,19 24,10 24,10 C24,10 19.5,1 12.09,1 L12.09,1 Z M12,16 C8.7,16 6,13.33 6,10 C6,6.7 8.7,4 12,4 C15.33,4 18,6.7 18,10 C18,13.33 15.33,16 12,16 L12,16 Z M15,10 C15,11.665 13.665,13 12,13 C10.335,13 9,11.665 9,10 C9,8.335 10.335,7 12,7 C13.665,7 15,8.335 15,10 L15,10 Z" id="Shape" fill="#445D6E"></path>
<path d="M31,15.0272045 L31,19 L34.9727791,19 L45.5668567,8.40587876 L41.5940776,4.4330833 L31,15.0272045 L31,15.0272045 Z M34.9727791,17.6757348 L32.3242597,17.6757348 L32.3242597,15.0272045 L33.6485194,15.0272045 L33.6485194,16.3514697 L34.9727791,16.3514697 L34.9727791,17.6757348 L34.9727791,17.6757348 Z M48.612654,5.36006891 L46.8911164,7.08161361 L42.9183373,3.10881814 L44.6398749,1.38727344 C44.8873057,1.13933381 45.2231988,1 45.573478,1 C45.9237573,1 46.2596503,1.13933381 46.5070811,1.38727344 L48.612654,3.49285504 C49.1291153,4.00931845 49.1291153,4.8436055 48.612654,5.36006891 L48.612654,5.36006891 Z" id="Shape" fill="#445D6E"></path>
</g>
<g id="3" transform="translate(0.000000, 42.000000)">
<path d="M75,11.3466667 L75,8.65333333 C73.6241667,8.16416667 72.755,8.02666667 72.3175,6.97083333 L72.3175,6.97 C71.8783333,5.91083333 72.4008333,5.19166667 73.0233333,3.88083333 L71.1191667,1.97666667 C69.8183333,2.595 69.0916667,3.1225 68.03,2.6825 L68.0291667,2.6825 C66.9716667,2.24416667 66.8333333,1.36916667 66.3466667,0 L63.6533333,0 C63.1683333,1.3625 63.0291667,2.24333333 61.9708333,2.6825 L61.97,2.6825 C60.9108333,3.1225 60.1933333,2.60083333 58.8808333,1.97666667 L56.9766667,3.88083333 C57.5975,5.1875 58.1225,5.90916667 57.6825,6.97 C57.2433333,8.02916667 56.3625,8.16833333 55,8.65333333 L55,11.3466667 C56.36,11.83 57.2433333,11.9708333 57.6825,13.0291667 C58.1241667,14.0975 57.5875,14.8341667 56.9766667,16.1183333 L58.8808333,18.0233333 C60.1825,17.4041667 60.9091667,16.8775 61.97,17.3175 L61.9708333,17.3175 C63.0291667,17.7558333 63.1675,18.6333333 63.6533333,20 L66.3466667,20 C66.8316667,18.6366667 66.9716667,17.7583333 68.0358333,17.315 L68.0366667,17.315 C69.0883333,16.8783333 69.8033333,17.3991667 71.1183333,18.0241667 L73.0225,16.1191667 C72.4025,14.8166667 71.8766667,14.0916667 72.3158333,13.0308333 C72.755,11.9716667 73.6391667,11.8308333 75,11.3466667 L75,11.3466667 Z M65,13.3333333 C63.1591667,13.3333333 61.6666667,11.8408333 61.6666667,10 C61.6666667,8.15916667 63.1591667,6.66666667 65,6.66666667 C66.8408333,6.66666667 68.3333333,8.15916667 68.3333333,10 C68.3333333,11.8408333 66.8408333,13.3333333 65,13.3333333 L65,13.3333333 Z" id="settings" fill="#C0C9CE"></path>
<path d="M12.09,1 C4.5,1 0,10 0,10 C0,10 4.5,19 12.09,19 C19.5,19 24,10 24,10 C24,10 19.5,1 12.09,1 L12.09,1 Z M12,16 C8.7,16 6,13.33 6,10 C6,6.7 8.7,4 12,4 C15.33,4 18,6.7 18,10 C18,13.33 15.33,16 12,16 L12,16 Z M15,10 C15,11.665 13.665,13 12,13 C10.335,13 9,11.665 9,10 C9,8.335 10.335,7 12,7 C13.665,7 15,8.335 15,10 L15,10 Z" id="Shape" fill="#445D6E"></path>
<path d="M31,15.0272045 L31,19 L34.9727791,19 L45.5668567,8.40587876 L41.5940776,4.4330833 L31,15.0272045 L31,15.0272045 Z M34.9727791,17.6757348 L32.3242597,17.6757348 L32.3242597,15.0272045 L33.6485194,15.0272045 L33.6485194,16.3514697 L34.9727791,16.3514697 L34.9727791,17.6757348 L34.9727791,17.6757348 Z M48.612654,5.36006891 L46.8911164,7.08161361 L42.9183373,3.10881814 L44.6398749,1.38727344 C44.8873057,1.13933381 45.2231988,1 45.573478,1 C45.9237573,1 46.2596503,1.13933381 46.5070811,1.38727344 L48.612654,3.49285504 C49.1291153,4.00931845 49.1291153,4.8436055 48.612654,5.36006891 L48.612654,5.36006891 Z" id="Shape" fill="#C0C9CE"></path>
</g>
<g id="2" transform="translate(105.000000, 0.000000)" fill="#445D6E">
<path d="M75,11.3466667 L75,8.65333333 C73.6241667,8.16416667 72.755,8.02666667 72.3175,6.97083333 L72.3175,6.97 C71.8783333,5.91083333 72.4008333,5.19166667 73.0233333,3.88083333 L71.1191667,1.97666667 C69.8183333,2.595 69.0916667,3.1225 68.03,2.6825 L68.0291667,2.6825 C66.9716667,2.24416667 66.8333333,1.36916667 66.3466667,0 L63.6533333,0 C63.1683333,1.3625 63.0291667,2.24333333 61.9708333,2.6825 L61.97,2.6825 C60.9108333,3.1225 60.1933333,2.60083333 58.8808333,1.97666667 L56.9766667,3.88083333 C57.5975,5.1875 58.1225,5.90916667 57.6825,6.97 C57.2433333,8.02916667 56.3625,8.16833333 55,8.65333333 L55,11.3466667 C56.36,11.83 57.2433333,11.9708333 57.6825,13.0291667 C58.1241667,14.0975 57.5875,14.8341667 56.9766667,16.1183333 L58.8808333,18.0233333 C60.1825,17.4041667 60.9091667,16.8775 61.97,17.3175 L61.9708333,17.3175 C63.0291667,17.7558333 63.1675,18.6333333 63.6533333,20 L66.3466667,20 C66.8316667,18.6366667 66.9716667,17.7583333 68.0358333,17.315 L68.0366667,17.315 C69.0883333,16.8783333 69.8033333,17.3991667 71.1183333,18.0241667 L73.0225,16.1191667 C72.4025,14.8166667 71.8766667,14.0916667 72.3158333,13.0308333 C72.755,11.9716667 73.6391667,11.8308333 75,11.3466667 L75,11.3466667 Z M65,13.3333333 C63.1591667,13.3333333 61.6666667,11.8408333 61.6666667,10 C61.6666667,8.15916667 63.1591667,6.66666667 65,6.66666667 C66.8408333,6.66666667 68.3333333,8.15916667 68.3333333,10 C68.3333333,11.8408333 66.8408333,13.3333333 65,13.3333333 L65,13.3333333 Z" id="settings"></path>
<path d="M12.09,1 C4.5,1 0,10 0,10 C0,10 4.5,19 12.09,19 C19.5,19 24,10 24,10 C24,10 19.5,1 12.09,1 L12.09,1 Z M12,16 C8.7,16 6,13.33 6,10 C6,6.7 8.7,4 12,4 C15.33,4 18,6.7 18,10 C18,13.33 15.33,16 12,16 L12,16 Z M15,10 C15,11.665 13.665,13 12,13 C10.335,13 9,11.665 9,10 C9,8.335 10.335,7 12,7 C13.665,7 15,8.335 15,10 L15,10 Z" id="Shape"></path>
<path d="M31,15.0272045 L31,19 L34.9727791,19 L45.5668567,8.40587876 L41.5940776,4.4330833 L31,15.0272045 L31,15.0272045 Z M34.9727791,17.6757348 L32.3242597,17.6757348 L32.3242597,15.0272045 L33.6485194,15.0272045 L33.6485194,16.3514697 L34.9727791,16.3514697 L34.9727791,17.6757348 L34.9727791,17.6757348 Z M48.612654,5.36006891 L46.8911164,7.08161361 L42.9183373,3.10881814 L44.6398749,1.38727344 C44.8873057,1.13933381 45.2231988,1 45.573478,1 C45.9237573,1 46.2596503,1.13933381 46.5070811,1.38727344 L48.612654,3.49285504 C49.1291153,4.00931845 49.1291153,4.8436055 48.612654,5.36006891 L48.612654,5.36006891 Z" id="Shape"></path>
</g>
<g id="1" fill="#C0C9CE">
<path d="M75,11.3466667 L75,8.65333333 C73.6241667,8.16416667 72.755,8.02666667 72.3175,6.97083333 L72.3175,6.97 C71.8783333,5.91083333 72.4008333,5.19166667 73.0233333,3.88083333 L71.1191667,1.97666667 C69.8183333,2.595 69.0916667,3.1225 68.03,2.6825 L68.0291667,2.6825 C66.9716667,2.24416667 66.8333333,1.36916667 66.3466667,0 L63.6533333,0 C63.1683333,1.3625 63.0291667,2.24333333 61.9708333,2.6825 L61.97,2.6825 C60.9108333,3.1225 60.1933333,2.60083333 58.8808333,1.97666667 L56.9766667,3.88083333 C57.5975,5.1875 58.1225,5.90916667 57.6825,6.97 C57.2433333,8.02916667 56.3625,8.16833333 55,8.65333333 L55,11.3466667 C56.36,11.83 57.2433333,11.9708333 57.6825,13.0291667 C58.1241667,14.0975 57.5875,14.8341667 56.9766667,16.1183333 L58.8808333,18.0233333 C60.1825,17.4041667 60.9091667,16.8775 61.97,17.3175 L61.9708333,17.3175 C63.0291667,17.7558333 63.1675,18.6333333 63.6533333,20 L66.3466667,20 C66.8316667,18.6366667 66.9716667,17.7583333 68.0358333,17.315 L68.0366667,17.315 C69.0883333,16.8783333 69.8033333,17.3991667 71.1183333,18.0241667 L73.0225,16.1191667 C72.4025,14.8166667 71.8766667,14.0916667 72.3158333,13.0308333 C72.755,11.9716667 73.6391667,11.8308333 75,11.3466667 L75,11.3466667 Z M65,13.3333333 C63.1591667,13.3333333 61.6666667,11.8408333 61.6666667,10 C61.6666667,8.15916667 63.1591667,6.66666667 65,6.66666667 C66.8408333,6.66666667 68.3333333,8.15916667 68.3333333,10 C68.3333333,11.8408333 66.8408333,13.3333333 65,13.3333333 L65,13.3333333 Z" id="settings"></path>
<path d="M12.09,1 C4.5,1 0,10 0,10 C0,10 4.5,19 12.09,19 C19.5,19 24,10 24,10 C24,10 19.5,1 12.09,1 L12.09,1 Z M12,16 C8.7,16 6,13.33 6,10 C6,6.7 8.7,4 12,4 C15.33,4 18,6.7 18,10 C18,13.33 15.33,16 12,16 L12,16 Z M15,10 C15,11.665 13.665,13 12,13 C10.335,13 9,11.665 9,10 C9,8.335 10.335,7 12,7 C13.665,7 15,8.335 15,10 L15,10 Z" id="Shape"></path>
<path d="M31,15.0272045 L31,19 L34.9727791,19 L45.5668567,8.40587876 L41.5940776,4.4330833 L31,15.0272045 L31,15.0272045 Z M34.9727791,17.6757348 L32.3242597,17.6757348 L32.3242597,15.0272045 L33.6485194,15.0272045 L33.6485194,16.3514697 L34.9727791,16.3514697 L34.9727791,17.6757348 L34.9727791,17.6757348 Z M48.612654,5.36006891 L46.8911164,7.08161361 L42.9183373,3.10881814 L44.6398749,1.38727344 C44.8873057,1.13933381 45.2231988,1 45.573478,1 C45.9237573,1 46.2596503,1.13933381 46.5070811,1.38727344 L48.612654,3.49285504 C49.1291153,4.00931845 49.1291153,4.8436055 48.612654,5.36006891 L48.612654,5.36006891 Z" id="Shape"></path>
</g>
</g>
<g id="repos" transform="translate(0.000000, 98.000000)">
<g id="node" transform="translate(0.000000, 84.000000)">
<text id="whale/node" font-family="OpenSans-Semibold, Open Sans" font-size="16" font-weight="500" fill="#C0C9CE">
<tspan x="33" y="19">whale/node</tspan>
</text>
<path d="M27.5661032,5.88472594 C28.0144632,6.52363904 28.1153442,7.24661966 27.8687462,8.05366778 L23.245033,23.2867012 C23.0320619,24.0040773 22.6033176,24.6065612 21.9588,25.0941528 C21.3142824,25.5817443 20.6277311,25.8255401 19.8991459,25.8255401 L4.38028296,25.8255401 C3.51718982,25.8255401 2.68492144,25.5256993 1.88347781,24.9260177 C1.08203418,24.3263361 0.524386344,23.5893443 0.210534294,22.7150421 C-0.0584817485,21.964039 -0.0696907502,21.2522674 0.176907289,20.5797273 C0.176907289,20.5348913 0.193720792,20.3835698 0.227347797,20.1257627 C0.260974802,19.8679557 0.283392806,19.6605891 0.294601808,19.5036631 C0.30581081,19.4139911 0.288997307,19.2934943 0.2441613,19.1421728 C0.199325293,18.9908513 0.18251179,18.8815635 0.193720792,18.8143095 C0.216138795,18.6910105 0.260974802,18.573316 0.328228813,18.4612259 C0.395482824,18.3491359 0.487957089,18.2174302 0.605651607,18.0661086 C0.723346126,17.9147871 0.815820391,17.7830813 0.883074402,17.6709913 C1.14088144,17.2450492 1.39308398,16.7322374 1.63968202,16.1325558 C1.88628006,15.5328742 2.05441509,15.0200624 2.1440871,14.5941203 C2.17771411,14.4820303 2.18051636,14.3138953 2.15249385,14.0897152 C2.12447135,13.8655352 2.1216691,13.7086092 2.1440871,13.6189372 C2.17771411,13.4956382 2.27299062,13.3387121 2.42991665,13.1481591 C2.58684267,12.9576061 2.68211919,12.8287025 2.71574619,12.7614485 C2.95113523,12.3579245 3.18652427,11.8423104 3.42191331,11.2146063 C3.65730234,10.5869022 3.79741487,10.0824971 3.84225087,9.70139105 C3.85345988,9.60051003 3.83944862,9.421166 3.80021712,9.16335896 C3.76098561,8.90555192 3.76378786,8.7486259 3.80862387,8.69258089 C3.85345988,8.54686386 3.9767589,8.37592659 4.17852093,8.17976905 C4.38028296,7.98361152 4.50358198,7.85751025 4.54841799,7.80146524 C4.76138902,7.5100312 4.99958031,7.03645087 5.26299185,6.38072427 C5.52640339,5.72499766 5.68052717,5.18416333 5.72536317,4.75822126 C5.73657218,4.66854924 5.71975867,4.52563447 5.67492267,4.32947694 C5.63008666,4.13331941 5.61887766,3.98480014 5.64129566,3.88391912 C5.66371366,3.79424711 5.71415417,3.69336609 5.79261718,3.58127607 C5.8710802,3.46918605 5.97196121,3.34028253 6.09526023,3.19456551 C6.21855925,3.04884849 6.31383577,2.93115397 6.38108978,2.84148195 C6.47076179,2.70697393 6.56323606,2.53603665 6.65851257,2.32867012 C6.75378909,2.12130359 6.8378566,1.92514606 6.91071511,1.74019753 C6.98357362,1.555249 7.07324564,1.35348697 7.17973116,1.13491143 C7.28621667,0.916335896 7.39550444,0.736991868 7.50759446,0.596879345 C7.61968448,0.456766823 7.76820375,0.325061052 7.95315228,0.201762032 C8.13810081,0.0784630125 8.33986284,0.0140112522 8.55843838,0.00840675134 C8.77701391,0.00280225045 9.0432277,0.0336270054 9.35707975,0.100881016 L9.34026625,0.151321524 C9.76620832,0.050440508 10.0520379,0 10.1977549,0 L22.9928304,0 C23.8222966,0 24.4612097,0.31385205 24.9095697,0.94155615 C25.3579298,1.56926025 25.4588108,2.29784537 25.2122128,3.1273115 L20.605313,18.3603449 C20.201789,19.6942161 19.8010672,20.554507 19.4031476,20.9412176 C19.005228,21.3279282 18.2850497,21.5212834 17.2426125,21.5212834 L2.63167868,21.5212834 C2.32903563,21.5212834 2.1160646,21.6053509 1.99276558,21.773486 C1.86946656,21.95283 1.86386206,22.1938235 1.97595208,22.4964666 C2.24496812,23.2810967 3.05201625,23.6734118 4.39709646,23.6734118 L19.9159594,23.6734118 C20.2410205,23.6734118 20.5548725,23.586542 20.8575156,23.4128025 C21.1601586,23.239063 21.3563162,23.0064762 21.4459882,22.7150421 L26.490039,6.12011498 C26.568502,5.87351694 26.5965245,5.55406039 26.5741065,5.16174532 C27.0000486,5.32988035 27.3307141,5.57087389 27.5661032,5.88472594 L27.5661032,5.88472594 Z M9.6765363,5.91835294 C9.6317003,6.06406997 9.6429093,6.19017124 9.71016331,6.29665675 C9.77741732,6.40314227 9.88950734,6.45638503 10.0464334,6.45638503 L20.269043,6.45638503 C20.41476,6.45638503 20.5576748,6.40314227 20.6977873,6.29665675 C20.8378998,6.19017124 20.9303741,6.06406997 20.9752101,5.91835294 L21.3282937,4.84228877 C21.3731297,4.69657175 21.3619207,4.57047048 21.2946667,4.46398496 C21.2274126,4.35749944 21.1153226,4.30425669 20.9583966,4.30425669 L10.735787,4.30425669 C10.5900699,4.30425669 10.4471552,4.35749944 10.3070427,4.46398496 C10.1669301,4.57047048 10.0744559,4.69657175 10.0296199,4.84228877 L9.6765363,5.91835294 Z M8.28101558,10.2226096 C8.23617957,10.3683267 8.24738858,10.4944279 8.31464259,10.6009134 C8.3818966,10.707399 8.49398662,10.7606417 8.65091264,10.7606417 L18.8735223,10.7606417 C19.0192393,10.7606417 19.1621541,10.707399 19.3022666,10.6009134 C19.4423791,10.4944279 19.5348534,10.3683267 19.5796894,10.2226096 L19.9327729,9.14654546 C19.9776089,9.00082844 19.9663999,8.87472717 19.8991459,8.76824165 C19.8318919,8.66175613 19.7198019,8.60851337 19.5628759,8.60851337 L9.34026625,8.60851337 C9.19454923,8.60851337 9.05163445,8.66175613 8.91152193,8.76824165 C8.77140941,8.87472717 8.67893514,9.00082844 8.63409914,9.14654546 L8.28101558,10.2226096 Z" id="Shape" fill="#1AAAF8"></path>
</g>
<g id="java" transform="translate(0.000000, 42.000000)">
<text id="whale/java" font-family="OpenSans-Semibold, Open Sans" font-size="16" font-weight="500" fill="#C0C9CE">
<tspan x="33" y="19">whale/java</tspan>
</text>
<path d="M27.5661032,5.88472594 C28.0144632,6.52363904 28.1153442,7.24661966 27.8687462,8.05366778 L23.245033,23.2867012 C23.0320619,24.0040773 22.6033176,24.6065612 21.9588,25.0941528 C21.3142824,25.5817443 20.6277311,25.8255401 19.8991459,25.8255401 L4.38028296,25.8255401 C3.51718982,25.8255401 2.68492144,25.5256993 1.88347781,24.9260177 C1.08203418,24.3263361 0.524386344,23.5893443 0.210534294,22.7150421 C-0.0584817485,21.964039 -0.0696907502,21.2522674 0.176907289,20.5797273 C0.176907289,20.5348913 0.193720792,20.3835698 0.227347797,20.1257627 C0.260974802,19.8679557 0.283392806,19.6605891 0.294601808,19.5036631 C0.30581081,19.4139911 0.288997307,19.2934943 0.2441613,19.1421728 C0.199325293,18.9908513 0.18251179,18.8815635 0.193720792,18.8143095 C0.216138795,18.6910105 0.260974802,18.573316 0.328228813,18.4612259 C0.395482824,18.3491359 0.487957089,18.2174302 0.605651607,18.0661086 C0.723346126,17.9147871 0.815820391,17.7830813 0.883074402,17.6709913 C1.14088144,17.2450492 1.39308398,16.7322374 1.63968202,16.1325558 C1.88628006,15.5328742 2.05441509,15.0200624 2.1440871,14.5941203 C2.17771411,14.4820303 2.18051636,14.3138953 2.15249385,14.0897152 C2.12447135,13.8655352 2.1216691,13.7086092 2.1440871,13.6189372 C2.17771411,13.4956382 2.27299062,13.3387121 2.42991665,13.1481591 C2.58684267,12.9576061 2.68211919,12.8287025 2.71574619,12.7614485 C2.95113523,12.3579245 3.18652427,11.8423104 3.42191331,11.2146063 C3.65730234,10.5869022 3.79741487,10.0824971 3.84225087,9.70139105 C3.85345988,9.60051003 3.83944862,9.421166 3.80021712,9.16335896 C3.76098561,8.90555192 3.76378786,8.7486259 3.80862387,8.69258089 C3.85345988,8.54686386 3.9767589,8.37592659 4.17852093,8.17976905 C4.38028296,7.98361152 4.50358198,7.85751025 4.54841799,7.80146524 C4.76138902,7.5100312 4.99958031,7.03645087 5.26299185,6.38072427 C5.52640339,5.72499766 5.68052717,5.18416333 5.72536317,4.75822126 C5.73657218,4.66854924 5.71975867,4.52563447 5.67492267,4.32947694 C5.63008666,4.13331941 5.61887766,3.98480014 5.64129566,3.88391912 C5.66371366,3.79424711 5.71415417,3.69336609 5.79261718,3.58127607 C5.8710802,3.46918605 5.97196121,3.34028253 6.09526023,3.19456551 C6.21855925,3.04884849 6.31383577,2.93115397 6.38108978,2.84148195 C6.47076179,2.70697393 6.56323606,2.53603665 6.65851257,2.32867012 C6.75378909,2.12130359 6.8378566,1.92514606 6.91071511,1.74019753 C6.98357362,1.555249 7.07324564,1.35348697 7.17973116,1.13491143 C7.28621667,0.916335896 7.39550444,0.736991868 7.50759446,0.596879345 C7.61968448,0.456766823 7.76820375,0.325061052 7.95315228,0.201762032 C8.13810081,0.0784630125 8.33986284,0.0140112522 8.55843838,0.00840675134 C8.77701391,0.00280225045 9.0432277,0.0336270054 9.35707975,0.100881016 L9.34026625,0.151321524 C9.76620832,0.050440508 10.0520379,0 10.1977549,0 L22.9928304,0 C23.8222966,0 24.4612097,0.31385205 24.9095697,0.94155615 C25.3579298,1.56926025 25.4588108,2.29784537 25.2122128,3.1273115 L20.605313,18.3603449 C20.201789,19.6942161 19.8010672,20.554507 19.4031476,20.9412176 C19.005228,21.3279282 18.2850497,21.5212834 17.2426125,21.5212834 L2.63167868,21.5212834 C2.32903563,21.5212834 2.1160646,21.6053509 1.99276558,21.773486 C1.86946656,21.95283 1.86386206,22.1938235 1.97595208,22.4964666 C2.24496812,23.2810967 3.05201625,23.6734118 4.39709646,23.6734118 L19.9159594,23.6734118 C20.2410205,23.6734118 20.5548725,23.586542 20.8575156,23.4128025 C21.1601586,23.239063 21.3563162,23.0064762 21.4459882,22.7150421 L26.490039,6.12011498 C26.568502,5.87351694 26.5965245,5.55406039 26.5741065,5.16174532 C27.0000486,5.32988035 27.3307141,5.57087389 27.5661032,5.88472594 L27.5661032,5.88472594 Z M9.6765363,5.91835294 C9.6317003,6.06406997 9.6429093,6.19017124 9.71016331,6.29665675 C9.77741732,6.40314227 9.88950734,6.45638503 10.0464334,6.45638503 L20.269043,6.45638503 C20.41476,6.45638503 20.5576748,6.40314227 20.6977873,6.29665675 C20.8378998,6.19017124 20.9303741,6.06406997 20.9752101,5.91835294 L21.3282937,4.84228877 C21.3731297,4.69657175 21.3619207,4.57047048 21.2946667,4.46398496 C21.2274126,4.35749944 21.1153226,4.30425669 20.9583966,4.30425669 L10.735787,4.30425669 C10.5900699,4.30425669 10.4471552,4.35749944 10.3070427,4.46398496 C10.1669301,4.57047048 10.0744559,4.69657175 10.0296199,4.84228877 L9.6765363,5.91835294 Z M8.28101558,10.2226096 C8.23617957,10.3683267 8.24738858,10.4944279 8.31464259,10.6009134 C8.3818966,10.707399 8.49398662,10.7606417 8.65091264,10.7606417 L18.8735223,10.7606417 C19.0192393,10.7606417 19.1621541,10.707399 19.3022666,10.6009134 C19.4423791,10.4944279 19.5348534,10.3683267 19.5796894,10.2226096 L19.9327729,9.14654546 C19.9776089,9.00082844 19.9663999,8.87472717 19.8991459,8.76824165 C19.8318919,8.66175613 19.7198019,8.60851337 19.5628759,8.60851337 L9.34026625,8.60851337 C9.19454923,8.60851337 9.05163445,8.66175613 8.91152193,8.76824165 C8.77140941,8.87472717 8.67893514,9.00082844 8.63409914,9.14654546 L8.28101558,10.2226096 Z" id="Shape" fill="#1AAAF8"></path>
</g>
<g id="golang">
<text id="whale/golang" font-family="OpenSans-Semibold, Open Sans" font-size="16" font-weight="500" fill="#C0C9CE">
<tspan x="33" y="19">whale/golang</tspan>
</text>
<path d="M27.5661032,5.88472594 C28.0144632,6.52363904 28.1153442,7.24661966 27.8687462,8.05366778 L23.245033,23.2867012 C23.0320619,24.0040773 22.6033176,24.6065612 21.9588,25.0941528 C21.3142824,25.5817443 20.6277311,25.8255401 19.8991459,25.8255401 L4.38028296,25.8255401 C3.51718982,25.8255401 2.68492144,25.5256993 1.88347781,24.9260177 C1.08203418,24.3263361 0.524386344,23.5893443 0.210534294,22.7150421 C-0.0584817485,21.964039 -0.0696907502,21.2522674 0.176907289,20.5797273 C0.176907289,20.5348913 0.193720792,20.3835698 0.227347797,20.1257627 C0.260974802,19.8679557 0.283392806,19.6605891 0.294601808,19.5036631 C0.30581081,19.4139911 0.288997307,19.2934943 0.2441613,19.1421728 C0.199325293,18.9908513 0.18251179,18.8815635 0.193720792,18.8143095 C0.216138795,18.6910105 0.260974802,18.573316 0.328228813,18.4612259 C0.395482824,18.3491359 0.487957089,18.2174302 0.605651607,18.0661086 C0.723346126,17.9147871 0.815820391,17.7830813 0.883074402,17.6709913 C1.14088144,17.2450492 1.39308398,16.7322374 1.63968202,16.1325558 C1.88628006,15.5328742 2.05441509,15.0200624 2.1440871,14.5941203 C2.17771411,14.4820303 2.18051636,14.3138953 2.15249385,14.0897152 C2.12447135,13.8655352 2.1216691,13.7086092 2.1440871,13.6189372 C2.17771411,13.4956382 2.27299062,13.3387121 2.42991665,13.1481591 C2.58684267,12.9576061 2.68211919,12.8287025 2.71574619,12.7614485 C2.95113523,12.3579245 3.18652427,11.8423104 3.42191331,11.2146063 C3.65730234,10.5869022 3.79741487,10.0824971 3.84225087,9.70139105 C3.85345988,9.60051003 3.83944862,9.421166 3.80021712,9.16335896 C3.76098561,8.90555192 3.76378786,8.7486259 3.80862387,8.69258089 C3.85345988,8.54686386 3.9767589,8.37592659 4.17852093,8.17976905 C4.38028296,7.98361152 4.50358198,7.85751025 4.54841799,7.80146524 C4.76138902,7.5100312 4.99958031,7.03645087 5.26299185,6.38072427 C5.52640339,5.72499766 5.68052717,5.18416333 5.72536317,4.75822126 C5.73657218,4.66854924 5.71975867,4.52563447 5.67492267,4.32947694 C5.63008666,4.13331941 5.61887766,3.98480014 5.64129566,3.88391912 C5.66371366,3.79424711 5.71415417,3.69336609 5.79261718,3.58127607 C5.8710802,3.46918605 5.97196121,3.34028253 6.09526023,3.19456551 C6.21855925,3.04884849 6.31383577,2.93115397 6.38108978,2.84148195 C6.47076179,2.70697393 6.56323606,2.53603665 6.65851257,2.32867012 C6.75378909,2.12130359 6.8378566,1.92514606 6.91071511,1.74019753 C6.98357362,1.555249 7.07324564,1.35348697 7.17973116,1.13491143 C7.28621667,0.916335896 7.39550444,0.736991868 7.50759446,0.596879345 C7.61968448,0.456766823 7.76820375,0.325061052 7.95315228,0.201762032 C8.13810081,0.0784630125 8.33986284,0.0140112522 8.55843838,0.00840675134 C8.77701391,0.00280225045 9.0432277,0.0336270054 9.35707975,0.100881016 L9.34026625,0.151321524 C9.76620832,0.050440508 10.0520379,0 10.1977549,0 L22.9928304,0 C23.8222966,0 24.4612097,0.31385205 24.9095697,0.94155615 C25.3579298,1.56926025 25.4588108,2.29784537 25.2122128,3.1273115 L20.605313,18.3603449 C20.201789,19.6942161 19.8010672,20.554507 19.4031476,20.9412176 C19.005228,21.3279282 18.2850497,21.5212834 17.2426125,21.5212834 L2.63167868,21.5212834 C2.32903563,21.5212834 2.1160646,21.6053509 1.99276558,21.773486 C1.86946656,21.95283 1.86386206,22.1938235 1.97595208,22.4964666 C2.24496812,23.2810967 3.05201625,23.6734118 4.39709646,23.6734118 L19.9159594,23.6734118 C20.2410205,23.6734118 20.5548725,23.586542 20.8575156,23.4128025 C21.1601586,23.239063 21.3563162,23.0064762 21.4459882,22.7150421 L26.490039,6.12011498 C26.568502,5.87351694 26.5965245,5.55406039 26.5741065,5.16174532 C27.0000486,5.32988035 27.3307141,5.57087389 27.5661032,5.88472594 L27.5661032,5.88472594 Z M9.6765363,5.91835294 C9.6317003,6.06406997 9.6429093,6.19017124 9.71016331,6.29665675 C9.77741732,6.40314227 9.88950734,6.45638503 10.0464334,6.45638503 L20.269043,6.45638503 C20.41476,6.45638503 20.5576748,6.40314227 20.6977873,6.29665675 C20.8378998,6.19017124 20.9303741,6.06406997 20.9752101,5.91835294 L21.3282937,4.84228877 C21.3731297,4.69657175 21.3619207,4.57047048 21.2946667,4.46398496 C21.2274126,4.35749944 21.1153226,4.30425669 20.9583966,4.30425669 L10.735787,4.30425669 C10.5900699,4.30425669 10.4471552,4.35749944 10.3070427,4.46398496 C10.1669301,4.57047048 10.0744559,4.69657175 10.0296199,4.84228877 L9.6765363,5.91835294 Z M8.28101558,10.2226096 C8.23617957,10.3683267 8.24738858,10.4944279 8.31464259,10.6009134 C8.3818966,10.707399 8.49398662,10.7606417 8.65091264,10.7606417 L18.8735223,10.7606417 C19.0192393,10.7606417 19.1621541,10.707399 19.3022666,10.6009134 C19.4423791,10.4944279 19.5348534,10.3683267 19.5796894,10.2226096 L19.9327729,9.14654546 C19.9776089,9.00082844 19.9663999,8.87472717 19.8991459,8.76824165 C19.8318919,8.66175613 19.7198019,8.60851337 19.5628759,8.60851337 L9.34026625,8.60851337 C9.19454923,8.60851337 9.05163445,8.66175613 8.91152193,8.76824165 C8.77140941,8.87472717 8.67893514,9.00082844 8.63409914,9.14654546 L8.28101558,10.2226096 Z" id="Shape" fill="#1AAAF8"></path>
</g>
</g>
</g>
<text id="Whale-organization" font-family="OpenSans-Semibold, Open Sans" font-size="16" font-weight="500" fill="#C0C9CE">
<tspan x="270" y="19">Whale organization</tspan>
</text>
<use id="border" stroke="#C0C9CE" mask="url(#mask-2)" stroke-width="2" xlink:href="#path-1"></use>
</g>
</g>
</svg>

Before

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 112 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 71 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 67 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 67 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 71 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 67 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 33 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.5 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 72 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 102 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 72 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 62 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

View File

@ -1,38 +0,0 @@
---
description: Learn how to install, configure, and use Docker Trusted Registry.
keywords: docker, registry, repository, images
title: Docker Trusted Registry overview
---
Docker Trusted Registry (DTR) is the enterprise-grade image storage solution
from Docker. You install it behind your firewall so that you can securely store
and manage the Docker images you use in your applications.
## Image management
Docker Trusted Registry can be installed on-premises, or on a virtual private
cloud. And with it, you can store your Docker images securely, behind your
firewall.
![](images/overview-1.png)
You can use DTR as part of your continuous integration, and continuous
delivery processes to build, run, and ship your applications.
## Built-in security and access control
DTR uses the same authentication mechanism as Docker Universal Control Plane.
It has a built-in authentication mechanism, and also integrates with LDAP
and Active Directory. It also supports Role Based Access Control (RBAC).
This allows you to implement fine-grain access control policies, on who has
access to your Docker images.
![](images/overview-2.png)
## Where to go next
* [DTR architecture](architecture.md)
* [Install DTR](install/index.md)

View File

@ -1,162 +0,0 @@
---
description: Learn how to install Docker Trusted Registry for production.
keywords: docker, dtr, registry, install
redirect_from:
- /docker-trusted-registry/install/dtr-ami-byol-launch/
- /docker-trusted-registry/install/dtr-ami-bds-launch/
- /docker-trusted-registry/install/dtr-vhd-azure/
- /docker-trusted-registry/install/install-dtr/
- /docker-trusted-registry/install/
title: Install Docker Trusted Registry
---
Docker Trusted Registry (DTR) is a containerized application that runs on a
Docker Universal Control Plane (UCP) cluster. It can be installed on-premises
or on a cloud infrastructure.
Use these instructions to install DTR.
## Step 1. Validate the system requirements
The first step in installing DTR, is ensuring your
infrastructure has all the [requirements DTR needs to run](system-requirements.md).
## Step 2. Install UCP
Since DTR requires a Docker Universal Control Plane (UCP) cluster
to run, you need to install UCP first.
[Learn how to install UCP](/datacenter/ucp/1.1/installation/install-production.md). Make sure that the node you install DTR on is already joined to the UCP cluster.
## Step 3. Install DTR
To install DTR you use the `docker/dtr` image. This image has commands to
install, configure, and backup DTR.
To install DTR:
1. Download a UCP client bundle.
Having a UCP client bundle allows you to run Docker commands on a UCP
cluster.
[Download a UCP client bundle](/datacenter/ucp/1.1/access-ucp/cli-based-access.md)
and set up your CLI client to use it.
2. Run the following command to install DTR.
```bash
# Get the certificates used by UCP
$ curl -k https://$UCP_HOST/ca > ucp-ca.pem
# Install DTR
$ docker run -it --rm \
docker/dtr install \
--ucp-url $UCP_URL \
--ucp-node $NODE_HOSTNAME \
--dtr-external-url $DTR_PUBLIC_IP \
--ucp-username $USER --ucp-password $PASSWORD \
--ucp-ca "$(cat ucp-ca.pem)"
```
Where:
* ucp-url, is the URL of the UCP controller,
* ucp-node, is the hostname of the UCP node where DTR will be installed,
* dtr-external-url, is the public IP or domain name where DTR can be reached,
* ucp-username, and ucp-password are the credentials of a UCP administrator,
* ucp-ca, is the certificate authority used by UCP.
3. Check that DTR is running.
In your browser, navigate to the Docker **Universal Control Plane**
web UI, and navigate to the **Applications** screen. DTR should be listed
as an application.
![](../images/install-dtr-1.png)
You can also access the **DTR web UI**, to make sure it is working. In your
browser, navigate to the address where you installed DTR.
![](../images/install-dtr-2.png)
## Step 4. Configure DTR
After installing DTR, you should configure:
* The Domain Name used to access DTR,
* The certificates used for TLS communication,
* The storage backend to store the Docker images.
To perform these configurations, navigate to the **Settings** page of DTR.
![](../images/install-dtr-3.png)
## Step 5. Test pushing and pulling
Now that you have a working installation of DTR, you should test that you can
push and pull images to it.
[Learn how to push and pull images](../repos-and-images/index.md).
## Step 6. Join replicas to the cluster
This step is optional.
To set up DTR for [high availability](../high-availability/index.md), you can
add more replicas to your DTR cluster. Adding more replicas allows you to
load-balance requests across all replicas, and keep DTR working if a replica
fails. Each replica must be located on a node already joined to the UCP cluster.
To add replicas to a DTR cluster, use the `docker/dtr join` command. To add
replicas:
1. Load you UCP user bundle.
2. Run the join command.
When you join a replica to a DTR cluster, you need to specify the
ID of a replica that is already part of the cluster. You can find an
existing replica ID by going to the **Applications** page on UCP.
Then run:
```bash
# Get the certificates used by UCP
$ curl -k https://$UCP_HOST/ca > ucp-ca.pem
$ docker run -it --rm \
docker/dtr join \
--ucp-url $UCP_URL \
--ucp-node $UCP_NODE \
--existing-replica-id $REPLICA_TO_JOIN \
--ucp-username $USER --ucp-password $PASSWORD \
--ucp-ca "$(cat ucp-ca.pem)"
```
Where:
* ucp-url, is the URL of the UCP controller,
* ucp-node, is the node on the ucp cluster where the DTR replica will be installed,
* existing-replica-id, is the ID of the DTR replica you want to replicate,
* ucp-username, and ucp-password are the credentials of a UCP administrator,
* ucp-ca, is the certificate used by UCP.
3. Check that all replicas are running.
In your browser, navigate to the Docker **Universal Control Plane**
web UI, and navigate to the **Applications** screen. All replicas should
be displayed.
![](../images/install-dtr-4.png)
4. Follow steps 1 to 3, to add more replicas to the DTR cluster.
When configuring your DTR cluster for high-availability, you should install
3, 5, or 7 replicas.
[Learn more about high availability](../high-availability/index.md)
## See also
* [Install DTR offline](install-dtr-offline.md)
* [Upgrade DTR](upgrade/upgrade-major.md)

View File

@ -1,62 +0,0 @@
---
description: Learn how to install Docker Trusted Registry on a machine with no internet
access.
keywords: docker, registry, install, offline
redirect_from:
- /docker-trusted-registry/install/install-dtr-offline/
title: Install Docker Trusted Registry offline
---
The procedure to install Docker Trusted Registry on a host is the same,
whether that host has access to the internet or not.
The only difference when installing on an offline host,
is that instead of pulling the UCP images from Docker Hub, you use a
computer that is connected to the internet to download a single package with
all the images. Then you copy that package to the host where youll install DTR.
## Versions available
{% include components/ddc_url_list.html %}
## Download the offline package
Use a computer with internet access to download a single package with all
Docker Datacenter components:
```bash
$ wget <package-url> -O docker-datacenter.tar.gz
```
Now that you have the package in your local machine, you can transfer it to
the machines where you want to install DTR.
For each machine where you want to install DTR:
1. Copy the Docker Datacenter package to that machine.
```bash
$ scp docker-datacenter.tar.gz <user>@<host>:/tmp
```
2. Use ssh to login into the hosts where you transferred the package.
3. Load the Docker Datacenter images.
Once the package is transferred to the hosts, you can use the
`docker load` command, to load the Docker images from the tar archive:
```bash
$ docker load < docker-datacenter.tar.gz
```
## Install DTR
Now that the offline hosts have all the images needed to install DTR,
you can [install DTR on that host](index.md).
## Where to go next
* [DTR architecture](../architecture.md)
* [Install DTR](index.md)

View File

@ -1,43 +0,0 @@
---
description: Learn how to license your Docker Trusted Registry installation.
keywords: docker, dtr, install, license
redirect_from:
- /docker-trusted-registry/license/
- /docker-trusted-registry/install/license
title: License Docker Trusted Registry
---
By default, you don't need to license your Docker Trusted Registry. When
installing DTR, it automatically starts using the same license file used on
your Docker Universal Control Plane cluster.
However, there are some situations when you need to manually license your
DTR installation:
* When upgrading to a new major version,
* When your current license expires.
## Download your license
Go to [Docker Hub](https://hub.docker.com/bundles/docker-datacenter) and
download your license.
![](../images/license-1.png)
## License your installation
Once you've downloaded the license file, you can apply it to your DTR
installation. Navigate to the **DTR web UI**, and then go to the **Settings
page**.
![](../images/license-2.png)
Click the **Apply new license** button, and upload your new license file.
## Where to go next
* [Install DTR](index.md)
* [Install DTR offline](install-dtr-offline.md)

View File

@ -1,48 +0,0 @@
---
description: Learn about the system requirements for installing Docker Trusted Registry.
keywords: docker, DTR, architecture, requirements
redirect_from:
- /docker-trusted-registry/install/system-requirements/
title: Docker Trusted Registry system requirements
---
Docker Trusted Registry can be installed on-premises or on the cloud.
Before installing, be sure your infrastructure has these requirements.
## Software requirements
To install DTR on a node, that node must be part of a Docker Universal
Control Plane 1.1 cluster.
## Ports used
When installing DTR on a node, make sure the following ports are open on that
node:
| Direction | Port | Purpose |
|:---------:|:-----|:---------------------------------------------------------------------------------|
| in | 80 | Web app and API client access to DTR. |
| 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, dont identify your company, users, applications,
or any other sensitive information. You can disable this on the DTR settings
page.
## Compatibility and maintenance lifecycle
Docker Datacenter is a software subscription that includes 3 products:
* CS Docker Engine,
* Docker Trusted Registry,
* Docker Universal Control Plane.
[Learn more about the maintenance lifecycle for these products](https://success.docker.com/article/Compatibility_Matrix).
## Where to go next
* [DTR architecture](../architecture.md)
* [Install DTR](index.md)

View File

@ -1,62 +0,0 @@
---
description: Learn how to uninstall your Docker Trusted Registry installation.
keywords: docker, dtr, install, uninstall
redirect_from:
- /docker-trusted-registry/install/uninstall/
title: Uninstall Docker Trusted Registry
---
Use the `docker/dtr remove` command, to remove a DTR replica from a cluster.
To uninstall a DTR cluster you remove all DTR replicas one at a time.
The remove command:
* Removes the replica from the cluster,
* Stops and removes all DTR containers,
* Deletes all DTR volumes.
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 remove --help
```
To remove a replica safely, you must tell the bootstrapper about one healthy
replica using the `--existing-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
remove a DTR replica from a cluster with multiple replicas:
```bash
# Get the certificates used by UCP
$ curl https://$UCP_HOST/ca > ucp-ca.pem
$ 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
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 healthy DTR replica of that cluster,
* replica-id: is the id of the DTR replica you want to remove,
* 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
`a701a510126c` no longer exists.
## Where to go next
* [Install DTR](index.md)
* [Install DTR offline](install-dtr-offline.md)

View File

@ -1,69 +0,0 @@
---
description: Learn how to upgrade your Docker Trusted Registry to a new minor version or patch release.
keywords: docker, dtr, upgrade, install
redirect_from:
- /docker-trusted-registry/install/upgrade/upgrade-minor/
title: Upgrade from 2.0.0
---
The first step in upgrading to a new minor version or patch release of DTR 2.0,
is ensuring you're running DTR 2.0. If that's not the case, start by upgrading
your installation to version 2.0.0, and then upgrade to the latest version
available.
There is no downtime when upgrading a highly-available DTR cluster. If your
DTR deployment has a single replica, schedule the upgrade to take place outside
business peak hours to ensure the impact on your business is close to none.
## Step 1. Upgrade DTR to 2.0
Make sure you're running DTR 2.0. If that's not the case,
[upgrade your installation to the 2.0 version](upgrade-major.md).
## Step 2. Upgrade DTR
To upgrade DTR you use the `docker/dtr upgrade` command.
1. Download a UCP client bundle.
Having a UCP client bundle allows you to run Docker commands on a UCP
cluster. Download a UCP client bundle and set up your CLI client to use it.
2. Find the DTR replica Id.
When you upgrade your installation, you need to specify the Id of a replica
that is part of the cluster. If you have a highly-available installation,
you can provide the Id of any replica.
You can find the DTR replica Ids on the **Applications** page of Docker
Universal Control Plane.
3. Pull the latest docker/dtr image.
```bash
$ docker pull docker/dtr
```
4. Run the upgrade command.
The upgrade command upgrades all DTR replicas that are part of your cluster:
```bash
# Get the certificates used by UCP
$ curl -k https://$UCP_URL/ca > ucp-ca.pem
$ docker run \
-it \
--rm \
docker/dtr upgrade \
--ucp-url $UCP_URL \
--existing-replica-id $DTR_REPLICA_ID \
--ucp-username $USER \
--ucp-password $PASSWORD \
--ucp-ca "$(cat ucp-ca.pem)"
```
## Where to go next
* [Upgrade to DTR 2.0](upgrade-major.md)
* [Monitor DTR](../../monitor-troubleshoot/index.md)

View File

@ -1,207 +0,0 @@
---
description: Learn how to upgrade your Docker Trusted Registry to the latest major release.
keywords: docker, dtr, upgrade, install
redirect_from:
- /docker-trusted-registry/install/upgrade/
- /docker-trusted-registry/upgrade/upgrade-major/
title: Upgrade from 1.4.3
---
The first step in upgrading to Docker Trusted Registry (DTR) 2.0, is ensuring
you are running DTR 1.4.3. If that's not the case, start by upgrading your
installation to version 1.4.3, and then upgrade to DTR 2.0.
To upgrade from DTR 1.4.3 to 2.0 you first need to do a fresh installation of
DTR 2.0. Then you migrate the data from your DTR 1.4.3 installation to the 2.0
installation. Finally, you decommission your 1.4.3 by uninstalling it.
## Step 1. Upgrade DTR to 1.4.3
Make sure you're running DTR 1.4.3. If that's not the case, upgrade your
installation to the 1.4.3 version.
## Step 2. Install DTR 2.0
To upgrade to DTR 2.0, you first need to do a fresh installation of DTR 2.0.
This can be done on the same node where DTR 1.4.3 is already running or on a
new node.
If you decide to install the new DTR on the same node, you need
to install it on a port other than 443, since DTR 1.4.3 is already using it.
Use these instructions to install DTR 2.0:
* [Release notes](../../release-notes/index.md)
* [System requirements](../system-requirements.md)
* [DTR architecture](../../architecture.md)
* [Install DTR 2.0](../index.md)
## Step 3. Migrate metadata
Once you have your DTR 1.4.3 and the new DTR 2.0 running, you can migrate
configurations, accounts, and repository metadata from one installation to
another.
For this, you can use the `docker/dtr migrate` command. This command
migrates configurations, accounts, and repository metadata. It doesn't migrate
the images that are on the storage backend used by DTR 1.4.3.
Before running the migration, get the DTR 2.0 CA certificate used for the `--dtr-ca` parameter:
1. Log into the **DTR 2.0 web UI**, and navigate to the **Settings** screen.
2. In the **Domain** section, click the **Show TLS settings** link.
3. Copy the content of the **TLS CA** field.
![](../../images/dtr-integration-1.png)
To start the migration:
1. Log into the host running DTR 1.4.3 using ssh.
2. Use the docker/dtr migrate command.
When you run the docker/dtr migrate command, Docker pulls the necessary
images from Docker Hub. If the host where DTR 1.4.3 is not connected
to the internet, you need to
[download the images to the host](../install-dtr-offline.md).
Then run the migrate command:
```bash
# Get the certificates used by UCP
$ curl https://$UCP_HOST/ca > ucpca.crt
# Migrate configurations, accounts, and repository metadata
docker run -it --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/dtr migrate \
--ucp-url $UCP_HOST --ucp-ca "$(cat ucpca.crt)" \
--dtr-external-url $DTR_HOST \
--dtr-ca "$(cat dtrca.crt)"
```
## Step 4. Validate your configurations
After the migration finishes, test your DTR 2.0 installation to make sure it is
properly configured.
In your browser navigate to the DTR 2.0 **Settings page**, and check that DTR:
* Is correctly licensed,
* The storage backend is correctly configured,
* The user authentication method is correctly configured.
You need to manually configure the following settings:
* Domain name,
* Certificates.
You can find the certificates of DTR 1.4.3 under `/usr/local/etc/dtr/ssl`.
## Step 5. Transfer image data to DTR 2.0
If utilizing local filesystem storage, the image data is not copied during by
the migrate command and should be transferred manually.
To transfer the images:
1. Log into the host running DTR 2.0 using ssh.
2. Get the filesystem volume path DTR 2.0 stores images:
```bash{% raw %}
$ docker volume inspect --format '{{ .Mountpoint }}' $(docker volume ls -q | grep dtr-registry)
{% endraw %}```
The path returned will be similar to: `/var/lib/docker/volumes/dtr-registry-fa61225dc006/_data`
3. Log into the host running DTR 1.4.3 using ssh.
4. Copy the image data:
```bash
$ scp -r /var/local/dtr/image-storage/local/* $DTR_HOST:$DTR_2_FS_VOLUME_PATH
```
For example:
```bash
$ scp -r /var/local/dtr/image-storage/local/* \
dtr2:/var/lib/docker/volumes/dtr-registry-4fb637dbbecc/_data/
```
## Step 6. Test your installation
Now that you have a working installation of DTR 2.0, you should test that you
can push and pull images to it.
[Learn how to push and pull images](../../repos-and-images/pull-an-image.md).
## Step 7. Join replicas to your cluster
This step is optional.
To set up DTR for [high availability](../../high-availability/index.md),
you can add more replicas to your DTR cluster. Adding more replicas allows you
to load-balance requests across all replicas, and keep DTR working if a
replica fails.
To add replicas to a DTR cluster, use the `docker/dtr join` command. To add
replicas:
1. Load you UCP user bundle.
2. Run the join command.
When you join a replica to a DTR cluster, you need to specify the
ID of a replica that is already part of the cluster. You can find an
existing replica ID by going to the **Applications** page on UCP.
Then run:
```bash
# Get the certificates used by UCP
$ curl -k https://$UCP_HOST/ca > ucp-ca.pem
$ docker run -it --rm \
docker/dtr join \
--ucp-url $UCP_URL \
--ucp-node $UCP_NODE \
--existing-replica-id $REPLICA_TO_JOIN \
--ucp-username $USER --ucp-password $PASSWORD \
--ucp-ca "$(cat ucp-ca.pem)"
```
Where:
* ucp-url, is the URL of the UCP controller,
* ucp-node, is the node on the ucp cluster where the DTR replica will be installed,
* existing-replica-id, is the ID of the DTR replica you want to replicate,
* ucp-username, and ucp-password are the credentials of a UCP administrator,
* ucp-ca, is the certificate used by UCP.
3. Check that all replicas are running.
In your browser, navigate to the Docker **Universal Control Plane**
web UI, and navigate to the **Applications** screen. All replicas should
be displayed.
![](../../images/install-dtr-4.png)
4. Follow steps 1 to 3, to add more replicas to the DTR cluster.
When configuring your DTR cluster for high-availability, you should install
3, 5, or 7 replicas.
[Learn more about high availability](../../high-availability/index.md)
## Step 8. Decommission DTR 1.4.3
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
* [Upgrade to DTR 2.x](index.md)
* [Monitor DTR](../../monitor-troubleshoot/index.md)

View File

@ -1,33 +0,0 @@
---
description: Learn how to monitor your DTR installation.
keywords: docker, registry, monitor, troubleshoot
redirect_from:
- /docker-trusted-registry/monitor-troubleshoot/monitor/
title: Monitor Docker Trusted Registry
---
Docker Trusted Registry is a Dockerized application. To monitor it, you can
use the same tools and techniques you're already using to monitor other
containerized applications running on your cluster. One way to monitor
DTR is using the monitoring capabilities of Docker Universal Control Plane.
In your browser, log in to **Docker Universal Control Plane** (UCP), and
navigate to the **Applications** page.
To make it easier to find DTR, use the search box to **search for the
DTR application**. If you have DTR set up for high-availability, then all the
DTR nodes are displayed.
![](../images/monitor-1.png)
**Click on the DTR application** to see all of its containers, and if they're
running. **Click on a container** to see its details, like configurations,
resources, and logs.
![](../images/monitor-2.png)
## Where to go next
* [Troubleshoot DTR](troubleshoot.md)
* [DTR architecture](../architecture.md)

View File

@ -1,68 +0,0 @@
---
description: Learn how to troubleshoot your DTR installation.
keywords: docker, registry, monitor, troubleshoot
redirect_from:
- /docker-trusted-registry/adminguide/
- /docker-trusted-registry/monitor/troubleshoot
title: Troubleshoot Docker Trusted Registry
---
## Overlay networking
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 -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
```
You can create new overlay network for this test with `docker network create
-d overlay network-name`. You can also use any images that contain `sh` and
`ping` for this test.
If the second command succeeds, overlay networking is working.
## DTR doesn't come up after a Docker restart
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
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.
```
2016-04-27 17:56:34.086748 W | rafthttp: the clock difference against peer aa4fdaf4c562342d is too high [8.484795885s > 1s]
```
## Accessing the RethinkDB Admin UI
> Warning: This command will expose your database to the internet with no authentication. Use with caution.
Run this on the UCP node that has a DTR replica with the given replica id:
```
docker run --rm -it --net dtr-br -p 9999:8080 svendowideit/ambassador dtr-rethinkdb-$REPLICA_ID 8080
```
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
## 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
```

View File

@ -1,44 +0,0 @@
---
description: Docker Trusted Registry backup command reference.
keywords: docker, registry, reference, backup
title: docker/dtr backup
---
Backup a DTR cluster to a tar file and stream it to stdout
## Usage
```bash
docker run -i --rm docker/dtr \
backup [command options] > backup.tar
```
## Description
This command creates a backup of configurations and image metadata, in a tar
file. It can be used to make periodic backups of a DTR installation.
This command only creates backups of configurations, and image metadata.
It does not backup the Docker images stored in your registry.
You should implement a separate backup policy for the Docker images stored
in your registry, taking in consideration whether your DTR installation is
configured to store images on the filesystem or using a cloud provider.
WARNING: This backup contains sensitive information and should be
stored securely.
## Options
| Option | Description |
|:------------------------|:-------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--existing-replica-id` | ID of an existing replica in a cluster |
| `--config-only` | Backup/restore only the configurations of DTR and not the database |

View File

@ -1,34 +0,0 @@
---
description: Docker Trusted Registry dumpcerts command reference.
keywords: docker, registry, reference, dumpcerts
title: docker/dtr dumpcerts
---
Dump out the TLS certificates used by this DTR instance
## Usage
```bash
docker run -i --rm docker/dtr \
dumpcerts [command options] > backup.tar
```
## Description
This command creates a backup of the certificates used by DTR for
communicating across replicas with TLS.
## Options
| Option | Description |
|:------------------------|:---------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--existing-replica-id` | ID of an existing replica in a cluster |

View File

@ -1,18 +0,0 @@
---
description: Docker Trusted Registry images command reference.
keywords: docker, registry, reference, images
title: docker/dtr images
---
Lists all the images necessary to install DTR
## Usage
```bash
docker run -it --rm docker/dtr \
images [command options]
```
## Description
This command lists all the images necessary to install DTR.

View File

@ -1,36 +0,0 @@
---
description: Learn about the options available on the docker/dtr image.
keywords: docker, dtr, install, uninstall, configure
title: docker/dtr overview
---
This tool has commands to install, configure, and backup Docker
Trusted Registry (DTR). It also allows uninstalling DTR.
By default the tool runs in interactive mode. It prompts you for
the values needed.
Additional help is available for each command with the '--help' option.
## Usage
```bash
docker run -it --rm docker/dtr \
command [command options]
```
## Commands
| Option | Description |
|:--------------|:--------------------------------------------------------------------------------|
| `install` | Install Docker Trusted Registry on this Docker Engine |
| `join` | Add a new replica to an existing DTR cluster |
| `reconfigure` | Change DTR configurations |
| `remove` | Remove a replica from a DTR cluster |
| `restore` | Create a new DTR cluster from an existing backup |
| `backup` | Backup a DTR cluster to a tar file and stream it to stdout |
| `migrate` | Migrate configurations, accounts, and repository metadata from DTR 1.4.3 to 2.0 |
| `upgrade` | Upgrade a v2.0.0 or later cluster to this version of DTR |
| `dumpcerts` | Dump out the TLS certificates used by this DTR instance |
| `images` | Lists all the images necessary to install DTR |

View File

@ -1,49 +0,0 @@
---
description: Docker Trusted Registry install command reference.
keywords: docker, registry, reference, install
title: docker/dtr install
---
Install Docker Trusted Registry on this Docker Engine
## Usage
```bash
docker run -it --rm docker/dtr \
install [command options]
```
## Description
This command installs DTR on the Docker Engine that runs the command.
After installing DTR, you can add more nodes to a DTR cluster with
the 'join' command.
## Options
| Option | Description |
|:----------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--http-proxy` | Set the HTTP proxy for outgoing requests |
| `--https-proxy` | Set the HTTPS proxy for outgoing requests |
| `--no-proxy` | Set the list of domains to not proxy to |
| `--replica-http-port` | Specify the public HTTP port for the DTR replica; 0 means unchanged/default |
| `--replica-https-port` | Specify the public HTTPS port for the DTR replica; 0 means unchanged/default |
| `--log-protocol` | The protocol for sending container logs: tcp, udp or internal. Default: internal |
| `--log-host` | Endpoint to send logs to, required if --log-protocol is tcp or udp |
| `--log-level` | Log level for container logs. Default: INFO |
| `--dtr-external-url` | Specify the external domain name and port for DTR. If using a load balancer, use its external URL instead. |
| `--etcd-heartbeat-interval` | Set etcd's frequency (ms) that its leader will notify followers that it is still the leader. |
| `--etcd-election-timeout` | Set etcd's timeout (ms) for how long a follower node will go without hearing a heartbeat before attempting to become leader itself. |
| `--etcd-snapshot-count` | Set etcd's number of changes before creating a snapshot. |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--ucp-node` | Specify the host to install Docker Trusted Registry |
| `--replica-id` | Specify the replica ID. Must be unique per replica, leave blank for random |
| `--unsafe` | Enable this flag to skip safety checks when installing or joining |
| `--extra-envs` | List of extra environment variables to use for deploying the DTR containers for the replica. This can be used to specify swarm constraints. Separate the environment variables with ampersands (&). You can escape actual ampersands with backslashes (\). Can't be used in combination with --ucp-node |

View File

@ -1,44 +0,0 @@
---
description: Docker Trusted Registry join command reference.
keywords: docker, registry, reference, join
title: docker/dtr join
---
Add a new replica to an existing DTR cluster
## Usage
```bash
$ docker run -it --rm docker/dtr \
join [command options]
```
## Description
This command installs DTR on the Docker Engine that runs the command,
and joins the new installation to an existing cluster.
To set up a cluster with high-availability, add 3, 5, or 7 nodes to
the cluster.
## Options
| Option | Description |
|:------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--ucp-node` | Specify the host to install Docker Trusted Registry |
| `--replica-id` | Specify the replica ID. Must be unique per replica, leave blank for random |
| `--unsafe` | Enable this flag to skip safety checks when installing or joining |
| `--existing-replica-id` | ID of an existing replica in a cluster |
| `--replica-http-port` | Specify the public HTTP port for the DTR replica; 0 means unchanged/default |
| `--replica-https-port` | Specify the public HTTPS port for the DTR replica; 0 means unchanged/default |
| `--skip-network-test` | Enable this flag to skip the overlay networking test |
| `--extra-envs` | List of extra environment variables to use for deploying the DTR containers for the replica. This can be used to specify swarm constraints. Separate the environment variables with ampersands (&). You can escape actual ampersands with backslashes (\). Can't be used in combination with --ucp-node |

View File

@ -1,45 +0,0 @@
---
description: Learn about the options available on the docker/dtr image.
keywords: docker, dtr, install, uninstall, configure
title: docker/dtr migrate
---
Migrate configurations, accounts, and repository metadata from DTR 1.4.3 to 2.0
## Usage
```bash
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker/dtr \
migrate [command options]
```
## Description
This command migrates configurations, accounts, and repository metadata from
Docker Trusted Registry 1.4.3 to 2.0.
To upgrade from DTR 1.4.3 to 2.0 you first need to do a fresh installation of
DTR 2.0. Then you run this command on the host where DTR 1.4.3 is running, to
migrate the data to the new installation. Finally, you decommission your
DTR 1.4.3 by uninstalling it.
## Options
| Option | Description |
|:-----------------------|:-----------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--run-full-migration` | Run full migration procedure instead of dumping configurations |
| `--dtr-external-url` | Specify the external domain name and port for DTR. If using a load balancer, use its external URL instead. |
| `--dtr-insecure-tls` | Disable TLS verification for DTR |
| `--dtr-ca` | PEM-encoded TLS CA cert for DTR |
| `--http-proxy` | Set the HTTP proxy for outgoing requests |
| `--https-proxy` | Set the HTTPS proxy for outgoing requests |
| `--no-proxy` | Set the list of domains to not proxy to |

View File

@ -1,48 +0,0 @@
---
description: Docker Trusted Registry reconfigure command reference.
keywords: docker, registry, reference, reconfigure
title: docker/dtr reconfigure
---
Change DTR configurations
## Usage
```bash
docker run -it --rm docker/dtr \
reconfigure [command options]
```
## Description
This command changes specified configurations for DTR and leaves
existing configurations in its original state.
WARNING: DTR is restarted for the new configurations to take
effect. To have no down time, configure your DTR for high-availability.
## Options
| Option | Description |
|:----------------------------|:------------------------------------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--http-proxy` | Set the HTTP proxy for outgoing requests |
| `--https-proxy` | Set the HTTPS proxy for outgoing requests |
| `--no-proxy` | Set the list of domains to not proxy to |
| `--replica-http-port` | Specify the public HTTP port for the DTR replica; 0 means unchanged/default |
| `--replica-https-port` | Specify the public HTTPS port for the DTR replica; 0 means unchanged/default |
| `--log-protocol` | The protocol for sending container logs: tcp, udp or internal. Default: internal |
| `--log-host` | Endpoint to send logs to, required if --log-protocol is tcp or udp |
| `--log-level` | Log level for container logs. Default: INFO |
| `--dtr-external-url` | Specify the external domain name and port for DTR. If using a load balancer, use its external URL instead. |
| `--etcd-heartbeat-interval` | Set etcd's frequency (ms) that its leader will notify followers that it is still the leader. |
| `--etcd-election-timeout` | Set etcd's timeout (ms) for how long a follower node will go without hearing a heartbeat before attempting to become leader itself. |
| `--etcd-snapshot-count` | Set etcd's number of changes before creating a snapshot. |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--existing-replica-id` | ID of an existing replica in a cluster |

View File

@ -1,35 +0,0 @@
---
description: Docker Trusted Registry remove command reference.
keywords: docker, registry, reference, remove
title: docker/dtr remove
---
Remove a replica from a DTR cluster
## Usage
```bash
docker run -it --rm docker/dtr \
remove [command options]
```
## Description
This command removes a replica from the cluster, stops and removes all
DTR containers, and deletes all DTR volumes.
## Options
| Option | Description |
|:------------------------|:-------------------------------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--force-remove` | Force removal of replica even if it can break your cluster's state. Necessary only when --existing-replica-id == --replica-id. |
| `--replica-id` | Specify the replica ID. Must be unique per replica, leave blank for random |
| `--existing-replica-id` | ID of an existing replica in a cluster |

View File

@ -1,59 +0,0 @@
---
description: Docker Trusted Registry restore command reference.
keywords: docker, registry, restore, backup
title: docker/dtr restore
---
Create a new DTR cluster from an existing backup
## Usage
```bash
docker run -i --rm docker/dtr \
restore [command options] < backup.tar
```
## Description
This command performs a fresh installation of DTR, and reconfigures it
with configuration data from a tar file generated by the 'backup' command.
The command starts by installing DTR, restores the configurations
stored on etcd, and then restores the repository metadata stored
on RethinkDB.
This command does not restore Docker images. You should implement a separate
restore procedure for the Docker images stored in your registry, taking in
consideration whether your DTR installation is configured to store images on
the filesystem or using a cloud provider.
After restoring DTR, you can add more nodes to the DTR cluster with
the 'join' command.
## Options
| Option | Description |
|:----------------------------|:------------------------------------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--http-proxy` | Set the HTTP proxy for outgoing requests |
| `--https-proxy` | Set the HTTPS proxy for outgoing requests |
| `--no-proxy` | Set the list of domains to not proxy to |
| `--replica-http-port` | Specify the public HTTP port for the DTR replica; 0 means unchanged/default |
| `--replica-https-port` | Specify the public HTTPS port for the DTR replica; 0 means unchanged/default |
| `--log-protocol` | The protocol for sending container logs: tcp, udp or internal. Default: internal |
| `--log-host` | Endpoint to send logs to, required if --log-protocol is tcp or udp |
| `--log-level` | Log level for container logs. Default: INFO |
| `--dtr-external-url` | Specify the external domain name and port for DTR. If using a load balancer, use its external URL instead. |
| `--etcd-heartbeat-interval` | Set etcd's frequency (ms) that its leader will notify followers that it is still the leader. |
| `--etcd-election-timeout` | Set etcd's timeout (ms) for how long a follower node will go without hearing a heartbeat before attempting to become leader itself. |
| `--etcd-snapshot-count` | Set etcd's number of changes before creating a snapshot. |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--ucp-node` | Specify the host to install Docker Trusted Registry |
| `--replica-id` | Specify the replica ID. Must be unique per replica, leave blank for random |
| `--config-only` | Backup/restore only the configurations of DTR and not the database |

View File

@ -1,47 +0,0 @@
---
description: Docker Trusted Registry upgrade command reference.
keywords: docker, registry, restore, upgrade
title: docker/dtr upgrade
---
Upgrade a v2.0.0 or later cluster to this version of DTR
## Usage
```bash
docker run -it --rm docker/dtr \
upgrade [command options]
```
## Description
This command upgrades an existing DTR 2.0.0 or later cluster to the current version of
this bootstrapper.
## Options
| Option | Description |
|:----------------------------|:------------------------------------------------------------------------------------------------------------------------------------|
| `--ucp-url` | Specify the UCP controller URL including domain and port |
| `--ucp-username` | Specify the UCP admin username |
| `--ucp-password` | Specify the UCP admin password |
| `--debug` | Enable debug mode, provides additional logging |
| `--hub-username` | Specify the Docker Hub username for pulling images |
| `--hub-password` | Specify the Docker Hub password for pulling images |
| `--http-proxy` | Set the HTTP proxy for outgoing requests |
| `--https-proxy` | Set the HTTPS proxy for outgoing requests |
| `--no-proxy` | Set the list of domains to not proxy to |
| `--replica-http-port` | Specify the public HTTP port for the DTR replica; 0 means unchanged/default |
| `--replica-https-port` | Specify the public HTTPS port for the DTR replica; 0 means unchanged/default |
| `--log-protocol` | The protocol for sending container logs: tcp, udp or internal. Default: internal |
| `--log-host` | Endpoint to send logs to, required if --log-protocol is tcp or udp |
| `--log-level` | Log level for container logs. Default: INFO |
| `--dtr-external-url` | Specify the external domain name and port for DTR. If using a load balancer, use its external URL instead. |
| `--etcd-heartbeat-interval` | Set etcd's frequency (ms) that its leader will notify followers that it is still the leader. |
| `--etcd-election-timeout` | Set etcd's timeout (ms) for how long a follower node will go without hearing a heartbeat before attempting to become leader itself. |
| `--etcd-snapshot-count` | Set etcd's number of changes before creating a snapshot. |
| `--ucp-insecure-tls` | Disable TLS verification for UCP |
| `--ucp-ca` | Use a PEM-encoded TLS CA certificate for UCP |
| `--existing-replica-id` | ID of an existing replica in a cluster |

View File

@ -1,227 +0,0 @@
---
description: Docker Trusted Registry release notes
keywords: docker, documentation, about, technology, understanding, enterprise, hub, registry, release notes, Docker Trusted Registry
title: Docker Trusted Registry release notes
---
Here you can learn about new features, bug fixes, breaking changes and
known issues for each DTR version.
You can then use [the upgrade instructions](../install/upgrade/index.md),
to upgrade your installation to the latest release.
## Version 2.0.4
(13 Oct 2016)
**General improvements**
* Increased limits on pagination for all lists in the UI
* Improved health check endpoints to report DTR status more accurately
**Bug fixes**
* You can now edit the permissions for a team member
* Fixed issue that prevented DTR from being installed in Docker Engine 1.12
* Several improvements to the migrate command
* Improved the reconfigure command to allow tuning the key-value store heartbeat
interval, election timeout, and snapshot count
* Users can now pull from public repositories in an organization namespace
without having to authenticate. Requires UCP 1.1.4
## Version 2.0.3
August 11, 2016
**Bug fixes**
* You can now add descriptions to the repositories using markdown
## Version 2.0.2
July 6, 2016
**docker/dtr image**
* Added the `docker/dtr images` command that lists all images needed for installing DTR.
* Added the `--extra-envs` flag to the install and join commands, that allows to specify
swarm constraints to the DTR containers.
**Misc**
* General improvements to the garbage collection settings screen.
* Deleting a repository is now faster.
* Upgraded the RethinkDB used internally to version 2.3.4, for improved security.
* Upgraded the Nginx used internally to version 1.8.1, for improved security.
**Bug fixes**
* Fixed problem that caused the last run time for the garbage collection job to
be wrong.
* When creating users and organizations, the 'Save & create another' button now
works as expected.
* In the Users screen, the organizations each user belongs to is now listed.
## Version 2.0.1
**New features**
* You can set a maximum duration for the garbage collection job to run. After
this timeout the garbage collection job stops. The job is then resumed on the
next scheduled interval.
* docker/dtr image
* Added the `docker/dtr upgrade` command, to upgrade an installation.
* Renamed the `--dtr-load-balancer` flag to `--dtr-external-url`.
**Deprecated features**
* The user authentication settings page is deprecated and will be removed in a
future release. Configure user authentication in UCP.
**Bug fixes**
* UI
* The dropdown filter in the Repositories screen works as expected.
* The global search now returns all results.
* When removing users from an organization, the page now refreshes
automatically.
* When configuring Swift as storage backend, it's now possible to define the
Chunk size option.
* When integrating with LDAP, the 'User search config' section is no longer
being displayed twice.
* When uploading a new license, the page now refreshes automatically.
* On the repository screen, the docker pull command is now displayed
correctly for all users.
* Users and teams
* When adding users to a team, it's now possible to deselect users.
* When listing users, the organizations those users belong to are displayed
correctly.
* After adding a user to a team, the 'Add user' modal now closes
automatically.
* When adding a user, errors are now displayed correctly.
* Browsers
* When logging in with Microsoft Edge on Windows 10, users are no longer
redirected indefinitely.
* You can now update DTR license when using Firefox version 45.
* You can now add managed users to teams when using Internet Explorer and
Firefox.
* You can now list repository tags when using Internet Explorer or Firefox.
* Misc
* The restore command now gives an error when running restore without input
redirection.
* With more than 150k users, the search API is now responsive.
* When UCP and DTR are running on the same host, restarting the host now
restarts DTR containers. For this to work you need to use CS Engine
1.11.1-cs2 and UCP 1.1.1, or newer versions.
* It's no longer possible to delete the default 'docker-datacenter'
organization.
**Known issues**
* UI
* It's not possible to delete tags already deleted by the garbage collection
job.
* On the Users page, the pagination only works until the 20th page.
* The navigation bar doesn't show what page is active.
* After migrating from DTR 1.4.3 some tags are displayed on the UI but cannot
be pulled because they are tags that are not associated with any image.
Contact Docker support for help in removing these tags.
* In the Repository screens, the filter dropdown doesn't reset after
selecting an organization.
* Misc
* When using Firefox 38.8.0, some buttons are not responsive and tags are not
displayed. As a workaround use a more recent version of Firefox, or a
different browser.
* The docker search command doesn't work with DTR 2.0 and CS Engine 1.10+.
This issue should be fixed on CS Engine 1.12.
* When the DTR proxy container stops, it may seem that the DTR UI is
responding, but it shows an "empty" notification when saving settings.
* When configuring DTR to use a proxy, connections to the Notary server
are routed through the proxy. If the Notary is not reachable through
the proxy, you need to add the Notary server url to the NO_PROXY settings.
## Version 2.0.0
4 May 2016
**Features**
* Core
* Support for high-availability and horizontal scalability.
* UCP and DTR are now using a unified authentication service.
* LDAP configurations should be performed on UCP. In future releases that
configuration will be removed from DTR.
* Users and teams created in the DTR Datacenter organization are displayed
in UCP.
* Credentials of LDAP and Active Directory users are no longer stored on disk
Instead a token is used for pushing and pulling images.
* Added anonymous event tracking to allow us to improve DTR. The data is
completely anonymized and you can turn this off in the DTR settings page.
* DTR installer
* The DTR installer is now similar to UCP.
* The DTR installer now runs on a container and has commands to install
configure, and backup DTR.
* UI
* Several changes to the UI to make it consistent with UCP.
**Bug fixes**
* Improved search functionality.
* Search autocomplete now displays all users.
* Image tags now take less time to be displayed.
**Known issues**
* UI
* The dropdown filter in the Repositories screen doesn't open, but you can
click on the input box.
* The global search is returning a limited number of results.
* When configuring Swift as storage backend, it's not possible to define
the Chunk size option.
* When logging in with Microsoft Edge on Windows 10, users are redirected
indefinitely.
* It's not possible to delete tags already delete by the garbage collector.
* When integrating with LDAP, the 'User search config' section is sometimes
displaying twice.
* On the Users page, the pagination only works until the 20th page.
* When navigating to detail pages, the navigation bar doesn't show what page
is active.
* Users and teams
* When removing a user from an organization, the page doesn't refresh
automatically.
* When adding users to a team, it's not possible to deselect users.
* When uploading a new license, the page doesn't refresh automatically.
* After adding a user to a team, the 'Add user' modal doesn't close
automatically.
* API and CLI
* With more than 150k users, the search API takes too long to return a
response.
* The docker search command does not work with DTR 2.0.
* The docker/dtr restore command doesn't return a meaningful error when
invoking the command without redirecting input from a file.
* Misc
* When using Docker Engine 1.11 and DTR and UCP are running on the same host,
restarting the host might cause the DTR containers not start. This is caused
by a [bug in Docker Engine](https://github.com/moby/moby/issues/22486).
You can restart the DTR containers from the UCP UI.
* When the DTR proxy container stops, it may seem that the DTR UI is
responding but it shows an "empty" notification when saving settings.
* Adding a proxy to the DTR configuration forces the connections to the
notary server to be routed through the proxy. If the notary server is not
reachable through the proxy, add the notary URL to the NO_PROXY setting.
* UCP has a single default organization “docker-datacenter”. If you delete
this organization on DTR, you wont be able to manage users and teams from
UCP. To recover from this, contact Docker support.
## Prior versions
You can find the release notes for older versions of DTR on the
[release notes archive](prior-release-notes.md).

View File

@ -1,319 +0,0 @@
---
description: Archived release notes for Docker Trusted Registry
keywords: docker, documentation, about, technology, understanding, enterprise, hub, registry, Docker Trusted Registry, release
redirect_from:
- /docker-trusted-registry/prior-release-notes/
- /docker-trusted-registry/release-notes/prior-release-notes/
title: DTR release notes archive
---
This document contains the release notes for all versions of Docker Trusted
Registry.
## Version 1.4.3
(22 February 2016)
The Trusted Registry is supported on SUSE Linux Enterprise 12 OS.
This release addresses the following issues in Docker Trusted Registry 1.4.2.
* Improved the Trusted Registry UI response when performing certain operations with a large set of users.
* Created a new Trusted Registry screen where image tags in a repository are displayed. This fixed the issue where long image tags were truncated in the UI.
* You can now download the Trusted Registry for offline installation. Refer to the documentation.
* Corrected an issue where if the Trusted Registry was set to a non default port, users couldnt push images to it.
* Improved LDAP configuration. There are now additional user search filters in the Trust Registry UI. The location is Settings > Auth. Select LDAP authentication method. The filters are:
* `UsernameAttrIsEmail`
* `ScopeOneLevel`
* Fixed an issue where the Trusted Registry correctly updates team members after an LDAP sync. This removed duplication of users if they were moved to a different team.
* Previously, if you started the Trusted Registry 1.4.2 with CS Engine 1.7.0 onwards, it might not start because `docker` might start the Trusted Registry containers in an order that makes [links impossible to create](https://github.com/moby/moby/issues/17118). Using CS Engine 1.9 and later with the latest Trusted Registry includes creation of a custom network that allows all containers to connect to each other without links. This means that every time the Trusted Registry starts up, there should be no error.
Also, when you upgrade CS Engine from 1.6 to 1.9 and the Trusted Registry admin server starts, it checks if it's running with links enabled. If that happens, the Trusted Registry restarts everything, creating the new network if necessary and removing the links, replacing them with a custom "dtr" network.
* This version deprecates the search API exposed at the /api/v0/index/search
endpoint. Starting on DTR 2.0 this API endpoint will no longer be available.
* On DTR 2.0 the autocomplete API exposed at the /api/v0/index/autocomplete
endpoint, will start returning a new result structure.
* On DTR 2.0 all API endpoints that return UserAccess and RepoUserAccess objects
are going to return objects with different properties.
## Version 1.4.2
(21 December 2015)
Release notes contain the following sections:
* Additional storage backend
* Fixed or updated with this release
**Additional storage backend**
This release introduces using Openstack Swift as a storage backend. Refer to the [configuration documentation](../configure/config-storage.md) for details on the Swift driver.
**Fixed or updated with this release**
This release addresses the following issues in Docker Trusted Registry 1.4.1.
* Updated the registry from version 2.2.0 to 2.2.1 to ensure that the backend storage Swift driver works correctly.
* Added a link to the release notes from the Trusted Registry UI Updates page.
* The Trusted Registry UI now displays a warning message if an administrator had not yet enabled authentication.
* Corrected an issue where if Trusted Registry administrators were also in a
read-only global team, then they would not see the Trusted Registry admin user
interface.
* Corrected an issue where uploading an image that took longer than five minutes resulted in an authentication failure.
* Fixed several issues that caused the Trusted Registry log files to record excessive unnecessary information.
* Fixed inconsistencies in the garbage collection cron job scheduling between the API and the Trusted Registry UI. This includes:
* Fixed an issue that if you ran the garbage collection process, the timestamp would not correctly display your last run.
* Improved the garbage collection cron format. Now a Trusted Registry admin can schedule cron jobs using additional fields such as `@yearly`, `@annually`, `@monthly`, `@weekly`, `@daily`, `@midnight`, and `@hourly`.
* Fixed an issue where if a Trusted Registry admin did not schedule a garbage collection process, then the Trusted Registry server would log an error.
## Version 1.4.1
(24 November 2015)
**Fixed with this release**
This release addresses the following issues in Docker Trusted Registry 1.4.0.
* Trusted Registry administrators previously could not pull unlisted repositories in any authorization mode.
* When using LDAP authentication, only users with lowercase letters, numbers, underscores, periods, and hyphens in their usernames in the LDAP server were
synchronized to the Trusted Registry user database. The Trusted Registry now
synchronizes users with usernames containing uppercase letters. If this affects
your organization, perform a LDAP sync from the Trusted Registry UI. Navigate to
Settings > Auth to perform the sync.
* Fixed an issue where Trusted Registry administrators could not list all repositories in the registries. To list them, you must use the `catalog` API using a `bash` shell. The following example lists repositories in a Trusted Registry located at my.dtr.host where the user `admin` has password `password`.
```none
bash -c 'host=vagrant.host admin=admin password=password token=$(curl -u $admin:$password -k "https://$host/auth/token?service=$host&scope=registry:catalog:*" | python2 -c "import json,sys;obj=json.load(sys.stdin);print obj[\"token\"]") && curl -k -H "Authorization: Bearer $token" "https://$host/v2/_catalog"'
```
## Version 1.4.3
(12 November 2015)
Release notes for the Trusted Registry contain the following sections:
* New features
* Fixed with this release
* Other corrected issues
* Known issues
**New features**
This release introduces the following new features. For additional information
on these features, refer to the documentation or when appropriate, the API
documentation.
* Image deletion and garbage collection
* You can now delete an image in the registry's image index. This step of marking an unwanted image is called a soft delete.
* Administrators can use the dashboard or API to configure a task to regularly reclaim the disk space taken up by deleted images.
* Repositories, Account Management, and interactive API UIs
* Set up, and manage user accounts, teams, organizations, and repositories from either APIs or through the Trusted Registry user interface.
* Search, browse, and discover images created by other users through either APIs or through the Trusted Registry UI.
* Users, depending on their roles, can access account information through the Trusted Registry UI.
* View new API documentation through the Trusted Registry UI. You can also view this documentation from Docker, Inc. docs section.
* New APIs
* There are new APIs for accessing repositories, account management, indexing, searching, and reindexing.
* You can also view an API and using the Swagger UI, click the Try it out button to perform the action. This might be useful, for example, if you need to reindex.
* Different repository behavior. A repository must first exist before you can push an image to it. This means you must explicitly create (or have it performed for you if you don't have the correct permissions) a repository. This behavior is different than how you would perform this in a free and open-source software registry.
* New experimental feature. Docker Trusted Registry now integrates with Docker Content Trust using Notary. This is an experimental feature that is available with this release.
**Fixed with this release**
This release corrects the following issues in Docker Trusted Registry 1.3.3.
**LDAP Configuration**
* Performance for LDAP user authentication has been significantly improved, reducing the number of required LDAP requests to only a single BIND request to authenticate a user.
* The "Read-Write Search Filter" and "Read-Only Search Filter" fields have been deprecated. You can create organization accounts and teams in the Trusted
Registry to allow for more fine grained access control. Team member lists can be
synced with a group in LDAP.
* The system requires an "Admin Password". Use this password to log in as the
user admin in case the Trusted Registry is unable to authenticate you using
your LDAP server. This account can be used to log in to the Trusted Registry and manage identity and authentication settings.
* Users on your LDAP server are now synced to the Trusted Registry's local
database using your configured "User Search Filter". Objects in LDAP that match
this filter and have a valid "User Login Attribute" are created as a local
user with the "User Login Attribute" as their username. Only these users are
able to log in to the Trusted Registry.
* The "Admin LDAP DN" must be specified to identify the group object on your LDAP server. This should be synced to the system administrators list. The
"Admin Group Member Attribute" should be set to the name of the attribute on
this group object which corresponds to the Distinguished Name of the group
member objects. This setting deprecates the old "Admin Search Filter" field.
**Other corrected issues**
* Corrected an issue where you could switch from none to managed authentication
without creating an administrator.
* Added a "rootdirectory" parameter to the S3 storage option.
**Known issues**
* Organization owners are unable to delete a repository from the UI. You can still delete a repository through the API and a system administrator can still
delete a repository from the UI.
* When using LDAP authentication, only users with valid usernames in the LDAP server are synchronized to the Trusted Registry user database. A valid username
only contains lowercase letters, numbers, underscores, periods, hyphens, and
begins and ends with an alphanumeric character.
* After upgrading to the Trusted Registry 1.4.0, users will not be able to access images from the Trusted Registry if they were previously created without
using namespaces. Docker recommends upgrading to version 1.4.1. After upgrading,
for any repository that was previously pushed to the Trusted Registry, that is
now inaccessible, a Trusted Registry administrator must make it accessible by
the following steps:
1. If the repository name is not of the form "namespace/repository", then an administrator must pull all of that repository's tags. For example, you might have an image called `devops_nginx`. The following example shows how you would pull it from a Trusted Registry instance located at my.dtr.host.
```
sudo docker pull --all-tags my.dtr.host/devops_nginx
```
2. Create a new repository. In the Trusted Registry dashboard, navigate to Repositories > New repository.
3. Select the account that you want to associate to that repository, and enter a repository name in that field and save. If you do not see the account name you wanted to use, then create a new organization or user first. For the example `devops_nginx`, you could use `devops` as the organization and `nginx` as the repository name.
4. Next, in a `bash` shell, retag all the tags of that repository as seen in the following example:
```
for tag in `sudo docker images | grep my.dtr.host/devops_nginx | awk '{print $2}'`
do sudo docker tag my.dtr.host/devops_nginx:$tag my.dtr.host/devops/nginx:$tag
done
```
5. Push the newly tagged version back to the Trusted Registry as seen in the following example:
`sudo docker push my.dtr.host/devops/nginx`
## Version 1.3.3
(18 September 2015) (amended: 2 November 2015)
This release corrects the following issues in Docker Trusted Registry 1.3.2
* Fixed an issue related to LDAP integration for users of Oracle Virtual Directory.
* Corrected an issue where Docker Trusted Registry would not accept a given certificate if the configured domain was only in the Subject Alternative Names
(SANs) field and not in the Common Name (CN) field of the certificate.
* Docker, Inc. discovered an issue in which the tokens used in authorization caused a break in certain deployments that utilized a load balancer in front of
multiple Trusted Registry instances to achieve high availability. We regret any
inconvenience this may have caused you and is working on a future fix.
## Version 1.3.2
(16 September 2015)
This release addresses the following change in Docker Trusted Registry 1.3.2 and is only available to customers who purchased DTR through Amazon Web Services (AWS) Marketplace.
* Docker Trusted Registry (DTR) now supports Amazon Web
Services (AWS) Integrated Billing. Previously, AWS users were required to
separately purchase a DTR license from Docker. AWS users can try DTR
out-of-the-box.
## Version 1.3.1
(31 August 2015)
This release corrects the following issues in Docker Trusted Registry 1.3.0
* The dashboard page was calculating incorrect stats.
* LDAP group sync failed to handle paginated results for extremely large groups.
* The repo delete endpoint returned incorrect error codes under certain conditions.
## Version 1.3.0
(26 August 2015)
This release addresses a few bugs and issues in Docker Trusted Registry 1.2.0 and introduces some new features and functionality, including:
* A completely new user-interface for the Admin application brings Docker Trusted Registry in line with other Docker products and provides greater ease-of-use.
* A new Accounts & Repos API provides new fine-grained role-based access control down to the per-repo level. See the [API's documentation](/apidocs/v1.3.3/) for more information.
* Improvements to the handling of configuration changes so that fewer restarts are required.
* Multiple security improvements and bug fixes.
## Version 1.2.0
(23 July 2015)
This release adds CentOS support and addresses a few bugs and issues in Docker Trusted Registry 1.1.0:
* Fixes an issue where for certain configurations of Docker Trusted Registry, proxy configuration settings and variables were not being passed to all Docker Trusted Registry containers and thus were not being respected.
* Documentation links in the UI now point to correct docs.
* Generated support info bundles have been scrubbed to remove highly sensitive data.
* Certifies support for CentOS 7.1.
## Version 1.1.0
(23 June 2015)
This release of Docker Trusted Registry (formerly DHE) adds major integration
with the AWS and Azure marketplaces, giving customers a smoother installation
path. Docker Trusted Registry 1.1 also adds finer-grained permissions and
improvements and additions to the UI and logging. Bugs in LDAP/AD integration
have also been remediated, improving the stability and usability of Docker
Trusted Registry. See below for specifics.
**New Features**
* New, more granular, [roles for users](../user-management/index.md). Docker Trusted Registry users can now be assigned different levels of access
(admin, r/w, r/o) to the repositories. **Important:** Existing Docker Trusted
Registry users should make sure to see the note [below](prior-release-notes.md#dhe-1-0-upgrade-warning) regarding migrating users before upgrading.
* A new storage status indicator for storage space. The dashboard now shows used and available storage space for supported storage drivers.
* A new diagnostics tool gathers and bundles Docker Trusted Registry logs, system information, container
information, and other configuration settings for use by Docker support or as a
backup.
* Performance and reliability improvements to the S3 storage backend.
* Docker Trusted Registry images are now available on the Amazon AWS and Microsoft Azure marketplaces.
**Fixes**
The following notable issues have been remediated:
* Fixed an issue that caused Docker Trusted Registry logins to fail if some LDAP servers were unreachable.
* Fixed a resource leak in Docker Trusted Registry storage.
**DHE 1.0 Upgrade Warning**
If you currently use DHE 1.0, you **must** follow the
[upgrading instructions](https://forums.docker.com/t/upgrading-docker-hub-enterprise-to-docker-trusted-registry/1925)
in our support Knowledge Base. These instructions show you how to modify
existing authentication data and storage volume settings to move to Docker
Trusted Registry. Automatic upgrading has been disabled for DHE users because of
these issues.
## Version 1.0.1
(11 May 2015)
- Addresses compatibility issue with 1.6.1 CS Docker Engine
## Version 1.0.0
(23 Apr 2015)
- First release

View File

@ -1,19 +0,0 @@
---
description: Learn how to delete images from your repositories on Docker Trusted Registry.
keywords: docker, registry, repository, delete, image
redirect_from:
- /docker-trusted-registry/soft-garbage/
- /docker-trusted-registry/repos-and-images/delete-images/
- /docker-trusted-registry/repos-and-images/delete-an-image/
title: Delete an image
---
To delete an image, go to the **DTR web UI**, and navigate to the image
**repository** you want to delete. In the **Tags** tab, select all the image
tags you want to delete, and click the **Delete button**.
![](../images/delete-an-image-1.png)
You can also delete all image versions, by deleting the repository. For that,
in the image **repository**, navigate to the **Settings** tab, and click the
**Delete** button.

View File

@ -1,97 +0,0 @@
---
description: Learn how to configure your Docker Engine to push and pull images from Docker Trusted Registry.
keywords: docker, registry, TLS, certificates
title: Configure your Docker Engine
---
By default Docker Engine uses TLS when pushing and pulling images to an
image registry like Docker Trusted Registry.
If DTR is using the default configurations or was configured to use
self-signed certificates, you need to configure your Docker Engine to trust DTR.
Otherwise, when you try to login or push and pull images to DTR, you get an
error:
```bash
$ docker login <dtr-domain-name>
x509: certificate signed by unknown authority
```
The first step to make your Docker Engine trust the certificate authority used
by DTR is to get the DTR CA certificate. Then you configure your operating
system to trust that certificate.
## Configure your host
### Ubuntu/ Debian
```bash
# Download the DTR CA certificate
$ curl -k https://<dtr-domain-name>/ca -o /usr/local/share/ca-certificates/<dtr-domain-name>.crt
# Refresh the list of certificates to trust
$ sudo update-ca-certificates
# Restart the Docker daemon
$ sudo service docker restart
```
### RHEL/ CentOS
```bash
# Download the DTR CA certificate
$ sudo curl -k https://<dtr-domain-name>/ca -o /etc/pki/ca-trust/source/anchors/<dtr-domain-name>.crt
# Refresh the list of certificates to trust
$ sudo update-ca-trust
# Restart the Docker daemon
$ sudo /bin/systemctl restart docker.service
```
### Boot2Docker
1. Login into the virtual machine with ssh:
```bash
docker-machine ssh <machine-name>
```
2. Create the `bootsync.sh` file, and make it executable:
```bash
sudo touch /var/lib/boot2docker/bootsync.sh
sudo chmod 755 /var/lib/boot2docker/bootsync.sh
```
3. Add the following content to the `bootsync.sh` file. You can use nano or vi
for this.
```bash
#!/bin/sh
cat /var/lib/boot2docker/server.pem >> /etc/ssl/certs/ca-certificates.crt
```
4. Add the DTR CA certificate to the `server.pem` file:
```bash
curl -k https://<dtr-domain-name>/ca | sudo tee -a /var/lib/boot2docker/server.pem
```
5. Run `bootsync.sh` and restart the Docker daemon:
```bash
sudo /var/lib/boot2docker/bootsync.sh
sudo /etc/init.d/docker restart
```
## Login into DTR
To validate that your Docker daemon trusts DTR, trying authenticating against
DTR.
```bash
$ docker login <dtr-domain-name>
```
## Where to go next
* [Pull an image from DTR](pull-an-image.md)

View File

@ -1,33 +0,0 @@
---
description: Learn how to pull an image from Docker Trusted Registry.
keywords: docker, registry, images, pull
redirect_from:
- /docker-trusted-registry/quick-start/
- /docker-trusted-registry/repos-and-images/pull-an-image/
title: Pull an image from DTR
---
Pulling an image from Docker Trusted Registry is the same as pulling an image
from Docker Hub. Since DTR is secure by default, you always need to authenticate
before pulling images.
In this example, DTR can be accessed at dtr.company.org, and the user
was granted permissions to access the Java, Python, and Golang repositories.
![](../images/pull-an-image-1.png)
Click on the repository to see its details.
![](../images/pull-an-image-2.png)
To pull the 1.7 tag of the dave.lauper/golang image, run:
```bash
$ docker login dtr.company.org
$ docker pull dtr.company.org/dave.lauper/golang:1.7
```
## Where to go next
* [Push an image to DTR](push-an-image.md)
* [Configure your Docker Engine](index.md)

View File

@ -1,73 +0,0 @@
---
description: Learn how to push an image to Docker Trusted Registry.
keywords: docker, registry, images, pull
redirect_from:
- /docker-trusted-registry/repos-and-images/create-repo/
- /docker-trusted-registry/userguide/
- /docker-trusted-registry/repos-and-images/push-and-pull-images/
- /docker-trusted-registry/repos-and-images/push-an-image/
title: Push an image to DTR
---
Pushing an image to Docker Trusted Registry is the same as pushing an image
to Docker Hub.
Since DTR is secure by default, you need to create the image repository before
you can push the image to DTR.
In this example, we create the 'golang' repository in DTR, and push the
Golang 1.7 image to it.
## Create a repository
To create a new repository, navigate to the **DTR web application**, and click
the **New repository** button.
![](../images/push-an-image-1.png)
Add a **name and description** for the repository, and choose whether your
repository is public or private:
* Public repositories are visible to all users, but can only be changed by
users granted with permission to write them.
* Private repositories can only be seen by users that have been granted
permissions to that repository.
![](../images/push-an-image-2.png)
Click **Save** to create the repository.
When creating a repository in DTR, the full name of the repository becomes
`<dtr-domain-name>/<user-or-org>/<repository-name>`. In this example, the full
name of our repository will be `dtr.company.org/dave.lauper/golang`.
## Tag the image
Before you can push an image to DTR, you need to tag it with the full
repository name. A tag defines where the image was pulled from, and where
it will be pushed to.
```bash
# Pull from Docker Hub the 1.7 tag of the golang image
$ docker pull golang:1.7
# Tag the golang:1.7 image with the full repository name we've created in DTR
$ docker tag golang:1.7 dtr.company.org/dave.lauper/golang:1.7
```
## Push the image
Now that you have tagged the image, you only need to authenticate and push the
image to DTR.
```bash
$ docker login dtr.company.org
$ docker push dtr.company.org/dave.lauper/golang:1.7
```
Go back to the **DTR web UI** to validate that the tag was successfully pushed.
![](../images/push-an-image-3.png)
## Where to go next
* [Pull an image from DTR](pull-an-image.md)

Some files were not shown because too many files have changed in this diff Show More