docker/docs
1
0
Fork 0
mirror of https://github.com/docker/docs.git synced 2026-11-05 00:14:17 +03:00
Code Activity

first draft of RNs, swift documentation to config doc, moved stuff to prior rn

Browse Source 
edited cron fixes in RN
edited cron jobs to reflect updates
typo in RN
mentioned users can use 3 parameters to GC
added links to FQDM and upgrade docs
small fixes in GC doc. want to add 2 graphics on line 28
reordered numbering and removed DTR refs
fixed typos
fixed link
removed broken link per https://docker.atlassian.net/browse/DTR-1595
removed another broken link
added two more RN issues for RC2
tweaks to GC
tweaking code in gc doc
added another issue to RNs
minor changes, and adding daemon parameters but need review
added daemon parameters to limit dupe logs

Signed-off-by: Carol Fager-Higgins <carol.fager-higgins@docker.com>
This commit is contained in:
Carol Fager-Higgins
2015-12-10 14:36:21 -08:00
parent e80591e28f
commit 22ed6876c2
7 changed files with 167 additions and 95 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
configuration.md
View File

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

34
install/dtr-ami-byol-launch.md
View File

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

13
install/dtr-vhd-azure.md
View File

@@ -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 <a href="http://www.docker.com/microsoft" target="_blank">read more information about running Docker with Microsoft</a>.
## 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 <a href="https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-fqdn-on-portal/" target="_blank">Microsoft Azure documentation</a>.
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).

6
install/engine-ami-launch.md
View File

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

22
prior-release-notes.md
View File

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

62
release-notes.md
View File

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

92
soft-garbage.md
View File

@@ -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 <username>:<password> -X DELETE https://<DTR HOST>/api/v0/repositories/<namespace>/<reponame>/manifests/<reference>`
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 <username>:<password> -H "Content-Type: application/json" "https://api/v0/admin/jobs" -d "{ \"job\" : \"registryGC\"}"`
curl -X POST -u <username>:<password> -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 <username>:<password> -H 'Content-Type: application/json' -X POST https://<DTR
HOST>/api/v0/admin/settings/registry/garbageCollection/schedule -d '{"schedule":
"<schedule>"}'`
```
curl -u <username>:<password> -H 'Content-Type: application/json' -X POST https://<DTR
HOST>/api/v0/admin/settings/registry/garbageCollection/schedule -d '{"schedule":
"<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 <username>:<password> https://<DTR
HOST>/api/v0/admin/settings/registry/garbageCollection/lastSavings`
```
curl -u <username>:<password> https://<DTR
HOST>/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