Merge pull request #5350 from dvdksn/docs-alerts-syntax

docs: use gh alert syntax for callouts

Author: dvdksn

docs/deprecated.md

@@ -562,8 +562,7 @@ Docker API v1.42 and up now ignores this option when set. Older versions of the
 API continue to accept the option, but depending on the OCI runtime used, may
 take no effect.
 
-> **Note**
-> 
+> [!NOTE]
 > While not deprecated (yet) in Docker, the OCI runtime specification also
 > deprecated the `memory.kmem.tcp.limit_in_bytes` option. When using `runc` as
 > runtime, this option takes no effect. The linux kernel did not explicitly

docs/extend/index.md

@@ -16,8 +16,7 @@ plugins using Docker Engine.
 For information about legacy (non-managed) plugins, refer to
 [Understand legacy Docker Engine plugins](legacy_plugins.md).
 
-> **Note**
->
+> [!NOTE]
 > Docker Engine managed plugins are currently not supported on Windows daemons.
 
 ## Installing and using a plugin
@@ -38,8 +37,7 @@ operation, such as creating a volume.
 In the following example, you install the `sshfs` plugin, verify that it is
 enabled, and use it to create a volume.
 
-> **Note**
->
+> [!NOTE]
 > This example is intended for instructional purposes only. Once the volume is
 > created, your SSH password to the remote host is exposed as plaintext when
 > inspecting the volume. Delete the volume as soon as you are done with the
@@ -126,8 +124,7 @@ commands and options, see the
 The `rootfs` directory represents the root filesystem of the plugin. In this
 example, it was created from a Dockerfile:
 
-> **Note**
->
+> [!NOTE]
 > The `/run/docker/plugins` directory is mandatory inside of the
 > plugin's filesystem for Docker to communicate with the plugin.
 

docs/extend/plugins_authorization.md

@@ -43,8 +43,7 @@ Authorization plugins must follow the rules described in [Docker Plugin API](plu
 Each plugin must reside within directories described under the
 [Plugin discovery](plugin_api.md#plugin-discovery) section.
 
-> **Note**
->
+> [!NOTE]
 > The abbreviations `AuthZ` and `AuthN` mean authorization and authentication
 > respectively.
 

docs/extend/plugins_metrics.md

@@ -8,8 +8,7 @@ Docker exposes internal metrics based on the Prometheus format. Metrics plugins
 enable accessing these metrics in a consistent way by providing a Unix
 socket at a predefined path where the plugin can scrape the metrics.
 
-> **Note**
->
+> [!NOTE]
 > While the plugin interface for metrics is non-experimental, the naming of the
 > metrics and metric labels is still considered experimental and may change in a
 > future version.

docs/extend/plugins_volume.md

@@ -80,8 +80,7 @@ provide the Docker Daemon with writeable paths on the host filesystem. The Docke
 daemon provides these paths to containers to consume. The Docker daemon makes
 the volumes available by bind-mounting the provided paths into the containers.
 
-> **Note**
->
+> [!NOTE]
 > Volume plugins should *not* write data to the `/var/lib/docker/` directory,
 > including `/var/lib/docker/volumes`. The `/var/lib/docker/` directory is
 > reserved for Docker.

docs/reference/commandline/config_create.md

@@ -19,8 +19,7 @@ Creates a config using standard input or from a file for the config content.
 
 For detailed information about using configs, refer to [store configuration data using Docker Configs](https://docs.docker.com/engine/swarm/configs/).
 
-> **Note**
->
+> [!NOTE]
 > This is a cluster management command, and must be executed on a Swarm
 > manager node. To learn about managers and workers, refer to the
 > [Swarm mode section](https://docs.docker.com/engine/swarm/) in the

docs/reference/commandline/config_inspect.md

@@ -25,8 +25,7 @@ describes all the details of the format.
 
 For detailed information about using configs, refer to [store configuration data using Docker Configs](https://docs.docker.com/engine/swarm/configs/).
 
-> **Note**
->
+> [!NOTE]
 > This is a cluster management command, and must be executed on a Swarm
 > manager node. To learn about managers and workers, refer to the
 > [Swarm mode section](https://docs.docker.com/engine/swarm/) in the

docs/reference/commandline/config_ls.md

@@ -24,8 +24,7 @@ Run this command on a manager node to list the configs in the Swarm.
 
 For detailed information about using configs, refer to [store configuration data using Docker Configs](https://docs.docker.com/engine/swarm/configs/).
 
-> **Note**
->
+> [!NOTE]
 > This is a cluster management command, and must be executed on a Swarm
 > manager node. To learn about managers and workers, refer to the
 > [Swarm mode section](https://docs.docker.com/engine/swarm/) in the

docs/reference/commandline/config_rm.md

@@ -16,8 +16,7 @@ Removes the specified configs from the Swarm.
 
 For detailed information about using configs, refer to [store configuration data using Docker Configs](https://docs.docker.com/engine/swarm/configs/).
 
-> **Note**
->
+> [!NOTE]
 > This is a cluster management command, and must be executed on a Swarm
 > manager node. To learn about managers and workers, refer to the
 > [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
@@ -32,8 +31,7 @@ $ docker config rm my_config
 sapth4csdo5b6wz2p5uimh5xg
 ```
 
-> **Warning**
->
+> [!WARNING]
 > This command doesn't ask for confirmation before removing a config.
 { .warning }
 

docs/reference/commandline/container_attach.md

@@ -25,8 +25,7 @@ Use `docker attach` to attach your terminal's standard input, output, and error
 ID or name. This lets you view its output or control it interactively, as
 though the commands were running directly in your terminal.
 
-> **Note**
->
+> [!NOTE]
 > The `attach` command displays the output of the container's `ENTRYPOINT` and
 > `CMD` process. This can appear as if the attach command is hung when in fact
 > the process may simply not be writing any output at that time.
@@ -39,8 +38,7 @@ container. If `--sig-proxy` is true (the default),`CTRL-c` sends a `SIGINT` to
 the container. If the container was run with `-i` and `-t`, you can detach from
 a container and leave it running using the `CTRL-p CTRL-q` key sequence.
 
-> **Note**
->
+> [!NOTE]
 > A process running as PID 1 inside a container is treated specially by
 > Linux: it ignores any signal with the default action. So, the process
 > doesn't terminate on `SIGINT` or `SIGTERM` unless it's coded to do so.