Docker Compose
kind: dockercompose
Description
The Docker compose crawler looks recursively for all docker compose manifests from a specific root directory. Then, for each of them, it tries to update each Docker image tag found.
Updatecli looks for the following file patterns:
docker-compose.yaml
docker-compose.yml
docker-compose.*.yaml
docker-compose.*.yml
The automatic discovery behavior can be tuned by providing a YAML manifest with a docker-compose
crawler in top-level directive autodiscovery
as explained in the "Autodiscovery" page.
Usage
The docker-compose autodiscovery can use with or without manifest.
Without manifest
Without manifest available, Updatecli will enable all default crawlers, including docker-compose.
updatecli diff
to run updatecli in dryrun
updatecli apply
to apply the changes locally
With a manifest
If a manifest is provided, Updatecli will only execute crawlers specified in the manifest such as in the following example
updatecli diff --config updatecli.d/default.yaml
to run updatecli in dryrunupdatecli apply --config updatecli.d/default.yaml
to apply the changes
# updatecli.d/default.yaml
name: "Docker compose autodiscovery using git scm"
scms:
updatemonitor:
kind: git
spec:
url: https://github.com/updatecli/updatemonitor.git
autodiscovery:
# scmid is applied to all crawlers
scmid: updatemonitor
crawlers:
dockercompose:
ignore:
- path: 'docker-compose.yaml'
services:
- traefik
#only:
# # - path: <filepath relative to scm repository>
# services: <docker compoes service name to match>
# platform: <docker compose service platform to match>
# image: <docker compose image to match>
Manifest
Parameters
Name | Type | Description | Required |
---|---|---|---|
auths | object | Auths provides a map of registry credentials where the key is the registry URL without scheme | |
digest | boolean | digest provides parameters to specify if the generated manifest should use a digest on top of the tag. | |
filematch | array | FileMatch allows to override default docker-compose.yaml file matching. Default [“docker-compose.yaml”,“docker-compose.yml”,“docker-compose..yaml”,“docker-compose..yml”] | |
ignore | array | Ignore allows to specify rule to ignore autodiscovery a specific Helm based on a rule | |
archs | array | Arch specifies a list of docker image architecture | |
images | array | Image specifies a list of docker image | |
path | string | Path specifies a Helm chart path pattern, the pattern requires to match all of name, not just a substring. | |
services | array | Services specifies a list of docker compose services | |
only | array | Only allows to specify rule to only autodiscover manifest for a specific Helm based on a rule | |
archs | array | Arch specifies a list of docker image architecture | |
images | array | Image specifies a list of docker image | |
path | string | Path specifies a Helm chart path pattern, the pattern requires to match all of name, not just a substring. | |
services | array | Services specifies a list of docker compose services | |
rootdir | string | RootDir defines the root directory used to recursively search for Helm Chart | |
versionfilter | object | versionfilter provides parameters to specify the version pattern used when generating manifest.
| |
kind | string | specifies the version kind such as semver, regex, or latest | |
pattern | string | specifies the version pattern according the version kind | |
strict | boolean | strict enforce strict versioning rule. Only used for semantic versioning at this time |
Docker Image Tag
The Docker ecosystem has no versioning guidelines. This means that it’s the wild west out there and pretty much impossible to detect all cases. Hence why Updatecli manifest was created.
That being said we are still interested in an autodiscovery feature that would detect as many cases as possible. This section is about documentation what is covered and what’s missing. Do not hesitate to look at the contributing section
Semantic Versioning
In the Docker ecosystem, many tags look like semver but are not.
For instance, node:18.12.1-alpine
would match the semver regular expression but the prerelease -alpine
is not a prerelease information as per semver convention but a variant of node:18.12.1-buster
or node:18.12.1
.
This means that we would expect a newer version with the -alpine
such as node:19.0.0-alpine
.
The docker-compose autodiscovery will handle the following scenarios
1
will suggest a version such2
otherwise stick to1
1-alpine
will suggest a version such2-alpine
otherwise stick to1-alpine
1.0
will suggest a version such2.1
otherwise stick to1.0
1.0-alpine
will suggest a version such2.1-alpine
otherwise stick to1.0-alpine
1.0.0
will suggest a version such2.1.0
otherwise stick to1.0.0
1.0.0-alpine
will suggest a version such2.1.0-alpine
otherwise stick to1.0.0-alpine
Any other version pattern such as PEP 440 are ignored in the current state. We are planning to add new versionFilter kinds in the future as the need raise.
Feel free to: