diff --git a/.markdownlint.json b/.markdownlint.json index 810281e8eb..eecf08fddf 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -20,5 +20,6 @@ }, "fenced-code-language": true, "table-pipe-style": true, - "table-column-count": true + "table-column-count": true, + "descriptive-link-text": { "prohibited_texts": ["click here","here","link","more","learn more","find out more"]} } diff --git a/content/contribute/components/videos.md b/content/contribute/components/videos.md index 3e2f1bcec5..72b27635ca 100644 --- a/content/contribute/components/videos.md +++ b/content/contribute/components/videos.md @@ -25,7 +25,7 @@ If all of the above criteria are met, you can reference the following best pract - Videos should adhere to the same standards for accessibility as the rest of the documentation. - Ensure the quality of your video by writing a script (if there's narration), making sure multiple browsers and URLs aren't visible, blurring or cropping out any sensitive information, and using smooth transitions between different browsers or screens. -Videos are not hosted in the Docker documentation repository. To add a video, you can use a [link](./links.md) to hosted content, or embed using an [iframe](#iframe). +Videos are not hosted in the Docker documentation repository. To add a video, you can [link to](./links.md) hosted content, or embed using an [iframe](#iframe). ## iframe diff --git a/content/guides/localstack.md b/content/guides/localstack.md index 856225f3de..e2c66e1576 100644 --- a/content/guides/localstack.md +++ b/content/guides/localstack.md @@ -76,7 +76,7 @@ Launch a quick demo of LocalStack by using the following steps: When you create a local S3 bucket using LocalStack, you're essentially simulating the creation of an S3 bucket on AWS. This lets you to test and develop applications that interact with S3 without needing an actual AWS account. - To create Local Amazon S3 bucket, you’ll need to install an `awscli-local` package to be installed on your system. This package provides the awslocal command, which is a thin wrapper around the AWS command line interface for use with LocalStack. It lets you to test and develop against a simulated environment on your local machine without needing to access the real AWS services. You can learn more about this utility [here](https://github.com/localstack/awscli-local). + To create Local Amazon S3 bucket, install the [`awscli-local` CLI](https://github.com/localstack/awscli-local) on your system. The `awslocal` command is a thin wrapper around the AWS command line interface for use with LocalStack. It lets you to test and develop against a simulated environment on your local machine without needing to access the real AWS services. ```console $ pip install awscli-local diff --git a/content/guides/python/configure-github-actions.md b/content/guides/python/configure-github-actions.md index b13e2dfbb2..96720fd995 100644 --- a/content/guides/python/configure-github-actions.md +++ b/content/guides/python/configure-github-actions.md @@ -110,7 +110,7 @@ Each GitHub Actions workflow includes one or several jobs. Each job consists of ## 2. Run the workflow -Let's commit the changes, push them to the `main` branch. In the workflow above, the trigger is set to `push` events on the `main` branch. This means that the workflow will run every time you push changes to the `main` branch. You can find more information about the workflow triggers [here](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). +Commit the changes and push them to the `main` branch. This workflow is runs every time you push changes to the `main` branch. You can find more information about workflow triggers [in the GitHub documentation](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). Go to the **Actions** tab of you GitHub repository. It displays the workflow. Selecting the workflow shows you the breakdown of all the steps. diff --git a/content/guides/ruby/configure-github-actions.md b/content/guides/ruby/configure-github-actions.md index 5203f158e1..a4a0301a04 100644 --- a/content/guides/ruby/configure-github-actions.md +++ b/content/guides/ruby/configure-github-actions.md @@ -89,7 +89,7 @@ Each GitHub Actions workflow includes one or several jobs. Each job consists of ## 2. Run the workflow -Let's commit the changes, push them to the `main` branch. In the workflow above, the trigger is set to `push` events on the `main` branch. This means that the workflow will run every time you push changes to the `main` branch. You can find more information about the workflow triggers [here](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). +Commit the changes and push them to the `main` branch. This workflow is runs every time you push changes to the `main` branch. You can find more information about workflow triggers [in the GitHub documentation](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). Go to the **Actions** tab of you GitHub repository. It displays the workflow. Selecting the workflow shows you the breakdown of all the steps. diff --git a/content/manuals/build/builders/drivers/kubernetes.md b/content/manuals/build/builders/drivers/kubernetes.md index 828d72cbd3..2036e7b863 100644 --- a/content/manuals/build/builders/drivers/kubernetes.md +++ b/content/manuals/build/builders/drivers/kubernetes.md @@ -75,8 +75,7 @@ is configurable using the following driver options: - `requests.cpu`, `requests.memory`, `requests.ephemeral-storage`, `limits.cpu`, `limits.memory`, `limits.ephemeral-storage` These options allow requesting and limiting the resources available to each - BuildKit pod according to the official Kubernetes documentation - [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). + BuildKit pod [according to the official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). For example, to create 4 replica BuildKit pods: @@ -247,8 +246,8 @@ that you want to support. ## Rootless mode The Kubernetes driver supports rootless mode. For more information on how -rootless mode works, and its requirements, see -[here](https://github.com/moby/buildkit/blob/master/docs/rootless.md). +rootless mode works, and its requirements, refer to the +[Rootless Buildkit documentation](https://github.com/moby/buildkit/blob/master/docs/rootless.md). To turn it on in your cluster, you can use the `rootless=true` driver option: diff --git a/content/manuals/build/builders/drivers/remote.md b/content/manuals/build/builders/drivers/remote.md index f002d49ea3..d059cdfdcc 100644 --- a/content/manuals/build/builders/drivers/remote.md +++ b/content/manuals/build/builders/drivers/remote.md @@ -48,9 +48,9 @@ Unix socket, and have Buildx connect through it. $ sudo ./buildkitd --group $(id -gn) --addr unix://$HOME/buildkitd.sock ``` - Alternatively, [see here](https://github.com/moby/buildkit/blob/master/docs/rootless.md) - for running buildkitd in rootless mode or [here](https://github.com/moby/buildkit/tree/master/examples/systemd) - for examples of running it as a systemd service. + Alternatively, refer to the [Rootless Buildkit documentation](https://github.com/moby/buildkit/blob/master/docs/rootless.md) + for running buildkitd in rootless mode, or [the BuildKit systemd examples](https://github.com/moby/buildkit/tree/master/examples/systemd) + for running it as a systemd service. 2. Check that you have a Unix socket that you can connect to. @@ -159,13 +159,13 @@ BuildKit manually. Additionally, when executing builds from inside Kubernetes pods, the Buildx builder will need to be recreated from within each pod or copied between them. -1. Create a Kubernetes deployment of `buildkitd`, as per the instructions - [here](https://github.com/moby/buildkit/tree/master/examples/kubernetes). +1. Create a Kubernetes deployment of `buildkitd` by following the instructions + [in the BuildKit documentation](https://github.com/moby/buildkit/tree/master/examples/kubernetes). - Following the guide, create certificates for the BuildKit daemon and client - using [create-certs.sh](https://github.com/moby/buildkit/blob/master/examples/kubernetes/create-certs.sh), - and create a deployment of BuildKit pods with a service that connects to - them. + Create certificates for the BuildKit daemon and client using the + [create-certs.sh](https://github.com/moby/buildkit/blob/master/examples/kubernetes/create-certs.sh), + script and create a deployment of BuildKit pods with a service that connects + to them. 2. Assuming that the service is called `buildkitd`, create a remote builder in Buildx, ensuring that the listed certificate files are present: diff --git a/content/manuals/build/buildkit/_index.md b/content/manuals/build/buildkit/_index.md index c15bec2645..147dd6426e 100644 --- a/content/manuals/build/buildkit/_index.md +++ b/content/manuals/build/buildkit/_index.md @@ -150,7 +150,7 @@ see [GitHub issues](https://github.com/moby/buildkit/issues?q=is%3Aissue%20state Select the Docker icon in the taskbar, and then **Switch to Windows containers...**. -3. Install containerd version 1.7.7 or later following the setup instructions [here](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#installing-containerd-on-windows). +3. Install containerd version 1.7.7 or later following the [setup instructions](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#installing-containerd-on-windows). 4. Download and extract the latest BuildKit release. diff --git a/content/manuals/docker-hub/repos/manage/builds/setup.md b/content/manuals/docker-hub/repos/manage/builds/setup.md index 38a97f360e..c5ce89478a 100644 --- a/content/manuals/docker-hub/repos/manage/builds/setup.md +++ b/content/manuals/docker-hub/repos/manage/builds/setup.md @@ -30,8 +30,8 @@ when the tests succeed. > [!NOTE] > - > You may be redirected to the settings page to [link](link-source.md) the - > code repository service. Otherwise, if you are editing the build settings + > You may be redirected to the settings page to [link the code repository + > service](link-source.md). Otherwise, if you are editing the build settings > for an existing automated build, select **Configure automated builds**. 4. Select the **source repository** to build the Docker images from. diff --git a/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md b/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md index 917ae4a172..7135384dfc 100644 --- a/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md +++ b/content/manuals/docker-hub/repos/manage/builds/troubleshoot.md @@ -61,7 +61,7 @@ system access to the repositories. This step is optional, but allows you to revoke the build-only keypair without removing other access. 2. Copy the private half of the keypair to your clipboard. -3. In Docker Hub, navigate to the build page for the repository that has linked private submodules. (If necessary, follow the steps [here](index.md#configure-automated-builds) to configure the automated build.) +3. In Docker Hub, navigate to the build page for the repository that has linked private submodules. (If necessary, [follow the steps here](index.md#configure-automated-builds) to configure the automated build.) 4. At the bottom of the screen, select the **plus** icon next to **Build Environment variables**. 5. Enter `SSH_PRIVATE` as the name for the new environment variable. 6. Paste the private half of the keypair into the **Value** field. diff --git a/content/manuals/engine/network/links.md b/content/manuals/engine/network/links.md index 2e84cd353f..acdc38fbc0 100644 --- a/content/manuals/engine/network/links.md +++ b/content/manuals/engine/network/links.md @@ -44,12 +44,6 @@ Let's say you used this command to run a simple Python Flask application: $ docker run -d -P training/webapp python app.py ``` -> [!NOTE] -> -> Containers have an internal network and an IP address. -> Docker can have a variety of network configurations. You can see more -> information on Docker networking [here](index.md). - When that container was created, the `-P` flag was used to automatically map any network port inside it to a random high port within an *ephemeral port range* on your Docker host. Next, when `docker ps` was run, you saw that port diff --git a/content/manuals/engine/security/seccomp.md b/content/manuals/engine/security/seccomp.md index 490eed296e..d85bcaed6a 100644 --- a/content/manuals/engine/security/seccomp.md +++ b/content/manuals/engine/security/seccomp.md @@ -20,11 +20,10 @@ CONFIG_SECCOMP=y ## Pass a profile for a container -The default `seccomp` profile provides a sane default for running containers with -seccomp and disables around 44 system calls out of 300+. It is moderately -protective while providing wide application compatibility. The default Docker -profile can be found -[here](https://github.com/moby/profiles/blob/main/seccomp/default.json). +The [default `seccomp` profile](https://github.com/moby/profiles/blob/main/seccomp/default.json) +provides a sane default for running containers with seccomp and disables around +44 system calls out of 300+. It is moderately protective while providing wide +application compatibility. In effect, the profile is an allowlist that denies access to system calls by default and then allows specific system calls. The profile works by defining a diff --git a/content/manuals/engine/security/trust/_index.md b/content/manuals/engine/security/trust/_index.md index 3d547c2ab7..8c50b075e8 100644 --- a/content/manuals/engine/security/trust/_index.md +++ b/content/manuals/engine/security/trust/_index.md @@ -121,8 +121,8 @@ Within the Docker CLI we can sign and push a container image with the `$ docker trust` command syntax. This is built on top of the Notary feature set. For more information, see the [Notary GitHub repository](https://github.com/theupdateframework/notary). -A prerequisite for signing an image is a Docker Registry with a Notary server (such as Docker Hub) attached. Instructions for -standing up a self-hosted environment can be found [here](/engine/security/trust/deploying_notary/). +A prerequisite for signing an image is a Docker Registry with a Notary server (such as Docker Hub) attached. +Refer to [Deploying Notary](/engine/security/trust/deploying_notary/) for instructions. > [!NOTE] > diff --git a/content/manuals/engine/security/trust/trust_delegation.md b/content/manuals/engine/security/trust/trust_delegation.md index 78f5e732d7..7476162ca9 100644 --- a/content/manuals/engine/security/trust/trust_delegation.md +++ b/content/manuals/engine/security/trust/trust_delegation.md @@ -96,8 +96,7 @@ configure the Notary CLI: The newly created configuration file contains information about the location of your local Docker trust data and the notary server URL. For more detailed information about how to use notary outside of the -Docker Content Trust use cases, refer to the Notary CLI documentation -[here](https://github.com/theupdateframework/notary/blob/master/docs/command_reference.md) +Docker Content Trust use cases, refer to the [Notary CLI documentation](https://github.com/theupdateframework/notary/blob/master/docs/command_reference.md) ## Creating delegation keys @@ -189,8 +188,8 @@ jeff 9deed251daa1aa6f9d5f9b752847647cf8d705da When the first delegation is added to the Notary Server using `$ docker trust`, we automatically initiate trust data for the repository. This includes creating the notary target and snapshots keys, and rotating the snapshot key to be -managed by the notary server. More information on these keys can be found -[here](trust_key_mng.md) +managed by the notary server. More information on these keys can be found in +[Manage keys for content trust](trust_key_mng.md). When initiating a repository, you will need the key and the passphrase of a local Notary Canonical Root Key. If you have not initiated a repository before, and @@ -374,8 +373,8 @@ Successfully removed ben from registry.example.com/admin/demo $ notary witness registry.example.com/admin/demo targets/releases --publish ``` - More information on the `$ notary witness` command can be found - [here](https://github.com/theupdateframework/notary/blob/master/docs/advanced_usage.md#recovering-a-delegation) + For more information on the `notary witness` command, refer to the + [Notary client advanced usage guide](https://github.com/theupdateframework/notary/blob/master/docs/advanced_usage.md#recovering-a-delegation) ### Removing a contributor's key from a delegation diff --git a/content/manuals/extensions/extensions-sdk/dev/api/overview.md b/content/manuals/extensions/extensions-sdk/dev/api/overview.md index fe129ddb4a..abcda23e85 100644 --- a/content/manuals/extensions/extensions-sdk/dev/api/overview.md +++ b/content/manuals/extensions/extensions-sdk/dev/api/overview.md @@ -34,4 +34,4 @@ The `ddClient` object gives access to various APIs: - [Dashboard](dashboard.md) - [Navigation](dashboard-routes-navigation.md) -Find the Extensions API reference [here](reference/api/extensions-sdk/_index.md). +See also the [Extensions API reference](reference/api/extensions-sdk/_index.md). diff --git a/content/manuals/subscription/desktop-license.md b/content/manuals/subscription/desktop-license.md index f1271ad44f..58ecc6d6a8 100644 --- a/content/manuals/subscription/desktop-license.md +++ b/content/manuals/subscription/desktop-license.md @@ -37,4 +37,4 @@ Docker Desktop is built using open-source software. For information about the li ## Open source components Docker Desktop distributes some components that are licensed under the -GNU General Public License. Select [here](https://download.docker.com/opensource/License.tar.gz) to download the source for these components. +GNU General Public License. [Download the source code for these components here](https://download.docker.com/opensource/License.tar.gz). diff --git a/content/reference/compose-file/build.md b/content/reference/compose-file/build.md index e2d9b1ca90..f9656bf5fa 100644 --- a/content/reference/compose-file/build.md +++ b/content/reference/compose-file/build.md @@ -115,8 +115,8 @@ must be prefixed to avoid ambiguity with a `type://` prefix. Compose warns you if the image builder does not support additional contexts and may list the unused contexts. -Illustrative examples of how this is used in Buildx can be found -[here](https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#-additional-build-contexts---build-context). +Refer to the reference documentation for [`docker buildx build --build-context`](https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#-additional-build-contexts---build-context) +for example usage. `additional_contexts` can also refer to an image built by another service. This allows a service image to be built using another service image as a base image, and to share diff --git a/content/reference/compose-file/services.md b/content/reference/compose-file/services.md index 2e2d319af8..fcbd1c5acc 100644 --- a/content/reference/compose-file/services.md +++ b/content/reference/compose-file/services.md @@ -1799,7 +1799,7 @@ runs with environment variables `DATABASE_URL` and `DATABASE_API_KEY`. As Compose stops the application, the `awesomecloud` binary is used to manage the `database` service tear down. -The mechanism used by Compose to delegate the service lifecycle to an external binary is described [here](https://github.com/docker/compose/tree/main/docs/extension.md). +The mechanism used by Compose to delegate the service lifecycle to an external binary is described in the [Compose extensibility documentation](https://github.com/docker/compose/tree/main/docs/extension.md). For more information on using the `provider` attribute, see [Use provider services](/manuals/compose/how-tos/provider-services.md).