mirror of https://github.com/docker/docs.git
Incorporated technical feedback
Update based on session with Ada and Ryan Discourage use of NFS storage URL flag Additional section on storage backend switch Discourage NFS storage URL option for now Polish on necessary storage backend updates Final technical edits Fix crud on DTR release notes page Update note on storage links
This commit is contained in:
Maria Bermudez
parent
a63b74a05d
commit
faf1e52357
|
|
@ -1,55 +1,61 @@
|
|||
---
|
||||
title: Configure DTR image storage
|
||||
description: Storage configuration for Docker Trusted Registry
|
||||
keywords: storage drivers, NFS, Azure, S3
|
||||
keywords: dtr, storage drivers, NFS, Azure, S3
|
||||
---
|
||||
|
||||
## Configure your storage backend
|
||||
|
||||
By default DTR uses the local filesystem of the node where it is running to
|
||||
store your Docker images. You can configure DTR to use an external storage
|
||||
backend, for improved performance or high availability.
|
||||
|
||||
|
||||
|
||||
If your DTR deployment only has a single replica, you can continue using the
|
||||
local filesystem to store your Docker images. If your DTR deployment has
|
||||
multiple replicas, for high availability, you need to ensure all replicas are
|
||||
using the same storage backend. When a user pulls an image, the node serving
|
||||
the request needs to have access to that image.
|
||||
If your DTR deployment has a single replica, you can continue using the
|
||||
local filesystem for storing your Docker images. If your DTR deployment has
|
||||
multiple replicas, make sure all replicas are
|
||||
using the same storage backend for high availability. Whenever a user pulls an image, the DTR
|
||||
node serving the request needs to have access to that image.
|
||||
|
||||
DTR supports these storage systems:
|
||||
DTR supports the following storage systems:
|
||||
|
||||
* Local filesystem
|
||||
* NFS
|
||||
* Amazon S3 or compatible
|
||||
* Google Cloud Storage
|
||||
* Microsoft Azure Blob storage
|
||||
* OpenStack Swift
|
||||
* [NFS](nfs.md)
|
||||
* [Bind Mount](/storage/bind-mounts/)
|
||||
* [Volume](/storage/volumes/)
|
||||
* Cloud Storage Providers
|
||||
* [Amazon S3](s3.md)
|
||||
* [Microsoft Azure](/registry/storage-drivers/azure/)
|
||||
* [OpenStack Swift](/registry/storage-drivers/swift/)
|
||||
* [Google Cloud Storage](/registry/storage-drivers/gcs/)
|
||||
|
||||
To configure the storage backend, you can log into the **DTR web UI**
|
||||
as an administrator user, navigate to the **Settings** page, and choose
|
||||
**Storage**.
|
||||
> **Note**: Some of the previous links are meant to be informative and are not representative of DTR's implementation of these storage systems.
|
||||
|
||||
To configure the storage backend, log in to the DTR web interface
|
||||
as an admin, and navigate to **System > Storage**.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
The storage configuration page in the DTR web UI has options for the most
|
||||
common configuration options, but you can also upload a yaml configuration file.
|
||||
The storage configuration page gives you the most
|
||||
common configuration options, but you have the option to upload a configuration file in `.yml`, `.yaml`, or `.txt` format.
|
||||
|
||||
The format of this configuration file is similar to the one used by
|
||||
[Docker Registry](/registry/configuration.md).
|
||||
See [Docker Registry Configuration](/registry/configuration.md) for configuration options.
|
||||
|
||||
## Local filesystem
|
||||
|
||||
By default, DTR creates a volume named `dtr-registry-<replica-id>` to store
|
||||
your images using the local filesystem. You can customize the name and path of
|
||||
the volume used by DTR, using the `docker/dtr reconfigure --dtr-storage-volume`
|
||||
option.
|
||||
the volume by using `docker/dtr install --dtr-storage-volume` or `docker/dtr reconfigure --dtr-storage-volume`.
|
||||
|
||||
> When running DTR 2.5 (with experimental online garbage collection) and 2.6.0 to 2.6.3, there is an issue with [reconfiguring DTR with `--nfs-storage-url`](/ee/dtr/release-notes#version-26) which leads to erased tags. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed. To work around the `--nfs-storage-url` flag issue, manually create a storage volume on each DTR node. If DTR is already installed in your cluster, [reconfigure DTR](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) with the `--dtr-storage-volume` flag using your newly-created volume.
|
||||
{: .warning}
|
||||
|
||||
If you're deploying DTR with high-availability, you need to use NFS or any other
|
||||
centralized storage backend so that all your DTR replicas have access to the
|
||||
same images.
|
||||
|
||||
To check how much space your images are taking in the local filesystem, you
|
||||
can ssh into the node where DTR is deployed and run:
|
||||
To check how much space your images are utilizing in the local filesystem, SSH into the DTR node and run:
|
||||
|
||||
```bash
|
||||
{% raw %}
|
||||
|
|
@ -62,15 +68,33 @@ $(dirname $(docker volume inspect --format '{{.Mountpoint}}' dtr-registry-<dtr-r
|
|||
{% endraw %}
|
||||
```
|
||||
|
||||
## NFS
|
||||
### NFS
|
||||
|
||||
You can configure your DTR replicas to store images on an NFS partition, so that
|
||||
all replicas can share the same storage backend.
|
||||
|
||||
[Learn how to configure DTR with NFS](nfs.md).
|
||||
|
||||
## Cloud Storage
|
||||
|
||||
## Amazon S3
|
||||
### Amazon S3
|
||||
|
||||
DTR supports AWS3 or other storage systems that are S3-compatible like Minio.
|
||||
[Learn how to configure DTR with Amazon S3](s3.md).
|
||||
DTR supports Amazon S3 or other storage systems that are S3-compatible like Minio.
|
||||
[Learn how to configure DTR with Amazon S3](s3.md).
|
||||
|
||||
## Switching storage backends
|
||||
|
||||
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. Make sure to [perform a backup](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-data) before you change your storage backend when running DTR 2.5 (with online garbage collection) and 2.6.0-2.6.3. If you encounter an issue with lost tags, refer to the following resources:
|
||||
* For changes to reconfigure and restore options in DTR 2.6, see [docker/dtr reconfigure](/reference/dtr/2.6/cli/reconfigure/) and [docker/dtr restore](/reference/dtr/2.6/cli/restore).
|
||||
* For Docker's recommended recovery strategies, see [DTR 2.6 lost tags after reconfiguring storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage).
|
||||
* For NFS-specific changes, see [Use NFS](nfs.md).
|
||||
* For S3-specific changes, see [Learn how to configure DTR with Amazon S3](s3.md).
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Use NFS](nfs.md)
|
||||
- [Use S3](s3.md)
|
||||
- CLI reference pages
|
||||
- [docker/dtr install](/reference/dtr/2.6/cli/install/)
|
||||
- [docker/dtr reconfigure](/reference/dtr/2.6/cli/reconfigure/)
|
||||
- [docker/dtr restore](/reference/dtr/2.6/cli/restore/)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,10 @@ description: Learn how to integrate Docker Trusted Registry with NFS
|
|||
keywords: registry, dtr, storage, nfs
|
||||
---
|
||||
|
||||
You can configure DTR to store Docker images in an NFS directory.
|
||||
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).
|
||||
See [changes to NFS reconfiguration below](/ee/dtr/admin/configure/external-storage/nfs/#reconfigure-dtr-to-use-nfs) if you have previously configured DTR to use NFS.
|
||||
|
||||
Before installing or configuring DTR to use an NFS directory, make sure that:
|
||||
|
||||
|
|
@ -36,23 +39,26 @@ docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }
|
|||
<other options>
|
||||
```
|
||||
|
||||
Use the format `nfs://<nfs server>/<directory>` for the NFS storage URL. To support **NFS v4**, you can now specify additional options when running [docker/dtr install](../../../../../reference/dtr/2.6/cli/install/) with `--nfs-storage-url`.
|
||||
Use the format `nfs://<nfs server>/<directory>` for the NFS storage URL. To support **NFS v4**, you can now specify additional options when running [docker/dtr install](/reference/dtr/2.6/cli/install/) with `--nfs-storage-url`.
|
||||
|
||||
When joining replicas to a DTR cluster, the replicas will pick up your storage
|
||||
configuration, so you will not need to specify it again.
|
||||
|
||||
### Reconfigure DTR to use NFS
|
||||
|
||||
When upgrading from a previous version of DTR that is already using
|
||||
NFS, you can continue using the same configurations. To support **NFS v4**, additional NFS reconfiguration options have been added to the CLI. See [docker/dtr reconfigure](../../../../../reference/dtr/2.6/cli/reconfigure/) for more details.
|
||||
To support **NFS v4**, more NFS options have been added to the CLI. See [New Features for 2.6.0 - CLI](/ee/dtr/release-notes/#260) for updates to [docker/dtr reconfigure](/reference/dtr/2.6/cli/reconfigure/).
|
||||
|
||||
|
||||
To take advantage of the new DTR built-in support for NFS, you can
|
||||
reconfigure DTR to use NFS:
|
||||
> When running DTR 2.5 (with experimental online garbage collection) and 2.6.0 to 2.6.3, there is an issue with [reconfiguring and restoring DTR with `--nfs-storage-url`](/ee/dtr/release-notes#version-26) which leads to erased tags. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed. To work around the `--nfs-storage-url` flag issue, manually create a storage volume. If DTR is already installed in your cluster, [reconfigure DTR](/reference/dtr/2.6/cli/reconfigure/) with the `--dtr-storage-volume` flag using your newly-created volume.
|
||||
>
|
||||
> See [Reconfigure Using a Local NFS Volume]( https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) for Docker's recommended recovery strategy.
|
||||
{: .warning}
|
||||
|
||||
```bash
|
||||
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }} reconfigure \
|
||||
--nfs-storage-url <nfs-storage-url>
|
||||
docker run --rm -it \
|
||||
docker/dtr:{{ page.dtr_version}} reconfigure \
|
||||
--ucp-url <ucp_url> \
|
||||
--ucp-username <ucp_username> \
|
||||
--dtr-storage-volume <dtr-registry-nf>
|
||||
```
|
||||
|
||||
To reconfigure DTR to stop using NFS storage, leave the `--nfs-storage-url` option
|
||||
|
|
@ -63,9 +69,12 @@ docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version}}
|
|||
--nfs-storage-url ""
|
||||
```
|
||||
|
||||
If the IP address of your NFS server changes with the DNS address staying the same, you should still
|
||||
reconfigure DTR to stop using NFS storage, and then add it back again.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Create a backup](/ee/dtr/admin/disaster-recovery/create-a-backup/)
|
||||
- [Restore from a backup](/ee/dtr/admin/disaster-recovery/restore-from-backup/)
|
||||
- [Configure where images are stored](index.md)
|
||||
- CLI reference pages
|
||||
- [docker/dtr install](/reference/dtr/2.6/cli/install/)
|
||||
- [docker/dtr reconfigure](/reference/dtr/2.6/cli/reconfigure/)
|
||||
- [docker/dtr restore](/reference/dtr/2.6/cli/restore/)
|
||||
|
|
|
|||
|
|
@ -64,14 +64,12 @@ Here's an example of a policy like that:
|
|||
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Configure DTR
|
||||
|
||||
Once you've created a bucket and user, you can configure DTR to use it.
|
||||
Navigate to the **DTR web UI**, go to **Settings**, and choose **Storage**.
|
||||
In your browser, navigate to `https://<dtr-url`. Select **System > Storage**.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Select the **S3** option, and fill-in the information about the bucket and
|
||||
user.
|
||||
|
|
@ -133,3 +131,18 @@ DTR supports the following S3 regions:
|
|||
| us-gov-west-1 |
|
||||
| ca-central-1 |
|
||||
|
||||
## Update your S3 settings on the web interface
|
||||
|
||||
There is currently an issue with [changing your S3 settings on the web interface](/ee/dtr/release-notes#version-26) which leads to erased metadata. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed.
|
||||
|
||||
## Restore DTR with S3
|
||||
|
||||
To [restore DTR using your previously configured S3 settings](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage), use `docker/dtr restore` with `--dtr-use-default-storage` to keep your metadata.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Configure where images are stored](index.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -80,9 +80,18 @@ Where:
|
|||
* `<replica-id>` the id of the replica you backed up
|
||||
* `<dtr-external-url>`the url that clients use to access DTR
|
||||
|
||||
#### DTR 2.5 and below
|
||||
|
||||
If you're using NFS as a storage backend, also include `--nfs-storage-url` as
|
||||
part of your restore command, otherwise DTR is restored but starts using a
|
||||
local volume to persist your Docker images.
|
||||
local volume to persist your Docker images.
|
||||
|
||||
#### DTR 2.5 (with experimental online garbage collection) and DTR 2.6.0-2.6.3
|
||||
|
||||
> When running DTR 2.5 (with experimental online garbage collection) and 2.6.0 to 2.6.3, there is an issue with [reconfiguring and restoring DTR with `--nfs-storage-url`](/ee/dtr/release-notes#version-26) which leads to erased tags. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed. To work around the `--nfs-storage-url`flag issue, manually create a storage volume on each DTR node. To [restore DTR](/reference/dtr/2.6/cli/restore/) from an existing backup, use `docker/dtr restore` with `--dtr-storage-volume` and the new volume.
|
||||
>
|
||||
> See [Restore to a Local NFS Volume]( https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for Docker's recommended recovery strategy.
|
||||
{: .warning}
|
||||
|
||||
### Re-fetch the vulnerability database
|
||||
|
||||
|
|
@ -90,3 +99,7 @@ If you're scanning images, you now need to download the vulnerability database.
|
|||
|
||||
After you successfully restore DTR, you can join new replicas the same way you
|
||||
would after a fresh installation. [Learn more](../configure/set-up-vulnerability-scans.md).
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [docker/dtr restore](/reference/dtr/2.6/cli/restore/)
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB After Width: | Height: | Size: 131 KiB |
|
|
@ -43,6 +43,10 @@ to upgrade your installation to the latest release.
|
|||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
* Changing your S3 settings through the web interface will lead to erased metadata (ENGDTR-793). See [Restore to Cloud Storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage) for Docker's recommended recovery strategy.
|
||||
|
||||
* CLI
|
||||
* When reconfiguring and restoring DTR, specifying `--nfs-storage-url` will assume you are switching to a fresh storage backend and will wipe your existing tags (ENGDTR-794). See [Reconfigure Using a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) and [Restore to a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for Docker's recommended recovery strategies.
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
|
|
@ -69,6 +73,10 @@ to upgrade your installation to the latest release.
|
|||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
* Changing your S3 settings through the web interface will lead to erased metadata (ENGDTR-793). See [Restore to Cloud Storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage) for Docker's recommended recovery strategy.
|
||||
|
||||
* CLI
|
||||
* When reconfiguring and restoring DTR, specifying `--nfs-storage-url` will assume you are switching to a fresh storage backend and will wipe your existing tags (ENGDTR-794). See [Reconfigure Using a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) and [Restore to a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for Docker's recommended recovery strategies.
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
|
|
@ -100,6 +108,10 @@ to upgrade your installation to the latest release.
|
|||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
* Changing your S3 settings through the web interface will lead to erased metadata (ENGDTR-793). See [Restore to Cloud Storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage) for Docker's recommended recovery strategy.
|
||||
|
||||
* CLI
|
||||
* When reconfiguring and restoring DTR, specifying `--nfs-storage-url` will assume you are switching to a fresh storage backend and will wipe your existing tags (ENGDTR-794). See [Reconfigure Using a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) and [Restore to a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for Docker's recommended recovery strategies.
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
|
|
@ -150,6 +162,10 @@ to upgrade your installation to the latest release.
|
|||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
* Changing your S3 settings through the web interface will lead to erased metadata (ENGDTR-793). See [Restore to Cloud Storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage) for Docker's recommended recovery strategy.
|
||||
|
||||
* CLI
|
||||
* When reconfiguring and restoring DTR, specifying `--nfs-storage-url` will assume you are switching to a fresh storage backend and will wipe your existing tags (ENGDTR-794). See [Reconfigure Using a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) and [Restore to a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for Docker's recommended recovery strategies.
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Change DTR configurations
|
|||
keywords: dtr, cli, reconfigure
|
||||
---
|
||||
|
||||
Change DTR configurations
|
||||
Change DTR configurations.
|
||||
|
||||
## Usage
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ docker run -it --rm docker/dtr \
|
|||
## Description
|
||||
|
||||
|
||||
This command changes DTR configuration settings.
|
||||
This command changes DTR configuration settings. If you are using NFS as a storage volume, see [Use NFS](/ee/dtr/admin/configure/external-storage/nfs/) for details on changes to the reconfiguration process.
|
||||
|
||||
DTR is restarted for the new configurations to take effect. To have no down
|
||||
time, configure your DTR for high availability.
|
||||
|
|
@ -40,7 +40,7 @@ time, configure your DTR for high availability.
|
|||
| `--log-host` | $LOG_HOST | The syslog system to send logs to. The endpoint to send logs to. Use this flag if you set `--log-protocol` to `tcp` or `udp`. |
|
||||
| `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: INFO. The supported log levels are `debug`, `info`, `warn`, `error`, or `fatal`. |
|
||||
| `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal. By default, DTR internal components log information using the logger specified in the Docker daemon in the node where the DTR replica is deployed. Use this option to send DTR logs to an external syslog system. The supported values are `tcp`, `udp`, and `internal`. Internal is the default option, stopping DTR from sending logs to an external system. Use this flag with `--log-host`. |
|
||||
| `--nfs-storage-url` | $NFS_STORAGE_URL | Use NFS to store Docker images following this format: `nfs://<ip|hostname>/<mountpoint>`. By default, DTR creates a volume to store the Docker images in the local filesystem of the node where DTR is running, without high availability. To use this flag, you need to install an NFS client library like `nfs-common` in the node where you're deploying DTR. You can test this by running `showmount -e <nfs-server>`. When you join new replicas, they will start using NFS so there is no need to specify this flag. To reconfigure DTR to stop using NFS, leave this option empty: `--nfs-storage-url ""`. See [USE NFS](/ee/dtr/admin/configure/external-storage/nfs/) for more details. |
|
||||
| `--nfs-storage-url` | $NFS_STORAGE_URL | When running DTR 2.5 (with experimental online garbage collection) and 2.6.0-2.6.3, there is an issue with [reconfiguring and restoring DTR with `--nfs-storage-url`](/ee/dtr/release-notes#version-26) which leads to erased tags. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed. To work around the issue, manually create a storage volume on each DTR node and reconfigure DTR with `--dtr-storage-volume` and your newly-created volume instead. See [Reconfigure Using a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#reconfigureusingalocalnfsvolume) for more details. To reconfigure DTR to stop using NFS, leave this option empty: `--nfs-storage-url ""`. See [USE NFS](/ee/dtr/admin/configure/external-storage/nfs/) for more details. |
|
||||
| `--async-nfs` | $ASYNC_NFS | Use async NFS volume options on the replica specified in the `--existing-replica-id` option. The NFS configuration must be set with `--nfs-storage-url` explicitly to use this option. Using `--async-nfs` will bring down any containers on the replica that use the NFS volume, delete the NFS volume, bring it back up with the appropriate configuration, and restart any containers that were brought down. |
|
||||
| `--nfs-options` | $NFS_OPTIONS | Pass in NFS volume options verbatim for the replica specified in the `--existing-replica-id` option. The NFS configuration must be set with `--nfs-storage-url` explicitly to use this option. Specifying `--nfs-options` will pass in character-for-character the options specified in the argument when creating or recreating the NFS volume. For instance, to use NFS v4 with async, pass in "rw,nfsvers=4,async" as the argument. |
|
||||
| `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for. When using `--http-proxy` you can use this flag to specify a list of domains that you don't want to route through the proxy. Format `acme.com[, acme.org]`. |
|
||||
|
|
|
|||
|
|
@ -46,9 +46,9 @@ DTR replicas for high availability.
|
|||
| `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with `--dtr-cert "$(cat ca.pem)"`. |
|
||||
| `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR. When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the URL you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users log in separately into the two applications. You can enable and disable single sign-on within your DTR system settings. Format `https://host[:port]`, where port is the value you used with `--replica-https-port`. |
|
||||
| `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with `--dtr-key "$(cat ca.pem)"`. |
|
||||
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Mandatory flag to allow for DTR to fall back to your configured storage setting at the time of backup. If you have previously configured DTR to use a full path or volume name for storage, specify this flag to use the same setting on restore. See [docker/dtr install](install.md) and [docker/dtr reconfigure](reconfigure.md) for usage details. Required if neither `--dtr-use-default-storage` nor `--nfs-storage-url` is set. |
|
||||
| `--dtr-use-default-storage` | $DTR_DEFAULT_STORAGE | Mandatory flag to allow for DTR to fall back to either your local filesystem or cloud storage depending on what was configured at the time of backup. If cloud storage was configured, then the default storage on restore is cloud storage. Otherwise, local storage is used. Required if neither `--dtr-storage-volume` nor `--nfs-storage-url` is set. |
|
||||
| `--nfs-storage-url` | $NFS_STORAGE_URL | Mandatory flag to allow for DTR to fall back to your configured storage setting at the time of backup. If NFS was previously configured, you must explicitly specify this flag to recover your NFS settings on restore. See [docker/dtr install](install.md) and [docker/dtr reconfigure](reconfigure.md) for NFS configuration options. Required if neither `--dtr-storage-volume` nor `--dtr-use-default-storage` is set. |
|
||||
| `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Mandatory flag to allow for DTR to fall back to your configured storage setting at the time of backup. If you have previously configured DTR to use a full path or volume name for storage, specify this flag to use the same setting on restore. See [docker/dtr install](install.md) and [docker/dtr reconfigure](reconfigure.md) for usage details. |
|
||||
| `--dtr-use-default-storage` | $DTR_DEFAULT_STORAGE | Mandatory flag to allow for DTR to fall back to your configured storage backend at the time of backup. If cloud storage was configured, then the default storage on restore is cloud storage. Otherwise, local storage is used. With DTR 2.5 (with experimental online garbage collection) and 2.6.0-2.6.3, this flag must be specified in order to keep your DTR metadata. If you encounter an issue with lost tags, see [Restore to Cloud Storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage) for Docker's recommended recovery strategy. |
|
||||
| `--nfs-storage-url` | $NFS_STORAGE_URL | Mandatory flag to allow for DTR to fall back to your configured storage setting at the time of backup. When running DTR 2.5 (with experimental online garbage collection) and 2.6.0-2.6.3, there is an issue with [reconfiguring and restoring DTR with `--nfs-storage-url`](/ee/dtr/release-notes#version-26) which leads to erased tags. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed. If NFS was previously configured, you have to manually create a storage volume on each DTR node and specify `--dtr-storage-volume` with the newly-created volume instead. See [Restore to a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for more details. For additional NFS configuration options to support **NFS v4**, see [docker/dtr install](install.md) and [docker/dtr reconfigure](reconfigure.md). |
|
||||
| `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server. Use `--enable-pprof=false` to disable it. Once DTR is deployed with this flag, you can access the `pprof` endpoint for the api server at `/debug/pprof`, and the registry endpoint at `/registry_debug_pprof/debug/pprof`. |
|
||||
| `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. |
|
||||
| `--http-proxy` | $DTR_HTTP_PROXY | The HTTP proxy used for outgoing requests. |
|
||||
|
|
|
|||
Loading…
Reference in New Issue