mirror of https://github.com/docker/docs.git
ENGDOCS-2080b (#20080)
* ENGDOCS-2080b * ENGDOCS-2080b * Update content/compose/compose-file/05-services.md Co-authored-by: David Karlsson <35727626+dvdksn@users.noreply.github.com> --------- Co-authored-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
parent
5e5e3afd2b
commit
5af3712985
|
@ -932,7 +932,9 @@ been the case if `group_add` were not declared.
|
|||
|
||||
## healthcheck
|
||||
|
||||
{{< include "compose/services-healthcheck.md" >}}
|
||||
{{< include "compose/services-healthcheck.md" >}}
|
||||
|
||||
For more information on `HEALTHCHECK`, see the [Dockerfile reference](../../reference/dockerfile.md#healthcheck).
|
||||
|
||||
```yml
|
||||
healthcheck:
|
||||
|
|
|
@ -6,6 +6,8 @@ keywords: compose, compose specification, extensions, compose file reference
|
|||
|
||||
{{< include "compose/extension.md" >}}
|
||||
|
||||
Extensions can also be used with [anchors and aliases](10-fragments.md).
|
||||
|
||||
They also can be used within any structure in a Compose file where user-defined keys are not expected.
|
||||
Compose uses those to enable experimental features, the same way browsers add support for [custom CSS features](https://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#vendor-keywords)
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
As with [Fragments](10-fragments.md), Extensions can be used to make your Compose file more efficient and easier to maintain. Extensions can also be used with [anchors and aliases](10-fragments.md).
|
||||
|
||||
Extensions can be used to make your Compose file more efficient and easier to maintain.
|
||||
|
||||
Use the prefix `x-` as a top-level element to modularize configurations that you want to reuse.
|
||||
Compose ignores any fields that start with `x-`, this is the sole exception where Compose silently ignores unrecognized fields.
|
|
@ -1,2 +1,2 @@
|
|||
Compose lets you define a Compose application model through [multiple Compose files](https://docs.docker.com/compose/multiple-compose-files/).
|
||||
Compose lets you define a Compose application model through multiple Compose files.
|
||||
When doing so, Compose follows certain rules to merge Compose files.
|
|
@ -1,3 +1,2 @@
|
|||
The `healthcheck` attribute declares a check that's run to determine whether or not the service containers are "healthy". It works in the same way, and has the same default values, as the
|
||||
[HEALTHCHECK Dockerfile instruction](https://docs.docker.com/reference/dockerfile/#healthcheck)
|
||||
The `healthcheck` attribute declares a check that's run to determine whether or not the service containers are "healthy". It works in the same way, and has the same default values, as the HEALTHCHECK Dockerfile instruction
|
||||
set by the service's Docker image. Your Compose file can override the values set in the Dockerfile.
|
|
@ -1,2 +1,2 @@
|
|||
The `networks` attribute defines the networks that service containers are attached to, referencing entries under the
|
||||
[`networks` top-level element](06-networks.md). The `networks` attribute helps manage the networking aspects of containers, providing control over how services are segmented and interact within the Docker environment. This is used to specify which networks the containers for that service should connect to. This is important for defining how containers communicate with each other and externally.
|
||||
`networks` top-level element. The `networks` attribute helps manage the networking aspects of containers, providing control over how services are segmented and interact within the Docker environment. This is used to specify which networks the containers for that service should connect to. This is important for defining how containers communicate with each other and externally.
|
|
@ -1 +1 @@
|
|||
The `secrets` attribute grants access to sensitive data defined by the [secrets](09-secrets.md) top-level element on a per-service basis. Services can be granted access to multiple secrets.
|
||||
The `secrets` attribute grants access to sensitive data defined by the secrets top-level element on a per-service basis. Services can be granted access to multiple secrets.
|
|
@ -2,4 +2,4 @@ The `volumes` attribute define mount host paths or named volumes that are access
|
|||
|
||||
If the mount is a host path and is only used by a single service, it can be declared as part of the service
|
||||
definition. To reuse a volume across multiple services, a named
|
||||
volume must be declared in the [top-level `volumes` key](07-volumes.md).
|
||||
volume must be declared in the `volumes` top-level element.
|
Loading…
Reference in New Issue