mirror of https://github.com/docker/docs.git
Appending of Enterprise Label to all Docker Enterprise md topic files.
This commit is contained in:
parent
15f4c78350
commit
67f49c63d2
|
@ -0,0 +1,4 @@
|
|||
<!-- This text will be included on all Docker pages that document Enterprise products, features, and technologies that are transitioning to Mirantis. -->
|
||||
This topic applies to Docker Enterprise.
|
||||
|
||||
The Docker Enterprise platform business, including products, customers, and employees, has been acquired by Mirantis, inc., effective 13-November-2019. For more information on the acquisition and how it may affect you and your business, refer to the [Docker Enterprise Customer FAQ](https://www.docker.com/faq-for-docker-enterprise-customers-and-partners).
|
|
@ -4,6 +4,8 @@ keywords: documentation, docs, docker, cluster, infrastructure, automation, AWS
|
|||
title: Get started with Docker Cluster on AWS
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Completed installation of [Docker Desktop Enterprise](../ee/desktop/) on Windows or Mac, or the [Docker Enterprise Engine](https://docs.docker.com/ee/supported-platforms/) on Linux.
|
||||
|
|
|
@ -4,6 +4,8 @@ keywords: documentation, docs, docker, cluster, infrastructure, automation, Azur
|
|||
title: Get started with Docker Cluster on Azure
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Completed installation of [Docker Desktop Enterprise](../ee/desktop/) on Windows or Mac, or the [Docker Enterprise Engine](https://docs.docker.com/ee/supported-platforms/) on Linux.
|
||||
|
|
|
@ -6,6 +6,8 @@ toc_max: 5
|
|||
toc_min: 1
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This topic describes version 1 of the Cluster file format.
|
||||
|
||||
## Cluster file structure and examples
|
||||
|
|
|
@ -4,6 +4,8 @@ keywords: documentation, docs, docker, cluster, infrastructure, automation
|
|||
title: Overview of Docker Cluster
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Cluster is a tool for lifecycle management of Docker clusters.
|
||||
With Cluster, you use a YAML file to configure your provider's resources.
|
||||
Then, with a single command, you provision and install all the resources
|
||||
|
|
|
@ -4,6 +4,8 @@ keywords: documentation, docs, docker, cluster, infrastructure, automation
|
|||
title: Cluster CLI environment variables
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Use the following environment variables as needed to configure the Docker Cluster command-line behavior.
|
||||
|
||||
## AWS\_ACCESS\_KEY\_ID
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the new features, bug fixes, and breaking changes for D
|
|||
keywords: cluster, whats new, release notes
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This page provides information about Docker Cluster versions.
|
||||
|
||||
# Version 1
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from:
|
|||
- /ee/ucp/admin/backups-and-disaster-recovery/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
UCP backups no longer require pausing the reconciler and deleting UCP containers, and backing up a UCP manager does not disrupt the manager’s activities.
|
||||
|
||||
Because UCP stores the same data on all manager nodes, you only need to back up a single UCP manager node.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to restore UCP from a backup
|
|||
keywords: enterprise, restore, swarm
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
To restore UCP, select one of the following options:
|
||||
|
||||
* Run the restore on the machines from which the backup originated or on new machines. You can use the same swarm from which the backup originated or a new swarm.
|
||||
|
|
|
@ -16,6 +16,8 @@ title: Get Docker Engine - Enterprise for CentOS
|
|||
{% assign gpg-fingerprint = "77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9" %}
|
||||
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
There are two ways to install and upgrade [Docker Enterprise](https://www.docker.com/enterprise-edition/){: target="_blank" class="_" }
|
||||
on {{ linux-dist-long }}:
|
||||
|
||||
|
|
|
@ -17,6 +17,8 @@ title: Get Docker Engine - Enterprise for Oracle Linux
|
|||
{% assign gpg-fingerprint = "77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9" %}
|
||||
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
There are two ways to install and upgrade [Docker Enterprise](https://www.docker.com/enterprise-edition/){: target="_blank" class="_" }
|
||||
on {{ linux-dist-long }}:
|
||||
|
||||
|
|
|
@ -18,6 +18,8 @@ title: Get Docker Engine - Enterprise for Red Hat Enterprise Linux
|
|||
{% assign gpg-fingerprint = "77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9" %}
|
||||
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
There are two ways to install and upgrade [Docker Enterprise](https://www.docker.com/enterprise-edition/){: target="_blank" class="_" }
|
||||
on {{ linux-dist-long }}:
|
||||
|
||||
|
|
|
@ -11,6 +11,8 @@ title: Get Docker Engine - Enterprise for SLES
|
|||
toc_max: 4
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
To get started with Docker on SUSE Linux Enterprise Server (SLES), make sure you
|
||||
[meet the prerequisites](#prerequisites), then
|
||||
[install Docker](#install-docker-ee).
|
||||
|
|
|
@ -11,6 +11,8 @@ title: Get Docker Engine - Enterprise for Ubuntu
|
|||
toc_max: 4
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
To get started with Docker Engine - Enterprise on Ubuntu, make sure you
|
||||
[meet the prerequisites](#prerequisites), then
|
||||
[install Docker](#install-docker-ee).
|
||||
|
|
|
@ -11,6 +11,8 @@ 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 %}
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
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
|
||||
|
|
|
@ -7,6 +7,8 @@ redirect_from:
|
|||
- /datacenter/dtr/2.5/guides/admin/configure/allow-creation-on-push/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
By default DTR only allows pushing images if the repository exists, and you
|
||||
have write access to the repository.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Enable auto-deletion of image events within a repository for mainte
|
|||
keywords: registry, events, log, activity stream
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Overview
|
||||
|
||||
Docker Trusted Registry has a global setting for repository event auto-deletion. This allows event records to be removed as part of [garbage collection](../admin/configure/garbage-collection.md). DTR administrators can enable auto-deletion of repository events in DTR 2.6 based on specified conditions which are covered below.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the different configuration options for DTR caches.
|
|||
keywords: DTR, cache
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
DTR caches are based on Docker Registry, and use the same configuration
|
||||
file format.
|
||||
[Learn more about the configuration options](/registry/configuration.md).
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to deploy a DTR cache with fault tolerance and high
|
|||
keywords: DTR, cache
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
If you're deploying a DTR cache in a zone with few users and with no uptime
|
||||
SLAs, a [single cache service is enough for you](simple.md).
|
||||
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Deploy DTR caches in different geographical locations for users to
|
|||
keywords: DTR, cache
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
The further away you are from the geographical location where DTR is deployed,
|
||||
the longer it will take to pull and push images.
|
||||
This happens because the files being transferred from DTR to your machine
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Deploy a DTR cache to allow users in remote geographical locations
|
|||
keywords: DTR, cache, kubernetes
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This example guides you through deploying a DTR cache, assuming that you've got
|
||||
a DTR deployment up and running. The below guide has been tested on
|
||||
Universal Control Plane 3.1, however it should work on any Kubernetes Cluster
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Deploy a DTR cache to make users in remove geographical locations
|
|||
keywords: DTR, cache
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This example guides you in deploying a DTR cache, assuming that you've got
|
||||
a DTR deployment up and running. It also assumes that you've provisioned
|
||||
[multiple nodes and joined them into a swarm](strategy.md#system-requirements).
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to deploy DTR caches across multiple datacenters to make
|
|||
keywords: DTR, cache
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
The main reason to use a DTR cache is so that users can pull images from
|
||||
a service that's geographically closer to them.
|
||||
|
||||
|
|
|
@ -3,6 +3,9 @@ title: Disable persistent cookies
|
|||
description: Learn how to disable persistent cookies for Docker Trusted Registry.
|
||||
keywords: dtr, browser cookies, sso
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
If you want your Docker Trusted Registry (DTR) to use session-based authentication cookies that expire when you close your browser, toggle "Disable persistent cookies".
|
||||
|
||||
{: .with-border}
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to set up single sign-on between UCP and DTR, so that you
|
|||
keywords: dtr, login, sso
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Users are shared between UCP and DTR by default, but the applications have separate browser-based interfaces which require authentication.
|
||||
|
||||
To only authenticate once, you can configure DTR to have single sign-on (SSO) with UCP.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Storage configuration for Docker Trusted Registry
|
|||
keywords: dtr, storage drivers, NFS, Azure, S3
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Configure your storage backend
|
||||
|
||||
By default DTR uses the local filesystem of the node where it is running to
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to integrate Docker Trusted Registry with NFS
|
|||
keywords: registry, dtr, storage, nfs
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
You can configure DTR to store Docker images in an NFS directory. Starting in DTR 2.6,
|
||||
changing storage backends involves initializing a new metadatastore instead of reusing an existing volume.
|
||||
This helps facilitate [online garbage collection](/ee/dtr/admin/configure/garbage-collection/#under-the-hood).
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to configure Docker Trusted Registry to store Docker imag
|
|||
keywords: dtr, storage driver, s3
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
You can configure DTR to store Docker images on Amazon S3, or other file servers
|
||||
with an S3-compatible API like Cleversafe or Minio.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Storage backend migration for Docker Trusted Registry
|
|||
keywords: dtr, storage drivers, local volume, NFS, Azure, S3,
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Starting in DTR 2.6, switching storage backends initializes a new metadata store and erases your existing tags. This helps facilitate online garbage collection, which has been introduced in 2.5 as an experimental feature. In earlier versions, DTR would subsequently start a `tagmigration` job to rebuild tag metadata from the file layout in the image layer store. This job has been discontinued for DTR 2.5.x (with garbage collection) and DTR 2.6, as your storage backend could get out of sync with your DTR metadata, like your manifests and existing repositories. As best practice, DTR storage backends and metadata should always be moved, backed up, and restored together.
|
||||
|
||||
## DTR 2.6.4 and above
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Save disk space by configuring the garbage collection settings in
|
|||
keywords: registry, online garbage collection, gc, space, disk space
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
You can configure the Docker Trusted Registry (DTR) to automatically delete unused image
|
||||
layers, thus saving you disk space. This process is also known as garbage collection.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to license your Docker Trusted Registry installation.
|
|||
keywords: dtr, install, license
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
By default, Docker Trusted Registry (DTR) automatically uses the same license file applied to
|
||||
your Universal Control Plane (UCP). In the following scenarios, you need to
|
||||
manually apply a license to your DTR:
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Lean how to scale Docker Trusted Registry by adding and removing re
|
|||
keywords: dtr, install, deploy
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry is designed to scale horizontally as your usage
|
||||
increases. You can add more replicas to make DTR scale to your demand and for
|
||||
high availability.
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from:
|
|||
- /datacenter/dtr/2.2/guides/admin/configure/set-up-vulnerability-scans/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This page explains how to set up and enable Docker Security Scanning on an
|
||||
existing installation of Docker Trusted Registry.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to configure a load balancer to balance user requests acr
|
|||
keywords: dtr, load balancer
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Once you’ve joined multiple DTR replicas nodes for
|
||||
[high-availability](set-up-high-availability.md), you can configure your own
|
||||
load balancer to balance user requests across all replicas.
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to configure Docker Content Trust to use a web proxy to
|
|||
keywords: dtr, configure, http, proxy
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry makes outgoing connections to check for new versions,
|
||||
automatically renew its license, and update its vulnerability database.
|
||||
If DTR can't access the internet, then you'll have to manually apply updates.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to configure Docker Trusted Registry with your own TLS ce
|
|||
keywords: dtr, tls, certificates, security
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry (DTR) services are exposed using HTTPS by default. This
|
||||
ensures encrypted communications between clients and your trusted registry. If
|
||||
you do not pass a PEM-encoded TLS certificate during installation, DTR will
|
||||
|
|
|
@ -5,6 +5,8 @@ keywords: dtr, disaster recovery
|
|||
toc_max_header: 3
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
{% assign metadata_backup_file = "dtr-metadata-backup.tar" %}
|
||||
{% assign image_backup_file = "dtr-image-backup.tar" %}
|
||||
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn the multiple disaster recovery strategies you can use with
|
|||
keywords: dtr, disaster recovery
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry is a clustered application. You can join multiple
|
||||
replicas for high availability.
|
||||
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from:
|
|||
- /datacenter/dtr/2.5/guides/admin/disaster-recovery/repair-a-cluster/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
For a DTR cluster to be healthy, a majority of its replicas (n/2 + 1) need to
|
||||
be healthy and be able to communicate with the other replicas. This is known
|
||||
as maintaining quorum.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to repair a single DTR replica when it is unhealthy.
|
|||
keywords: dtr, disaster recovery
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
When one or more DTR replicas are unhealthy but the overall majority
|
||||
(n/2 + 1) is healthy and able to communicate with one another, your DTR
|
||||
cluster is still functional and healthy.
|
||||
|
|
|
@ -7,6 +7,8 @@ keywords: dtr, disaster recovery
|
|||
{% assign metadata_backup_file = "dtr-metadata-backup.tar" %}
|
||||
{% assign image_backup_file = "dtr-image-backup.tar" %}
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Restore DTR data
|
||||
|
||||
If your DTR has a majority of unhealthy replicas, the one way to restore it to
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to install Docker Trusted Registry for production.
|
|||
keywords: dtr, registry, install
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry (DTR) is a containerized application that runs on a
|
||||
swarm managed by the Universal Control Plane (UCP). It can be installed
|
||||
on-premises or on a cloud infrastructure.
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to install Docker Trusted Registry on a machine with no i
|
|||
keywords: registry, install, offline
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
The procedure to install Docker Trusted Registry on a host is the same,
|
||||
whether that host has access to the internet or not.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the system requirements for installing Docker Trusted R
|
|||
keywords: DTR, architecture, requirements
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry can be installed on-premises or on the cloud.
|
||||
Before installing, be sure your infrastructure has these requirements.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to uninstall your Docker Trusted Registry installation.
|
|||
keywords: dtr, install, uninstall
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Uninstalling DTR can be done by simply removing all data associated with each
|
||||
replica. To do that, you just run the destroy command once per replica:
|
||||
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from: /ee/dtr/admin/monitor-and-troubleshoot/troubleshoot-batch-jobs/
|
|||
---
|
||||
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Overview
|
||||
|
||||
This covers troubleshooting batch jobs via the API and was introduced in DTR 2.2. Starting in DTR 2.6, admins have the ability to [audit jobs](audit-jobs-via-ui.md) using the web interface.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: View a list of jobs happening within DTR and review the detailed lo
|
|||
keywords: dtr, troubleshoot, audit, job logs, jobs, ui
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
As of DTR 2.2, admins were able to [view and audit jobs within DTR](audit-jobs-via-api) using the API. DTR 2.6 enhances those capabilities by adding a **Job Logs** tab under **System** settings on the user interface. The tab displays a sortable and paginated list of jobs along with links to associated job logs.
|
||||
|
||||
## Prerequisite
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Enable auto-deletion of old or unnecessary job logs for maintenance
|
|||
keywords: dtr, jobs, log, job logs, system
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Overview
|
||||
|
||||
Docker Trusted Registry has a global setting for auto-deletion of job logs which allows them to be removed as part of [garbage collection](../configure/garbage-collection.md). DTR admins can enable auto-deletion of repository events in DTR 2.6 based on specified conditions which are covered below.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how Docker Trusted Registry runs batch jobs for troubleshooti
|
|||
keywords: dtr, job queue, job management
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry (DTR) uses a job queue to schedule batch jobs. Jobs are added to a cluster-wide job queue, and then consumed and executed by a job runner within DTR.
|
||||
|
||||

|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to set up organizations to enforce security in Docker Tru
|
|||
keywords: registry, security, permissions, organizations
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
When a user creates a repository, only that user has permissions to make changes
|
||||
to the repository.
|
||||
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to manage teams to enforce fine-grain access control in D
|
|||
keywords: registry, security, permissions, teams
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
You can extend a user's default permissions by granting them individual
|
||||
permissions in other image repositories, by adding the user to a team. A team
|
||||
defines the permissions a set of users have for a set of repositories.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to manage user permissions in Docker Trusted Registry.
|
|||
keywords: registry, security, permissions, users
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
When using the built-in authentication, you can create users
|
||||
to grant them fine-grained permissions.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the permission levels available on Docker Trusted Regis
|
|||
keywords: registry, security, permissions, users
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
With DTR you get to control which users have access to your image repositories.
|
||||
|
||||
By default, anonymous users can only pull images from public repositories.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the permission levels available in Docker Trusted Regis
|
|||
keywords: registry, security, permissions
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry allows you to define fine-grain permissions over image
|
||||
repositories.
|
||||
|
||||
|
|
|
@ -7,6 +7,8 @@ redirect_from:
|
|||
- /ee/dtr/user/create-and-manage-webhooks/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
You can configure DTR to automatically post event notifications to a webhook URL of your choosing. This lets you build complex CI and CD pipelines with your Docker images. The following is a complete list of event types you can trigger webhook notifications for via the [web interface](use-the-web-ui) or the [API](use-the-API).
|
||||
|
||||
## Webhook types
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to create, configure, and test webhooks for DTR using the
|
|||
keywords: dtr, webhooks, api, registry
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Prerequisite
|
||||
|
||||
See [Webhook types](/ee/dtr/admin/manage-webhooks/index.md/#webhook-types) for a list of events you can trigger notifications for via the API.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to create, configure, and test repository webhooks for DT
|
|||
keywords: dtr, webhooks, ui, web interface, registry
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You must have admin privileges to the repository in order to create a webhook.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to monitor your DTR installation.
|
|||
keywords: registry, monitor, troubleshoot
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry is a Dockerized application. To monitor it, you can
|
||||
use the same tools and techniques you're already using to monitor other
|
||||
containerized applications running on your cluster. One way to monitor
|
||||
|
|
|
@ -5,6 +5,8 @@ description: When you push signed images, Docker Trusted Registry keeps audit
|
|||
keywords: registry, monitor, troubleshoot
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Content Trust (DCT) keeps audit logs of changes made to trusted repositories.
|
||||
Every time you push a signed image to a repository, or delete trust data for a
|
||||
repository, DCT logs that information.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how Docker Trusted Registry run batch jobs, so that you can t
|
|||
keywords: dtr, troubleshoot
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
DTR uses a job queue to schedule batch jobs. A job is placed on this work queue,
|
||||
and a job runner component of DTR consumes work from this cluster-wide job
|
||||
queue and executes it.
|
||||
|
|
|
@ -5,6 +5,8 @@ keywords: registry, monitor, troubleshoot
|
|||
redirect_from: /ee/dtr/admin/monitor-and-troubleshoot/troubleshoot-with-logs
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This guide contains tips and tricks for troubleshooting DTR problems.
|
||||
|
||||
## Troubleshoot overlay networks
|
||||
|
|
|
@ -6,6 +6,8 @@ keywords: dtr, upgrade, install
|
|||
|
||||
{% assign previous_version="2.6" %}
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
DTR uses [semantic versioning](http://semver.org/) and Docker aims to achieve specific
|
||||
guarantees while upgrading between versions. While downgrades are not supported, Docker supports upgrades according to the following rules:
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the architecture of Docker Trusted Registry.
|
|||
keywords: registry, dtr, architecture
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry (DTR) is a containerized application that runs on a
|
||||
Docker Universal Control Plane cluster.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to install, configure, and use Docker Trusted Registry.
|
|||
keywords: registry, repository, images
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
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.
|
||||
|
|
|
@ -9,6 +9,8 @@ redirect_from:
|
|||
- /datacenter/dtr/2.5/guides/release-notes/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Here you can learn about new features, bug fixes, breaking changes, and
|
||||
known issues for each DTR version.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to configure your Docker Engine to push and pull images f
|
|||
keywords: registry, TLS, certificates
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
By default Docker Engine uses TLS when pushing and pulling images to an
|
||||
image registry like Docker Trusted Registry.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to configure your Docker Trusted Registry account to pull
|
|||
keywords: registry, cache
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry can be configured to have one or more caches. This
|
||||
allows you to choose from which cache to pull images from for faster
|
||||
download times.
|
||||
|
|
|
@ -7,6 +7,8 @@ redirect_from:
|
|||
- /datacenter/dtr/2.5/guides/user/access-tokens/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry lets you create and distribute access tokens to enable programmatic access to DTR. Access tokens are linked to a particular user account and duplicate whatever permissions that account has at the time of use. If the account changes permissions, so will the token.
|
||||
|
||||
Access tokens are useful in cases such as building integrations since you can issue multiple tokens – one for each integration – and revoke them at any time.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: View and audit your repository events.
|
|||
keywords: dtr, events, log, activity stream
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## 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](/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.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to manage applications in Docker Trusted Registry.
|
|||
keywords: DTR, trusted registry, Docker apps
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
With the introduction of [the experimental `app` plugin](/engine/reference/commandline/app/) to the Docker CLI, DTR has been enhanced to include application management. In DTR 2.7, you can push an app to your DTR repository and have an application be clearly distinguished from [individual and multi-architecture container images](/ee/dtr/user/manage-images/pull-and-push-images/#push-an-image/), as well as [plugins](/engine/reference/commandline/plugin_push/). When you push an application to DTR, you see two image tags:
|
||||
|
||||
| Image | Tag | Type | Under the hood |
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to delete images from Docker Trusted Registry.
|
|||
keywords: registry, delete
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
To delete an image, navigate to the **Tags** tab of the repository page on the DTR web interface.
|
||||
In the **Tags** tab, select all the image
|
||||
tags you want to delete, and click the **Delete** button.
|
||||
|
|
|
@ -7,6 +7,8 @@ redirect_from:
|
|||
- /ee/dtr/deprecation-notice/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Since DTR is secure by default, you need to create the image repository before
|
||||
being able to push the image to DTR.
|
||||
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to dismiss a vulnerability reported by the security
|
|||
keywords: registry, security scanner
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
DTR scans your images for vulnerabilities but sometimes it can report that
|
||||
your image has vulnerabilities you know have been fixed. If that happens you
|
||||
can dismiss the warning.
|
||||
|
|
|
@ -10,6 +10,8 @@ keywords: registry, immutable
|
|||
{% assign repo="wordpress" %}
|
||||
{% assign tag="latest" %}
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
By default, users with [read and write access](../../admin/manage-users/permission-levels/) to a repository can push the same tag
|
||||
multiple times to that repository. For example, when ***user A*** pushes an image to `{{ org }}/{{ repo }}:{{ tag }}`, there is no preventing ***user B***
|
||||
from pushing an image with the same name but a completely different functionality. This can make it difficult to trace the image back to the build that generated
|
||||
|
|
|
@ -11,6 +11,8 @@ redirect_from:
|
|||
{% assign repo="wordpress" %}
|
||||
{% assign tag="latest" %}
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
You interact with Docker Trusted registry in the same way you interact with
|
||||
Docker Hub or any other registry:
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: View your repository permissions.
|
|||
keywords: dtr, repository, permissions
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
The **Repository Info** tab includes the following details:
|
||||
* README (which you can [edit if you have admin rights to the repository](../../admin/manage-users/permission-levels/#team-permission-levels))
|
||||
* Docker Pull Command
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to scan your Docker images for vulnerabilities.
|
|||
keywords: registry, scan, vulnerability
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
[](https://www.youtube.com/watch?v=121poCB0Nn8 "Images Security Scanning"){: target="_blank" ._}
|
||||
|
||||
Docker Trusted Registry can scan images in your repositories to verify that they
|
||||
|
|
|
@ -7,6 +7,8 @@ redirect_from:
|
|||
- /ee/dtr/user/manage-images/sign-images/manage-trusted-repositories/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Two key components of the Docker Trusted Registry are the Notary Server and the Notary
|
||||
Signer. These two containers provide the required components for using Docker Content
|
||||
Trust (DCT) out of the box. [Docker Content
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from:
|
|||
- /ee/ucp/admin/configure/integrate-with-multiple-registries/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
For more advanced deployments, you may want to share one Docker Trusted Registry
|
||||
across multiple Universal Control Planes. However, customers wanting to adopt
|
||||
this model alongside the [Only Run Signed
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to create a promotion policies that can automatically
|
|||
keywords: registry, promotion, mirror
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry allows you to automatically promote and mirror images
|
||||
based on a policy. In DTR 2.7, you have the option to promote applications with [the experimental `docker app` CLI addition](/ee/dtr/user/manage-applications/).
|
||||
Note that scanning-based promotion policies do not take effect until all application-bundled images have been scanned.
|
||||
|
|
|
@ -8,6 +8,8 @@ redirect_from:
|
|||
- /datacenter/dtr/2.5/guides/user/create-promotion-policies/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry allows you to create image promotion pipelines based on
|
||||
policies.
|
||||
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to set up a repository to poll for changes in another reg
|
|||
keywords: registry, promotion, mirror
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry allows you to set up a mirror of a repository by
|
||||
constantly polling it and pulling new image tags as they are pushed. This ensures your images are replicated across different registries for high availability. It also makes it easy to create a development pipeline that allows different
|
||||
users access to a certain image without giving them access to everything in the remote registry.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to create a promotion policy that promotes images to an e
|
|||
keywords: registry, promotion, mirror
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Trusted Registry allows you to create mirroring policies for a repository.
|
||||
When an image gets pushed to a repository and meets the mirroring criteria,
|
||||
DTR automatically pushes it to a repository in a remote Docker Trusted or Hub registry.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to use templates when setting your promotion policies to
|
|||
keywords: registry, promotion, mirror
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
When defining promotion policies you can use templates to dynamically name the
|
||||
tag that is going to be created.
|
||||
|
||||
|
|
|
@ -6,6 +6,8 @@ keywords: registry, tag pruning, tag limit, repo management
|
|||
|
||||
## Overview
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Tag pruning is the process of cleaning up unnecessary or unwanted repository tags. As of v2.6, you can configure the Docker Trusted Registry (DTR) to automatically perform tag pruning on repositories that you manage by:
|
||||
|
||||
* specifying a tag pruning policy or alternatively,
|
||||
|
|
|
@ -7,6 +7,7 @@ redirect_from:
|
|||
- /manuals/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
The Docker Enterprise platform is the leading container platform for continuous, high-velocity innovation. Docker is the only independent container platform that enables developers to seamlessly build and share any application — from legacy to modern — and operators to securely run them anywhere - from hybrid cloud to the edge.
|
||||
|
||||
|
|
|
@ -6,6 +6,8 @@ toc_min: 1
|
|||
toc_max: 2
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This page provides information about Docker Enterprise 3.0 licensing. Docker Enterprise 3.0 is a soft bundle of products that deliver the complete desktop-to-cloud workflow.
|
||||
|
||||
> Important
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn about the new features, bug fixes, and breaking changes for D
|
|||
keywords: engine enterprise, ucp, dtr, desktop enterprise, whats new, release notes
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This page provides information about Docker Enterprise 3.0. For
|
||||
detailed information about for each enterprise component, refer to the individual component release notes
|
||||
pages listed in the following **Docker Enterprise components install and upgrade** section.
|
||||
|
|
|
@ -13,6 +13,8 @@ green-check: '{: style="height: 14px; mar
|
|||
install-prefix-ee: '/install/linux/docker-ee'
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker Enterprise is designed for enterprise development as well as IT teams who build, share, and run business-critical
|
||||
applications at scale in production. Docker Enterprise is an integrated container platform that includes
|
||||
Docker Desktop Enterprise, a secure image registry, advanced management control plane, and Docker Engine - Enterprise.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to add metadata to cluster nodes that can be used to spec
|
|||
keywords: cluster, node, label, swarm, metadata
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
With Docker UCP, you can add labels to your nodes. Labels are metadata that
|
||||
describe the node, like its role (development, QA, production), its region
|
||||
(US, EU, APAC), or the kind of disk (hdd, ssd). Once you have labeled your
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to add new SANs to cluster nodes, allowing you to connect
|
|||
keywords: cluster, node, label, certificate, SAN
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
UCP always runs with HTTPS enabled. When you connect to UCP, you need to make
|
||||
sure that the hostname that you use to connect is recognized by UCP's
|
||||
certificates. If, for instance, you put UCP behind a load balancer that
|
||||
|
|
|
@ -5,6 +5,8 @@ keywords: cluster, psp, security
|
|||
---
|
||||
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
This is the current list of admission controllers used by Docker:
|
||||
|
||||
### Default
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from:
|
|||
- /engine/admin/prometheus/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
[Prometheus](https://prometheus.io/) is an open-source systems monitoring and
|
||||
alerting toolkit. You can configure Docker as a Prometheus target. This topic
|
||||
shows you how to configure Docker, set up Prometheus to run as a Docker
|
||||
|
|
|
@ -6,6 +6,8 @@ redirect_from:
|
|||
- /ee/ucp/authorization/migrate-kubernetes-roles/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
UCP 3.0 used its own role-based access control (RBAC) for Kubernetes clusters. New in UCP 3.1 is the ability to use native Kubernetes RBAC. The benefits of doing this are:
|
||||
|
||||
- Many ecosystem applications and integrations expect Kubernetes RBAC as a part of their YAML files to provide access to service accounts.
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to deploy Calico Route Reflectors to improve performance
|
|||
keywords: cluster, node, label, certificate, SAN
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
UCP uses Calico as the default Kubernetes networking solution. Calico is
|
||||
configured to create a BGP mesh between all nodes in the cluster.
|
||||
|
||||
|
|
|
@ -5,6 +5,8 @@ keywords: logs, ucp, swarm, kubernetes, audits
|
|||
redirect_from: /ee/ucp/admin/configure/create-audit-logs/
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Audit logs are a chronological record of security-relevant activities by
|
||||
individual users, administrators or software components that have affected the
|
||||
system. They are focused on external user/agent actions and security rather than
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to modify service accounts to enable Helm and Tiller to o
|
|||
keywords: Helm, ucp, Tiller, Kubernetes, service accounts, Kubernetes
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
To use [Helm and Tiller](https://helm.sh/) with UCP, you must modify the `kube-system` default service account to define the necessary roles. Enter the following `kubectl` commands in this order:
|
||||
|
||||
```
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to configure user authentication with SAML 2.0
|
|||
keywords: SAML, ucp, authentication, SSO, Okta, ADFS
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
SAML is commonly supported by enterprise authentication systems. SAML-based single sign-on (SSO) gives you access to UCP through a SAML 2.0-compliant identity provider.
|
||||
|
||||
SAML-based single sign-on (SSO) gives you access to UCP through a SAML 2.0-compliant identity provider. UCP supports SAML for authentication as a service provider integrated with your identity provider.
|
||||
|
|
|
@ -5,6 +5,8 @@ description: Learn how to integrate UCP with an LDAP service, so that you can
|
|||
keywords: LDAP, UCP, authentication, user management
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
Docker UCP integrates with LDAP directory services, so that you can manage
|
||||
users and groups from your organization's directory and it will automatically
|
||||
propagate that information to UCP and DTR.
|
||||
|
|
|
@ -4,6 +4,8 @@ description: Learn how to use SAML to link a UCP team with an Identity Provider
|
|||
keywords: cluster, node, join
|
||||
---
|
||||
|
||||
>{% include enterprise_label_shortform.md %}
|
||||
|
||||
## SAML integration
|
||||
|
||||
Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties. The SAML integration process is described below.
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue