mirror of https://github.com/docker/docs.git
Merge branch 'master' into consolidation-changes
This commit is contained in:
Jeffrey Morgan
commit
dacad06fbd
|
|
@ -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)
|
||||
|
|
@ -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 ""
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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 ""
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
{: .img-fluid .with-border}
|
||||
{: .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 – pruning, pull / push mirroring, or promotion – 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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
>
|
||||
> ```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
---
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue