Remove enterprise content
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
|
@ -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.
|
||||
|
||||

|
||||
|
||||
|
||||
## Containers
|
||||
|
||||
When you install DTR on a node, the following containers are started:
|
||||
|
||||
| Name | Description |
|
||||
|:---------------------------------|:----------------------------------------------------------------------------------------------------------------------------------|
|
||||
| dtr-nginx-<replica_id> | 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-<replica_id> | Executes the DTR business logic. It serves the DTR web application, and API. |
|
||||
| dtr-registry-<replica_id> | Implements the functionality for pulling and pushing Docker images. It also handles how images are stored. |
|
||||
| dtr-etcd-<replica_id> | 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-<replica_id> | 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-<replica_id> | dtr-ca/_data | The volume where the private keys and certificates are stored so that containers can use TLS to communicate. |
|
||||
| dtr-etcd-<replica_id> | dtr-etcd/_data | The volume used by etcd to persist DTR configurations. |
|
||||
| dtr-registry-<replica_id> | dtr-registry/_data | The volume where images are stored, if DTR is configured to store images on the local filesystem. |
|
||||
| dtr-rethink-<replica_id> | dtr-rethink/_data | The volume used by RethinkDB to persist DTR data, like users and repositories. |
|
||||
|
||||
If you don’t 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)
|
Before Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 47 KiB |
|
@ -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://<dtr-host>/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)
|
|
@ -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)
|
|
@ -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
|
||||
organization’s 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 Microsoft’s 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)
|
|
@ -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)
|
|
@ -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)
|
|
@ -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)
|
|
@ -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.
|
||||
|
||||

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

|
||||
|
||||
## 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)
|
|
@ -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)
|
Before Width: | Height: | Size: 85 KiB |
Before Width: | Height: | Size: 65 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 55 KiB |
Before Width: | Height: | Size: 64 KiB |
Before Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 43 KiB |
Before Width: | Height: | Size: 53 KiB |
Before Width: | Height: | Size: 45 KiB |
Before Width: | Height: | Size: 76 KiB |
Before Width: | Height: | Size: 75 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 8.0 KiB |
|
@ -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 |
Before Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 112 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 28 KiB |
Before Width: | Height: | Size: 71 KiB |
Before Width: | Height: | Size: 69 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 51 KiB |
Before Width: | Height: | Size: 67 KiB |
Before Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 67 KiB |
Before Width: | Height: | Size: 49 KiB |
Before Width: | Height: | Size: 71 KiB |
Before Width: | Height: | Size: 58 KiB |
Before Width: | Height: | Size: 67 KiB |
Before Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 33 KiB |
Before Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 126 KiB |
Before Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 6.5 KiB |
Before Width: | Height: | Size: 8.0 KiB |
Before Width: | Height: | Size: 92 KiB |
Before Width: | Height: | Size: 56 KiB |
Before Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 68 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 102 KiB |
Before Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 68 KiB |
Before Width: | Height: | Size: 92 KiB |
Before Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 51 KiB |
Before Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 59 KiB |
Before Width: | Height: | Size: 68 KiB |
Before Width: | Height: | Size: 53 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 47 KiB |
|
@ -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.
|
||||
|
||||

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

|
||||
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [DTR architecture](architecture.md)
|
||||
* [Install DTR](install/index.md)
|
|
@ -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.
|
||||
|
||||

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

|
||||
|
||||
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
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)
|
|
@ -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 you’ll 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)
|
|
@ -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.
|
||||
|
||||

|
||||
|
||||
|
||||
## 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**.
|
||||
|
||||

|
||||
|
||||
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)
|
|
@ -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, don’t 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)
|
|
@ -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)
|
|
@ -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)
|
|
@ -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.
|
||||
|
||||

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

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

|
||||
|
||||
**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.
|
||||
|
||||

|
||||
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [Troubleshoot DTR](troubleshoot.md)
|
||||
* [DTR architecture](../architecture.md)
|
|
@ -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
|
||||
```
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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.
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 |
|
|
@ -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 won’t 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).
|
|
@ -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 couldn’t 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
|
|
@ -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**.
|
||||
|
||||

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

|
||||
|
||||
Click on the repository to see its details.
|
||||
|
||||

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

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

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

|
||||
|
||||
## Where to go next
|
||||
|
||||
* [Pull an image from DTR](pull-an-image.md)
|