diff --git a/.vale.ini b/.vale.ini index 55aa8f26f79a..68ca544a2994 100644 --- a/.vale.ini +++ b/.vale.ini @@ -13,6 +13,19 @@ Docker.Capitalization = NO Vale.Spelling = NO Vale.Terms = NO Docker.Capitalization = NO +Docker.We = NO + +[content/manuals/build/buildkit/dockerfile-release-notes.md] +Vale.Spelling = NO +Vale.Terms = NO +Docker.Capitalization = NO +Docker.We = NO + +[content/manuals/*/release-notes.md] +Vale.Spelling = NO +Vale.Terms = NO +Docker.Capitalization = NO +Docker.We = NO [content/contribute/*.md] Vale.Spelling = NO diff --git a/_vale/config/vocabularies/Docker/accept.txt b/_vale/config/vocabularies/Docker/accept.txt index 9fb5c354da85..a2e494e4631f 100644 --- a/_vale/config/vocabularies/Docker/accept.txt +++ b/_vale/config/vocabularies/Docker/accept.txt @@ -14,14 +14,15 @@ bootup Btrfs Bugsnag BuildKit +buildkitd BusyBox CentOS Ceph cgroup Chrome Chrome DevTools -Citrix CI/CD +Citrix cli CLI CloudFront @@ -39,7 +40,6 @@ denylist deprovisioning deserialization deserialize -[Dd]ev Dev Environments? Dex displayName @@ -59,6 +59,7 @@ Docker's Dockerfile dockerignore Dockerize +Dockerized Dockerizing Entra EPERM @@ -129,6 +130,7 @@ netfilter netlabel netlink Netplan +Neovim NFSv\d Nginx npm @@ -142,9 +144,10 @@ osquery osxfs OTel Paketo +perl pgAdmin -plist PKG +plist Postgres PowerShell Python @@ -173,8 +176,8 @@ subvolume Syft syntaxes Sysbox -sysctls sysctl +sysctls Sysdig systemd Testcontainers @@ -184,8 +187,6 @@ Trivy Trixie Ubuntu ufw -ui -uid umask uncaptured Uncaptured @@ -203,6 +204,7 @@ Windows windowsfilter WireMock workdir +WORKDIR Xdebug youki Yubikey @@ -219,6 +221,8 @@ Zsh [Cc]odenames? [Cc]ompose [Cc]onfigs +[dD]eduplicate +[Dd]ev [Dd]istroless [Ff]ilepaths? [Ff]iletypes? diff --git a/content/manuals/build/bake/variables.md b/content/manuals/build/bake/variables.md index e4861a5a7239..120c18b3e848 100644 --- a/content/manuals/build/bake/variables.md +++ b/content/manuals/build/bake/variables.md @@ -2,7 +2,7 @@ title: Variables in Bake linkTitle: Variables weight: 40 -description: +description: keywords: build, buildx, bake, buildkit, hcl, variables --- @@ -93,7 +93,7 @@ range, or other condition, you can define custom validation rules using the `validation` block. In the following example, validation is used to enforce a numeric constraint on -a variable value; the `PORT` variable must be 1024 or higher. +a variable value; the `PORT` variable must be 1024 or greater. ```hcl {title=docker-bake.hcl} # Define a variable `PORT` with a default value and a validation rule @@ -103,7 +103,7 @@ variable "PORT" { # Validation block to ensure `PORT` is a valid number within the acceptable range validation { condition = PORT >= 1024 # Ensure `PORT` is at least 1024 - error_message = "The variable 'PORT' must be 1024 or higher." # Error message for invalid values + error_message = "The variable 'PORT' must be 1024 or greater." # Error message for invalid values } } ``` diff --git a/content/manuals/build/building/best-practices.md b/content/manuals/build/building/best-practices.md index c04e53e3ee53..fc480294f1a9 100644 --- a/content/manuals/build/building/best-practices.md +++ b/content/manuals/build/building/best-practices.md @@ -259,8 +259,8 @@ to create an efficient and maintainable Dockerfile. > [!TIP] > -> Want a better editing experience for Dockerfiles in VS Code? -> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning. +> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code +> see [Docker VS Code Extension](https://marketplace.visualstudio.com/items?itemName=docker.docker). ### FROM @@ -487,7 +487,7 @@ service, such as Apache and Rails, you would run something like `CMD for any service-based image. In most other cases, `CMD` should be given an interactive shell, such as bash, -python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD +Python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD ["php", "-a"]`. Using this form means that when you execute something like `docker run -it python`, you’ll get dropped into a usable shell, ready to go. `CMD` should rarely be used in the manner of `CMD ["param", "param"]` in @@ -556,7 +556,7 @@ $ docker run --rm test sh -c 'echo $ADMIN_USER' mark ``` -To prevent this, and really unset the environment variable, use a `RUN` command +To prevent this and unset the environment variable, use a `RUN` command with shell commands, to set, use, and unset the variable all in a single layer. You can separate your commands with `;` or `&&`. If you use the second method, and one of the commands fails, the `docker build` also fails. This is usually a @@ -763,7 +763,7 @@ RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres > with a significantly large UID inside a Docker container can lead to disk > exhaustion because `/var/log/faillog` in the container layer is filled with > NULL (\0) characters. A workaround is to pass the `--no-log-init` flag to -> useradd. The Debian/Ubuntu `adduser` wrapper does not support this flag. +> `useradd`. The Debian/Ubuntu `adduser` wrapper does not support this flag. Avoid installing or using `sudo` as it has unpredictable TTY and signal-forwarding behavior that can cause problems. If you absolutely need @@ -778,11 +778,11 @@ For more information about `USER`, see [Dockerfile reference for the USER instru ### WORKDIR For clarity and reliability, you should always use absolute paths for your -`WORKDIR`. Also, you should use `WORKDIR` instead of proliferating instructions +`WORKDIR`. Also, you should use `WORKDIR` instead of proliferating instructions like `RUN cd … && do-something`, which are hard to read, troubleshoot, and maintain. -For more information about `WORKDIR`, see [Dockerfile reference for the WORKDIR instruction](/reference/dockerfile.md#workdir). +For more information about `WORKDIR`, see [Dockerfile reference for the `WORKDIR` instruction](/reference/dockerfile.md#workdir). ### ONBUILD @@ -802,7 +802,7 @@ Dockerfile, as you can see in [Ruby’s `ONBUILD` variants](https://github.com/d Images built with `ONBUILD` should get a separate tag. For example, `ruby:1.9-onbuild` or `ruby:2.0-onbuild`. -Be careful when putting `ADD` or `COPY` in `ONBUILD`. The onbuild image +Be careful when putting `ADD` or `COPY` in `ONBUILD`. The `onbuild image fails catastrophically if the new build's context is missing the resource being added. Adding a separate tag, as recommended above, helps mitigate this by allowing the Dockerfile author to make a choice. diff --git a/content/manuals/build/buildkit/_index.md b/content/manuals/build/buildkit/_index.md index 35afb1ee6ad9..c15bec26456b 100644 --- a/content/manuals/build/buildkit/_index.md +++ b/content/manuals/build/buildkit/_index.md @@ -29,8 +29,9 @@ Apart from many new features, the main areas BuildKit improves on the current experience are performance, storage management, and extensibility. From the performance side, a significant update is a new fully concurrent build graph solver. It can run build steps in parallel when possible and optimize out -commands that don't have an impact on the final result. We have also optimized -the access to the local source files. By tracking only the updates made to these +commands that don't have an impact on the final result. +The access to the local source files has also been optimized. By tracking +only the updates made to these files between repeated build invocations, there is no need to wait for local files to be read or uploaded before the work can begin. @@ -39,7 +40,7 @@ files to be read or uploaded before the work can begin. At the core of BuildKit is a [Low-Level Build (LLB)](https://github.com/moby/buildkit#exploring-llb) definition format. LLB is an intermediate binary format that allows developers to extend BuildKit. LLB defines a content-addressable -dependency graph that can be used to put together very complex build +dependency graph that can be used to put together complex build definitions. It also supports features not exposed in Dockerfiles, like direct data mounting and nested invocation. @@ -115,7 +116,7 @@ daemon. BuildKit has experimental support for Windows containers (WCOW) as of version 0.13. This section walks you through the steps for trying it out. -We appreciate any feedback you submit by [opening an issue here](https://github.com/moby/buildkit/issues/new), especially `buildkitd.exe`. +To share feedback, [open an issue in the repository](https://github.com/moby/buildkit/issues/new), especially `buildkitd.exe`. ### Known limitations diff --git a/content/manuals/build/checks.md b/content/manuals/build/checks.md index afbf82392668..90cfda90735c 100644 --- a/content/manuals/build/checks.md +++ b/content/manuals/build/checks.md @@ -38,8 +38,8 @@ Build checks are useful for: > [!TIP] > -> Want a better editing experience for Dockerfiles in VS Code? -> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning. +> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code +> see [Docker VS Code Extension](https://marketplace.visualstudio.com/items?itemName=docker.docker). ## Build with checks diff --git a/content/manuals/build/ci/github-actions/_index.md b/content/manuals/build/ci/github-actions/_index.md index 4f80a110be52..68968242d5c3 100644 --- a/content/manuals/build/ci/github-actions/_index.md +++ b/content/manuals/build/ci/github-actions/_index.md @@ -29,7 +29,7 @@ The following GitHub Actions are available: - [Docker Setup Compose](https://github.com/marketplace/actions/docker-setup-compose): installs and sets up [Compose](../../../compose). - [Docker Setup Docker](https://github.com/marketplace/actions/docker-setup-docker): - installs Docker CE. + installs Docker Engine. - [Docker Setup QEMU](https://github.com/marketplace/actions/docker-setup-qemu): installs [QEMU](https://github.com/qemu/qemu) static binaries for multi-platform builds. diff --git a/content/manuals/build/ci/github-actions/cache.md b/content/manuals/build/ci/github-actions/cache.md index 5626447e1e43..9619a9315f1b 100644 --- a/content/manuals/build/ci/github-actions/cache.md +++ b/content/manuals/build/ci/github-actions/cache.md @@ -37,7 +37,7 @@ jobs: - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - + - name: Build and push uses: docker/build-push-action@v6 with: @@ -67,10 +67,10 @@ jobs: with: username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} - + - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - + - name: Build and push uses: docker/build-push-action@v6 with: @@ -108,10 +108,10 @@ jobs: with: username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} - + - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - + - name: Build and push uses: docker/build-push-action@v6 with: @@ -124,13 +124,13 @@ jobs: > [!IMPORTANT] > > Starting [April 15th, 2025, only GitHub Cache service API v2 will be supported](https://gh.io/gha-cache-sunset). -> +> > If you encounter the following error during your build: -> +> > ```console > ERROR: failed to solve: This legacy service is shutting down, effective April 15, 2025. Migrate to the new service ASAP. For more information: https://gh.io/gha-cache-sunset > ``` -> +> > You're probably using outdated tools that only support the legacy GitHub > Cache service API v1. Here are the minimum versions you need to upgrade to > depending on your use case: @@ -138,33 +138,33 @@ jobs: > * BuildKit >= v0.20.0 > * Docker Compose >= v2.33.1 > * Docker Engine >= v28.0.0 (if you're building using the Docker driver with containerd image store enabled) -> +> > If you're building using the `docker/build-push-action` or `docker/bake-action` > actions on GitHub hosted runners, Docker Buildx and BuildKit are already up > to date but on self-hosted runners, you may need to update them yourself. > Alternatively, you can use the `docker/setup-buildx-action` action to install > the latest version of Docker Buildx: -> +> > ```yaml > - name: Set up Docker Buildx > uses: docker/setup-buildx-action@v3 > with: > version: latest > ``` -> +> > If you're building using Docker Compose, you can use the > `docker/setup-compose-action` action: -> +> > ```yaml > - name: Set up Docker Compose > uses: docker/setup-compose-action@v1 > with: > version: latest > ``` -> +> > If you're building using the Docker Engine with the containerd image store > enabled, you can use the `docker/setup-docker-action` action: -> +> > ```yaml > - > name: Set up Docker @@ -182,7 +182,7 @@ jobs: ### Cache mounts BuildKit doesn't preserve cache mounts in the GitHub Actions cache by default. -If you wish to put your cache mounts into GitHub Actions cache and reuse it +To put your cache mounts into GitHub Actions cache and reuse it between builds, you can use a workaround provided by [`reproducible-containers/buildkit-cache-dance`](https://github.com/reproducible-containers/buildkit-cache-dance). @@ -224,7 +224,7 @@ jobs: with: username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} - + - name: Set up QEMU uses: docker/setup-qemu-action@v3 diff --git a/content/manuals/build/concepts/context.md b/content/manuals/build/concepts/context.md index 2818bec9b7b6..2bff1f4eef68 100644 --- a/content/manuals/build/concepts/context.md +++ b/content/manuals/build/concepts/context.md @@ -498,6 +498,7 @@ The following code snippet shows an example `.dockerignore` file. */*/temp* temp? ``` + This file causes the following build behavior: @@ -508,6 +509,8 @@ This file causes the following build behavior: | `*/*/temp*` | Exclude files and directories starting with `temp` from any subdirectory that is two levels below the root. For example, `/somedir/subdir/temporary.txt` is excluded. | | `temp?` | Exclude files and directories in the root directory whose names are a one-character extension of `temp`. For example, `/tempa` and `/tempb` are excluded. | + + Matching is done using Go's [`filepath.Match` function](https://golang.org/pkg/path/filepath#Match) rules. A preprocessing step uses Go's diff --git a/content/manuals/build/concepts/dockerfile.md b/content/manuals/build/concepts/dockerfile.md index 18601a9b15de..e62a763656fd 100644 --- a/content/manuals/build/concepts/dockerfile.md +++ b/content/manuals/build/concepts/dockerfile.md @@ -8,6 +8,8 @@ aliases: - /build/building/packaging/ --- + + ## Dockerfile It all starts with a Dockerfile. @@ -19,8 +21,8 @@ reference in the [Dockerfile reference](/reference/dockerfile.md). Here are the most common types of instructions: -| Instruction | Description | -| ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Instruction | Description | +|-----------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | [`FROM `](/reference/dockerfile.md#from) | Defines a base for your image. | | [`RUN `](/reference/dockerfile.md#run) | Executes any commands in a new layer on top of the current image and commits the result. `RUN` also has a shell form for running commands. | | [`WORKDIR `](/reference/dockerfile.md#workdir) | Sets the working directory for any `RUN`, `CMD`, `ENTRYPOINT`, `COPY`, and `ADD` instructions that follow it in the Dockerfile. | @@ -167,7 +169,7 @@ the container. Note the `# install app dependencies` line. This is a comment. Comments in Dockerfiles begin with the `#` symbol. As your Dockerfile evolves, comments can be instrumental to document how your Dockerfile works for any future readers -and editors of the file, including your future self! +and editors of the file, including your future self. > [!NOTE] > @@ -194,7 +196,7 @@ use the command to install the flask web framework. The next instruction uses the [`COPY` instruction](/reference/dockerfile.md#copy) to copy the -`hello.py` file from the local build context into the root directory of our image. +`hello.py` file from the local build context into the root directory of our image. ```dockerfile COPY hello.py / @@ -281,5 +283,5 @@ Docker host. > [!TIP] > -> Want a better editing experience for Dockerfiles in VS Code? -> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning. +> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code +> see [Docker VS Code Extension](https://marketplace.visualstudio.com/items?itemName=docker.docker). diff --git a/content/manuals/build/exporters/_index.md b/content/manuals/build/exporters/_index.md index 2921fb1ff31e..67ddf0df668a 100644 --- a/content/manuals/build/exporters/_index.md +++ b/content/manuals/build/exporters/_index.md @@ -222,8 +222,8 @@ The common parameters described here are: When you export a compressed output, you can configure the exact compression algorithm and level to use. While the default values provide a good -out-of-the-box experience, you may wish to tweak the parameters to optimize for -storage vs compute costs. Changing the compression parameters can reduce storage +out-of-the-box experience, you can tweak the parameters to optimize for +storage versus compute costs. Changing the compression parameters can reduce storage space required, and improve image download times, but will increase build times. To select the compression algorithm, you can use the `compression` option. For diff --git a/content/manuals/build/metadata/annotations.md b/content/manuals/build/metadata/annotations.md index 330deb818137..80eebbb2dc2f 100644 --- a/content/manuals/build/metadata/annotations.md +++ b/content/manuals/build/metadata/annotations.md @@ -6,6 +6,8 @@ aliases: - /build/building/annotations/ --- + + Annotations provide descriptive metadata for images. Use annotations to record arbitrary information and attach it to your image, which helps consumers and tools understand the origin, contents, and how to use the image. @@ -39,7 +41,7 @@ You can add annotations to an image at build-time, or when creating the image manifest or index. > [!NOTE] -> +> > The Docker Engine image store doesn't support loading images with > annotations. To build with annotations, make sure to push the image directly > to a registry, using the `--push` CLI flag or the diff --git a/content/manuals/build/release-notes.md b/content/manuals/build/release-notes.md index 07ef7ecd67a3..0849a9d0506e 100644 --- a/content/manuals/build/release-notes.md +++ b/content/manuals/build/release-notes.md @@ -157,10 +157,10 @@ The full release notes for this release are available ### Enhancements -- The history inspection command `buildx history inspect` now supports custom formatting with `--format` flag and JSON formatting for machine-readable output. [docker/buildx#2964](https://github.com/docker/buildx/pull/2964) +- The history inspection command `buildx history inspect` now supports custom formatting with `--format` flag and JSON formatting for machine-readable output. [docker/buildx#2964](https://github.com/docker/buildx/pull/2964) - Support for CDI device entitlement in build and bake. [docker/buildx#2994](https://github.com/docker/buildx/pull/2994) - Supported CDI devices are now shown in the builder inspection. [docker/buildx#2983](https://github.com/docker/buildx/pull/2983) -- When using [GitHub Cache backend `type=gha`](cache/backends/gha.md), the URL for the Version 2 or API is now read from the environment and sent to BuildKit. Version 2 backend requires BuildKit v0.20.0 or later. [docker/buildx#2983](https://github.com/docker/buildx/pull/2983), [docker/buildx#3001](https://github.com/docker/buildx/pull/3001) +- When using [GitHub Cache backend `type=gha`](cache/backends/gha.md), the URL of the Version 2 or API is now read from the environment and sent to BuildKit. Version 2 backend requires BuildKit v0.20.0 or later. [docker/buildx#2983](https://github.com/docker/buildx/pull/2983), [docker/buildx#3001](https://github.com/docker/buildx/pull/3001) ### Bug fixes diff --git a/content/manuals/desktop/settings-and-maintenance/settings.md b/content/manuals/desktop/settings-and-maintenance/settings.md index e33d365b2832..6cdf029213b7 100644 --- a/content/manuals/desktop/settings-and-maintenance/settings.md +++ b/content/manuals/desktop/settings-and-maintenance/settings.md @@ -249,7 +249,7 @@ and automatically uses these settings for signing in to Docker, for pulling and container Internet access. If the proxy requires authorization then Docker Desktop dynamically asks the developer for a username and password. All passwords are stored securely in the OS credential store. Note that only the `Basic` proxy authentication method is supported so we recommend using an `https://` -URL for your HTTP/HTTPS proxies to protect passwords while in transit on the network. Docker Desktop +URL of your HTTP/HTTPS proxies to protect passwords while in transit on the network. Docker Desktop supports TLS 1.3 when communicating with proxies. To set a different proxy for Docker Desktop, turn on **Manual proxy configuration** and enter a single @@ -278,7 +278,7 @@ The HTTPS proxy settings used for scanning images are set using the `HTTPS_PROXY If your proxy uses Basic authentication, Docker Desktop prompts developers for a username and password and caches the credentials. All passwords are stored securely in the OS credential store. It will request re-authentication if that cache is removed. -It's recommended that you use an `https://` URL for HTTP/HTTPS proxies to protect passwords during network transit. Docker Desktop also supports TLS 1.3 for communication with proxies. +It's recommended that you use an `https://` URL of HTTP/HTTPS proxies to protect passwords during network transit. Docker Desktop also supports TLS 1.3 for communication with proxies. ##### Kerberos and NTLM authentication diff --git a/content/manuals/desktop/use-desktop/volumes.md b/content/manuals/desktop/use-desktop/volumes.md index 1486ff4f8dbf..02b4d2423be2 100644 --- a/content/manuals/desktop/use-desktop/volumes.md +++ b/content/manuals/desktop/use-desktop/volumes.md @@ -152,7 +152,7 @@ You can either [export a volume now](#export-a-volume-now) or [schedule a recurr Refer to the following documentation for your cloud provider to learn how to obtain a URL. - - Amazon Web Services: [Create a presigned URL for Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html) + - Amazon Web Services: [Create a presigned URL of Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html) - Microsoft Azure: [Generate a SAS token and URL](https://learn.microsoft.com/en-us/azure/data-explorer/kusto/api/connection-strings/generate-sas-token) - Google Cloud: [Create a signed URL to upload an object](https://cloud.google.com/storage/docs/access-control/signing-urls-with-helpers#upload-object) @@ -198,7 +198,7 @@ You can either [export a volume now](#export-a-volume-now) or [schedule a recurr Refer to the following documentation for your cloud provider to learn how to obtain a URL. - - Amazon Web Services: [Create a presigned URL for Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html) + - Amazon Web Services: [Create a presigned URL of Amazon S3 using an AWS SDK](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example_s3_Scenario_PresignedUrl_section.html) - Microsoft Azure: [Generate a SAS token and URL](https://learn.microsoft.com/en-us/azure/data-explorer/kusto/api/connection-strings/generate-sas-token) - Google Cloud: [Create a signed URL to upload an object](https://cloud.google.com/storage/docs/access-control/signing-urls-with-helpers#upload-object) diff --git a/content/manuals/engine/network/links.md b/content/manuals/engine/network/links.md index 0f97ccd40ab1..2e84cd353f7b 100644 --- a/content/manuals/engine/network/links.md +++ b/content/manuals/engine/network/links.md @@ -295,9 +295,9 @@ Docker uses this prefix format to define three distinct environment variables: * The `prefix_ADDR` variable contains the IP Address from the URL, for example `WEBDB_PORT_5432_TCP_ADDR=172.17.0.82`. -* The `prefix_PORT` variable contains just the port number from the URL for +* The `prefix_PORT` variable contains just the port number from the URL of example `WEBDB_PORT_5432_TCP_PORT=5432`. -* The `prefix_PROTO` variable contains just the protocol from the URL for +* The `prefix_PROTO` variable contains just the protocol from the URL of example `WEBDB_PORT_5432_TCP_PROTO=tcp`. If the container exposes multiple ports, an environment variable set is diff --git a/content/manuals/engine/security/trust/trust_delegation.md b/content/manuals/engine/security/trust/trust_delegation.md index df4b8d933ada..78f5e732d737 100644 --- a/content/manuals/engine/security/trust/trust_delegation.md +++ b/content/manuals/engine/security/trust/trust_delegation.md @@ -26,7 +26,7 @@ same as the registry URL specified in the image tag (following a similar logic t `$ docker push`). When using Docker Hub or DTR, the notary server URL is the same as the registry URL. However, for self-hosted environments or 3rd party registries, you will need to specify an alternative -URL for the notary server. This is done with: +URL of the notary server. This is done with: ```console $ export DOCKER_CONTENT_TRUST_SERVER=https://: