Merge branch 'master' into consolidation-changes

This commit is contained in:
Jeffrey Morgan 2018-11-19 15:41:14 -05:00
commit dacad06fbd
15 changed files with 383 additions and 93 deletions

View File

@ -0,0 +1,140 @@
GEM
remote: https://rubygems.org/
specs:
activesupport (4.1.11)
i18n (~> 0.6, >= 0.6.9)
json (~> 1.7, >= 1.7.7)
minitest (~> 5.1)
thread_safe (~> 0.1)
tzinfo (~> 1.1)
autoprefixer-rails (5.2.0.1)
execjs
json
celluloid (0.16.0)
timers (~> 4.0.0)
chunky_png (1.3.4)
coffee-script (2.4.1)
coffee-script-source
execjs
coffee-script-source (1.9.1.1)
compass (1.0.3)
chunky_png (~> 1.2)
compass-core (~> 1.0.2)
compass-import-once (~> 1.0.5)
rb-fsevent (>= 0.9.3)
rb-inotify (>= 0.9)
sass (>= 3.3.13, < 3.5)
compass-core (1.0.3)
multi_json (~> 1.0)
sass (>= 3.3.0, < 3.5)
compass-import-once (1.0.5)
sass (>= 3.2, < 3.5)
erubis (2.7.0)
execjs (2.5.2)
ffi (1.9.8)
haml (4.0.6)
tilt
hike (1.2.3)
hitimes (1.2.2)
hooks (0.4.0)
uber (~> 0.0.4)
i18n (0.7.0)
json (1.8.3)
kramdown (1.7.0)
libv8 (3.16.14.7)
listen (2.10.1)
celluloid (~> 0.16.0)
rb-fsevent (>= 0.9.3)
rb-inotify (>= 0.9)
middleman (3.3.12)
coffee-script (~> 2.2)
compass (>= 1.0.0, < 2.0.0)
compass-import-once (= 1.0.5)
execjs (~> 2.0)
haml (>= 4.0.5)
kramdown (~> 1.2)
middleman-core (= 3.3.12)
middleman-sprockets (>= 3.1.2)
sass (>= 3.4.0, < 4.0)
uglifier (~> 2.5)
middleman-autoprefixer (2.4.4)
autoprefixer-rails (~> 5.2.0)
middleman-core (>= 3.3.3)
middleman-core (3.3.12)
activesupport (~> 4.1.0)
bundler (~> 1.1)
erubis
hooks (~> 0.3)
i18n (~> 0.7.0)
listen (>= 2.7.9, < 3.0)
padrino-helpers (~> 0.12.3)
rack (>= 1.4.5, < 2.0)
rack-test (~> 0.6.2)
thor (>= 0.15.2, < 2.0)
tilt (~> 1.4.1, < 2.0)
middleman-gh-pages (0.0.3)
rake (> 0.9.3)
middleman-sprockets (3.4.2)
middleman-core (>= 3.3)
sprockets (~> 2.12.1)
sprockets-helpers (~> 1.1.0)
sprockets-sass (~> 1.3.0)
middleman-syntax (2.0.0)
middleman-core (~> 3.2)
rouge (~> 1.0)
minitest (5.7.0)
multi_json (1.11.1)
padrino-helpers (0.12.5)
i18n (~> 0.6, >= 0.6.7)
padrino-support (= 0.12.5)
tilt (~> 1.4.1)
padrino-support (0.12.5)
activesupport (>= 3.1)
rack (1.6.11)
rack-test (0.6.3)
rack (>= 1.0)
rake (10.4.2)
rb-fsevent (0.9.5)
rb-inotify (0.9.5)
ffi (>= 0.5.0)
redcarpet (3.3.2)
ref (1.0.5)
rouge (1.9.0)
sass (3.4.14)
sprockets (2.12.3)
hike (~> 1.2)
multi_json (~> 1.0)
rack (~> 1.0)
tilt (~> 1.1, != 1.3.0)
sprockets-helpers (1.1.0)
sprockets (~> 2.0)
sprockets-sass (1.3.1)
sprockets (~> 2.0)
tilt (~> 1.1)
therubyracer (0.12.2)
libv8 (~> 3.16.14.0)
ref
thor (0.19.1)
thread_safe (0.3.5)
tilt (1.4.1)
timers (4.0.1)
hitimes
tzinfo (1.2.2)
thread_safe (~> 0.1)
uber (0.0.13)
uglifier (2.7.1)
execjs (>= 0.3.0)
json (>= 1.8.0)
PLATFORMS
ruby
DEPENDENCIES
middleman (~> 3.3.10)
middleman-autoprefixer (~> 2.4.4)
middleman-gh-pages (~> 0.0.3)
middleman-syntax (~> 2.0.0)
rake (~> 10.4.2)
redcarpet (~> 3.3.2)
rouge (~> 1.9.0)
therubyracer (~> 0.12.1)

View File

@ -31,7 +31,7 @@ mkdir /tmp/mydir && sudo mount -t nfs <nfs server>:<directory>
One way to configure DTR to use an NFS directory is at install time:
```none
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ dtr_version }} install \
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }} install \
--nfs-storage-url <nfs-storage-url> \
<other options>
```
@ -50,7 +50,7 @@ If you want to start using the new DTR built-in support for NFS you can
reconfigure DTR:
```none
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ dtr_version }} reconfigure \
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }} reconfigure \
--nfs-storage-url <nfs-storage-url>
```
@ -58,7 +58,7 @@ If you want to reconfigure DTR to stop using NFS storage, leave the option
in blank:
```none
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ dtr_version}} reconfigure \
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version}} reconfigure \
--nfs-storage-url ""
```

View File

@ -21,9 +21,9 @@ firewall.
You can use DTR as part of your continuous integration, and continuous
delivery processes to build, ship, and run your applications.
DTR has a web based user interface that allows authorized users in your
organization to browse docker images. It provides information about
who pushed what image at what time. It even allows you to see what dockerfile
DTR has a web user interface that allows authorized users in your
organization to browse Docker images. It provides information about
who pushed what image at what time. It even allows you to see what Dockerfile
lines were used to produce the image and, if security scanning is enabled, to
see a list of all of the software installed in your images.
@ -35,27 +35,27 @@ and metadata such that if a machine fails, DTR continues to operate and can be r
## Efficiency
DTR has the ability to [cache images closer to users](admin/configure/deploy-caches/index.md)
to reduce the amount of bandwidth used during docker pulls.
to reduce the amount of bandwidth used when pulling Docker images.
DTR has the ability to [clean up unreferenced manifests and layers](admin/configure/garbage-collection.md).
## Built-in access control
DTR uses the same authentication mechanism as Docker Universal Control Plane.
Users can be managed manually or synched from LDAP or Active Directory. DTR
Users can be managed manually or synchronized from LDAP or Active Directory. DTR
uses [Role Based Access Control](admin/manage-users/index.md) (RBAC) to allow you to implement fine-grained
access control policies for who has access to your Docker images.
access control policies for your Docker images.
## Security scanning
DTR has a built in security scanner that can be used to discover what versions
DTR has a built-in security scanner that can be used to discover what versions
of software are used in your images. It scans each layer and aggregates the
results to give you a complete picture of what you are shipping as a part of
your stack. Most importantly, it co-relates this information with a
vulnerability database that is kept up to date through
[periodic updates](admin/configure/set-up-vulnerability-scans.md). This
gives you
[unprecedented insight into your exposure to known security threats](user/manage-images/scan-images-for-vulnerabilities.md).
your stack. Most importantly, it correlates this information with a
vulnerability database that is kept up to date through [periodic
updates](admin/configure/set-up-vulnerability-scans.md). This
gives you [unprecedented insight into your exposure to known security
threats](user/manage-images/scan-images-for-vulnerabilities.md).
## Image signing
@ -69,3 +69,4 @@ the [DTR-specific notary documentation](user/manage-images/sign-images/index.md)
* [DTR architecture](architecture.md)
* [Install DTR](admin/install/index.md)

View File

@ -31,7 +31,7 @@ mkdir /tmp/mydir && sudo mount -t nfs <nfs server>:<directory> /tmp/mydir
One way to configure DTR to use an NFS directory is at install time:
```bash
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ dtr_version }} install \
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }} install \
--nfs-storage-url <nfs-storage-url> \
<other options>
```
@ -51,7 +51,7 @@ To take advantage of the new DTR built-in support for NFS, you can
reconfigure DTR to use NFS:
```bash
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ dtr_version }} reconfigure \
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }} reconfigure \
--nfs-storage-url <nfs-storage-url>
```
@ -59,7 +59,7 @@ To reconfigure DTR to stop using NFS storage, leave the `--nfs-storage-url` opti
blank:
```bash
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ dtr_version}} reconfigure \
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version}} reconfigure \
--nfs-storage-url ""
```

View File

@ -41,10 +41,10 @@ replicas.
## Cluster status
The `/api/v0/meta/cluster_status` [endpoint](/reference/dtr/2.5/api/)
requires administrator credentials, and returns a JSON object for the entire
cluster as observed by the replica being queried. You can authenticate your
requests using HTTP basic auth.
The `/api/v0/meta/cluster_status` [endpoint](/reference/dtr/{{ site.dtr_version
}}/api/) requires administrator credentials, and returns a JSON object for the
entire cluster as observed by the replica being queried. You can authenticate
your requests using HTTP basic auth.
```bash
curl -ksL -u <user>:<pass> https://<dtr-domain>/api/v0/meta/cluster_status
@ -72,4 +72,4 @@ troubleshoot, try [troubleshooting using logs](troubleshoot-with-logs.md).
## Where to go next
- [Troubleshoot with logs](troubleshoot-with-logs.md)
- [Troubleshoot with logs](troubleshoot-with-logs.md)

View File

@ -8,7 +8,7 @@ Docker Trusted Registry (DTR) is the enterprise-grade image storage solution
from Docker. You install it behind your firewall so that you can securely store
and manage the Docker images you use in your applications.
## Image management
## Image and job management
DTR can be installed on-premises, or on a virtual private
cloud. And with it, you can store your Docker images securely, behind your
@ -17,11 +17,10 @@ firewall.
You can use DTR as part of your continuous integration, and continuous
delivery processes to build, ship, and run your applications.
DTR has a web based user interface that allows authorized users in your
organization to browse docker images. It provides information about
who pushed what image at what time. It even allows you to see what dockerfile
DTR has a web user interface that allows authorized users in your
organization to browse Docker images and [review repository events](/ee/dtr/user/audit-repository-events/). It even allows you to see what Dockerfile
lines were used to produce the image and, if security scanning is enabled, to
see a list of all of the software installed in your images.
see a list of all of the software installed in your images. Additionally, you can now [review and audit jobs on the web interface](/ee/dtr/admin/manage-jobs/audit-jobs-via-ui/).
## Availability
@ -31,23 +30,23 @@ and metadata such that if a machine fails, DTR continues to operate and can be r
## Efficiency
DTR has the ability to [cache images closer to users](admin/configure/deploy-caches/index.md)
to reduce the amount of bandwidth used during docker pulls.
to reduce the amount of bandwidth used when pulling Docker images.
DTR has the ability to [clean up unreferenced manifests and layers](admin/configure/garbage-collection.md).
## Built-in access control
DTR uses the same authentication mechanism as Docker Universal Control Plane.
Users can be managed manually or synched from LDAP or Active Directory. DTR
Users can be managed manually or synchronized from LDAP or Active Directory. DTR
uses [Role Based Access Control](admin/manage-users/index.md) (RBAC) to allow you to implement fine-grained
access control policies for who has access to your Docker images.
access control policies for your Docker images.
## Security scanning
DTR has a built in security scanner that can be used to discover what versions
DTR has a built-in security scanner that can be used to discover what versions
of software are used in your images. It scans each layer and aggregates the
results to give you a complete picture of what you are shipping as a part of
your stack. Most importantly, it co-relates this information with a
your stack. Most importantly, it correlates this information with a
vulnerability database that is kept up to date through [periodic
updates](admin/configure/set-up-vulnerability-scans.md). This
gives you [unprecedented insight into your exposure to known security

View File

@ -30,7 +30,7 @@ to upgrade your installation to the latest release.
* Web Interface
* Online garbage collection is no longer an experimental feature. Users can now write to DTR and push images during garbage collection. [Learn about garbage collection](/ee/dtr/admin/configure/garbage-collection/).
* Repository admins can now enable tag pruning for every repository that they manage by adding a pruning policy or setting a tag limit. [Learn about tag pruning](/ee/dtr/user/tag-pruning).
* Users can now review and audit repository events on the web interface with the addition of the **Activity** tab on each repository.[Learn about repository event audits](/ee/dtr/user/audit-repository-events/).
* Users can now review and audit repository events on the web interface with the addition of the **Activity** tab on each repository. [Learn about repository event audits](/ee/dtr/user/audit-repository-events/).
* DTR admins can now enable auto-deletion of repository events based on specified conditions. [Learn about repository event auto-deletion](/ee/dtr/admin/configure/auto-delete-repo-events/).
* DTR admins can now review and audit jobs on the web interface with the addition of **Job Logs** within System settings. [Learn about job audits on the web interface](/ee/dtr/admin/manage-jobs/audit-jobs-via-ui/).
* DTR admins can now enable auto-deletion of job logs based on specified conditions. [Learn about job log auto-deletion](/ee/dtr/admin/manage-jobs/auto-delete-job-logs/).

View File

@ -6,14 +6,14 @@ keywords: dtr, events, log, activity stream
## Overview
Starting in DTR 2.6, each repository page includes an **Activity** tab which displays a sortable and paginated list of the most recent events within the repository. This offers better visibility along with the ability to audit events. Event types listed will vary according to your [repository permission level](../../admin/manage-users/permission-levels/). Additionally, DTR admins can [enable auto-deletion of repository events](../../admin/configure/auto-delete-repo-events/) as part of maintenance and cleanup.
Starting in DTR 2.6, each repository page includes an **Activity** tab which displays a sortable and paginated list of the most recent events within the repository. This offers better visibility along with the ability to audit events. Event types listed will vary according to your [repository permission level](/ee/dtr/admin/manage-users/permission-levels/). Additionally, DTR admins can [enable auto-deletion of repository events](/ee/dtr/admin/configure/auto-delete-repo-events/) as part of maintenance and cleanup.
In the following section, we will show you how to view and audit the list of events in a repository. We will also cover the event types associated with your permission level.
## View List of Events
As of DTR 2.3, admins were able to view a list of DTR events [using the API](../../../../datacenter/dtr/2.3/reference/api/#!/events/GetEvents). DTR 2.6 enhances that feature by showing a permission-based events list for each repository page on the web interface. To view the list of events within a repository, do the following:
1. Navigate to `https://<dtr-url>`and log in with your UCP credentials.
As of DTR 2.3, admins were able to view a list of DTR events [using the API](/datacenter/dtr/2.3/reference/api/#!/events/GetEvents). DTR 2.6 enhances that feature by showing a permission-based events list for each repository page on the web interface. To view the list of events within a repository, do the following:
1. Navigate to `https://<dtr-url>` and log in with your UCP credentials.
2. Select **Repositories** on the left navigation pane, and then click on the name of the repository that you want to view. Note that you will have to click on the repository name following the `/` after the specific namespace for your repository.
@ -21,7 +21,7 @@ As of DTR 2.3, admins were able to view a list of DTR events [using the API](../
* If you're a repository or a DTR admin, uncheck "Exclude pull" to view pull events. This should give you a better understanding of who is consuming your images.
* To update your event view, select a different time filter from the drop-down list.
![](../../images/manage-repo-events-0.png){: .img-fluid .with-border}
![](/ee/dtr/images/manage-repo-events-0.png){: .img-fluid .with-border}
### Activity Stream
@ -31,12 +31,12 @@ The following table breaks down the data included in an event and uses the highl
| Event Detail | Description | Example |
|:----------------|:-------------------------------------------------|:--------|
| Label | Friendly name of the event. | `Create Promotion Policy`
| Repository | This will always be the repository in review following the `<user-or-org>/<repository_name>` convention outlined in [Create a Repository](../manage-images/#create-a-repository). | `test-org/test-repo-1` |
| Repository | This will always be the repository in review following the `<user-or-org>/<repository_name>` convention outlined in [Create a Repository](/ee/dtr/user/manage-images/#create-a-repository). | `test-org/test-repo-1` |
| Tag | Tag affected by the event, when applicable. | `test-org/test-repo-1:latest` where `latest` is the affected tag|
| SHA | The [digest value](../../../../registry/spec/api/#content-digests) for `CREATE` operations such as creating a new image tag or a promotion policy. | `sha256:bbf09ba3` |
| SHA | The [digest value](/registry/spec/api/#content-digests) for `CREATE` operations such as creating a new image tag or a promotion policy. | `sha256:bbf09ba3` |
| Type | Event type. Possible values are: `CREATE`, `GET`, `UPDATE`, `DELETE`, `SEND`, `FAIL` and `SCAN` | `CREATE` |
| Initiated by | The actor responsible for the event. For user-initiated events, this will reflect the user ID and link to that user's profile. For image events triggered by a policy &ndash; pruning, pull / push mirroring, or promotion &ndash; this will reflect the relevant policy ID except for manual promotions where it reflects `PROMOTION MANUAL_P`, and link to the relevant policy page. Other event actors may not include a link. | `PROMOTION CA5E7822` |
| Date and Time | When the event happened in your configured time zone. | `9/13/2018 9:59 PM` |
| Date and Time | When the event happened in your configured time zone. | 2018 9:59 PM` |
### Event Audits
@ -44,18 +44,18 @@ Given the level of detail on each event, it should be easy for DTR and security
### Event Permissions
For more details on different permission levels within DTR, see [Authentication and authorization in DTR](../../admin/manage-users/) to understand the minimum level required to view the different repository events.
For more details on different permission levels within DTR, see [Authentication and authorization in DTR](/ee/dtr/admin/manage-users/) to understand the minimum level required to view the different repository events.
| Repository Event | Description | Minimum Permission Level |
|:----------------|:---------------------------------------------------| :----------------|
| Push | Refers to "Create Manifest" and "Update Tag" events. Learn more about [pushing images](../manage-images/pull-and-push-images/#push-the-image). | Authenticated Users |
| Scan | Requires [security scanning to be set up](../../admin/configure/set-up-vulnerability-scans/) by a DTR admin. Once enabled, this will display as a `SCAN` event type. | Authenticated Users |
| Promotion | Refers to a "Create Promotion Policy" event which links to the **Promotions** tab of the repository where you can edit the existing promotions. See [Promotion Policies](../promotion-policies/) for different ways to promote an image. | Repository Admin |
| Delete | Refers to "Delete Tag" events. Learn more about [deleting images](../manage-images/delete-images). | Authenticated Users |
| Pull | Refers to "Get Tag" events. Learn more about [pulling images](../manage-images/pull-and-push-images/#pull-an-image). | Repository Admin |
| Mirror |Refers to "Pull mirroring" and "Push mirroring" events. See [Mirror images to another registry](../promotion-policies/#mirror-images-to-another-registry) and [Mirror images from another registry](../promotion-policies/#mirror-images-from-another-registry) for more details. | Repository Admin |
| Create repo | Refers to "Create Repository" events. See [Create a repository](../manage-images/) for more details. | Authenticated Users |
| Push | Refers to "Create Manifest" and "Update Tag" events. Learn more about [pushing images](/ee/dtr/user/manage-images/pull-and-push-images/#push-the-image). | Authenticated Users |
| Scan | Requires [security scanning to be set up](/ee/dtr/admin/configure/set-up-vulnerability-scans/) by a DTR admin. Once enabled, this will display as a `SCAN` event type. | Authenticated Users |
| Promotion | Refers to a "Create Promotion Policy" event which links to the **Promotions** tab of the repository where you can edit the existing promotions. See [Promotion Policies](/ee/dtr/user/promotion-policies/) for different ways to promote an image. | Repository Admin |
| Delete | Refers to "Delete Tag" events. Learn more about [deleting images](/ee/dtr/user/manage-images/delete-images). | Authenticated Users |
| Pull | Refers to "Get Tag" events. Learn more about [pulling images](/ee/dtr/user/manage-images/pull-and-push-images/#pull-an-image). | Repository Admin |
| Mirror |Refers to "Pull mirroring" and "Push mirroring" events. See [Mirror images to another registry](/ee/dtr/user/promotion-policies/#mirror-images-to-another-registry) and [Mirror images from another registry](/ee/dtr/user/promotion-policies/#mirror-images-from-another-registry) for more details. | Repository Admin |
| Create repo | Refers to "Create Repository" events. See [Create a repository](/ee/dtr/user/manage-images/) for more details. | Authenticated Users |
## Where to go next
- [Enable auto-deletion of repository events](../../admin/configure/auto-delete-repo-events.md)
- [Enable auto-deletion of repository events](/ee/dtr/admin/configure/auto-delete-repo-events.md)

View File

@ -1,26 +1,26 @@
---
title: Join Windows worker nodes to your cluster
description: Join worker nodes that are running on Windows Server 2016 to a Docker EE cluster.
keywords: Docker EE, UCP, cluster, scale, worker, Windows
description: Join worker nodes that are running on Windows Server to a Docker Enterprise cluster.
keywords: Docker Enterprise, UCP, cluster, scale, worker, Windows
redirect_from:
- /datacenter/ucp/3.0/guides/admin/configure/join-nodes/join-windows-nodes-to-cluster/
---
Docker Enterprise Edition supports worker nodes that run on Windows Server 2016 or 1709.
Only worker nodes are supported on Windows, and all manager nodes in the cluster
Docker Enterprise 2.1 supports worker nodes that run on Windows Server 2016, 1709,
or 1803. Only worker nodes are supported on Windows, and all manager nodes in the cluster
must run on Linux.
Follow these steps to enable a worker node on Windows.
1. Install Docker EE Engine on Windows Server 2016.
1. Install Docker Engine - Enterprise on Windows Server 2016, 1709, or 1803.
2. Configure the Windows node.
3. Join the Windows node to the cluster.
## Install Docker EE Engine on Windows Server 2016 or 1709
## Install Docker Engine - Enterprise on Windows Server
[Install Docker EE Engine](/engine/installation/windows/docker-ee/#use-a-script-to-install-docker-ee)
on a Windows Server 2016 or 1709 instance to enable joining a cluster that's managed by
Docker Enterprise Edition.
[Install Docker Engine - Enterprise](/engine/installation/windows/docker-ee/#use-a-script-to-install-docker-ee)
on a Windows Server 2016, 1709 or 1803 instance to enable joining a cluster that's managed by
Docker Enterprise 2.1.
## Configure the Windows node
@ -29,7 +29,7 @@ Follow these steps to configure the docker daemon and the Windows environment.
1. Add a label to the node.
2. Pull the Windows-specific image of `ucp-agent`, which is named `ucp-agent-win`.
3. Run the Windows worker setup script provided with `ucp-agent-win`.
4. Join the cluster with the token provided by the Docker EE web UI or CLI.
4. Join the cluster with the token provided by the Docker UCP web interface or CLI.
### Add a label to the node
@ -117,9 +117,9 @@ to the corresponding files in `C:\ProgramData\docker\daemoncerts`:
## Join the Windows node to the cluster
Now you can join the cluster by using the `docker swarm join` command that's
provided by the Docker EE web UI and CLI.
provided by the Docker UCP web interface and CLI.
1. Log in to the Docker EE web UI with an administrator account.
1. Log in to the Docker UCP web interface with an administrator account.
2. Navigate to the **Nodes** page.
3. Click **Add Node** to add a new node.
4. In the **Node Type** section, click **Windows**.
@ -163,7 +163,7 @@ docker container run --rm {{ page.ucp_org }}/ucp-agent-win:{{ page.ucp_version }
### Open ports in the Windows firewall
Docker EE requires that ports 2376 and 12376 are open for inbound TCP traffic.
Docker Enterprise requires that ports 2376 and 12376 are open for inbound TCP traffic.
In a PowerShell terminal running as Administrator, run these commands
to add rules to the Windows firewall.
@ -193,11 +193,11 @@ netsh advfirewall firewall add rule name="docker_proxy" dir=in action=allow prot
Start-Service docker
```
The `dockerd` service and the Windows environment are now configured to join a Docker EE cluster.
The `dockerd` service and the Windows environment are now configured to join a Docker Enterprise cluster.
> TLS certificate setup
>
> If the TLS certificates aren't set up correctly, the Docker EE web UI shows the
> If the TLS certificates aren't set up correctly, the Docker UCP web interface shows the
> following warning.
>
> ```

View File

@ -1,5 +1,5 @@
---
title: Upgrade to UCP 3.0
title: Upgrade to UCP 3.1
description: Learn how to upgrade Docker Universal Control Plane with minimal impact to your users.
keywords: UCP, upgrade, update
---

View File

@ -38,7 +38,7 @@ consistency and compatibility reasons.
* Add `builder prune` subcommand to prune BuildKit build cache [docker/cli#1295](https://github.com/docker/cli/pull/1295) [docker/cli#1334](https://github.com/docker/cli/pull/1334)
* BuildKit: Add configurable garbage collection policy for the BuildKit build cache [docker/engine#59](https://github.com/docker/engine/pull/59) / [moby/moby#37846](https://github.com/moby/moby/pull/37846)
* BuildKit: Add support for `docker build --pull ...` when using BuildKit [moby/moby#37613](https://github.com/moby/moby/pull/37613)
* BuildKit: Add support or "registry-mirrors" and "insecure-registries" when using BuildKit docker/engine#59](https://github.com/docker/engine/pull/59) / [moby/moby#37852](https://github.com/moby/moby/pull/37852)
* BuildKit: Add support or "registry-mirrors" and "insecure-registries" when using BuildKit [docker/engine#59](https://github.com/docker/engine/pull/59) / [moby/moby#37852](https://github.com/moby/moby/pull/37852)
* BuildKit: Enable net modes and bridge. [moby/moby#37620](https://github.com/moby/moby/pull/37620)
* Add `docker engine` subcommand to manage the lifecycle of a Docker Engine running as a privileged container on top of containerd, and to allow upgrades to Docker Engine Enterprise [docker/cli#1260](https://github.com/docker/cli/pull/1260)
* Expose product license in `docker info` output [docker/cli#1313](https://github.com/docker/cli/pull/1313)
@ -166,6 +166,25 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
+ Support for `--chown` with `COPY` and `ADD` in `Dockerfile`.
+ Add support for multiple logging drivers for `docker logs`.
### 17.06.2-ee-17
2018-10-25
#### Networking
* Changed loglevel from error to warning for missing disable_ipv6 file. [docker/libnetwork#2223](https://github.com/docker/libnetwork/pull/2223)
* Fixed subnet allocation to avoid reallocating recently freed subnets. [docker/libnetwork#2255](https://github.com/docker/libnetwork/pull/2255)
* Fixed libnetwork issue which caused errors to be returned when iptables or firewalld issues transient warnings. [docker/libnetwork#2218](https://github.com/docker/libnetwork/pull/2218)
#### Plugins
* Fixed too many "Plugin not found" error messages. [moby/moby#36119](https://github.com/moby/moby/pull/36119)
#### Swarm mode
* Added failed allocations retry immediately upon a deallocation to overcome IP exhaustion. [docker/swarmkit#2711](https://github.com/docker/swarmkit/pull/2711)
* Fixed leaking task resources. [docker/swarmkit#2755](https://github.com/docker/swarmkit/pull/2755)
* Fixed deadlock in dispatcher that could cause node to crash. [docker/swarmkit#2753](https://github.com/docker/swarmkit/pull/2753)
### 17.06.2-ee-16
2018-07-26

View File

@ -50,10 +50,10 @@ On {{ linux-dist-long }}, Docker EE supports storage drivers, `overlay2` and `de
With Docker EE Basic license for versions 18.03 and later, Docker provides FIPS 140-2 support in RHEL 7.3, 7.4 and 7.5. This includes a FIPS supported cryptographic module. If the RHEL implementation already has FIPS support enabled, FIPS is automatically enabled in the Docker engine.
To verify the FIPS-140-2 module is enabled in the Linux kernel, confirm the file `/proc/sys/crypto/fips_enabled.conf` contains `1`.
To verify the FIPS-140-2 module is enabled in the Linux kernel, confirm the file `/proc/sys/crypto/fips_enabled` contains `1`.
```
$ cat /proc/sys/crypto/fips_enabled.conf
$ cat /proc/sys/crypto/fips_enabled
1
```

View File

@ -1,7 +1,7 @@
---
description: How to install Docker EE for Windows Server
keywords: Windows, Windows Server, install, download, ucp, Docker EE
title: Install Docker Enterprise Edition for Windows Server
description: How to install Docker Engine - Enterprise for Windows Server
keywords: Windows, Windows Server, install, download, ucp, Docker Engine - Enterprise
title: Install Docker Engine - Enterprise on Windows Servers
redirect_from:
- /docker-ee-for-windows/install/
- /engine/installation/windows/docker-ee/
@ -9,15 +9,28 @@ redirect_from:
{% capture filename %}{{ page.win_latest_build }}.zip{% endcapture %} {% capture download_url %}https://download.docker.com/components/engine/windows-server/{{ site.docker_ee_version }}/{{ filename }}{% endcapture %}
Docker Enterprise Edition for Windows Server (*Docker EE*) enables native Docker containers on Windows Server. Windows Server 2016 and later versions are supported. The Docker EE installation package includes everything you need to run Docker on Windows Server. This topic describes pre-install considerations, and how to download and install Docker EE.
Docker Engine - Enterprise enables native Docker containers on Windows Server. Windows Server 2016 and later versions are supported. The Docker Engine - Enterprise installation package includes everything you need to run Docker on Windows Server. This topic describes pre-install considerations, and how to download and install Docker Engine - Enterprise.
> Release notes
>
> [Release notes for all versions](/release-notes/)
## Install Docker EE
## System requirements
Docker EE for Windows requires Windows Server 2016 or later. See
Windows OS requirements around specific CPU and RAM requirements also need to be met as specified
in the [Windows Server Requirements](https://docs.microsoft.com/en-us/windows-server/get-started/system-requirements).
This provides information for specific CPU and memory specs and capabilities (instruction sets like CMPXCHG16b,
LAHF/SAHF, and PrefetchW, security: DEP/NX, etc.).
* OS Versions: Server 2016 (Core and GUI), 1709 and 1803
* RAM: 4GB
* Disk space: [32 GB minimum recommendation for Windows](https://docs.microsoft.com/en-us/windows-server/get-started/system
requirements). An additional 32 GB of Space is recommended for base images for ServerCore and NanoServer along with buffer
space for workload containers running IIS, SQL Server and .Net apps.
## Install Docker Engine - Enterprise
Docker Engine - Enterprise requires Windows Server 2016, 1703, or 1803. See
[What to know before you install](#what-to-know-before-you-install) for a
full list of prerequisites.
@ -39,7 +52,8 @@ full list of prerequisites.
Restart-Computer
```
3. Test your Docker EE installation by running the `hello-world` container.
3. Test your Docker Engine - Enterprise installation by running the
`hello-world` container.
```PowerShell
docker run hello-world:nanoserver
@ -156,19 +170,14 @@ installs, or install on air-gapped systems.
## Install a specific version
There are currently two channels available for Docker EE for Windows Server:
* `18.09` - Use this version if you're using Docker Enterprise 2.1 (Engine, UCP, DTR), or if you're running Docker Engine alone. `18.09` is the default.
* `17.06` - Use this version if you're using Docker Enterprise 2.0.
To install a specific version, use the `RequiredVersion` flag:
```PowerShell
Install-Package -Name docker -ProviderName DockerMsftProvider -Force -RequiredVersion 17.06
Install-Package -Name docker -ProviderName DockerMsftProvider -Force -RequiredVersion 18.09
...
Name Version Source Summary
---- ------- ------ -------
Docker 17.06.2-ee-17 Docker Contains Docker EE for use with Windows Server...
Docker 18.09.0 Docker Contains Docker Engine - Enterprise for use with Windows Server...
```
### Updating the DockerMsftProvider
@ -180,12 +189,12 @@ Update-Module DockerMsftProvider
Then open a new Powershell session for the update to take effect.
## Update Docker EE
## Update Docker Engine - Enterprise
To update Docker EE Engine to the most recent release, specify the `-RequiredVersion` and `-Update` flags:
To update Docker Engine - Enterprise to the most recent release, specify the `-RequiredVersion` and `-Update` flags:
```PowerShell
Install-Package -Name docker -ProviderName DockerMsftProvider -RequiredVersion 18.03.1-ee-2 -Update -Force
Install-Package -Name docker -ProviderName DockerMsftProvider -RequiredVersion 18.09 -Update -Force
```
The required version must match any of the versions available in this json file: https://dockermsft.blob.core.windows.net/dockercontainer/DockerMsftIndex.json
@ -193,7 +202,7 @@ The required version must match any of the versions available in this json file:
## Preparing a Docker EE Engine for use with UCP
Run the
[UCP installation script for Windows](/datacenter/ucp/2.2/guides/admin/configure/join-windows-worker-nodes/#run-the-windows-node-setup-script).
[UCP installation script for Windows](/datacenter/ucp/3.0/guides/admin/configure/join-windows-worker-nodes/#run-the-windows-node-setup-script).
Start the Docker service:
@ -201,15 +210,13 @@ Start the Docker service:
Start-Service Docker
```
## What to know before you install
* **What the Docker EE for Windows install includes**: The installation
* **What the Docker Engine - Enterprise install includes**: The installation
provides [Docker Engine](/engine/userguide/intro.md) and the
[Docker CLI client](/engine/reference/commandline/cli.md).
## About Docker EE containers and Windows Server
## About Docker Engine - Enterprise containers and Windows Server
Looking for information on using Docker EE containers?
Looking for information on using Docker Engine - Enterprise containers?
* [Getting Started with Windows Containers (Lab)](https://github.com/docker/labs/blob/master/windows/windows-containers/README.md)
provides a tutorial on how to set up and run Windows containers on Windows 10

View File

@ -0,0 +1,124 @@
---
description: High level discussion of garbage collection
keywords: registry, garbage, images, tags, repository, distribution
title: Garbage collection
---
As of v2.4.0 a garbage collector command is included within the registry binary.
This document describes what this command does and how and why it should be used.
## About garbage collection
In the context of the Docker registry, garbage collection is the process of
removing blobs from the filesystem when they are no longer referenced by a
manifest. Blobs can include both layers and manifests.
Registry data can occupy considerable amounts of disk space. In addition,
garbage collection can be a security consideration, when it is desirable to ensure
that certain layers no longer exist on the filesystem.
## Garbage collection in practice
Filesystem layers are stored by their content address in the Registry. This
has many advantages, one of which is that data is stored once and referred to by manifests.
See [here](compatibility.md#content-addressable-storage-cas) for more details.
Layers are therefore shared amongst manifests; each manifest maintains a reference
to the layer. As long as a layer is referenced by one manifest, it cannot be garbage
collected.
Manifests and layers can be `deleted` with the registry API (refer to the API
documentation [here](spec/api.md#deleting-a-layer) and
[here](spec/api.md#deleting-an-image) for details). This API removes references
to the target and makes them eligible for garbage collection. It also makes them
unable to be read via the API.
If a layer is deleted, it is removed from the filesystem when garbage collection
is run. If a manifest is deleted the layers to which it refers are removed from
the filesystem if no other manifests refers to them.
### Example
In this example manifest A references two layers: `a` and `b`. Manifest `B` references
layers `a` and `c`. In this state, nothing is eligible for garbage collection:
```
A -----> a <----- B
\--> b |
c <--/
```
Manifest B is deleted via the API:
```
A -----> a B
\--> b
c
```
In this state layer `c` no longer has a reference and is eligible for garbage
collection. Layer `a` had one reference removed but not garbage
collected as it is still referenced by manifest `A`. The blob representing
manifest `B` is eligible for garbage collection.
After garbage collection has been run, manifest `A` and its blobs remain.
```
A -----> a
\--> b
```
### More details about garbage collection
Garbage collection runs in two phases. First, in the 'mark' phase, the process
scans all the manifests in the registry. From these manifests, it constructs a
set of content address digests. This set is the 'mark set' and denotes the set
of blobs to *not* delete. Secondly, in the 'sweep' phase, the process scans all
the blobs and if a blob's content address digest is not in the mark set, the
process deletes it.
> **Note**: You should ensure that the registry is in read-only mode or not running at
> all. If you were to upload an image while garbage collection is running, there is the
> risk that the image's layers are mistakenly deleted leading to a corrupted image.
This type of garbage collection is known as stop-the-world garbage collection.
## Run garbage collection
Garbage collection can be run as follows
`bin/registry garbage-collect [--dry-run] /path/to/config.yml`
The garbage-collect command accepts a `--dry-run` parameter, which prints the progress
of the mark and sweep phases without removing any data. Running with a log level of `info`
gives a clear indication of items eligible for deletion.
The config.yml file should be in the following format:
```
version: 0.1
storage:
filesystem:
rootdirectory: /registry/data
```
_Sample output from a dry run garbage collection with registry log level set to `info`_
```
hello-world
hello-world: marking manifest sha256:fea8895f450959fa676bcc1df0611ea93823a735a01205fd8622846041d0c7cf
hello-world: marking blob sha256:03f4658f8b782e12230c1783426bd3bacce651ce582a4ffb6fbbfa2079428ecb
hello-world: marking blob sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
hello-world: marking configuration sha256:690ed74de00f99a7d00a98a5ad855ac4febd66412be132438f9b8dbd300a937d
ubuntu
4 blobs marked, 5 blobs eligible for deletion
blob eligible for deletion: sha256:28e09fddaacbfc8a13f82871d9d66141a6ed9ca526cb9ed295ef545ab4559b81
blob eligible for deletion: sha256:7e15ce58ccb2181a8fced7709e9893206f0937cc9543bc0c8178ea1cf4d7e7b5
blob eligible for deletion: sha256:87192bdbe00f8f2a62527f36bb4c7c7f4eaf9307e4b87e8334fb6abec1765bcb
blob eligible for deletion: sha256:b549a9959a664038fc35c155a95742cf12297672ca0ae35735ec027d55bf4e97
blob eligible for deletion: sha256:f251d679a7c61455f06d793e43c06786d7766c88b8c24edf242b2c08e3c3f599
```

View File

@ -9,7 +9,7 @@ redirect_from:
By default all files created inside a container are stored on a writable
container layer. This means that:
- The data doesn't persist when that container is no longer running, and it can be
- The data doesn't persist when that container no longer exists, and it can be
difficult to get the data out of the container if another process needs it.
- A container's writable layer is tightly coupled to the host machine
where the container is running. You can't easily move the data somewhere else.