diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose.md index 26a216e0218d..5a69a01b508f 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/compose.md +++ b/_vendor/github.com/docker/compose/v2/docs/reference/compose.md @@ -1,150 +1,11 @@ # docker compose - -You can use the compose subcommand, `docker compose [-f ...] [options] [COMMAND] [ARGS...]`, to build and manage -multiple services in Docker containers. - -### Use `-f` to specify the name and path of one or more Compose files -Use the `-f` flag to specify the location of a Compose configuration file. - -#### Specifying multiple Compose files -You can supply multiple `-f` configuration files. When you supply multiple files, Compose combines them into a single -configuration. Compose builds the configuration in the order you supply the files. Subsequent files override and add -to their predecessors. - -For example, consider this command line: - -```console -$ docker compose -f docker-compose.yml -f docker-compose.admin.yml run backup_db -``` - -The `docker-compose.yml` file might specify a `webapp` service. - -```yaml -services: - webapp: - image: examples/web - ports: - - "8000:8000" - volumes: - - "/data" -``` -If the `docker-compose.admin.yml` also specifies this same service, any matching fields override the previous file. -New values, add to the `webapp` service configuration. - -```yaml -services: - webapp: - build: . - environment: - - DEBUG=1 +```text +docker compose [-f ...] [options] [COMMAND] [ARGS...] ``` -When you use multiple Compose files, all paths in the files are relative to the first configuration file specified -with `-f`. You can use the `--project-directory` option to override this base path. - -Use a `-f` with `-` (dash) as the filename to read the configuration from stdin. When stdin is used all paths in the -configuration are relative to the current working directory. - -The `-f` flag is optional. If you don’t provide this flag on the command line, Compose traverses the working directory -and its parent directories looking for a `compose.yaml` or `docker-compose.yaml` file. - -#### Specifying a path to a single Compose file -You can use the `-f` flag to specify a path to a Compose file that is not located in the current directory, either -from the command line or by setting up a `COMPOSE_FILE` environment variable in your shell or in an environment file. - -For an example of using the `-f` option at the command line, suppose you are running the Compose Rails sample, and -have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like `docker compose pull` to -get the postgres image for the db service from anywhere by using the `-f` flag as follows: - -```console -$ docker compose -f ~/sandbox/rails/compose.yaml pull db -``` - -### Use `-p` to specify a project name - -Each configuration has a project name. Compose sets the project name using -the following mechanisms, in order of precedence: -- The `-p` command line flag -- The `COMPOSE_PROJECT_NAME` environment variable -- The top level `name:` variable from the config file (or the last `name:` -from a series of config files specified using `-f`) -- The `basename` of the project directory containing the config file (or -containing the first config file specified using `-f`) -- The `basename` of the current directory if no config file is specified -Project names must contain only lowercase letters, decimal digits, dashes, -and underscores, and must begin with a lowercase letter or decimal digit. If -the `basename` of the project directory or current directory violates this -constraint, you must use one of the other mechanisms. - -```console -$ docker compose -p my_project ps -a -NAME SERVICE STATUS PORTS -my_project_demo_1 demo running - -$ docker compose -p my_project logs -demo_1 | PING localhost (127.0.0.1): 56 data bytes -demo_1 | 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.095 ms -``` - -### Use profiles to enable optional services - -Use `--profile` to specify one or more active profiles -Calling `docker compose --profile frontend up` starts the services with the profile `frontend` and services -without any specified profiles. -You can also enable multiple profiles, e.g. with `docker compose --profile frontend --profile debug up` the profiles `frontend` and `debug` is enabled. - -Profiles can also be set by `COMPOSE_PROFILES` environment variable. - -### Configuring parallelism - -Use `--parallel` to specify the maximum level of parallelism for concurrent engine calls. -Calling `docker compose --parallel 1 pull` pulls the pullable images defined in the Compose file -one at a time. This can also be used to control build concurrency. - -Parallelism can also be set by the `COMPOSE_PARALLEL_LIMIT` environment variable. - -### Set up environment variables - -You can set environment variables for various docker compose options, including the `-f`, `-p` and `--profiles` flags. - -Setting the `COMPOSE_FILE` environment variable is equivalent to passing the `-f` flag, -`COMPOSE_PROJECT_NAME` environment variable does the same as the `-p` flag, -`COMPOSE_PROFILES` environment variable is equivalent to the `--profiles` flag -and `COMPOSE_PARALLEL_LIMIT` does the same as the `--parallel` flag. - -If flags are explicitly set on the command line, the associated environment variable is ignored. - -Setting the `COMPOSE_IGNORE_ORPHANS` environment variable to `true` stops docker compose from detecting orphaned -containers for the project. - -Setting the `COMPOSE_MENU` environment variable to `false` disables the helper menu when running `docker compose up` -in attached mode. Alternatively, you can also run `docker compose up --menu=false` to disable the helper menu. - -### Use Dry Run mode to test your command - -Use `--dry-run` flag to test a command without changing your application stack state. -Dry Run mode shows you all the steps Compose applies when executing a command, for example: -```console -$ docker compose --dry-run up --build -d -[+] Pulling 1/1 - ✔ DRY-RUN MODE - db Pulled 0.9s -[+] Running 10/8 - ✔ DRY-RUN MODE - build service backend 0.0s - ✔ DRY-RUN MODE - ==> ==> writing image dryRun-754a08ddf8bcb1cf22f310f09206dd783d42f7dd 0.0s - ✔ DRY-RUN MODE - ==> ==> naming to nginx-golang-mysql-backend 0.0s - ✔ DRY-RUN MODE - Network nginx-golang-mysql_default Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-db-1 Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-backend-1 Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-proxy-1 Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-db-1 Healthy 0.5s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-backend-1 Started 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-proxy-1 Started Started -``` -From the example above, you can see that the first step is to pull the image defined by `db` service, then build the `backend` service. -Next, the containers are created. The `db` service is started, and the `backend` and `proxy` wait until the `db` service is healthy before starting. - -Dry Run mode works with almost all commands. You cannot use Dry Run mode with a command that doesn't change the state of a Compose stack such as `ps`, `ls`, `logs` for example. + +Define and run multi-container applications with Docker ### Subcommands @@ -158,6 +19,7 @@ Dry Run mode works with almost all commands. You cannot use Dry Run mode with a | [`down`](compose_down.md) | Stop and remove containers, networks | | [`events`](compose_events.md) | Receive real time events from containers | | [`exec`](compose_exec.md) | Execute a command in a running container | +| [`export`](compose_export.md) | Export a service container's filesystem as a tar archive | | [`images`](compose_images.md) | List images used by the created containers | | [`kill`](compose_kill.md) | Force stop service containers | | [`logs`](compose_logs.md) | View output from containers | @@ -178,7 +40,7 @@ Dry Run mode works with almost all commands. You cannot use Dry Run mode with a | [`unpause`](compose_unpause.md) | Unpause services | | [`up`](compose_up.md) | Create and start containers | | [`version`](compose_version.md) | Show the Docker Compose version information | -| [`wait`](compose_wait.md) | Block until the first service container stops | +| [`wait`](compose_wait.md) | Block until containers of all (or specified) services stop. | | [`watch`](compose_watch.md) | Watch build context for service and rebuild/refresh containers when files are updated | @@ -201,10 +63,7 @@ Dry Run mode works with almost all commands. You cannot use Dry Run mode with a -## Description - -You can use the compose subcommand, `docker compose [-f ...] [options] [COMMAND] [ARGS...]`, to build and manage -multiple services in Docker containers. +## Examples ### Use `-f` to specify the name and path of one or more Compose files Use the `-f` flag to specify the location of a Compose configuration file. diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_generate.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_generate.md new file mode 100644 index 000000000000..f4054627798c --- /dev/null +++ b/_vendor/github.com/docker/compose/v2/docs/reference/compose_alpha_generate.md @@ -0,0 +1,17 @@ +# docker compose alpha generate + + +EXPERIMENTAL - Generate a Compose file from existing containers + +### Options + +| Name | Type | Default | Description | +|:----------------|:---------|:--------|:------------------------------------------| +| `--dry-run` | `bool` | | Execute command in dry run mode | +| `--format` | `string` | `yaml` | Format the output. Values: [yaml \| json] | +| `--name` | `string` | | Project name to set in the Compose file | +| `--project-dir` | `string` | | Directory to use for the project | + + + + diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_cp.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_cp.md index 9ed14140eab0..0886bbd9f941 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_cp.md +++ b/_vendor/github.com/docker/compose/v2/docs/reference/compose_cp.md @@ -7,6 +7,7 @@ Copy files/folders between a service container and the local filesystem | Name | Type | Default | Description | |:----------------------|:-------|:--------|:--------------------------------------------------------| +| `--all` | `bool` | | Include containers created by the run command | | `-a`, `--archive` | `bool` | | Archive mode (copy all uid/gid information) | | `--dry-run` | `bool` | | Execute command in dry run mode | | `-L`, `--follow-link` | `bool` | | Always follow symbol link in SRC_PATH | diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_export.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_export.md new file mode 100644 index 000000000000..942ea6a347f3 --- /dev/null +++ b/_vendor/github.com/docker/compose/v2/docs/reference/compose_export.md @@ -0,0 +1,16 @@ +# docker compose export + + +Export a service container's filesystem as a tar archive + +### Options + +| Name | Type | Default | Description | +|:-----------------|:---------|:--------|:---------------------------------------------------------| +| `--dry-run` | `bool` | | Execute command in dry run mode | +| `--index` | `int` | `0` | index of the container if service has multiple replicas. | +| `-o`, `--output` | `string` | | Write to a file, instead of STDOUT | + + + + diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/compose_wait.md b/_vendor/github.com/docker/compose/v2/docs/reference/compose_wait.md index cc62d5967b8a..59474c9b5090 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/compose_wait.md +++ b/_vendor/github.com/docker/compose/v2/docs/reference/compose_wait.md @@ -1,7 +1,7 @@ # docker compose wait -Block until the first service container stops +Block until containers of all (or specified) services stop. ### Options diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml index 82c7cd184476..f59ec4a04b2c 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose.yaml @@ -1,150 +1,6 @@ command: docker compose short: Docker Compose -long: |- - You can use the compose subcommand, `docker compose [-f ...] [options] [COMMAND] [ARGS...]`, to build and manage - multiple services in Docker containers. - - ### Use `-f` to specify the name and path of one or more Compose files - Use the `-f` flag to specify the location of a Compose configuration file. - - #### Specifying multiple Compose files - You can supply multiple `-f` configuration files. When you supply multiple files, Compose combines them into a single - configuration. Compose builds the configuration in the order you supply the files. Subsequent files override and add - to their predecessors. - - For example, consider this command line: - - ```console - $ docker compose -f docker-compose.yml -f docker-compose.admin.yml run backup_db - ``` - - The `docker-compose.yml` file might specify a `webapp` service. - - ```yaml - services: - webapp: - image: examples/web - ports: - - "8000:8000" - volumes: - - "/data" - ``` - If the `docker-compose.admin.yml` also specifies this same service, any matching fields override the previous file. - New values, add to the `webapp` service configuration. - - ```yaml - services: - webapp: - build: . - environment: - - DEBUG=1 - ``` - - When you use multiple Compose files, all paths in the files are relative to the first configuration file specified - with `-f`. You can use the `--project-directory` option to override this base path. - - Use a `-f` with `-` (dash) as the filename to read the configuration from stdin. When stdin is used all paths in the - configuration are relative to the current working directory. - - The `-f` flag is optional. If you don’t provide this flag on the command line, Compose traverses the working directory - and its parent directories looking for a `compose.yaml` or `docker-compose.yaml` file. - - #### Specifying a path to a single Compose file - You can use the `-f` flag to specify a path to a Compose file that is not located in the current directory, either - from the command line or by setting up a `COMPOSE_FILE` environment variable in your shell or in an environment file. - - For an example of using the `-f` option at the command line, suppose you are running the Compose Rails sample, and - have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like `docker compose pull` to - get the postgres image for the db service from anywhere by using the `-f` flag as follows: - - ```console - $ docker compose -f ~/sandbox/rails/compose.yaml pull db - ``` - - ### Use `-p` to specify a project name - - Each configuration has a project name. Compose sets the project name using - the following mechanisms, in order of precedence: - - The `-p` command line flag - - The `COMPOSE_PROJECT_NAME` environment variable - - The top level `name:` variable from the config file (or the last `name:` - from a series of config files specified using `-f`) - - The `basename` of the project directory containing the config file (or - containing the first config file specified using `-f`) - - The `basename` of the current directory if no config file is specified - Project names must contain only lowercase letters, decimal digits, dashes, - and underscores, and must begin with a lowercase letter or decimal digit. If - the `basename` of the project directory or current directory violates this - constraint, you must use one of the other mechanisms. - - ```console - $ docker compose -p my_project ps -a - NAME SERVICE STATUS PORTS - my_project_demo_1 demo running - - $ docker compose -p my_project logs - demo_1 | PING localhost (127.0.0.1): 56 data bytes - demo_1 | 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.095 ms - ``` - - ### Use profiles to enable optional services - - Use `--profile` to specify one or more active profiles - Calling `docker compose --profile frontend up` starts the services with the profile `frontend` and services - without any specified profiles. - You can also enable multiple profiles, e.g. with `docker compose --profile frontend --profile debug up` the profiles `frontend` and `debug` is enabled. - - Profiles can also be set by `COMPOSE_PROFILES` environment variable. - - ### Configuring parallelism - - Use `--parallel` to specify the maximum level of parallelism for concurrent engine calls. - Calling `docker compose --parallel 1 pull` pulls the pullable images defined in the Compose file - one at a time. This can also be used to control build concurrency. - - Parallelism can also be set by the `COMPOSE_PARALLEL_LIMIT` environment variable. - - ### Set up environment variables - - You can set environment variables for various docker compose options, including the `-f`, `-p` and `--profiles` flags. - - Setting the `COMPOSE_FILE` environment variable is equivalent to passing the `-f` flag, - `COMPOSE_PROJECT_NAME` environment variable does the same as the `-p` flag, - `COMPOSE_PROFILES` environment variable is equivalent to the `--profiles` flag - and `COMPOSE_PARALLEL_LIMIT` does the same as the `--parallel` flag. - - If flags are explicitly set on the command line, the associated environment variable is ignored. - - Setting the `COMPOSE_IGNORE_ORPHANS` environment variable to `true` stops docker compose from detecting orphaned - containers for the project. - - Setting the `COMPOSE_MENU` environment variable to `false` disables the helper menu when running `docker compose up` - in attached mode. Alternatively, you can also run `docker compose up --menu=false` to disable the helper menu. - - ### Use Dry Run mode to test your command - - Use `--dry-run` flag to test a command without changing your application stack state. - Dry Run mode shows you all the steps Compose applies when executing a command, for example: - ```console - $ docker compose --dry-run up --build -d - [+] Pulling 1/1 - ✔ DRY-RUN MODE - db Pulled 0.9s - [+] Running 10/8 - ✔ DRY-RUN MODE - build service backend 0.0s - ✔ DRY-RUN MODE - ==> ==> writing image dryRun-754a08ddf8bcb1cf22f310f09206dd783d42f7dd 0.0s - ✔ DRY-RUN MODE - ==> ==> naming to nginx-golang-mysql-backend 0.0s - ✔ DRY-RUN MODE - Network nginx-golang-mysql_default Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-db-1 Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-backend-1 Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-proxy-1 Created 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-db-1 Healthy 0.5s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-backend-1 Started 0.0s - ✔ DRY-RUN MODE - Container nginx-golang-mysql-proxy-1 Started Started - ``` - From the example above, you can see that the first step is to pull the image defined by `db` service, then build the `backend` service. - Next, the containers are created. The `db` service is started, and the `backend` and `proxy` wait until the `db` service is healthy before starting. - - Dry Run mode works with almost all commands. You cannot use Dry Run mode with a command that doesn't change the state of a Compose stack such as `ps`, `ls`, `logs` for example. +long: Define and run multi-container applications with Docker usage: docker compose pname: docker plink: docker.yaml @@ -157,6 +13,7 @@ cname: - docker compose down - docker compose events - docker compose exec + - docker compose export - docker compose images - docker compose kill - docker compose logs @@ -188,6 +45,7 @@ clink: - docker_compose_down.yaml - docker_compose_events.yaml - docker_compose_exec.yaml + - docker_compose_export.yaml - docker_compose_images.yaml - docker_compose_kill.yaml - docker_compose_logs.yaml @@ -367,6 +225,148 @@ options: experimentalcli: false kubernetes: false swarm: false +examples: |- + ### Use `-f` to specify the name and path of one or more Compose files + Use the `-f` flag to specify the location of a Compose configuration file. + + #### Specifying multiple Compose files + You can supply multiple `-f` configuration files. When you supply multiple files, Compose combines them into a single + configuration. Compose builds the configuration in the order you supply the files. Subsequent files override and add + to their predecessors. + + For example, consider this command line: + + ```console + $ docker compose -f docker-compose.yml -f docker-compose.admin.yml run backup_db + ``` + + The `docker-compose.yml` file might specify a `webapp` service. + + ```yaml + services: + webapp: + image: examples/web + ports: + - "8000:8000" + volumes: + - "/data" + ``` + If the `docker-compose.admin.yml` also specifies this same service, any matching fields override the previous file. + New values, add to the `webapp` service configuration. + + ```yaml + services: + webapp: + build: . + environment: + - DEBUG=1 + ``` + + When you use multiple Compose files, all paths in the files are relative to the first configuration file specified + with `-f`. You can use the `--project-directory` option to override this base path. + + Use a `-f` with `-` (dash) as the filename to read the configuration from stdin. When stdin is used all paths in the + configuration are relative to the current working directory. + + The `-f` flag is optional. If you don’t provide this flag on the command line, Compose traverses the working directory + and its parent directories looking for a `compose.yaml` or `docker-compose.yaml` file. + + #### Specifying a path to a single Compose file + You can use the `-f` flag to specify a path to a Compose file that is not located in the current directory, either + from the command line or by setting up a `COMPOSE_FILE` environment variable in your shell or in an environment file. + + For an example of using the `-f` option at the command line, suppose you are running the Compose Rails sample, and + have a `compose.yaml` file in a directory called `sandbox/rails`. You can use a command like `docker compose pull` to + get the postgres image for the db service from anywhere by using the `-f` flag as follows: + + ```console + $ docker compose -f ~/sandbox/rails/compose.yaml pull db + ``` + + ### Use `-p` to specify a project name + + Each configuration has a project name. Compose sets the project name using + the following mechanisms, in order of precedence: + - The `-p` command line flag + - The `COMPOSE_PROJECT_NAME` environment variable + - The top level `name:` variable from the config file (or the last `name:` + from a series of config files specified using `-f`) + - The `basename` of the project directory containing the config file (or + containing the first config file specified using `-f`) + - The `basename` of the current directory if no config file is specified + Project names must contain only lowercase letters, decimal digits, dashes, + and underscores, and must begin with a lowercase letter or decimal digit. If + the `basename` of the project directory or current directory violates this + constraint, you must use one of the other mechanisms. + + ```console + $ docker compose -p my_project ps -a + NAME SERVICE STATUS PORTS + my_project_demo_1 demo running + + $ docker compose -p my_project logs + demo_1 | PING localhost (127.0.0.1): 56 data bytes + demo_1 | 64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.095 ms + ``` + + ### Use profiles to enable optional services + + Use `--profile` to specify one or more active profiles + Calling `docker compose --profile frontend up` starts the services with the profile `frontend` and services + without any specified profiles. + You can also enable multiple profiles, e.g. with `docker compose --profile frontend --profile debug up` the profiles `frontend` and `debug` is enabled. + + Profiles can also be set by `COMPOSE_PROFILES` environment variable. + + ### Configuring parallelism + + Use `--parallel` to specify the maximum level of parallelism for concurrent engine calls. + Calling `docker compose --parallel 1 pull` pulls the pullable images defined in the Compose file + one at a time. This can also be used to control build concurrency. + + Parallelism can also be set by the `COMPOSE_PARALLEL_LIMIT` environment variable. + + ### Set up environment variables + + You can set environment variables for various docker compose options, including the `-f`, `-p` and `--profiles` flags. + + Setting the `COMPOSE_FILE` environment variable is equivalent to passing the `-f` flag, + `COMPOSE_PROJECT_NAME` environment variable does the same as the `-p` flag, + `COMPOSE_PROFILES` environment variable is equivalent to the `--profiles` flag + and `COMPOSE_PARALLEL_LIMIT` does the same as the `--parallel` flag. + + If flags are explicitly set on the command line, the associated environment variable is ignored. + + Setting the `COMPOSE_IGNORE_ORPHANS` environment variable to `true` stops docker compose from detecting orphaned + containers for the project. + + Setting the `COMPOSE_MENU` environment variable to `false` disables the helper menu when running `docker compose up` + in attached mode. Alternatively, you can also run `docker compose up --menu=false` to disable the helper menu. + + ### Use Dry Run mode to test your command + + Use `--dry-run` flag to test a command without changing your application stack state. + Dry Run mode shows you all the steps Compose applies when executing a command, for example: + ```console + $ docker compose --dry-run up --build -d + [+] Pulling 1/1 + ✔ DRY-RUN MODE - db Pulled 0.9s + [+] Running 10/8 + ✔ DRY-RUN MODE - build service backend 0.0s + ✔ DRY-RUN MODE - ==> ==> writing image dryRun-754a08ddf8bcb1cf22f310f09206dd783d42f7dd 0.0s + ✔ DRY-RUN MODE - ==> ==> naming to nginx-golang-mysql-backend 0.0s + ✔ DRY-RUN MODE - Network nginx-golang-mysql_default Created 0.0s + ✔ DRY-RUN MODE - Container nginx-golang-mysql-db-1 Created 0.0s + ✔ DRY-RUN MODE - Container nginx-golang-mysql-backend-1 Created 0.0s + ✔ DRY-RUN MODE - Container nginx-golang-mysql-proxy-1 Created 0.0s + ✔ DRY-RUN MODE - Container nginx-golang-mysql-db-1 Healthy 0.5s + ✔ DRY-RUN MODE - Container nginx-golang-mysql-backend-1 Started 0.0s + ✔ DRY-RUN MODE - Container nginx-golang-mysql-proxy-1 Started Started + ``` + From the example above, you can see that the first step is to pull the image defined by `db` service, then build the `backend` service. + Next, the containers are created. The `db` service is started, and the `backend` and `proxy` wait until the `db` service is healthy before starting. + + Dry Run mode works with almost all commands. You cannot use Dry Run mode with a command that doesn't change the state of a Compose stack such as `ps`, `ls`, `logs` for example. deprecated: false hidden: false experimental: false diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha.yaml index 807097a387e6..e6b6b6e6b6f7 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha.yaml +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha.yaml @@ -4,9 +4,11 @@ long: Experimental commands pname: docker compose plink: docker_compose.yaml cname: + - docker compose alpha generate - docker compose alpha publish - docker compose alpha viz clink: + - docker_compose_alpha_generate.yaml - docker_compose_alpha_publish.yaml - docker_compose_alpha_viz.yaml inherited_options: diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_generate.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_generate.yaml new file mode 100644 index 000000000000..0932af080ecc --- /dev/null +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_generate.yaml @@ -0,0 +1,53 @@ +command: docker compose alpha generate +short: EXPERIMENTAL - Generate a Compose file from existing containers +long: EXPERIMENTAL - Generate a Compose file from existing containers +usage: docker compose alpha generate [OPTIONS] [CONTAINERS...] +pname: docker compose alpha +plink: docker_compose_alpha.yaml +options: + - option: format + value_type: string + default_value: yaml + description: 'Format the output. Values: [yaml | json]' + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false + - option: name + value_type: string + description: Project name to set in the Compose file + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false + - option: project-dir + value_type: string + description: Directory to use for the project + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false +inherited_options: + - option: dry-run + value_type: bool + default_value: "false" + description: Execute command in dry run mode + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false +deprecated: false +hidden: false +experimental: false +experimentalcli: true +kubernetes: false +swarm: false + diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml index 38868104a5f4..7a2da5ca92da 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_alpha_publish.yaml @@ -1,7 +1,7 @@ command: docker compose alpha publish short: Publish compose application long: Publish compose application -usage: docker compose alpha publish [OPTIONS] [REPOSITORY] +usage: docker compose alpha publish [OPTIONS] REPOSITORY[:TAG] pname: docker compose alpha plink: docker_compose_alpha.yaml options: diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_cp.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_cp.yaml index 8ff3cf37e034..24f6aec87f94 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_cp.yaml +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_cp.yaml @@ -10,9 +10,9 @@ options: - option: all value_type: bool default_value: "false" - description: Copy to all the containers of the service - deprecated: true - hidden: true + description: Include containers created by the run command + deprecated: false + hidden: false experimental: false experimentalcli: false kubernetes: false diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_export.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_export.yaml new file mode 100644 index 000000000000..5dfb3be0a47b --- /dev/null +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_export.yaml @@ -0,0 +1,45 @@ +command: docker compose export +short: Export a service container's filesystem as a tar archive +long: Export a service container's filesystem as a tar archive +usage: docker compose export [OPTIONS] SERVICE +pname: docker compose +plink: docker_compose.yaml +options: + - option: index + value_type: int + default_value: "0" + description: index of the container if service has multiple replicas. + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false + - option: output + shorthand: o + value_type: string + description: Write to a file, instead of STDOUT + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false +inherited_options: + - option: dry-run + value_type: bool + default_value: "false" + description: Execute command in dry run mode + deprecated: false + hidden: false + experimental: false + experimentalcli: false + kubernetes: false + swarm: false +deprecated: false +hidden: false +experimental: false +experimentalcli: false +kubernetes: false +swarm: false + diff --git a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_wait.yaml b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_wait.yaml index 87f69059ce15..5d8f3013cc01 100644 --- a/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_wait.yaml +++ b/_vendor/github.com/docker/compose/v2/docs/reference/docker_compose_wait.yaml @@ -1,6 +1,6 @@ command: docker compose wait -short: Block until the first service container stops -long: Block until the first service container stops +short: Block until containers of all (or specified) services stop. +long: Block until containers of all (or specified) services stop. usage: docker compose wait SERVICE [SERVICE...] [OPTIONS] pname: docker compose plink: docker_compose.yaml diff --git a/_vendor/modules.txt b/_vendor/modules.txt index ef5eccf8c37b..49cad9b66715 100644 --- a/_vendor/modules.txt +++ b/_vendor/modules.txt @@ -1,6 +1,6 @@ # github.com/moby/moby v27.3.1+incompatible # github.com/moby/buildkit v0.16.0 # github.com/docker/buildx v0.17.1 -# github.com/docker/cli v27.3.1+incompatible -# github.com/docker/compose/v2 v2.29.6 +# github.com/docker/cli v27.3.2-0.20241008150905-cb3048fbebb1+incompatible +# github.com/docker/compose/v2 v2.30.0 # github.com/docker/scout-cli v1.13.0 diff --git a/content/manuals/compose/how-tos/lifecycle.md b/content/manuals/compose/how-tos/lifecycle.md new file mode 100644 index 000000000000..aa332877e9e3 --- /dev/null +++ b/content/manuals/compose/how-tos/lifecycle.md @@ -0,0 +1,65 @@ +--- +title: Using lifecycle hooks with Compose +linkTitle: Use lifecycle hooks +weight: 20 +desription: How to use lifecycle hooks with Docker Compose +keywords: cli, compose, lifecycle, hooks reference +--- + +## Services lifecycle hooks + +When Docker Compose runs a container, it uses two elements, +[ENTRYPOINT and COMMAND](https://github.com/manuals//engine/containers/run.md#default-command-and-options), +to manage what happens when the container starts and stops. + +However, it can sometimes be easier to handle these tasks separately with lifecycle hooks - +commands that run right after the container starts or just before it stops. + +Lifecycle hooks are particularly useful because they can have special privileges +(like running as the root user), even when the container itself runs with lower privileges +for security. This means that certain tasks requiring higher permissions can be done without +compromising the overall security of the container. + +### Post-start hooks + +Post-start hooks are commands that run after the container has started, but there's no +set time for when exactly they will execute. The hook execution timing is not assured during +the execution of the container's `entrypoint`. + +In the example provided: + +- The hook is used to change the ownership of a volume to a non-root user (because volumes +are created with root ownership by default). +- After the container starts, the `chown` command changes the ownership of the `/data` directory to user `1001`. + +```yaml +services: + app: + image: backend + user: 1001 + volumes: + - data:/data + post_start: + - command: chown -R /data 1001:1001 + user: root + +volumes: + data: {} # a Docker volume is created with root ownership +``` + +### Pre-stop hooks + +Pre-stop hooks are commands that run before the container is stopped by a specific +command (like `docker compose down` or stopping it manually with `Ctrl+C`). +These hooks won't run if the container stops by itself or gets killed suddenly. + +In the following example, before the container stops, the `./data_flush.sh` script is +run to perform any necessary cleanup. + +```yaml +services: + app: + image: backend + pre_stop: + - command: ./data_flush.sh +``` diff --git a/content/manuals/compose/releases/release-notes.md b/content/manuals/compose/releases/release-notes.md index 8bdbb821b682..df95b0bc75d7 100644 --- a/content/manuals/compose/releases/release-notes.md +++ b/content/manuals/compose/releases/release-notes.md @@ -13,6 +13,32 @@ aliases: For more detailed information, see the [release notes in the Compose repo](https://github.com/docker/compose/releases/). +## 2.30.0 + +{{< release-date date="2024-10-29" >}} + +### Update + +- Dependencies upgrade: bump compose-go to v2.4.1 +- Dependencies upgrade: bump docker engine and cli to v27.3.1 + +### Bug fixes and enhancements + +- Introduction of service hooks support. +- Addition of alpha `generate` command. +- Addition of `export` command. +- Added support for CDI device requests using `devices` in the Compose file. +- A lot a bug fixes. + +## 2.29.7 + +{{< release-date date="2024-09-20" >}} + + +### Bug fixes and enhancements + +- Fixed a regression when using mount API for bind mounts. + ## 2.29.6 {{< release-date date="2024-09-19" >}} diff --git a/content/manuals/desktop/troubleshoot/topics.md b/content/manuals/desktop/troubleshoot/topics.md index 3ec1c1b37d12..03295f3b299a 100644 --- a/content/manuals/desktop/troubleshoot/topics.md +++ b/content/manuals/desktop/troubleshoot/topics.md @@ -259,7 +259,8 @@ Your machine must have the following features for Docker Desktop to function cor 1. Virtual Machine Platform 2. [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) -3. [Virtualization enabled in the BIOS](https://www.virtualmetric.com/blog/how-to-enable-hardware-virtualization) +3. [Virtualization enabled in the BIOS](https://support.microsoft.com/en-gb/windows/enable-virtualization-on-windows-c5578302-6e43-4b4b-a449-8ced115f58e1) + Note that many Windows devices already have virtualization enabled, so this may not apply. 4. Hypervisor enabled at Windows startup ![WSL 2 enabled](../images/wsl2-enabled.png) @@ -270,7 +271,8 @@ On Windows 10 Pro or Enterprise, you can also use Hyper-V with the following fea 1. [Hyper-V](https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-technology-overview) installed and working -2. [Virtualization enabled in the BIOS](https://www.virtualmetric.com/blog/how-to-enable-hardware-virtualization) +2. [Virtualization enabled in the BIOS](https://support.microsoft.com/en-gb/windows/enable-virtualization-on-windows-c5578302-6e43-4b4b-a449-8ced115f58e1) + Note that many Windows devices already have virtualization enabled, so this may not apply. 3. Hypervisor enabled at Windows startup ![Hyper-V on Windows features](../images/hyperv-enabled.png) diff --git a/content/manuals/security/for-admins/enforce-sign-in/_index.md b/content/manuals/security/for-admins/enforce-sign-in/_index.md index 9435cd369dbc..f4f26318baed 100644 --- a/content/manuals/security/for-admins/enforce-sign-in/_index.md +++ b/content/manuals/security/for-admins/enforce-sign-in/_index.md @@ -16,14 +16,14 @@ receive the [benefits of your organization’s subscription](../../../subscription/core-subscription/details.md) and they can circumvent [Docker’s security features](/manuals/security/for-admins/hardened-desktop/_index.md) for your organization. -There are multiple ways you can enforce sign-in, depending on your companies' set up and preferences: +There are multiple methods for enforcing sign-in, depending on your companies' set up and preferences: - [Registry key method (Windows only)](methods.md#registry-key-method-windows-only){{< badge color=green text="New" >}} - [`.plist` method (Mac only)](methods.md#plist-method-mac-only){{< badge color=green text="New" >}} - [`registry.json` method (All)](methods.md#registryjson-method-all) ## How is sign-in enforced? -When Docker Desktop starts and it detects a registry key, a `.plist` file or `registry.json` file, the +When Docker Desktop starts and it detects a registry key, `.plist` file, or `registry.json` file, the following occurs: - A **Sign in required!** prompt appears requiring the user to sign @@ -48,4 +48,9 @@ description and benefits when using each feature. | Enforce sign-in only | Users must sign in before using Docker Desktop. | Ensures users receive the benefits of your subscription and ensures security features are applied. In addition, you gain insights into users’ activity. | | Enforce single sign-on (SSO) only | If users sign in, they must sign in using SSO. | Centralizes authentication and enforces unified policies set by the identity provider. | | Enforce both | Users must sign in using SSO before using Docker Desktop. | Ensures users receive the benefits of your subscription and ensures security features are applied. In addition, you gain insights into users’ activity. Finally, it centralizes authentication and enforces unified policies set by the identity provider. | -| Enforce neither | If users sign in, they can use SSO or their Docker credentials. | Allows users to access Docker Desktop without barriers, but at the cost of reduced security and insights. | +| Enforce neither | If users sign in, they can use SSO or their Docker credentials. | Lets users access Docker Desktop without barriers, but at the cost of reduced security and insights. | + +## What's next? + +- To enforce sign-in, review the [Methods](/manuals/security/for-admins/enforce-sign-in/methods.md) guide. +- To enforce SSO, review the [Enforce SSO](/manuals/security/for-admins/single-sign-on/connect.md) steps. \ No newline at end of file diff --git a/content/manuals/security/for-admins/enforce-sign-in/methods.md b/content/manuals/security/for-admins/enforce-sign-in/methods.md index ef311b4e46df..796e351bfa5a 100644 --- a/content/manuals/security/for-admins/enforce-sign-in/methods.md +++ b/content/manuals/security/for-admins/enforce-sign-in/methods.md @@ -5,7 +5,7 @@ title: Ways to enforce sign-in for Docker Desktop linkTitle: Methods --- -This page outlines the different ways you can enforce sign-in for Docker Desktop. +This page outlines the different methods for enforcing sign-in for Docker Desktop. ## Registry key method (Windows only) @@ -13,18 +13,20 @@ This page outlines the different ways you can enforce sign-in for Docker Desktop > > The registry key method is available with Docker Desktop version 4.32 and later. +To enforce sign-in for Docker Desktop on Windows, you can configure a registry key that specifies your organization's allowed users. The following steps guide you through creating and deploying the registry key to enforce this policy: + 1. Create the registry key. Your new key should look like the following: - ```console + ```console $ HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop ``` -2. Create a multi-string value `allowedOrgs`. +2. Create a multi-string value `allowedOrgs`. > [!IMPORTANT] > > Only one entry for `allowedOrgs` is currently supported. If you add more than one value, sign-in enforcement silently fails. -3. As string data use your organization’s name, all lowercase. +3. Use your organization's name, all lowercase as string data. 4. Restart Docker Desktop. -5. Open Docker Desktop and when Docker Desktop starts, verify that the **Sign in required!** prompt appears. +5. When Docker Desktop restarts, verify that the **Sign in required!** prompt appears. In some cases, a system reboot may be necessary for enforcement to take effect. @@ -34,24 +36,25 @@ In some cases, a system reboot may be necessary for enforcement to take effect. ### Example deployment via Group Policy -The following is only an illustrative example. - -There are many ways to deploy the registry key, for example using an MDM solution or with PowerShell scripting. The method you choose is dependent on your organizations infrastructure, security policies, and the administrative rights of the end-users. +The following example outlines how to deploy a registry key to enforce sign-in on Docker Desktop using Group Policy. There are multiple ways to deploy this configuration depending on your organization's infrastructure, security policies, and management tools. 1. Create the registry script. Write a script to create the `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Docker\Docker Desktop` key, add the `allowedOrgs` multi-string, and then set the value to your organization’s name. 2. Within Group Policy, create or edit a Group Policy Objective (GPO) that applies to the machines or users you want to target. -3. Within the GPO, navigate to **Computer Configuration** > **Preferences** > **Windows Settings** > **Registry**. -4. Add the registry item. Right-click on the **Registry** node, select **New** > **Registry Item**. -5. Configure the new registry item to match the registry script you created, specifying the action as **Update**. Make sure you input the correct path, value name (`allowedOrgs`), and value data (your organization’s name). -6. Link the GPO to an Organizational Unit (OU) that contains the machines you want to apply this setting to. -7. Test the GPO. Test the GPO on a small set of machines first to ensure it behaves as expected. You can use the `gpupdate /force` command on a test machine to manually refresh its group policy settings and check the registry to confirm the changes. -8. Once verified, you can proceed with broader deployment. Monitor the deployment to ensure the settings are applied correctly across the organization's computers. +3. Within the GPO, navigate to **Computer Configuration** and select **Preferences**. +4. Select **Windows Settings** then **Registry**. +5. To add the registry item, right-click on the **Registry** node, select **New**, and then **Registry Item**. +6. Configure the new registry item to match the registry script you created, specifying the action as **Update**. Make sure you input the correct path, value name (`allowedOrgs`), and value data (your organization’s name). +7. Link the GPO to an Organizational Unit (OU) that contains the machines you want to apply this setting to. +8. Test the GPO on a small set of machines first to ensure it behaves as expected. You can use the `gpupdate /force` command on a test machine to manually refresh its group policy settings and check the registry to confirm the changes. +9. Once verified, you can proceed with broader deployment. Monitor the deployment to ensure the settings are applied correctly across the organization's computers. ## plist method (Mac only) > [!NOTE] > -> The registry key method is available with Docker Desktop version 4.32 and later. +> The `plist` method is available with Docker Desktop version 4.32 and later. + +To enforce sign-in for Docker Desktop on macOS, you can use a `plist` file that defines the required settings. The following steps guide you through the process of creating and deploying the necessary `plist` file to enforce this policy: 1. Create the file `/Library/Application Support/com.docker.docker/desktop.plist`. 2. Open `desktop.plist` in a text editor and add the following content, where `myorg` is replaced with your organization’s name all lowercase: @@ -73,18 +76,16 @@ There are many ways to deploy the registry key, for example using an MDM solutio > Only one entry for `allowedOrgs` is currently supported. If you add more than one value, sign-in enforcement silently fails. 3. Modify the file permissions to ensure the file cannot be edited by any non-administrator users. -4. Restart Docker Desktop. -5. Open Docker Desktop and when Docker Desktop starts, verify that the **Sign in required!** prompt appears. +4. Restart Docker Desktop. +5. When Docker Desktop restarts, verify that the **Sign in required!** prompt appears. > [!NOTE] > > If a `plist` and `registry.json` file both exist, the `plist` file takes precedence. -### Example deployment +### Example deployment -The following is only an illustrative example. - -There are many ways to deploy the `.plist` file. The method you choose is dependent on your organizations infrastructure, security policies, and the administrative rights of the end-users. +The following example outlines how to create and distribute the `plist` file to enforce sign-in on Docker Desktop. There are multiple ways to deploy this configuration depending on your organization's infrastructure, security policies, and management tools. {{< tabs >}} {{< tab name="MDM" >}} @@ -107,22 +108,21 @@ There are many ways to deploy the `.plist` file. The method you choose is depend 2. Before deploying the script across the organization, test it on a local macOS machine to ensure it behaves as expected. Pay attention to directory paths, permissions, and the successful application of `plist` settings. 3. Ensure that you have the capability to execute scripts remotely on macOS devices. This might involve setting up SSH access or using a remote support tool that supports macOS. 4. Use a method of remote script execution that fits your organization's infrastructure. Options include: - - SSH. If SSH is enabled on the target machines, you can use it to execute the script remotely. This method requires knowledge of the device's IP address and appropriate credentials. - - Remote support tool. For organizations using a remote support tool, you can add the script to a task and execute it across all selected machines. -5. Ensure the script is running as expected on all targeted devices. This might involve checking log files or implementing logging within the script itself to report its success or failure. + - SSH: If SSH is enabled on the target machines, you can use it to execute the script remotely. This method requires knowledge of the device's IP address and appropriate credentials. + - Remote support tool: For organizations using a remote support tool, you can add the script to a task and execute it across all selected machines. +5. Ensure the script is running as expected on all targeted devices. You may have to check log files or implement logging within the script itself to report its success or failure. {{< /tab >}} {{< /tabs >}} ## registry.json method (All) - -The following instructions explain how to create and deploy a `registry.json` file to a single device. There are many ways to deploy the `registry.json` file. You can follow the example deployments outlined in the `.plist` file section. The method you choose is dependent on your organization's infrastructure, security policies, and the administrative rights of the end-users. + +The following instructions explain how to create and deploy a `registry.json` file to a single device. There are many ways to deploy the `registry.json` file. You can follow the example deployments outlined in the `.plist` file section. The method you choose is dependent on your organization's infrastructure, security policies, and the administrative rights of the end-users. ### Option 1: Create a registry.json file to enforce sign-in -1. Ensure that the user is a member of your organization in Docker. For more +1. Ensure the user is a member of your organization in Docker. For more details, see [Manage members](/admin/organization/members/). - 2. Create the `registry.json` file. Based on the user's operating system, create a file named `registry.json` at the following location and make sure the file can't be edited by the user. @@ -150,8 +150,8 @@ details, see [Manage members](/admin/organization/members/). 4. Verify that sign-in is enforced. To activate the `registry.json` file, restart Docker Desktop on the user’s machine. When Docker Desktop starts, verify that the **Sign in - required!** prompt appears. - + required!** prompt appears. + In some cases, a system reboot may be necessary for the enforcement to take effect. > [!TIP] diff --git a/go.mod b/go.mod index bb24453ba25e..7e88fc496b6a 100644 --- a/go.mod +++ b/go.mod @@ -4,8 +4,8 @@ go 1.23.1 require ( github.com/docker/buildx v0.17.1 // indirect - github.com/docker/cli v27.3.1+incompatible // indirect - github.com/docker/compose/v2 v2.29.6 // indirect + github.com/docker/cli v27.3.2-0.20241008150905-cb3048fbebb1+incompatible // indirect + github.com/docker/compose/v2 v2.30.0 // indirect github.com/docker/scout-cli v1.13.0 // indirect github.com/moby/buildkit v0.16.0 // indirect github.com/moby/moby v27.3.1+incompatible // indirect @@ -14,7 +14,7 @@ require ( replace ( github.com/docker/buildx => github.com/docker/buildx v0.17.1 github.com/docker/cli => github.com/docker/cli v27.3.1+incompatible - github.com/docker/compose/v2 => github.com/docker/compose/v2 v2.29.2 + github.com/docker/compose/v2 => github.com/docker/compose/v2 v2.30.0 github.com/docker/scout-cli => github.com/docker/scout-cli v1.13.0 github.com/moby/buildkit => github.com/moby/buildkit v0.16.0 github.com/moby/moby => github.com/moby/moby v27.3.1+incompatible diff --git a/go.sum b/go.sum index 8259a1d72de5..9aef408d12cc 100644 --- a/go.sum +++ b/go.sum @@ -170,6 +170,8 @@ github.com/docker/compose/v2 v2.29.0 h1:qPBhzfjT2zkxUXuu+TcbQq292bPpB0ozzVHot2w2 github.com/docker/compose/v2 v2.29.0/go.mod h1:95QFO8lue3WJmLUDSdOLBkm7KdGhcG6U+RvVxrQIzOo= github.com/docker/compose/v2 v2.29.2 h1:gRlR2ApZ0IGcwmSUb/wlEVCk18Az8b7zl03hJArldOg= github.com/docker/compose/v2 v2.29.2/go.mod h1:U+yqqZqYPhILehkmmir+Yh7ZhCfkKqAvaZdrM47JBRs= +github.com/docker/compose/v2 v2.30.0 h1:EjtEBeIPeqzlY3DUQhdjkiMwigX8TrUrgPAyAqey1d0= +github.com/docker/compose/v2 v2.30.0/go.mod h1:WlU5gYgsYfNLuDeUdTusvutEC5PV3sDc15aClbR5lPw= github.com/docker/distribution v2.8.2+incompatible h1:T3de5rq0dB1j30rp0sA2rER+m322EBzniBPB6ZIzuh8= github.com/docker/distribution v2.8.2+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w= github.com/docker/distribution v2.8.3+incompatible h1:AtKxIZ36LoNK51+Z6RpzLpddBirtxJnzDrHLEKxTAYk= diff --git a/hugo.yaml b/hugo.yaml index ba2782620fe7..385eb2c21e11 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -112,7 +112,7 @@ params: latest_engine_api_version: "1.47" docker_ce_version: "27.2.1" - compose_version: "v2.29.6" + compose_version: "v2.30.0" compose_file_v3: "3.8" compose_file_v2: "2.4" buildkit_version: "0.16.0"