diff --git a/datacenter/ucp/1.1/installation/system-requirements.md b/datacenter/ucp/1.1/installation/system-requirements.md index b011b3b6c1..a68e71c053 100644 --- a/datacenter/ucp/1.1/installation/system-requirements.md +++ b/datacenter/ucp/1.1/installation/system-requirements.md @@ -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) \ No newline at end of file +* [Plan a production installation](plan-production-install.md) diff --git a/datacenter/ucp/2.0/guides/configuration/index.md b/datacenter/ucp/2.0/guides/configuration/index.md index d8ee7ff2b7..a1f22a22c4 100644 --- a/datacenter/ucp/2.0/guides/configuration/index.md +++ b/datacenter/ucp/2.0/guides/configuration/index.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 diff --git a/datacenter/ucp/2.0/guides/configuration/integrate-with-dtr.md b/datacenter/ucp/2.0/guides/configuration/integrate-with-dtr.md index 8a6f2623fb..2404bed0e1 100644 --- a/datacenter/ucp/2.0/guides/configuration/integrate-with-dtr.md +++ b/datacenter/ucp/2.0/guides/configuration/integrate-with-dtr.md @@ -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) diff --git a/docker-hub/publish/index.md b/docker-hub/publish/index.md index 868d9965ba..6b5511c88d 100644 --- a/docker-hub/publish/index.md +++ b/docker-hub/publish/index.md @@ -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 diff --git a/docker-hub/publish/publisher_faq.md b/docker-hub/publish/publisher_faq.md index 5f3003c395..5500002e51 100644 --- a/docker-hub/publish/publisher_faq.md +++ b/docker-hub/publish/publisher_faq.md @@ -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. diff --git a/ee/dtr/admin/configure/external-storage/storage-backend-migration.md b/ee/dtr/admin/configure/external-storage/storage-backend-migration.md index 6d883cc109..b8eca97dde 100644 --- a/ee/dtr/admin/configure/external-storage/storage-backend-migration.md +++ b/ee/dtr/admin/configure/external-storage/storage-backend-migration.md @@ -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 :$TOKEN -X POST "https:///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 :$TOKEN -X POST "https:///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 :$TOKEN -X POST "https:///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 :$TOKEN -X POST "https:///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) diff --git a/ee/dtr/user/manage-images/sign-images/index.md b/ee/dtr/user/manage-images/sign-images/index.md index 9bac5a1991..f2409bfc34 100644 --- a/ee/dtr/user/manage-images/sign-images/index.md +++ b/ee/dtr/user/manage-images/sign-images/index.md @@ -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 ![image without signature](../../../images/sign-an-image-1.svg) @@ -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. ![DTR](../../../images/sign-an-image-3.png){: .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 diff --git a/ee/ucp/admin/install/plan-installation.md b/ee/ucp/admin/install/plan-installation.md index d3b7e0bfba..b4e7a80739 100644 --- a/ee/ucp/admin/install/plan-installation.md +++ b/ee/ucp/admin/install/plan-installation.md @@ -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. diff --git a/index.md b/index.md index 7959711d85..8ec4ccc76a 100644 --- a/index.md +++ b/index.md @@ -22,14 +22,14 @@ production servers in the cloud. Total reading time is less than an hour.
-## 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');"}
@@ -52,15 +52,17 @@ channel for more predictability.
-### 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"}
diff --git a/install/windows/docker-ee.md b/install/windows/docker-ee.md index 31f53e3abb..9f8a7fcf99 100644 --- a/install/windows/docker-ee.md +++ b/install/windows/docker-ee.md @@ -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 diff --git a/storage/storagedriver/index.md b/storage/storagedriver/index.md index e55ecfacc2..7144701b1d 100644 --- a/storage/storagedriver/index.md +++ b/storage/storagedriver/index.md @@ -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.