mirror of https://github.com/docker/docs.git
				
				
				
			Merge branch 'master' of github.com:docker/docker.github.io
This commit is contained in:
		
						commit
						38636dec3a
					
				| 
						 | 
				
			
			@ -17,7 +17,7 @@ all nodes must have:
 | 
			
		|||
 | 
			
		||||
* Linux kernel version 3.10 or higher
 | 
			
		||||
* CS Docker Engine version 1.10 or higher. Learn about the
 | 
			
		||||
[operating systems supported by CS Docker Engine](/cs-engine/install/).
 | 
			
		||||
[operating systems supported by CS Docker Engine](/install/).
 | 
			
		||||
* 2.00 GB of RAM
 | 
			
		||||
* 3.00 GB of available disk space
 | 
			
		||||
* A static IP address
 | 
			
		||||
| 
						 | 
				
			
			@ -59,4 +59,4 @@ Docker Datacenter is a software subscription that includes 3 products:
 | 
			
		|||
## Where to go next
 | 
			
		||||
 | 
			
		||||
* [UCP architecture](../architecture.md)
 | 
			
		||||
* [Plan a production installation](plan-production-install.md)
 | 
			
		||||
* [Plan a production installation](plan-production-install.md)
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -1,8 +1,8 @@
 | 
			
		|||
 ---
 | 
			
		||||
---
 | 
			
		||||
title: Use externally-signed certificates
 | 
			
		||||
description: Learn how to configure Docker Universal Control Plane to use your own
 | 
			
		||||
  certificates.
 | 
			
		||||
keywords: Universal Control Plane, UCP, certificate, authentication, tls
 | 
			
		||||
title: Use externally-signed certificates
 | 
			
		||||
---
 | 
			
		||||
 | 
			
		||||
All UCP services are exposed using HTTPS, to ensure all communications between
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -139,4 +139,4 @@ steps as you used to configure your local computer.
 | 
			
		|||
 | 
			
		||||
## Where to go next
 | 
			
		||||
 | 
			
		||||
* [use your own externally-signed TLS certificates](index.md#customize-the-ucp-tls-certificates)
 | 
			
		||||
* [Use your own externally-signed TLS certificates](/datacenter/ucp/2.0/guides/configuration/index.md#customize-the-ucp-tls-certificates)
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -38,14 +38,6 @@ experience the following benefits:
 | 
			
		|||
Docker Hub welcomes free and open-source content, as well as software sold
 | 
			
		||||
directly by publishers. We support the following commercial models:
 | 
			
		||||
 | 
			
		||||
### Paid through Docker
 | 
			
		||||
 | 
			
		||||
This commercial model allows customers to pay for ISV content through Docker, as
 | 
			
		||||
described in the Store Vendor Partner agreement. Paid-through-Docker content
 | 
			
		||||
includes both software that can be deployed on a host, as well as software that
 | 
			
		||||
runs in the cloud and can be accessed by the customer through an agent
 | 
			
		||||
(containerized cloud services, for example).
 | 
			
		||||
 | 
			
		||||
### Licensed content through Docker Hub BYOL program
 | 
			
		||||
 | 
			
		||||
ISVs can use Docker Hub as an entitlement and distribution platform. Using
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -71,7 +71,7 @@ We don't support the abiltiy to view available tags for published products becau
 | 
			
		|||
 | 
			
		||||
Official images and community images have available tags visible because anyone can access any tag at any time anonymously.
 | 
			
		||||
 | 
			
		||||
We aim to have product listings published with the concept of versions, allowing publishers to manage which versions of their products they expose to customers for access. (Expected Q3 2018)
 | 
			
		||||
We aim to have product listings published with the concept of versions, allowing publishers to manage which versions of their products they expose to customers for access.
 | 
			
		||||
 | 
			
		||||
### On the page for another vendor’s product on Docker Hub, I see the following chunks of data: How do these fields map to the following that are required in the publish process?
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -169,11 +169,6 @@ As a publisher you can charge a subscription fee every month in USD. The amount
 | 
			
		|||
is determined by you. We are working on other pricing options. If you have
 | 
			
		||||
feedback about pricing, send us an email at publisher-support@docker.com
 | 
			
		||||
 | 
			
		||||
### As a publisher, I have not setup any payment account. How does money get to me if my commercial content gets purchased by customers?
 | 
			
		||||
 | 
			
		||||
We (Docker) cut you a check post a revenue share. Your Docker Hub Vendor
 | 
			
		||||
Agreement should cover specifics.
 | 
			
		||||
 | 
			
		||||
### How does Docker handle Export control? Can individual countries be specified if differing from Docker's list of embargoed countries?
 | 
			
		||||
 | 
			
		||||
We provide export control through blacklisting several countries, IPs and users
 | 
			
		||||
| 
						 | 
				
			
			@ -212,4 +207,4 @@ Yes
 | 
			
		|||
 | 
			
		||||
### Can I have a publish by date for my content?
 | 
			
		||||
 | 
			
		||||
Not yet. Potential ETA Q2 2018.
 | 
			
		||||
Not yet. This is a planned enhancement, but we have no specific availability date at this time.
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -26,27 +26,26 @@ Docker recommends the following steps for your storage backend and metadata migr
 | 
			
		|||
 | 
			
		||||
5. With DTR restored from your backup and your storage data migrated to your new backend, garbage collect any dangling blobs using the following API request:
 | 
			
		||||
 | 
			
		||||
        ```bash
 | 
			
		||||
        curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/jobs" -H "accept: application/json" -H "content-type: application/json" -d "{ \"action": \"onlinegc_blobs\" }"
 | 
			
		||||
        ``` 
 | 
			
		||||
        On success, you should get a `202 Accepted` response with a job `id` and other related details.
 | 
			
		||||
   
 | 
			
		||||
This ensures any blobs which are not referenced in your previously created backup get destroyed.
 | 
			
		||||
     ```bash
 | 
			
		||||
     curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/jobs" -H "accept: application/json" -H "content-type: application/json" -d "{ \"action": \"onlinegc_blobs\" }"
 | 
			
		||||
     ``` 
 | 
			
		||||
        
 | 
			
		||||
     On success, you should get a `202 Accepted` response with a job `id` and other related details. This ensures any blobs which are not referenced in your previously created backup get destroyed.
 | 
			
		||||
    
 | 
			
		||||
### Alternative option for data migration
 | 
			
		||||
 | 
			
		||||
- If you have a long maintenance window, you can skip some steps from above and do the following:
 | 
			
		||||
If you have a long maintenance window, you can skip some steps from above and do the following:
 | 
			
		||||
 | 
			
		||||
    1. Put DTR in "read-only" mode using the following API request:
 | 
			
		||||
1. Put DTR in "read-only" mode using the following API request:
 | 
			
		||||
   
 | 
			
		||||
        ```bash
 | 
			
		||||
        curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/meta/settings" -H "accept: application/json" -H "content-type: application/json" -d "{ \"readOnlyRegistry\": true }"
 | 
			
		||||
        ``` 
 | 
			
		||||
        On success, you should get a `202 Accepted` response.
 | 
			
		||||
     ```bash
 | 
			
		||||
     curl -u <username>:$TOKEN -X POST "https://<dtr-url>/api/v0/meta/settings" -H "accept: application/json" -H "content-type: application/json" -d "{ \"readOnlyRegistry\": true }"
 | 
			
		||||
     ``` 
 | 
			
		||||
     On success, you should get a `202 Accepted` response.
 | 
			
		||||
 | 
			
		||||
    2. Migrate the contents of your current storage backend to the new one you are switching to. For example, upload your current storage data to your new NFS server.
 | 
			
		||||
2. Migrate the contents of your current storage backend to the new one you are switching to. For example, upload your current storage data to your new NFS server.
 | 
			
		||||
 | 
			
		||||
    3. [Reconfigure DTR](/reference/dtr/2.6/cli/reconfigure) while specifying the `--storage-migrated` flag to preserve your existing tags. 
 | 
			
		||||
3. [Reconfigure DTR](/reference/dtr/2.6/cli/reconfigure) while specifying the `--storage-migrated` flag to preserve your existing tags. 
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
## DTR 2.6.0-2.6.4 and DTR 2.5 (with experimental garbage collection)
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -7,21 +7,21 @@ redirect_from:
 | 
			
		|||
- /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/
 | 
			
		||||
---
 | 
			
		||||
 | 
			
		||||
2 Key components of the Docker Trusted Registry are the Notary Server and Notary
 | 
			
		||||
Signer. These 2 containers give us the required components to use Docker Content
 | 
			
		||||
Trust right out of the box. [Docker Content
 | 
			
		||||
Trust](/engine/security/trust/content_trust/) allows us to sign image tags,
 | 
			
		||||
therefore whoever pulls the image can validate that they are getting the image
 | 
			
		||||
you create, or a forged one. 
 | 
			
		||||
Two key components of the Docker Trusted Registry are the Notary Server and the Notary
 | 
			
		||||
Signer. These two containers provide the required components for using Docker Content
 | 
			
		||||
Trust (DCT) out of the box. [Docker Content
 | 
			
		||||
Trust](/engine/security/trust/content_trust/) allows you to sign image tags,
 | 
			
		||||
therefore giving consumers a way to verify the integrity of your image.
 | 
			
		||||
 | 
			
		||||
As part of Docker Trusted Registry both the Notary server and the Registry
 | 
			
		||||
server are accessed through a front end Proxy, with both components sharing the
 | 
			
		||||
UCP's RBAC Engine. Therefore no additional configuration of the Docker Client
 | 
			
		||||
is required to use trust.
 | 
			
		||||
As part of DTR, both the Notary and the Registry
 | 
			
		||||
servers are accessed through a front-end proxy, with both components sharing the
 | 
			
		||||
UCP's RBAC (Role-based Access Control) Engine. Therefore, you do not need additional Docker client
 | 
			
		||||
configuration in order to use DCT.
 | 
			
		||||
 | 
			
		||||
Docker Content Trust is integrated into the Docker CLI, allowing you to
 | 
			
		||||
configure repositories, add signers and sign images all through the `$ docker
 | 
			
		||||
trust` command.
 | 
			
		||||
DCT is integrated with the Docker CLI, and allows you to:
 | 
			
		||||
- Configure repositories
 | 
			
		||||
- Add signers, and 
 | 
			
		||||
- Sign images using the `docker trust` command
 | 
			
		||||
 | 
			
		||||

 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -29,31 +29,29 @@ trust` command.
 | 
			
		|||
 | 
			
		||||
UCP has a feature which will prevent [untrusted
 | 
			
		||||
images](/ee/ucp/admin/configure/run-only-the-images-you-trust/) from being
 | 
			
		||||
deployed on the cluster. To use this feature, we first need to upload and sign
 | 
			
		||||
images into DTR. To tie the signed images back to UCP, we will actually sign the
 | 
			
		||||
images with private keys of UCP users. Inside of a UCP Client bundle the
 | 
			
		||||
`key.pem` can be used a User's private key, with the `cert.pem` being a public
 | 
			
		||||
key within a x509 certificate. 
 | 
			
		||||
deployed on the cluster. To use the feature, you need to sign and push images to your DTR. 
 | 
			
		||||
To tie the signed images back to UCP, you need to sign the
 | 
			
		||||
images with the private keys of the UCP users. From a UCP client bundle, use
 | 
			
		||||
`key.pem` as your private key, and `cert.pem` as your public key
 | 
			
		||||
on an `x509` certificate. 
 | 
			
		||||
 | 
			
		||||
To sign images in a way that UCP trusts them, you need to:
 | 
			
		||||
To sign images in a way that UCP can trust, you need to:
 | 
			
		||||
 | 
			
		||||
1. Download a Client Bundle for a User you want to use to sign the images. 
 | 
			
		||||
2. Load the private key of the User into your workstations trust store.
 | 
			
		||||
1. Download a client bundle for the user account you want to use for signing the images. 
 | 
			
		||||
2. Add the user's private key to your machine's trust store.
 | 
			
		||||
3. Initialize trust metadata for the repository. 
 | 
			
		||||
4. Delegate signing for that repository to the UCP User.
 | 
			
		||||
5. Sign the Image. 
 | 
			
		||||
4. Delegate signing for that repository to the UCP user.
 | 
			
		||||
5. Sign the image. 
 | 
			
		||||
 | 
			
		||||
In this example we're going to pull a nginx image from the Docker Hub, re-tag it
 | 
			
		||||
as `dtr.example.com/dev/nginx:1`, push the image to DTR and sign it in a way
 | 
			
		||||
that is trusted by UCP. If you manage multiple repositories, you'll have to do
 | 
			
		||||
the same procedure for each repository.
 | 
			
		||||
The following example shows the `nginx` image getting pulled from Docker Hub, tagged
 | 
			
		||||
as `dtr.example.com/dev/nginx:1`, pushed to DTR, and signed in a way
 | 
			
		||||
that is trusted by UCP.
 | 
			
		||||
 | 
			
		||||
### Import a UCP User's Private Key
 | 
			
		||||
### Import a UCP user's private key
 | 
			
		||||
 | 
			
		||||
Once you have download and extracted a UCP User's client bundle into your local
 | 
			
		||||
directory, you need to load the Private key into the local Docker trust store
 | 
			
		||||
`(~/.docker/trust)`. The name used here is purely metadata to help keep track of
 | 
			
		||||
which keys you have imported.
 | 
			
		||||
After downloading and extracting a UCP client bundle into your local
 | 
			
		||||
directory, you need to load the private key into the local Docker trust store
 | 
			
		||||
`(~/.docker/trust)`. To illustrate the process, we will use `jeff` as an example user.
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
$ docker trust key load --name jeff key.pem
 | 
			
		||||
| 
						 | 
				
			
			@ -63,16 +61,16 @@ Repeat passphrase for new jeff key with ID a453196:
 | 
			
		|||
Successfully imported key from key.pem
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
### Initialize the trust metadata and add the Public Key
 | 
			
		||||
### Initialize the trust metadata and add the user's public certificate
 | 
			
		||||
 | 
			
		||||
Next, we need to initiate trust metadata for a DTR repository. If you have not
 | 
			
		||||
done so already, navigate to the **DTR web UI**, and create a repository for
 | 
			
		||||
your image. In this example we've created the `prod/nginx` repository.
 | 
			
		||||
Next,initiate trust metadata for a DTR repository. If you have not
 | 
			
		||||
already done so, navigate to the **DTR web UI**, and create a repository for
 | 
			
		||||
your image. This example uses the `nginx` repository in the `prod` namespace.
 | 
			
		||||
 | 
			
		||||
As part of initiating the repository, we will add the public key of the UCP User
 | 
			
		||||
as a signer. You will be asked for a number of passphrases to protect the keys.
 | 
			
		||||
Make a note of these passphrases, and see [Managing Delegations in a Notary Server](/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server) 
 | 
			
		||||
to learn more about managing keys.
 | 
			
		||||
As part of initiating the repository, the public key of the UCP user needs to be added 
 | 
			
		||||
to the Notary server as a signer for the repository. You will be asked for a number of 
 | 
			
		||||
passphrases to protect the keys.Make a note of these passphrases, and 
 | 
			
		||||
see [Managing Delegations in a Notary Server](/engine/security/trust/trust_delegation/#managing-delegations-in-a-notary-server) to learn more about managing keys.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
| 
						 | 
				
			
			@ -86,7 +84,7 @@ Successfully initialized "dtr.example.com/prod/nginx"
 | 
			
		|||
Successfully added signer: jeff to dtr.example.com/prod/nginx
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
We can inspect the trust metadata of the repository to make sure the User has
 | 
			
		||||
Inspect the trust metadata of the repository to make sure the user has
 | 
			
		||||
been added correctly.
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
| 
						 | 
				
			
			@ -105,11 +103,10 @@ Administrative keys for dtr.example.com/prod/nginx
 | 
			
		|||
  Root Key:     b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
### Sign the Image
 | 
			
		||||
### Sign the image
 | 
			
		||||
 | 
			
		||||
Finally, we will sign an image tag. These steps download the Image from the
 | 
			
		||||
Docker Hub, retag the Image to the DTR repository, push the image up to DTR, as
 | 
			
		||||
well as signing the tag with the UCP User's keys. 
 | 
			
		||||
Finally, user `jeff` can sign an image tag. The following steps include downloading the image from Hub, tagging the image for Jeff's DTR repository, pushing the image to Jeff's DTR, as
 | 
			
		||||
well as signing the tag with Jeff's keys. 
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
$ docker pull nginx:latest
 | 
			
		||||
| 
						 | 
				
			
			@ -128,7 +125,7 @@ Enter passphrase for jeff key with ID 927f303:
 | 
			
		|||
Successfully signed dtr.example.com/prod/nginx:1
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
We can inspect the trust metadata again to make sure the image tag has been
 | 
			
		||||
Inspect the trust metadata again to make sure the image tag has been
 | 
			
		||||
signed successfully. 
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
| 
						 | 
				
			
			@ -150,49 +147,48 @@ Administrative keys for dtr.example.com/prod/nginx:1
 | 
			
		|||
  Root Key:     b74854cb27cc25220ede4b08028967d1c6e297a759a6939dfef1ea72fbdd7b9a
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Or we can have a look at the signed image from within the **DTR UI**. 
 | 
			
		||||
Alternatively, you can review the signed image from the DTR web UI.
 | 
			
		||||
 | 
			
		||||
{: .with-border}
 | 
			
		||||
 | 
			
		||||
### Adding Additional Delegations
 | 
			
		||||
### Add delegations
 | 
			
		||||
 | 
			
		||||
If you wanted to sign this image with multiple UCP Users, maybe if you had a use
 | 
			
		||||
case where an image needed to be signed by a member of the `Security` team and a
 | 
			
		||||
member of the `Developers` team. Then you can add multiple signers to a
 | 
			
		||||
repository. 
 | 
			
		||||
You have the option to sign an image using multiple UCP users' keys. For example, an image
 | 
			
		||||
needs to be signed by a member of the `Security` team and a
 | 
			
		||||
member of the `Developers` team. Let's assume `jeff` is a member of the Developers team.
 | 
			
		||||
In this case, we only need to add a member of the Security team.
 | 
			
		||||
 | 
			
		||||
To do so, first load a private key from a UCP User of the Security Team's in to
 | 
			
		||||
the local Docker Trust Store. 
 | 
			
		||||
To do so, first add the private key of the Security team member to
 | 
			
		||||
the local Docker trust store. 
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
$ docker trust key load --name security key.pem
 | 
			
		||||
$ docker trust key load --name ian key.pem
 | 
			
		||||
Loading key from "key.pem"...
 | 
			
		||||
Enter passphrase for new security key with ID 5ac7d9a:
 | 
			
		||||
Repeat passphrase for new security key with ID 5ac7d9a:
 | 
			
		||||
Enter passphrase for new ian key with ID 5ac7d9a:
 | 
			
		||||
Repeat passphrase for new ian key with ID 5ac7d9a:
 | 
			
		||||
Successfully imported key from key.pem
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Upload the Public Key to the Notary Server and Sign the Image. You will be asked
 | 
			
		||||
for both the Developers passphrase, as well as the Security Users passphrase to
 | 
			
		||||
Upload the user's public key to the Notary Server and sign the image. You will be asked
 | 
			
		||||
for `jeff`, the developer's passphrase, as well as the `ian` user's passphrase to
 | 
			
		||||
sign the tag. 
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
$ docker trust signer add --key cert.pem security dtr.example.com/prod/nginx
 | 
			
		||||
Adding signer "security" to dtr.example.com/prod/nginx...
 | 
			
		||||
$ docker trust signer add --key cert.pem ian dtr.example.com/prod/nginx
 | 
			
		||||
Adding signer "ian" to dtr.example.com/prod/nginx...
 | 
			
		||||
Enter passphrase for repository key with ID e0d15a2:
 | 
			
		||||
Successfully added signer: security to dtr.example.com/prod/nginx
 | 
			
		||||
Successfully added signer: ian to dtr.example.com/prod/nginx
 | 
			
		||||
 | 
			
		||||
$ docker trust sign dtr.example.com/prod/nginx:1
 | 
			
		||||
Signing and pushing trust metadata for dtr.example.com/prod/nginx:1
 | 
			
		||||
Existing signatures for tag 1 digest 5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033 from:
 | 
			
		||||
jeff
 | 
			
		||||
Enter passphrase for jeff key with ID 927f303:
 | 
			
		||||
Enter passphrase for security key with ID 5ac7d9a:
 | 
			
		||||
Enter passphrase for ian key with ID 5ac7d9a:
 | 
			
		||||
Successfully signed dtr.example.com/prod/nginx:1
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
Finally, we can check the tag again to make sure it is now signed by 2
 | 
			
		||||
signatures. 
 | 
			
		||||
Finally, check the tag again to make sure it includes two signers.
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
$ docker trust inspect --pretty dtr.example.com/prod/nginx:1
 | 
			
		||||
| 
						 | 
				
			
			@ -200,13 +196,13 @@ $ docker trust inspect --pretty dtr.example.com/prod/nginx:1
 | 
			
		|||
Signatures for dtr.example.com/prod/nginx:1
 | 
			
		||||
 | 
			
		||||
SIGNED TAG          DIGEST                                                             SIGNERS
 | 
			
		||||
1                   5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033   jeff, security
 | 
			
		||||
1                   5b49c8e2c890fbb0a35f6050ed3c5109c5bb47b9e774264f4f3aa85bb69e2033   jeff, ian
 | 
			
		||||
 | 
			
		||||
List of signers and their keys for dtr.example.com/prod/nginx:1
 | 
			
		||||
 | 
			
		||||
SIGNER              KEYS
 | 
			
		||||
jeff                927f30366699
 | 
			
		||||
security            5ac7d9af7222
 | 
			
		||||
ian                 5ac7d9af7222
 | 
			
		||||
 | 
			
		||||
Administrative keys for dtr.example.com/prod/nginx:1
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -218,13 +214,12 @@ For more advanced use cases like this, see [Delegations for content trust](/engi
 | 
			
		|||
 | 
			
		||||
## Delete trust data
 | 
			
		||||
 | 
			
		||||
If an Administrator wants to delete a DTR repository that contains Trust
 | 
			
		||||
metadata, they will be prompted to delete the trust metadata first before the
 | 
			
		||||
repository can be removed. 
 | 
			
		||||
If an administrator wants to delete a DTR repository that contains trust
 | 
			
		||||
metadata, they will be prompted to delete the trust metadata first before removing the repository.
 | 
			
		||||
 | 
			
		||||
To delete trust metadata we need to use the Notary CLI. For information on how
 | 
			
		||||
to download and configure the Notary CLI head
 | 
			
		||||
[here](/engine/security/trust/trust_delegation/#configuring-the-notary-client)
 | 
			
		||||
To delete trust metadata, you need to use the Notary CLI. For information on how
 | 
			
		||||
to download and configure the Notary CLI see
 | 
			
		||||
[Configuring the Notary client](/engine/security/trust/trust_delegation/#configuring-the-notary-client)
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
```bash
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -44,7 +44,7 @@ this.
 | 
			
		|||
 | 
			
		||||
The `service-cluster-ip-range` Kubernetes API Server flag is currently set to `10.96.0.0/16` and cannot be changed.
 | 
			
		||||
 | 
			
		||||
Swarm uses a default address pool of `10.0.0.0/16` for its overlay networks. If this conflicts with your current network implementation, please use a custom IP address pool. To specify a custom IP address pool, use the `--default-address-pool` command line option during [Swarm initialization](../../../../engine/swarm/swarm-mode.md). 
 | 
			
		||||
Swarm uses a default address pool of `10.0.0.0/8` for its overlay networks. If this conflicts with your current network implementation, please use a custom IP address pool. To specify a custom IP address pool, use the `--default-address-pool` command line option during [Swarm initialization](../../../../engine/swarm/swarm-mode.md). 
 | 
			
		||||
 | 
			
		||||
> **Note**: Currently, the UCP installation process does not support this flag. To deploy with a custom IP pool, Swarm must first be installed using this flag and UCP must be installed on top of it.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
							
								
								
									
										18
									
								
								index.md
								
								
								
								
							
							
						
						
									
										18
									
								
								index.md
								
								
								
								
							| 
						 | 
				
			
			@ -22,14 +22,14 @@ production servers in the cloud. Total reading time is less than an hour.
 | 
			
		|||
</div>
 | 
			
		||||
<div markdown="1" class="col-xs-12 col-sm-12 col-md-12 col-lg-6 block">
 | 
			
		||||
 | 
			
		||||
## Try Docker Enterprise Edition
 | 
			
		||||
## Try Docker Enterprise
 | 
			
		||||
 | 
			
		||||
Run your solution in production with Docker Enterprise Edition to get a
 | 
			
		||||
Run your solution in production with Docker Enterprise to get a
 | 
			
		||||
management dashboard, security scanning, LDAP integration, content signing,
 | 
			
		||||
multi-cloud support, and more. Click below to test-drive a running instance of
 | 
			
		||||
Docker EE without installing anything.
 | 
			
		||||
Docker Enterprise without installing anything.
 | 
			
		||||
 | 
			
		||||
[Try Docker Enterprise Edition](https://trial.docker.com){: class="button outline-btn" onclick="ga('send', 'event', 'EE Trial Referral', 'Front Page', 'Click');"}
 | 
			
		||||
[Try Docker Enterprise](https://trial.docker.com){: class="button outline-btn" onclick="ga('send', 'event', 'EE Trial Referral', 'Front Page', 'Click');"}
 | 
			
		||||
 | 
			
		||||
</div>
 | 
			
		||||
</div>
 | 
			
		||||
| 
						 | 
				
			
			@ -52,15 +52,17 @@ channel for more predictability.
 | 
			
		|||
</div>
 | 
			
		||||
<div markdown="1" class="col-xs-12 col-sm-12 col-md-12 col-lg-6 block">
 | 
			
		||||
 | 
			
		||||
### Docker Enterprise Edition
 | 
			
		||||
### Docker Enterprise Platform
 | 
			
		||||
 | 
			
		||||
Designed for enterprise development and IT teams who build, ship, and run
 | 
			
		||||
business critical applications in production at scale. Integrated, certified,
 | 
			
		||||
and supported to provide enterprises with the most secure container platform in
 | 
			
		||||
the industry to modernize all applications. Docker EE Advanced comes with enterprise
 | 
			
		||||
[add-ons](#docker-ee-add-ons) like UCP and DTR.
 | 
			
		||||
the industry to modernize all applications. Docker Enterprise Advanced comes with enterprise
 | 
			
		||||
[add-ons](#docker-ee-add-ons) like Universal Control Plane (UCP) for managing and 
 | 
			
		||||
orchestrating the container runtime, and Docker Trusted Registry (DTR) for storing and 
 | 
			
		||||
securing images in an enterprise grade registry.
 | 
			
		||||
 | 
			
		||||
[Learn more about Docker EE](/ee/supported-platforms/){: class="button outline-btn"}
 | 
			
		||||
[Learn more about Docker Enterprise](/ee/supported-platforms/){: class="button outline-btn"}
 | 
			
		||||
 | 
			
		||||
</div>
 | 
			
		||||
</div><!-- end row -->
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -148,7 +148,7 @@ manually, via a script, or on air-gapped systems.
 | 
			
		|||
    ```
 | 
			
		||||
 | 
			
		||||
    If you need to download a specific Docker EE Engine release, all URLs can be
 | 
			
		||||
    found on this [JSON index](https://download.docker.com/components/engine/windows-server/index.json)
 | 
			
		||||
    found on this [JSON index](https://dockermsft.blob.core.windows.net/dockercontainer/DockerMsftIndex.json)
 | 
			
		||||
 | 
			
		||||
2.  Copy the zip file to the machine where you want to install Docker. In a
 | 
			
		||||
    PowerShell command prompt, use the following commands to extract the archive,
 | 
			
		||||
| 
						 | 
				
			
			@ -222,7 +222,7 @@ To update Docker Engine - Enterprise to the most recent release, specify the
 | 
			
		|||
```powershell
 | 
			
		||||
Install-Package -Name docker -ProviderName DockerMsftProvider -RequiredVersion {{ site.docker_ee_version }} -Update -Force
 | 
			
		||||
```
 | 
			
		||||
The required version number must match a versions available on the [JSON
 | 
			
		||||
The required version number must match a version available on the [JSON
 | 
			
		||||
index](https://dockermsft.blob.core.windows.net/dockercontainer/DockerMsftIndex.json)
 | 
			
		||||
 | 
			
		||||
## Uninstall Docker EE
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -16,7 +16,10 @@ your applications and avoid performance problems along the way.
 | 
			
		|||
 | 
			
		||||
Storage drivers allow you to create data in the writable layer of your container.
 | 
			
		||||
The files won't be persisted after the container is deleted, and both read and
 | 
			
		||||
write speeds are low.
 | 
			
		||||
write speeds are lower than native file system performance. 
 | 
			
		||||
 | 
			
		||||
 > **Note**: Operations that are known to be problematic include write-intensive database storage, 
 | 
			
		||||
particularly when pre-existing data exists in the write-only layer. More details are provided in this document.
 | 
			
		||||
 | 
			
		||||
[Learn how to use volumes](../volumes.md) to persist data and improve performance.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in New Issue