mirror of https://github.com/docker/docs.git
Merge pull request #14486 from docker/master
Publish updates from master
This commit is contained in:
Usha Mandya
GitHub
commit
c01c51e402
|
|
@ -1040,14 +1040,20 @@ reference:
|
|||
section:
|
||||
- path: /compose/compose-file/
|
||||
title: Compose Specification
|
||||
- path: /compose/compose-file/build/
|
||||
title: Compose file build
|
||||
- path: /compose/compose-file/deploy/
|
||||
title: Compose file deploy
|
||||
- path: /compose/faq/
|
||||
title: Frequently asked questions
|
||||
- sectiontitle: Legacy versions
|
||||
section:
|
||||
- path: /compose/compose-file/compose-versioning/
|
||||
title: About versions and upgrading
|
||||
- path: /compose/compose-file/compose-file-v3/
|
||||
title: Version 3
|
||||
- path: /compose/compose-file/compose-file-v2/
|
||||
title: Version 2
|
||||
- path: /compose/compose-file/compose-versioning/
|
||||
title: About versions and upgrading
|
||||
- path: /compose/faq/
|
||||
title: Frequently asked questions
|
||||
- sectiontitle: Drivers and specifications
|
||||
section:
|
||||
- sectiontitle: Registry image manifests
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ To create your `registry.json` file on macOS:
|
|||
3. Open a new terminal and type the following command:
|
||||
|
||||
```console
|
||||
sudo mkdir -p /Library/Application\ Support/com.docker.docker
|
||||
$ sudo mkdir -p /Library/Application\ Support/com.docker.docker
|
||||
```
|
||||
|
||||
If prompted, type your password associated with your local computer.
|
||||
|
|
@ -60,5 +60,5 @@ To create your `registry.json` file on macOS:
|
|||
4. Type the following command:
|
||||
|
||||
```console
|
||||
sudo cp Documents/registry.json /Library/Application\ Support/com.docker.docker/registry.json
|
||||
$ sudo cp Documents/registry.json /Library/Application\ Support/com.docker.docker/registry.json
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
<!DOCTYPE html>
|
||||
<!-- Page generated {{ site.time }}
|
||||
{%- if page.edit_url -%}
|
||||
{%- assign edit_url = page.edit_url -%}
|
||||
{%- else -%}
|
||||
{%- assign edit_url = "https://github.com/docker/docker.github.io/edit/master/" | append: page.path -%}
|
||||
{%- endif -%} -->
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
{%- include head.html -%}
|
||||
<body class="colums">
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!-- Page generated {{ site.time }} -->
|
||||
<!DOCTYPE html>
|
||||
<!-- Page generated {{ site.time }} -->
|
||||
<html lang="en">
|
||||
{%- include head.html -%}
|
||||
<body id="landing" class="landing">
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ toc_max: 2
|
|||
|
||||
## Overview
|
||||
|
||||
The Docker Compose CLI enables developers to use native Docker commands to run applications in Amazon EC2 Container Service (ECS) when building cloud-native applications.
|
||||
The Docker Compose CLI enables developers to use native Docker commands to run applications in Amazon Elastic Container Service (ECS) when building cloud-native applications.
|
||||
|
||||
The integration between Docker and Amazon ECS allows developers to use the Docker Compose CLI to:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,305 @@
|
|||
---
|
||||
description: Compose file build reference
|
||||
keywords: fig, composition, compose, docker
|
||||
title: Compose file build reference
|
||||
toc_max: 4
|
||||
toc_min: 2
|
||||
---
|
||||
|
||||
Compose specification is a platform-neutral way to define multi-container applications. A Compose implementation
|
||||
focusing on development use-case to run application on local machine will obviously also support (re)building
|
||||
application from sources. The Compose Build specification allows to define the build process within a Compose file
|
||||
in a portable way.
|
||||
|
||||
## Definitions
|
||||
|
||||
Compose Specification is extended to support an OPTIONAL `build` subsection on services. This section define the
|
||||
build requirements for service container image. Only a subset of Compose file services MAY define such a Build
|
||||
subsection, others being created based on `Image` attribute. When a Build subsection is present for a service, it
|
||||
is *valid* for a Compose file to miss an `Image` attribute for corresponding service, as Compose implementation
|
||||
can build image from source.
|
||||
|
||||
Build can be either specified as a single string defining a context path, or as a detailed build definition.
|
||||
|
||||
In the former case, the whole path is used as a Docker context to execute a docker build, looking for a canonical
|
||||
`Dockerfile` at context root. Context path can be absolute or relative, and if so relative path MUST be resolved
|
||||
from Compose file parent folder. As an absolute path prevent the Compose file to be portable, Compose implementation
|
||||
SHOULD warn user accordingly.
|
||||
|
||||
In the later case, build arguments can be specified, including an alternate `Dockerfile` location. This one can be
|
||||
absolute or relative path. If Dockerfile path is relative, it MUST be resolved from context path. As an absolute
|
||||
path prevent the Compose file to be portable, Compose implementation SHOULD warn user if an absolute alternate
|
||||
Dockerfile path is used.
|
||||
|
||||
## Consistency with Image
|
||||
|
||||
When service definition do include both `Image` attribute and a `Build` section, Compose implementation can't
|
||||
guarantee a pulled image is strictly equivalent to building the same image from sources. Without any explicit
|
||||
user directives, Compose implementation with Build support MUST first try to pull Image, then build from source
|
||||
if image was not found on registry. Compose implementation MAY offer options to customize this behaviour by user
|
||||
request.
|
||||
|
||||
## Publishing built images
|
||||
|
||||
Compose implementation with Build support SHOULD offer an option to push built images to a registry. Doing so, it
|
||||
MUST NOT try to push service images without an `Image` attribute. Compose implementation SHOULD warn user about
|
||||
missing `Image` attribute which prevent image being pushed.
|
||||
|
||||
Compose implementation MAY offer a mechanism to compute an `Image` attribute for service when not explicitly
|
||||
declared in yaml file. In such a case, the resulting Compose configuration is considered to have a valid `Image`
|
||||
attribute, whenever the actual raw yaml file doesn't explicitly declare one.
|
||||
|
||||
## Illustrative sample
|
||||
|
||||
The following sample illustrates Compose specification concepts with a concrete sample application. The sample is non-normative.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
frontend:
|
||||
image: awesome/webapp
|
||||
build: ./webapp
|
||||
|
||||
backend:
|
||||
image: awesome/database
|
||||
build:
|
||||
context: backend
|
||||
dockerfile: ../backend.Dockerfile
|
||||
|
||||
custom:
|
||||
build: ~/custom
|
||||
```
|
||||
|
||||
When used to build service images from source, such a Compose file will create three docker images:
|
||||
|
||||
* `awesome/webapp` docker image is build using `webapp` sub-directory within Compose file parent folder as docker build context. Lack of a `Dockerfile` within this folder will throw an error.
|
||||
* `awesome/database` docker image is build using `backend` sub-directory within Compose file parent folder. `backend.Dockerfile` file is used to define build steps, this file is searched relative to context path, which means for this sample `..` will resolve to Compose file parent folder, so `backend.Dockerfile` is a sibling file.
|
||||
* a docker image is build using `custom` directory within user's HOME as docker context. Compose implementation warn user about non-portable path used to build image.
|
||||
|
||||
On push, both `awesome/webapp` and `awesome/database` docker images are pushed to (default) registry. `custom` service image is skipped as no `Image` attribute is set and user is warned about this missing attribute.
|
||||
|
||||
## Build definition
|
||||
|
||||
The `build` element define configuration options that are applied by Compose implementations to build Docker image from source.
|
||||
`build` can be specified either as a string containing a path to the build context or a detailed structure:
|
||||
|
||||
```yml
|
||||
services:
|
||||
webapp:
|
||||
build: ./dir
|
||||
```
|
||||
|
||||
Using this string syntax, only the build context can be configured as a relative path to the Compose file's parent folder.
|
||||
This path MUST be a directory and contain a `Dockerfile`.
|
||||
|
||||
Alternatively `build` can be an object with fields defined as follow
|
||||
|
||||
### context (REQUIRED)
|
||||
|
||||
`context` defines either a path to a directory containing a Dockerfile, or a url to a git repository.
|
||||
|
||||
When the value supplied is a relative path, it MUST be interpreted as relative to the location of the Compose file.
|
||||
Compose implementations MUST warn user about absolute path used to define build context as those prevent Compose file
|
||||
for being portable.
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: ./dir
|
||||
```
|
||||
|
||||
### dockerfile
|
||||
|
||||
`dockerfile` allows to set an alternate Dockerfile. A relative path MUST be resolved from the build context.
|
||||
Compose implementations MUST warn user about absolute path used to define Dockerfile as those prevent Compose file
|
||||
for being portable.
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
dockerfile: webapp.Dockerfile
|
||||
```
|
||||
|
||||
### args
|
||||
|
||||
`args` define build arguments, i.e. Dockerfile `ARG` values.
|
||||
|
||||
Using following Dockerfile:
|
||||
|
||||
```Dockerfile
|
||||
ARG GIT_COMMIT
|
||||
RUN echo "Based on commit: $GIT_COMMIT"
|
||||
```
|
||||
|
||||
`args` can be set in Compose file under the `build` key to define `GIT_COMMIT`. `args` can be set a mapping or a list:
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
args:
|
||||
GIT_COMMIT: cdc3b19
|
||||
```
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
args:
|
||||
- GIT_COMMIT=cdc3b19
|
||||
```
|
||||
|
||||
Value can be omitted when specifying a build argument, in which case its value at build time MUST be obtained by user interaction,
|
||||
otherwise build arg won't be set when building the Docker image.
|
||||
|
||||
```yml
|
||||
args:
|
||||
- GIT_COMMIT
|
||||
```
|
||||
|
||||
### ssh
|
||||
|
||||
`ssh` defines SSH authentications that the image builder SHOULD use during image build (e.g., cloning private repository)
|
||||
|
||||
`ssh` property syntax can be either:
|
||||
* `default` - let the builder connect to the ssh-agent.
|
||||
* `ID=path` - a key/value definition of an ID and the associated path. Can be either a [PEM](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) file, or path to ssh-agent socket
|
||||
|
||||
Simple `default` sample
|
||||
```yaml
|
||||
build:
|
||||
context: .
|
||||
ssh:
|
||||
- default # mount the default ssh agent
|
||||
```
|
||||
or
|
||||
```yaml
|
||||
build:
|
||||
context: .
|
||||
ssh: ["default"] # mount the default ssh agent
|
||||
```
|
||||
|
||||
Using a custom id `myproject` with path to a local SSH key:
|
||||
```yaml
|
||||
build:
|
||||
context: .
|
||||
ssh:
|
||||
- myproject=~/.ssh/myproject.pem
|
||||
```
|
||||
Image builder can then rely on this to mount SSH key during build.
|
||||
For illustration, [BuildKit extended syntax](https://github.com/compose-spec/compose-spec/pull/234/%5Bmoby/buildkit@master/frontend/dockerfile/docs/syntax.md#run---mounttypessh%5D(https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/syntax.md#run---mounttypessh)) can be used to mount ssh key set by ID and access a secured resource:
|
||||
|
||||
`RUN --mount=type=ssh,id=myproject git clone ...`
|
||||
|
||||
### cache_from
|
||||
|
||||
`cache_from` defines a list of sources the Image builder SHOULD use for cache resolution.
|
||||
|
||||
Cache location syntax MUST follow the global format `[NAME|type=TYPE[,KEY=VALUE]]`. Simple `NAME` is actually a shortcut notation for `type=registry,ref=NAME`.
|
||||
|
||||
Compose Builder implementations MAY support custom types, the Compose Specification defines canonical types which MUST be supported:
|
||||
|
||||
- `registry` to retrieve build cache from an OCI image set by key `ref`
|
||||
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
cache_from:
|
||||
- alpine:latest
|
||||
- type=local,src=path/to/cache
|
||||
- type=gha
|
||||
```
|
||||
|
||||
Unsupported caches MUST be ignored and not prevent user from building image.
|
||||
|
||||
### cache_to
|
||||
|
||||
`cache_to` defines a list of export locations to be used to share build cache with future builds.
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
cache_to:
|
||||
- user/app:cache
|
||||
- type=local,dest=path/to/cache
|
||||
```
|
||||
|
||||
Cache target is defined using the same `type=TYPE[,KEY=VALUE]` syntax defined by [`cache_from`](#cache_from).
|
||||
|
||||
Unsupported cache target MUST be ignored and not prevent user from building image.
|
||||
|
||||
### extra_hosts
|
||||
|
||||
`extra_hosts` adds hostname mappings at build-time. Use the same syntax as [extra_hosts](index.md#extra_hosts).
|
||||
|
||||
```yml
|
||||
extra_hosts:
|
||||
- "somehost:162.242.195.82"
|
||||
- "otherhost:50.31.209.229"
|
||||
```
|
||||
|
||||
Compose implementations MUST create matching entry with the IP address and hostname in the container's network
|
||||
configuration, which means for Linux `/etc/hosts` will get extra lines:
|
||||
|
||||
```
|
||||
162.242.195.82 somehost
|
||||
50.31.209.229 otherhost
|
||||
```
|
||||
|
||||
### isolation
|
||||
|
||||
`isolation` specifies a build’s container isolation technology. Like [isolation](index.md#isolation) supported values
|
||||
are platform-specific.
|
||||
|
||||
### labels
|
||||
|
||||
`labels` add metadata to the resulting image. `labels` can be set either as an array or a map.
|
||||
|
||||
reverse-DNS notation SHOULD be used to prevent labels from conflicting with those used by other software.
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
labels:
|
||||
com.example.description: "Accounting webapp"
|
||||
com.example.department: "Finance"
|
||||
com.example.label-with-empty-value: ""
|
||||
```
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
labels:
|
||||
- "com.example.description=Accounting webapp"
|
||||
- "com.example.department=Finance"
|
||||
- "com.example.label-with-empty-value"
|
||||
```
|
||||
|
||||
### shm_size
|
||||
|
||||
`shm_size` set the size of the shared memory (`/dev/shm` partition on Linux) allocated for building Docker image. Specify
|
||||
as an integer value representing the number of bytes or as a string expressing a [byte value](index.md#specifying-byte-values).
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
shm_size: '2gb'
|
||||
```
|
||||
|
||||
```yaml
|
||||
build:
|
||||
context: .
|
||||
shm_size: 10000000
|
||||
```
|
||||
|
||||
### target
|
||||
|
||||
`target` defines the stage to build as defined inside a multi-stage `Dockerfile`.
|
||||
|
||||
```yml
|
||||
build:
|
||||
context: .
|
||||
target: prod
|
||||
```
|
||||
|
||||
## Implementations
|
||||
|
||||
* [docker-compose](https://docs.docker.com/compose)
|
||||
* [buildX bake](https://docs.docker.com/buildx/working-with-buildx/)
|
||||
|
|
@ -0,0 +1,298 @@
|
|||
---
|
||||
description: Compose file deploy reference
|
||||
keywords: fig, composition, compose, docker
|
||||
title: Compose file deploy reference
|
||||
toc_max: 4
|
||||
toc_min: 2
|
||||
---
|
||||
|
||||
Compose specification is a platform-neutral way to define multi-container applications. A Compose implementation supporting
|
||||
deployment of application model MAY require some additional metadata as the Compose application model is way too abstract
|
||||
to reflect actual infrastructure needs per service, or lifecycle constraints.
|
||||
|
||||
Compose Specification Deployment allows users to declare additional metadata on services so Compose implementations get
|
||||
relevant data to allocate adequate resources on platform and configure them to match user's needs.
|
||||
|
||||
## Definitions
|
||||
|
||||
Compose Specification is extended to support an OPTIONAL `deploy` subsection on services. This section define runtime requirements
|
||||
for a service.
|
||||
|
||||
### endpoint_mode
|
||||
|
||||
`endpoint_mode` specifies a service discovery method for external clients connecting to a service. Default and available values
|
||||
are platform specific, anyway the Compose specification define two canonical values:
|
||||
|
||||
* `endpoint_mode: vip`: Assigns the service a virtual IP (VIP) that acts as the front end for clients to reach the service
|
||||
on a network. Platform routes requests between the client and nodes running the service, without client knowledge of how
|
||||
many nodes are participating in the service or their IP addresses or ports.
|
||||
|
||||
* `endpoint_mode: dnsrr`: Platform sets up DNS entries for the service such that a DNS query for the service name returns a
|
||||
list of IP addresses (DNS round-robin), and the client connects directly to one of these.
|
||||
|
||||
```yml
|
||||
services:
|
||||
frontend:
|
||||
image: awesome/webapp
|
||||
ports:
|
||||
- "8080:80"
|
||||
deploy:
|
||||
mode: replicated
|
||||
replicas: 2
|
||||
endpoint_mode: vip
|
||||
```
|
||||
|
||||
### labels
|
||||
|
||||
`labels` specifies metadata for the service. These labels MUST *only* be set on the service and *not* on any containers for the service.
|
||||
This assumes the platform has some native concept of "service" that can match Compose application model.
|
||||
|
||||
```yml
|
||||
services:
|
||||
frontend:
|
||||
image: awesome/webapp
|
||||
deploy:
|
||||
labels:
|
||||
com.example.description: "This label will appear on the web service"
|
||||
```
|
||||
|
||||
### mode
|
||||
|
||||
`mode` define the replication model used to run the service on platform. Either `global` (exactly one container per physical node) or `replicated` (a specified number of containers). The default is `replicated`.
|
||||
|
||||
```yml
|
||||
services:
|
||||
frontend:
|
||||
image: awesome/webapp
|
||||
deploy:
|
||||
mode: global
|
||||
```
|
||||
|
||||
### placement
|
||||
|
||||
`placement` specifies constraints and preferences for platform to select a physical node to run service containers.
|
||||
|
||||
#### constraints
|
||||
|
||||
`constraints` defines a REQUIRED property the platform's node MUST fulfill to run service container. Can be set either
|
||||
by a list or a map with string values.
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
placement:
|
||||
constraints:
|
||||
- disktype=ssd
|
||||
```
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
placement:
|
||||
constraints:
|
||||
disktype: ssd
|
||||
```
|
||||
|
||||
#### preferences
|
||||
|
||||
`preferences` defines a property the platform's node SHOULD fulfill to run service container. Can be set either
|
||||
by a list or a map with string values.
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
placement:
|
||||
preferences:
|
||||
- datacenter=us-east
|
||||
```
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
placement:
|
||||
preferences:
|
||||
datacenter: us-east
|
||||
```
|
||||
|
||||
### replicas
|
||||
|
||||
If the service is `replicated` (which is the default), `replicas` specifies the number of containers that SHOULD be
|
||||
running at any given time.
|
||||
|
||||
```yml
|
||||
services:
|
||||
fronted:
|
||||
image: awesome/webapp
|
||||
deploy:
|
||||
mode: replicated
|
||||
replicas: 6
|
||||
```
|
||||
|
||||
### resources
|
||||
|
||||
`resources` configures physical resource constraints for container to run on platform. Those constraints can be configured
|
||||
as a:
|
||||
|
||||
- `limits`: The platform MUST prevent container to allocate more
|
||||
- `reservations`: The platform MUST guarantee container can allocate at least the configured amount
|
||||
|
||||
```yml
|
||||
services:
|
||||
frontend:
|
||||
image: awesome/webapp
|
||||
deploy:
|
||||
resources:
|
||||
limits:
|
||||
cpus: '0.50'
|
||||
memory: 50M
|
||||
pids: 1
|
||||
reservations:
|
||||
cpus: '0.25'
|
||||
memory: 20M
|
||||
```
|
||||
|
||||
#### cpus
|
||||
|
||||
`cpus` configures a limit or reservation for how much of the available CPU resources (as number of cores) a container can use.
|
||||
|
||||
#### memory
|
||||
|
||||
`memory` configures a limit or reservation on the amount of memory a container
|
||||
can allocate, set as a string expressing a
|
||||
[byte value](index.md#specifying-byte-values).
|
||||
|
||||
#### pids
|
||||
|
||||
`pids` tunes a container’s PIDs limit, set as an integer.
|
||||
|
||||
#### devices
|
||||
|
||||
`devices` configures reservations of the devices a container can use. It contains a list of reservations, each set as an object with the following parameters: `capabilities`, `driver`, `count`, `device_ids` and `options`.
|
||||
|
||||
Devices are reserved using a list of capabilities, making `capabilities` the only required field. A device MUST satisfy all the requested capabilities for a successful reservation.
|
||||
|
||||
##### capabilities
|
||||
|
||||
`capabilities` are set as a list of strings, expressing both generic and driver specific capabilities.
|
||||
The following generic capabilities are recognized today:
|
||||
|
||||
- `gpu`: Graphics accelerator
|
||||
- `tpu`: AI accelerator
|
||||
|
||||
To avoid name clashes, driver specific capabilities MUST be prefixed with the driver name.
|
||||
For example, reserving an nVidia CUDA-enabled accelerator might look like this:
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- capabilities: ["nvidia-compute"]
|
||||
```
|
||||
|
||||
##### driver
|
||||
|
||||
A different driver for the reserved device(s) can be requested using `driver` field. The value is specified as a string.
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- capabilities: ["nvidia-compute"]
|
||||
driver: nvidia
|
||||
```
|
||||
|
||||
##### count
|
||||
|
||||
If `count` is set to `all` or not specified, Compose implementations MUST reserve all devices that satisfy the requested capabilities. Otherwise, Compose implementations MUST reserve at least the number of devices specified. The value is specified as an integer.
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- capabilities: ["tpu"]
|
||||
count: 2
|
||||
```
|
||||
|
||||
`count` and `device_ids` fields are exclusive. Compose implementations MUST return an error if both are specified.
|
||||
|
||||
##### device_ids
|
||||
|
||||
If `device_ids` is set, Compose implementations MUST reserve devices with the specified IDs providing they satisfy the requested capabilities. The value is specified as a list of strings.
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- capabilities: ["gpu"]
|
||||
device_ids: ["GPU-f123d1c9-26bb-df9b-1c23-4a731f61d8c7"]
|
||||
```
|
||||
|
||||
`count` and `device_ids` fields are exclusive. Compose implementations MUST return an error if both are specified.
|
||||
|
||||
##### options
|
||||
|
||||
Driver specific options can be set with `options` as key-value pairs.
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- capabilities: ["gpu"]
|
||||
driver: gpuvendor
|
||||
options:
|
||||
virtualization: false
|
||||
```
|
||||
|
||||
### restart_policy
|
||||
|
||||
`restart_policy` configures if and how to restart containers when they exit. If `restart_policy` is not set, Compose implementations MUST consider `restart` field set by service configuration.
|
||||
|
||||
- `condition`: One of `none`, `on-failure` or `any` (default: `any`).
|
||||
- `delay`: How long to wait between restart attempts, specified as a [duration](index.md#specifying-durations) (default: 0).
|
||||
- `max_attempts`: How many times to attempt to restart a container before giving up (default: never give up). If the restart does not
|
||||
succeed within the configured `window`, this attempt doesn't count toward the configured `max_attempts` value.
|
||||
For example, if `max_attempts` is set to '2', and the restart fails on the first attempt, more than two restarts MUST be attempted.
|
||||
- `window`: How long to wait before deciding if a restart has succeeded, specified as a [duration](#specifying-durations) (default:
|
||||
decide immediately).
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
restart_policy:
|
||||
condition: on-failure
|
||||
delay: 5s
|
||||
max_attempts: 3
|
||||
window: 120s
|
||||
```
|
||||
|
||||
### rollback_config
|
||||
|
||||
`rollback_config` configures how the service should be rollbacked in case of a failing update.
|
||||
|
||||
- `parallelism`: The number of containers to rollback at a time. If set to 0, all containers rollback simultaneously.
|
||||
- `delay`: The time to wait between each container group's rollback (default 0s).
|
||||
- `failure_action`: What to do if a rollback fails. One of `continue` or `pause` (default `pause`)
|
||||
- `monitor`: Duration after each task update to monitor for failure `(ns|us|ms|s|m|h)` (default 0s).
|
||||
- `max_failure_ratio`: Failure rate to tolerate during a rollback (default 0).
|
||||
- `order`: Order of operations during rollbacks. One of `stop-first` (old task is stopped before starting new one),
|
||||
or `start-first` (new task is started first, and the running tasks briefly overlap) (default `stop-first`).
|
||||
|
||||
### update_config
|
||||
|
||||
`update_config` configures how the service should be updated. Useful for configuring rolling updates.
|
||||
|
||||
- `parallelism`: The number of containers to update at a time.
|
||||
- `delay`: The time to wait between updating a group of containers.
|
||||
- `failure_action`: What to do if an update fails. One of `continue`, `rollback`, or `pause` (default: `pause`).
|
||||
- `monitor`: Duration after each task update to monitor for failure `(ns|us|ms|s|m|h)` (default 0s).
|
||||
- `max_failure_ratio`: Failure rate to tolerate during an update.
|
||||
- `order`: Order of operations during updates. One of `stop-first` (old task is stopped before starting new one),
|
||||
or `start-first` (new task is started first, and the running tasks briefly overlap) (default `stop-first`).
|
||||
|
||||
```yml
|
||||
deploy:
|
||||
update_config:
|
||||
parallelism: 2
|
||||
delay: 10s
|
||||
order: stop-first
|
||||
```
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -148,10 +148,11 @@ Status: Downloaded newer image for molly/privateimage:latest
|
|||
docker.io/molly/privateimage:latest
|
||||
```
|
||||
|
||||
## Feedback
|
||||
|
||||
## Logs
|
||||
Thanks for trying out the Docker Desktop Linux (beta) release. We'd love to hear from you. You can provide feedback and report any bugs through the **Issues** tracker within the [docker/desktop-linux](https://github.com/docker/desktop-linux/issues){: target="_blank" rel="noopener" class="_"} repository.
|
||||
|
||||
To create and upload a diagnostics bundle:
|
||||
To create and upload a diagnostics bundle with your bug report:
|
||||
|
||||
1. From the Docker menu, select **Troubleshoot** > **Get support**.
|
||||
2. When the diagnostics are available, click **Upload to get a Diagnostic ID**.
|
||||
|
|
@ -160,7 +161,9 @@ To create and upload a diagnostics bundle:
|
|||
be generated, once uploaded, it displays a diagnostics ID that can be sent to
|
||||
us for investigation.
|
||||
|
||||
Or, if you prefer to investigate the issue, you can access Docker Desktop logs by running the following command:
|
||||
## Logs
|
||||
|
||||
If you prefer to investigate issues yourself, you can access Docker Desktop logs by running the following command:
|
||||
|
||||
```console
|
||||
$ journalctl --user --unit=docker-desktop
|
||||
|
|
|
|||
|
|
@ -224,7 +224,7 @@ To install server and client binaries, perform the following steps:
|
|||
3. Register the service and start the Docker Engine:
|
||||
|
||||
```powershell
|
||||
PS C:\> $Env:ProgramFiles\Docker\dockerd --register-service
|
||||
PS C:\> &$Env:ProgramFiles\Docker\dockerd --register-service
|
||||
PS C:\> Start-Service docker
|
||||
```
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ To install server and client binaries, perform the following steps:
|
|||
image.
|
||||
|
||||
```powershell
|
||||
PS C:\> $Env:ProgramFiles\Docker\docker run hello-world:nanoserver
|
||||
PS C:\> &$Env:ProgramFiles\Docker\docker run hello-world:nanoserver
|
||||
```
|
||||
|
||||
This command downloads a test image and runs it in a container. When the
|
||||
|
|
|
|||
|
|
@ -30,7 +30,10 @@ redirect_from:
|
|||
|
||||
> **Docker Desktop for Linux**
|
||||
>
|
||||
> Docker Desktop helps you build, share, and run containers easily on Mac and Windows as you do on Linux. Docker handles the complex setup and allows you to focus on writing the code. Thanks to the positive support we received on the [subscription updates](https://www.docker.com/blog/updating-product-subscriptions/){: target="_blank" rel="noopener" class="_" id="dkr_docs_cta"}, we've started working on [Docker Desktop for Linux](https://www.docker.com/blog/accelerating-new-features-in-docker-desktop/){: target="_blank" rel="noopener" class="_" id="dkr_docs_cta"} which is the second-most popular feature request in our public roadmap. If you are interested in early access, sign up for our [Developer Preview program](https://www.docker.com/community/get-involved/developer-preview){: target="_blank" rel="noopener" class="_" id="dkr_docs_cta"}.
|
||||
> Docker Desktop helps you build, share, and run containers easily on Mac and
|
||||
> Windows as you do on Linux. We are excited to share that Docker Desktop for
|
||||
> Linux (Beta) is now available for you to test. For more information, see
|
||||
[Docker Desktop for Linux](../../desktop/linux/index.md).
|
||||
{: .important}
|
||||
|
||||
## Supported platforms
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ So, let's do it!
|
|||
|
||||
1. Make sure you don't have any previous `getting-started` containers running.
|
||||
|
||||
2. Run the following command. We'll explain what's going on afterwards:
|
||||
2. Run the following command from the app directory. We'll explain what's going on afterwards:
|
||||
|
||||
```console
|
||||
$ docker run -dp 3000:3000 \
|
||||
|
|
@ -66,7 +66,7 @@ So, let's do it!
|
|||
running `yarn install` to install _all_ dependencies and then running `yarn run dev`. If we look in the `package.json`,
|
||||
we'll see that the `dev` script is starting `nodemon`.
|
||||
|
||||
3. You can watch the logs using `docker logs -f <container-id>`. You'll know you're ready to go when you see this:
|
||||
3. You can watch the logs using `docker logs`. You'll know you're ready to go when you see this:
|
||||
|
||||
```console
|
||||
$ docker logs -f <container-id>
|
||||
|
|
@ -96,7 +96,11 @@ So, let's do it!
|
|||
{: .text-center }
|
||||
|
||||
6. Feel free to make any other changes you'd like to make. When you're done, stop the container and build your new image
|
||||
using `docker build -t getting-started .`.
|
||||
using:
|
||||
|
||||
```console
|
||||
$ docker build -t getting-started .
|
||||
```
|
||||
|
||||
Using bind mounts is _very_ common for local development setups. The advantage is that the dev machine doesn't need to have
|
||||
all of the build tools and environments installed. With a single `docker run` command, the dev environment is pulled and ready
|
||||
|
|
|
|||
|
|
@ -98,6 +98,11 @@ For now, we will create the network first and attach the MySQL container at star
|
|||
+--------------------+
|
||||
5 rows in set (0.00 sec)
|
||||
```
|
||||
Exit the MySQL shell to return to the shell on our machine.
|
||||
|
||||
```console
|
||||
mysql> exit
|
||||
```
|
||||
|
||||
Hooray! We have our `todos` database and it's ready for us to use!
|
||||
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ and a `docker-compose.yml` file. (You can use either a `.yml` or `.yaml` extensi
|
|||
volumes:
|
||||
- ./data/db:/var/lib/postgresql/data
|
||||
environment:
|
||||
- POSTGRES_NAME=postgres
|
||||
- POSTGRES_DB=postgres
|
||||
- POSTGRES_USER=postgres
|
||||
- POSTGRES_PASSWORD=postgres
|
||||
web:
|
||||
|
|
|
|||
Loading…
Reference in New Issue