diff --git a/configuration.md b/configuration.md index 61347e5f85..5a74d4c95c 100644 --- a/configuration.md +++ b/configuration.md @@ -24,9 +24,10 @@ To start, navigate to the Trusted Registry user interface (UI) > Settings to vie * Authentication settings * Garbage collection * Updates +* Docker daemon (this is set from the Trusted Registry CLI and not the UI) >**Note**: ->Saving changes you've made to settings may restart various services, as follows: +>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 @@ -379,8 +380,10 @@ Set the "Account name", "Account key", "Container", and "Realm" on the [Azure st ### Openstack Swift settings -View the [openstack Swift settings](/registry/configuration.md#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. +View the [openstack Swift settings](/registry/configuration.md#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. ### Yaml configuration file @@ -395,8 +398,8 @@ will need to specify a root directory which will get mounted as a sub-path of ## Authentication -Use the "Authentication" settings to control access -to the Docker Trusted Registry web admin tool and to the Docker Trusted Registry. +Use the "Authentication" settings to control access to the Docker Trusted +Registry web admin tool and to the Docker Trusted Registry. The current authentication methods are `None`, `Managed` and `LDAP`. @@ -423,7 +426,7 @@ to assign those users roles using the Docker Trusted Registry admin UI. * Choose the appropriate button to add one user, or to upload a CSV file containing username, password pairs, and selection boxes for "admin", "read-write", and "read-only" roles. * You can also create, or allow others to create the username, password pair using the - [Account API](http://docs.docker.com/apidocs/v1.3.3/#!/accounts/func1_0) + [Account API](http://docs.docker.com/apidocs/v1.3.3/#!/accounts/func1_0). ### LDAP authentication @@ -478,9 +481,9 @@ output should allow you to confirm which setting you need. * *Use StartTLS*: defaults to unchecked, check to enable StartTLS * *User Base DN*: **required** defaults to null, user base DN in the form (e.g., - dc=example,dc=com) * *User Login Attribute*: **required** defaults to null, user login attribute (e.g., - uid or sAMAccountName) -* *Search User DN*: **required** defaults to null, search user DN (e.g., - domain\username) +* *Search User DN*: **required** defaults to null, search user DN (for example, domain\username) * *Search User Password*: **required** defaults to null, search user password -* *LDAP Sync Interval*: **required** defaults to 1h0m0s, sets the interval for Docker Trusted Registry to sync with the LDAP db. +* *LDAP Sync Interval*: **required** defaults to 1h0m0s, sets the interval for Docker Trusted Registry to sync with the LDAP database. * *User Search Filter*: Users on your LDAP server are synced to Docker Trusted Registry's local database using this 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 @@ -489,9 +492,19 @@ login to the Trusted Registry. * *Admin Group Member Attribute*: **required** This value matches the name of the attribute on this group object which corresponds to the Distinguished Name of the group member objects. -#### Confirm login with current configuration +##### Confirm login with current configuration -You can test your current LDAP configuration before saving it by entering a test username and password and then clicking "Try Login". If the login succeeds, your configuration is working. +You can test your current LDAP configuration before saving it by entering a test +username and password and then clicking "Try Login". If the login succeeds, your +configuration is working. + +## 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` + +To learn about Trusted Registry logs, view the [Logs tab](adminguide.md) in the admin guide documentation. ## Next Steps diff --git a/install/dtr-ami-byol-launch.md b/install/dtr-ami-byol-launch.md index e4f2e12efc..75615a7053 100644 --- a/install/dtr-ami-byol-launch.md +++ b/install/dtr-ami-byol-launch.md @@ -85,7 +85,7 @@ The following steps walk you through the 1-Click Launch settings: 2. Select the Region you want to deploy to from the "Region" dropdown. -3. Select the EC2 Instance type +3. Select the EC2 Instance type. Be sure to check the "Pricing Details" and "Cost Estimator" boxes when changing EC2 Instance types. @@ -112,15 +112,15 @@ The following steps walk you through the 1-Click Launch settings: ## Connect to the Docker Trusted Registry Administration web interface -You administer your Trusted Registry server via the Administration web -interface (hereafter referred to as *DTR Administration web interface*). +You administer your Trusted Registry server through the Administration web +interface (hereafter referred to as *Trusted Registry Administration web interface*). -You can configure your own custom DNS names for your EC2 instance -using CNAME records and so forth. Or, you can use the default DNS names provided by -AWS. These instructions use the default DNS name provided by AWS. +You can configure your own custom DNS names for your EC2 instance using CNAME +records and so forth. Or, you can use the default DNS names provided by AWS. +These instructions use the default DNS name provided by AWS. -The DTR Administration web interface is exposed on port 443 (HTTPS) of -the EC2 instance. To connect to the DTR Administration web +The Trusted Registry Administration web interface is exposed on port 443 (HTTPS) +of the EC2 instance. To connect to the Trusted Registry Administration web interface: 1. Log into the AWS Console. @@ -137,23 +137,23 @@ interface: 7. Copy the Public DNS or Public IP into your browser's address bar and press `return`. - > **Note:** Connecting to the DTR Administration web + > **Note:** Connecting to the Trusted Registry Administration web interface may result in a certificate related browser warning. This is expected behavior and you can bypass the warning. - The interface prompts you for the username and password. + The interface prompts you for the username and password. 8. Enter "admin" for the username. 9. For the password, use the EC2 Instance ID. - You'll find the Instance ID on the "Description" tab on the EC2 Dashboard as shown in the image below: + You'll find the Instance ID on the "Description" tab on the EC2 Dashboard as shown in the following image: ![](images/aws-instance-id.png) ## Configure the Docker Trusted Registry Service -When you first login to the DTR Administration web interface you are prompted to complete two configuration items: +When you first log into the Trusted Registry Administration web interface, you are prompted to complete two configuration items: 1. Configure the "Domain name" on the "General" tab of the "Settings" page. @@ -161,9 +161,9 @@ When you first login to the DTR Administration web interface you are prompted to Enter your desired domain name and click the "Save and restart" button at the bottom of the page. - After the Trusted Registry server restarts, return to the DTR Administration web interface. The browser displays another certificate related browser warning. Changing the Domain Name property of your Trusted Registry server generates a new self-signed certificate. Again, this is expected behavior and you can bypass the warning. + After the Trusted Registry server restarts, return to the Trusted Registry Administration web interface. The browser displays another certificate related browser warning. Changing the Domain Name property of your Trusted Registry server generates a new self-signed certificate. Again, this is expected behavior and you can bypass the warning. - Log back in to the DTR Administration web interface. + Log back in to the Trusted Registry Administration web interface. 2. License your copy of Docker Trusted Registry from the "License" tab of the "Settings" page. @@ -173,13 +173,13 @@ When you first login to the DTR Administration web interface you are prompted to From the Docker Trusted Registry Administration web interface, select "Settings" and then "License". Under the "Apply a new license" heading select "Choose File". Select your downloaded license file and click "Save and restart". -> **Note:** Restarting your Trusted Registry from the DTR Administration web interface, or as part of the above procedures, does not restart the EC2 instance. Therefore, the Public IP and Public DNS of the EC2 instance does not change. +> **Note:** Restarting your Trusted Registry from the Trusted Registry Administration web interface, or as part of the above procedures, does not restart the EC2 instance. Therefore, the Public IP and Public DNS of the EC2 instance does not change. -Log into the DTR Administration web interface and change the default password for the "admin" account from the "Auth" tab on the "Settings" page. +Log into the Trusted Registry Administration web interface and change the default password for the "admin" account. Navigate to Settings > Auth. Your Docker Trusted Registry server is now ready for use. ## Next Steps -For more information on using DTR, go to the +For more information on using Trusted Registry, go to the [User's Guide](https://docs.docker.com/docker-trusted-registry/userguide/). diff --git a/install/dtr-vhd-azure.md b/install/dtr-vhd-azure.md index 108d5d1cbf..89184d05ec 100644 --- a/install/dtr-vhd-azure.md +++ b/install/dtr-vhd-azure.md @@ -18,7 +18,6 @@ network. If you have not already done so, make sure you have first read the Before installing, you may want to read more information about running Docker with Microsoft. - ## Prerequisites This installation requires that you "bring your own license" (BYOL). This means @@ -122,7 +121,8 @@ You should be able to complete the installation in under thirty minutes. # Set the Trusted Registry domain name -At this point, the Docker Trusted Registry Administrator site should warn that the Domain Name is not set. +At this point, the Docker Trusted Registry Administrator site should warn that +the Domain Name is not set. While you can use the public IP address that the portal created, you may find it more convenient to create a fully qualified domain name (FQDN). Refer to the Microsoft Azure documentation. 1. Select Settings from the global nav bar at the top of the page. @@ -200,8 +200,9 @@ See [Docker Trusted Registry Authentication settings](../configuration.md#authen ## See also -* [Install the CS Engine](install-csengine.md) -* To configure for your environment, see the[configuration instructions](../configuration.md). -* To use Docker Trusted Registry, see the User guide[../userguide.md). -* To make administrative changes, see [the Admin guide](../adminguide.md). +* [Upgrade information](upgrade.md) to upgrade either the Docker Trusted Registry or the commercially supported engine. +* [Install the CS Engine](install-csengine.md). +* To configure for your environment, see the [configuration instructions](../configuration.md). +* To use Docker Trusted Registry, see the [User guide](../userguide.md). +* To make administrative changes, see the[Admin guide](../adminguide.md). * To see previous changes, see [the release notes](../release-notes.md). diff --git a/install/engine-ami-launch.md b/install/engine-ami-launch.md index 89a6439f3b..592ea94604 100644 --- a/install/engine-ami-launch.md +++ b/install/engine-ami-launch.md @@ -132,7 +132,7 @@ To connect to the command line of your Docker Engine EC2 Instance: Connecting to the Docker Engine EC2 Instance will gnerate and authentication warning. This is expected behavior and you can continue. - If you're connecting from a Windows machine, you'll need to have an SSH client isntalled and in your PATH variable. + If you're connecting from a Windows machine, you'll need to have an SSH client installed and in your PATH variable. For more information about connecting to your Docker Engine EC2 Instance over SSH, right-click your EC2 Instance and choose "Connect". @@ -267,9 +267,9 @@ This guide assumes your Docker Trusted Registry is reachable at "ec2-52-24-229-1 You have now successfully deployed the *Docker Engine for AWS (Business Day Support)* AMI and configured it to work with *Docker Trusted Registry for AWS (Business Day Support)*. -## Next Steps +## Next step -For more information on using Docker Enginer in AWS, visit our [AWS Documentation](https://www.docker.com/aws). +For more information on using Docker Engineer in AWS, go to the [AWS Documentation](https://www.docker.com/aws). ## See also diff --git a/prior-release-notes.md b/prior-release-notes.md index fa8702e12e..70bf6545e4 100644 --- a/prior-release-notes.md +++ b/prior-release-notes.md @@ -10,8 +10,24 @@ weight=101 # Release Notes +This document contains the previous versions of the Docker Trusted Registry and commercially supported engine release notes. + ## Docker Trusted Registry +### Docker Trusted Registry 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. + ### Docker Trusted Registry 1.3.2 (16 September 2015) @@ -94,10 +110,8 @@ Customers who are currently using DHE 1.0 **must** follow the [upgrading instruc (21 May 2015) For customers running Docker Engine on [supported versions of RedHat Enterprise -Linux](https://www.docker.com/enterprise/support/) with [SELinux -enabled]( -https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html -), the `docker build` and `docker run` +Linux](https://www.docker.com/enterprise/support/) with SELinux +enabled, the `docker build` and `docker run` commands will not have DNS host name resolution and bind-mounted volumes may not be accessible. As a result, customers with SELinux will be unable to use hostname-based network diff --git a/release-notes.md b/release-notes.md index 6217787667..2919fa76d8 100644 --- a/release-notes.md +++ b/release-notes.md @@ -18,6 +18,42 @@ These notes refer to the current and immediately prior releases of Docker Trusted Registry and the commercially supported Docker Engine. For notes on older versions of these, see the [prior release notes archive](prior-release-notes.md). +# Docker Trusted Registry 1.4.2 +(18 December 2015) + +Release notes for the Trusted Registry contain the following sections: + +* New feature +* Fixed or updated with this release + +### New feature +This release introduces using Openstack Swift as a storage backend. Refer to the [configuration documentation](configuration.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. + # Docker Trusted Registry 1.4.1 (24 November 2015) @@ -150,21 +186,6 @@ the following steps: `sudo docker push my.dtr.host/devops/nginx` - -### Docker Trusted Registry 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. - ## Commercially Supported Docker Engine Commercially Supported (CS) Docker Engine is a packaged release that identifies @@ -244,19 +265,18 @@ mailing list, or find us in #docker-security. (21 May 2015) For customers running Docker Engine on [supported versions of RedHat Enterprise -Linux](https://www.docker.com/enterprise/support/) with [SELinux -enabled]( -https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html -), the `docker build` and `docker run` +Linux](https://www.docker.com/enterprise/support/) with SELinux +enabled, the `docker build` and `docker run` commands will not have DNS host name resolution and bind-mounted volumes may not be accessible. As a result, customers with SELinux will be unable to use hostname-based network access in either `docker build` or `docker run`, nor will they be able to `docker run` containers that use `--volume` or `-v` bind-mounts (with an incorrect SELinux label) in -their environment. By installing Docker Engine 1.6.2-cs5, customers can use Docker as intended on RHEL with SELinux enabled. +their environment. By installing Docker Engine 1.6.2-cs5, customers can use +Docker as intended on RHEL with SELinux enabled. -For example, you see will failures like: +For example, you see will failures such as: ``` [root@dtr ~]# docker -v diff --git a/soft-garbage.md b/soft-garbage.md index fb20e9f111..29b4da39db 100644 --- a/soft-garbage.md +++ b/soft-garbage.md @@ -11,20 +11,23 @@ weight=12 # Overview This document describes the two-step process of removing an image from the -Trusted Registry. This process is first performed by users wanting to remove -their images then, an administrator removes those images mainly through a -recurring job. +Trusted Registry. This process is first performed by developers wanting to +remove their images and marking them for deletion. Then, an administrator +removes those images mainly through a recurring garbage collection job. -## Images and manifests +## Understand the role of images and manifests in image deletion -Manifests describe images. They reference a list of layers and hold metadata -about the image. Manifests can share layers. Tags point to manifests. You can +Manifests are a type of file that describe images. They reference a list of +layers and hold metadata about the described image. Manifests can also share +layers. Tags, which are labels applied to images, point to manifests. You can reference an image by tag or directly by the hash of the manifest. If you purposefully delete one of those manifests and the image layers referenced by that manifest become orphaned, then they can be removed during the garbage collection job. This occurs if they are not referenced by other manifests. -**Note**: Since many developers may use a base image for future images, it is possible that there will be image layers that may never be deleted. There might be other manifests that point to layers of the base image which could still be used by others. +Since many developers may use a base image for future images, it is possible that there will be image layers that will never be deleted. There might +be other manifests that point to layers of the base image which could still be +used by others. ## Prerequisites You need an image to remove. @@ -34,56 +37,77 @@ You need an image to remove. Developers may want to remove an image for several reasons. Examples include: -* the image is outdated and there is a new version -* the image is no longer to be used +* The image is outdated and there is a new version. +* The image is no longer used. -If a developer removes the manifest of an image, then it is called a -soft deletion. Access to the image has been removed although physically, it is -still in the repository. +If a developer removes the manifest of an image, then it is called a soft +deletion. Developers won't be able to access that image, although physically, it +it still in the repository. -Soft deletion occurs through the following API endpoint `DELETE`. From the command line type: +To perform a soft deletion, open a Trusted Registry command line and type: `curl -u : -X DELETE https:///api/v0/repositories///manifests/` You can only delete one image at a time and you must also be authenticated as a user who has "write" level access to the repository. -## Garbage collection +## Set up garbage collection -Administrators may want to optimize registry storage and free up space. They can -set up a recurring job where the system searches for any layers that are not -referenced by any manifests and removes them. It can be either performed immediately, or more realistically, on a periodic automatic schedule. System -administrators can perform garbage collection of unreferenced layers tags in two ways: +Trusted Registry administrators can optimize registry storage and free up space. +They do this by setting up a recurring garbage collection job (cron job) where +the system searches for any layers that are not referenced by any manifests and +removes them. Administrators can perform this garbage collection process +immediately, or more realistically, on a periodic automatic schedule. +They perform garbage collection of unreferenced layers tags either +through a Trusted Registry CLI or through the Trusted Registry UI. -* Immediately, by typing the following: +If administrators choose to have the garbage collection process performed +immediately, they can type in a Trusted Registry CLI: -`curl -X POST -u : -H "Content-Type: application/json" "https://api/v0/admin/jobs" -d "{ \"job\" : \"registryGC\"}"` + curl -X POST -u : -H "Content-Type: application/json" "https://api/v0/admin/jobs" -d "{ \"job\" : \"registryGC\"}" -* Routinely, through a cron job, as you can see in the following example: +However, it is more common to set up the garbage collection cron job to be performed routinely as seen in the following example: -`curl -u : -H 'Content-Type: application/json' -X POST https:///api/v0/admin/settings/registry/garbageCollection/schedule -d '{"schedule": -""}'` +``` + curl -u : -H 'Content-Type: application/json' -X POST https:///api/v0/admin/settings/registry/garbageCollection/schedule -d '{"schedule": + ""}' +``` -See the [cron package](https://godoc.org/github.com/robfig/cron) for other -examples depending on your needs. An example schedule: `0 0 3 * * SAT` (every -Saturday at 3 AM). +Trusted Registry administrators can also set the cron job through the Trusted +Registry UI. Navigate to Settings > Garbage collection to schedule a job. -You can also set the cron job through the Trusted Registry UI. Note that it is -not as granular as setting a cron job from the command line. Navigate to -Settings > Garbage collection and schedule your job. +### A cron job example +A Trusted Registry cron format has **at most** four fields representing hour, +day, month, and day of week respectively. Moreover, administrators can use the +following shortcuts: `@yearly`, `@annually`, `@monthly`, `@weekly`, `@daily`, +`@midnight`, `@hourly` in either the UI or through the Trusted Registry CLI. If +administrators choose to use the shortcuts, then only one can be used. + +An example schedule of nightly at midnight would be: `0 * * *`. Or alternately, +for the same schedule, you could enter: @midnight. You can also enter less than +four parameters if that's all the job requires. + +See the [package cron page](https://godoc.org/github.com/robfig/cron) for other +examples depending on your company's requirements. + +>**Note**: The prior link displays examples using more than four fields. When Trusted Registry administrators set up a cron schedule, they are limited to only the four fields representing hour, day, month, and day of week. Your downtime depends on the number of images and/or layers that are to be deleted. Docker recommends performing garbage collection weekly during off time. While garbage collection is occurring, anyone who tries to push an image will get an error message. -## See the results of the garbage collection +## See your garbage collection results -View the results by running the following example in a command line: +View your results by running the following example in a Trusted Registry CLI: -`curl -u : https:///api/v0/admin/settings/registry/garbageCollection/lastSavings` +``` +curl -u : https:///api/v0/admin/settings/registry/garbageCollection/lastSavings +``` + +The results are also displayed in the Trusted Registry UI by navigating to Settings > Garbage collection. ### See also