Merge branch 'dev' into 'master' (391b0aee) · Commits · REDMIC Project / Docker / Docker deploy

.env

+2 −2

Original line number	Diff line number	Diff line
		DOCKER_COMPOSE_VERSION=1.29.2
		OPENSSH_CLIENT_VERSION=8.3_p1-r3
		DOCKER_VERSION=24.0.7-cli-alpine3.18
		OPENSSH_VERSION=9.3_p2-r0

.gitlab-ci.yml

+1 −1

Original line number	Diff line number	Diff line
		@@ -10,4 +10,4 @@ stages:

		.docker-build:
		variables:
		COMPOSE_FILE_NAME: docker-compose.yml
		COMPOSE_FILE_NAME: compose.yaml

Dockerfile

+4 −4

Original line number	Diff line number	Diff line
		ARG DOCKER_COMPOSE_VERSION
		FROM docker/compose:${DOCKER_COMPOSE_VERSION}
		ARG DOCKER_VERSION
		FROM docker:${DOCKER_VERSION}

		LABEL maintainer="info@redmic.es"

		ARG OPENSSH_CLIENT_VERSION
		ARG OPENSSH_VERSION
		RUN apk --update --no-cache add \
		openssh-client=${OPENSSH_CLIENT_VERSION}
		openssh-client-default=${OPENSSH_VERSION}

		COPY script/ /script/
		RUN \

README.md

+56 −62

Original line number	Diff line number	Diff line
		# Docker deploy

		Docker deployment utilities for REDMIC infrastructure.
		You can use it to deploy your own services, supporting docker-compose and Docker Swarm environments.
		You can use it to deploy your own services, supporting Docker Compose (both v1 and v2) and Docker Swarm environments.

		## Actions

		* deploy: Perform a service deployment on a remote Docker environment. Contains 3 stages:

		* prepare-deploy: Copy resources to remote environment (docker-compose files, service configurations...), prepare environment variables and directories, etc.

		* do-deploy: Launch service on Docker environment. Both standard (using docker-compose) and Swarm modes are supported on remote Docker environment, but Swarm mode is recommended (even for single-node clusters).

		* deploy: Perform a service deployment at a Docker environment. Contains 3 stages:
		* prepare-deploy: Check dependencies, copy resources to deployment target host (compose files, service configurations...), prepare environment variables and directories, etc.
		* do-deploy: Launch service at deployment target host. Both standard (using `docker compose`) and Swarm (using `docker stack deploy`) modes are supported (deprecated versions too), but Swarm mode is recommended (even for single-node clusters).
		* check-deploy: Once deployment is done, this stage waits a defined time period for the service to being up and running (or stopped after run successfully). If service status remains stable after several checks, then it is considered successfully deployed.

		* create-nets: Prepare remote environment creating Docker networks which are external to service definition (not created by service deployment itself, defined as external in compose files).

		* create-nets: Prepare deployment target host environment creating Docker networks which are external to service definition (not created by service deployment itself, defined as external in compose files).
		* relaunch: Force a previously deployed service to update, relaunching it with the same service configuration. Available only for Swarm mode.

		## Usage
		@@ -23,9 +18,10 @@ For REDMIC, we use this image into CI/CD configuration. Deploy jobs are defined

		```sh
		docker run --rm --name docker-deploy \
		-e SSH_REMOTE=ssh-user@host -e DEPLOY_KEY="<your-private-key>" \
		-e SSH_REMOTE=ssh-user@host \
		-e DEPLOY_KEY="<your-private-key>" \
		-e STACK=your-stack-name \
		-v $(pwd)/docker-compose.yml:/docker-compose.yml \
		-v $(pwd)/compose.yaml:/compose.yaml \
		-v $(pwd)/.env:/.env \
		redmic/docker-docker-deploy:latest \
		<action> <arg1> <arg2> ...
		@@ -36,11 +32,11 @@ As you can see, configuration is possible through environment variables and by s
		Using environment variables, you can configure:

		* Behaviour of this image itself.
		* Remote environment (where you are deploying to) for service configuration and service environment variables. Only when action is deploy and using the `ENV_PREFIX` prefix in your variable names.
		* Deployment target host environment (where you are deploying to) for service deployment configuration and deployed service environment variables (the latter only when action is deploy and using the `ENV_PREFIX` prefix in your variable names).

		Using script parameters you can set:

		* When action is deploy, remote environment for service configuration and service environment variables. These parameters overwrite previous environment values, including those defined using the `ENV_PREFIX` prefix.
		* When action is deploy, deployment target host environment (where you are deploying to) for service deployment configuration and deployed service environment variables. These parameters overwrite previous environment values, including those defined using the `ENV_PREFIX` prefix.
		* When action is create-nets, the name of external networks to create.

		## Configuration
		@@ -49,46 +45,44 @@ Using script parameters you can set:

		You may define these environment variables (bold are mandatory):

		* DEPLOY_KEY: Private key used to authenticate, paired with a public key accepted by remote host.
		* SSH_REMOTE: SSH user and hostname (DNS or IP) of remote host where you are going to deploy.
		* STACK: Name of Docker stack (Swarm mode) or project (docker-compose mode) used to wrap deployed services.

		* COMPOSE_FILE: Name of service definition file. Multiple files are supported, separated by colon (`:`). Default `docker-compose.yml`.
		* DEFAULT_DEPLOY_FILES: Files needed for deployment. Used only if `DEPLOY_DIR_NAME` directory does not exist. Default `docker-compose*.yml .env`.
		* DEPLOY_DIR_NAME: Name of directory containing files needed for deployment. If directory exists, `DEFAULT_DEPLOY_FILES` is ignored and all content is copied to remote host. Default `deploy`.
		* DEPLOY_PATH: Path in remote host where deployment directory (used to hold temporary files) will be created. Default `~`.
		* ENV_PREFIX: Prefix used to identify variables to be defined in remote environment and service, available there without this prefix. Change this if default value collides with the beginning of your variable names. Default `DD_`.
		* ENV_SPACE_REPLACEMENT: Unique string (change this if that is not true for you) used to replace spaces into variable values while handling them. Default `<dd-space>`.
		* FORCE_DOCKER_COMPOSE: Use always standard (docker-compose) mode instead of Docker Swarm, even if it is available on remote Docker environment. Default `0`.
		* OMIT_CLEAN_DEPLOY: Leave at remote host deployment resources after doing a successful deploy. Useful when using bind mounts or docker-compose secrets (pointing to static content in deployment resources). Default `0`.
		* SWARM_RESOLVE_IMAGE: Allow edit behaviour of query the registry to resolve image digest and supported platforms ("always"\|"changed"\|"never"). Default `always`.
		* GREP_BIN: Path to grep binary in remote host. Default `grep`.
		* REGISTRY_PASS: Docker registry password, corresponding to a user with read permissions. Required for private registry or repository.
		* REGISTRY_URL: Docker registry address, where Docker must log in to retrieve images. Useful only when using private registry or repository. Default is empty, to use Docker Hub registry.
		* REGISTRY_USER: Docker registry username, corresponding to a user with read permissions. Required for private registry or repository.
		* SERVICES_TO_AUTH: Names of services which need authorization to access to private registry, separated by space. Default is empty, to use service names found into docker-compose files with stack prefix (`<stack-name>_<service-name>`).
		* SERVICE: Name of service to relaunch (`<stack-name>_<service-name>`). Available and required only for relaunch action.
		* SERVICES_TO_CHECK: Names of services to check after deployment, separated by space. Default is empty, to use service names found into docker-compose files with stack prefix (`<stack-name>_<service-name>`).
		* SERVICES_TO_DEPLOY: Names of services to deploy, separated by space. Available only for standard (docker-compose) mode. Default is empty, to deploy all defined services.
		* STATUS_CHECK_DELAY: Seconds to wait before check deployment. Default `120`.
		* STATUS_CHECK_INTERVAL: Seconds to wait between check iterations. Default `20`.
		* STATUS_CHECK_MIN_HITS: Minimum number of successful checks to consider deployment as successful. Default `3`.
		* STATUS_CHECK_RETRIES: Maximum number of checks before considering deployment as failed. Default `10`.
		* USE_IMAGE_DIGEST: Update service image using digest data when relaunching. Available only for relaunch action. Default `0`.
		* SSH_PORT: Port used for SSH connection to remote host. Default `22`.
		* SSH_CONTROL_PERSIST: Number of seconds while SSH connection to remote host remain open (useful for short but frequent connections). Default `10`.
		\| Variable name \| Default value \| Description \|
		\| - \| - \| - \|
		\| DEPLOY_KEY \| - \| Private key used to authenticate, paired with a public key accepted by remote host. \|
		\| SSH_REMOTE \| - \| SSH user and hostname (DNS or IP) of remote host where you are going to deploy. \|
		\| STACK \| - \| Name of Docker stack (Swarm mode) or project (Compose mode) used to wrap deployed services. \|
		\| COMPOSE_FILE \| `compose.yaml` \| Name of service definition file. Multiple files are supported, separated by colon (`:`). \|
		\| DEFAULT_DEPLOY_FILES \| `compose.y*ml .env` \| Files needed for deployment. Used only if `DEPLOY_DIR_NAME` directory does not exist. \|
		\| DEPLOY_DIR_NAME \| `deploy` \| Name of directory containing files needed for deployment. If directory exists, `DEFAULT_DEPLOY_FILES` is ignored and all contents are copied to deployment target host. \|
		\| DEPLOY_PATH \| `~` \| Path in deployment target host where deployment directory (used to hold temporary files) will be created. \|
		\| ENV_PREFIX \| `DD_` \| Prefix used to identify variables to be defined in deployment target host environment and service, available there without this prefix. Change this if default value collides with the beginning of your variable names. \|
		\| ENV_SPACE_REPLACEMENT \| `<dd-space>` \| Unique string (change this if that is not true for you) used to replace spaces into variable values while handling them. \|
		\| FORCE_DOCKER_COMPOSE \| `0` \| Use always standard (Compose) mode instead of Docker Swarm, even if it is available at deployment target host. \|
		\| OMIT_CLEAN_DEPLOY \| `0` \| Leave at deployment target host deployment resources after doing a successful deploy. Useful when using bind mounts or Compose secrets (pointing to static content in deployment resources). \|
		\| SWARM_RESOLVE_IMAGE \| `always` \| Allows to edit the behaviour of the registry query to resolve image digests and supported platforms (`always`, `changed` or `never`). \|
		\| GREP_BIN \| `grep` \| Path to grep binary in deployment target host. \|
		\| REGISTRY_PASS \| - \| Docker registry password, corresponding to a user with read permissions. Required for private registry or repository. \|
		\| REGISTRY_URL \| - \| Docker registry address, where Docker must log in to retrieve images. Useful only when using private registry or repository. Default is empty, to use Docker Hub registry. \|
		\| REGISTRY_USER \| - \| Docker registry username, corresponding to a user with read permissions. Required for private registry or repository. \|
		\| SERVICES_TO_AUTH \| - \| Names of services which need authorization to access to private registry, separated by space. Default is empty, to use service names found into compose files with stack prefix (`<stack-name>_<service-name>`). \|
		\| SERVICE \| - \| Name of service to relaunch (`<stack-name>_<service-name>`). Available and required only for relaunch action. \|
		\| SERVICES_TO_CHECK \| - \| Names of services to check after deployment, separated by space. Default is empty, to use service names found into compose files with stack prefix (`<stack-name>_<service-name>`). \|
		\| SERVICES_TO_DEPLOY \| - \| Names of services to deploy, separated by space. Available only for standard (Compose) mode. Default is empty, to deploy all defined services. \|
		\| STATUS_CHECK_DELAY \| `120` \| Seconds to wait before check deployment. \|
		\| STATUS_CHECK_INTERVAL \| `20` \| Seconds to wait between check iterations. \|
		\| STATUS_CHECK_MIN_HITS \| `3` \| Minimum number of successful checks to consider deployment as successful. \|
		\| STATUS_CHECK_RETRIES \| `10` \| Maximum number of checks before considering deployment as failed. \|
		\| USE_IMAGE_DIGEST \| `0` \| Update service image using digest data when relaunching. Available only for relaunch action. \|
		\| SSH_PORT \| `22` \| Port used for SSH connection to remote host. \|
		\| SSH_CONTROL_PERSIST \| `10` \| Number of seconds while SSH connection to remote host remain open (useful for short but frequent connections). \|

		### Your services

		When using deploy action, you can configure your own services through variables:

		* Define any variable whose name is prefixed by `ENV_PREFIX` prefix:

		1. Set variable `docker run ... -e DD_ANY_NAME=value ... deploy`.
		2. `ANY_NAME` will be available into service containers with `value` value.

		* Pass any variable as deploy script parameter (without `ENV_PREFIX` prefix):

		1. Set parameter to deploy script: `docker run ... deploy ANY_NAME=value`.
		2. `ANY_NAME` will be available into service containers with `value` value.

		@@ -98,7 +92,7 @@ When using deploy action, you can configure your own services through variable

		```sh
		$ ls -a deploy
		. .. docker-compose.yml .env
		. .. compose.yaml .env

		$ export DEPLOY_KEY="
		-----BEGIN RSA PRIVATE KEY-----
		@@ -119,20 +113,20 @@ sIhl4aG94WSKaj6MdST5Dzt/0qbyJXCThChJbahWToou
		"

		$ docker run --rm --name docker-deploy \
		-e SSH_REMOTE=user@domain.net -e DEPLOY_KEY \
		-e STACK=example -e SERVICES_TO_CHECK=example_service-name \
		-e SSH_REMOTE=user@domain.net \
		-e DEPLOY_KEY \
		-e STACK=example \
		-e DD_VARIABLE_1="variable 1" \
		-v $(pwd)/deploy:/deploy \
		redmic/docker-docker-deploy \
		deploy VARIABLE_2="variable 2"
		```

		1. You must define the deploy configuration, a valid `docker-compose.yml` file at least.
		1. You must define the deploy configuration, a valid `compose.yaml` file at least.
		2. To authenticate, you must use a private key allowed in the remote host.
		3. Start service deployment. In this example:
		* to `domain.net` remote host
		* identified as `user`
		* authenticated through a RSA-1024 private key
		* into `example` stack
		* check service `example_service-name` deployment
		* with `VARIABLE_1` and `VARIABLE_2` set in service

docker-compose.yml→compose.yaml

+2 −2

Original line number	Diff line number	Diff line
		@@ -5,5 +5,5 @@ services:
		context: .
		dockerfile: ${DOCKERFILE:-Dockerfile}
		args:
		DOCKER_COMPOSE_VERSION:
		OPENSSH_CLIENT_VERSION:
		DOCKER_VERSION:
		OPENSSH_VERSION:

Original line number	Diff line number	Diff line
		# Docker deploy

		Docker deployment utilities for REDMIC infrastructure.
		You can use it to deploy your own services, supporting docker-compose and Docker Swarm environments.
		You can use it to deploy your own services, supporting Docker Compose (both v1 and v2) and Docker Swarm environments.

		## Actions

		* deploy: Perform a service deployment on a remote Docker environment. Contains 3 stages:

		* prepare-deploy: Copy resources to remote environment (docker-compose files, service configurations...), prepare environment variables and directories, etc.

		* do-deploy: Launch service on Docker environment. Both standard (using docker-compose) and Swarm modes are supported on remote Docker environment, but Swarm mode is recommended (even for single-node clusters).

		* deploy: Perform a service deployment at a Docker environment. Contains 3 stages:
		* prepare-deploy: Check dependencies, copy resources to deployment target host (compose files, service configurations...), prepare environment variables and directories, etc.
		* do-deploy: Launch service at deployment target host. Both standard (using `docker compose`) and Swarm (using `docker stack deploy`) modes are supported (deprecated versions too), but Swarm mode is recommended (even for single-node clusters).
		* check-deploy: Once deployment is done, this stage waits a defined time period for the service to being up and running (or stopped after run successfully). If service status remains stable after several checks, then it is considered successfully deployed.

		* create-nets: Prepare remote environment creating Docker networks which are external to service definition (not created by service deployment itself, defined as external in compose files).

		* create-nets: Prepare deployment target host environment creating Docker networks which are external to service definition (not created by service deployment itself, defined as external in compose files).
		* relaunch: Force a previously deployed service to update, relaunching it with the same service configuration. Available only for Swarm mode.

		## Usage
		@@ -23,9 +18,10 @@ For REDMIC, we use this image into CI/CD configuration. Deploy jobs are defined

		```sh
		docker run --rm --name docker-deploy \
		-e SSH_REMOTE=ssh-user@host -e DEPLOY_KEY="<your-private-key>" \
		-e SSH_REMOTE=ssh-user@host \
		-e DEPLOY_KEY="<your-private-key>" \
		-e STACK=your-stack-name \
		-v $(pwd)/docker-compose.yml:/docker-compose.yml \
		-v $(pwd)/compose.yaml:/compose.yaml \
		-v $(pwd)/.env:/.env \
		redmic/docker-docker-deploy:latest \
		<action> <arg1> <arg2> ...
		@@ -36,11 +32,11 @@ As you can see, configuration is possible through environment variables and by s
		Using environment variables, you can configure:

		* Behaviour of this image itself.
		* Remote environment (where you are deploying to) for service configuration and service environment variables. Only when action is deploy and using the `ENV_PREFIX` prefix in your variable names.
		* Deployment target host environment (where you are deploying to) for service deployment configuration and deployed service environment variables (the latter only when action is deploy and using the `ENV_PREFIX` prefix in your variable names).

		Using script parameters you can set:

		* When action is deploy, remote environment for service configuration and service environment variables. These parameters overwrite previous environment values, including those defined using the `ENV_PREFIX` prefix.
		* When action is deploy, deployment target host environment (where you are deploying to) for service deployment configuration and deployed service environment variables. These parameters overwrite previous environment values, including those defined using the `ENV_PREFIX` prefix.
		* When action is create-nets, the name of external networks to create.

		## Configuration
		@@ -49,46 +45,44 @@ Using script parameters you can set:

		You may define these environment variables (bold are mandatory):

		* DEPLOY_KEY: Private key used to authenticate, paired with a public key accepted by remote host.
		* SSH_REMOTE: SSH user and hostname (DNS or IP) of remote host where you are going to deploy.
		* STACK: Name of Docker stack (Swarm mode) or project (docker-compose mode) used to wrap deployed services.

		* COMPOSE_FILE: Name of service definition file. Multiple files are supported, separated by colon (`:`). Default `docker-compose.yml`.
		* DEFAULT_DEPLOY_FILES: Files needed for deployment. Used only if `DEPLOY_DIR_NAME` directory does not exist. Default `docker-compose*.yml .env`.
		* DEPLOY_DIR_NAME: Name of directory containing files needed for deployment. If directory exists, `DEFAULT_DEPLOY_FILES` is ignored and all content is copied to remote host. Default `deploy`.
		* DEPLOY_PATH: Path in remote host where deployment directory (used to hold temporary files) will be created. Default `~`.
		* ENV_PREFIX: Prefix used to identify variables to be defined in remote environment and service, available there without this prefix. Change this if default value collides with the beginning of your variable names. Default `DD_`.
		* ENV_SPACE_REPLACEMENT: Unique string (change this if that is not true for you) used to replace spaces into variable values while handling them. Default `<dd-space>`.
		* FORCE_DOCKER_COMPOSE: Use always standard (docker-compose) mode instead of Docker Swarm, even if it is available on remote Docker environment. Default `0`.
		* OMIT_CLEAN_DEPLOY: Leave at remote host deployment resources after doing a successful deploy. Useful when using bind mounts or docker-compose secrets (pointing to static content in deployment resources). Default `0`.
		* SWARM_RESOLVE_IMAGE: Allow edit behaviour of query the registry to resolve image digest and supported platforms ("always"\|"changed"\|"never"). Default `always`.
		* GREP_BIN: Path to grep binary in remote host. Default `grep`.
		* REGISTRY_PASS: Docker registry password, corresponding to a user with read permissions. Required for private registry or repository.
		* REGISTRY_URL: Docker registry address, where Docker must log in to retrieve images. Useful only when using private registry or repository. Default is empty, to use Docker Hub registry.
		* REGISTRY_USER: Docker registry username, corresponding to a user with read permissions. Required for private registry or repository.
		* SERVICES_TO_AUTH: Names of services which need authorization to access to private registry, separated by space. Default is empty, to use service names found into docker-compose files with stack prefix (`<stack-name>_<service-name>`).
		* SERVICE: Name of service to relaunch (`<stack-name>_<service-name>`). Available and required only for relaunch action.
		* SERVICES_TO_CHECK: Names of services to check after deployment, separated by space. Default is empty, to use service names found into docker-compose files with stack prefix (`<stack-name>_<service-name>`).
		* SERVICES_TO_DEPLOY: Names of services to deploy, separated by space. Available only for standard (docker-compose) mode. Default is empty, to deploy all defined services.
		* STATUS_CHECK_DELAY: Seconds to wait before check deployment. Default `120`.
		* STATUS_CHECK_INTERVAL: Seconds to wait between check iterations. Default `20`.
		* STATUS_CHECK_MIN_HITS: Minimum number of successful checks to consider deployment as successful. Default `3`.
		* STATUS_CHECK_RETRIES: Maximum number of checks before considering deployment as failed. Default `10`.
		* USE_IMAGE_DIGEST: Update service image using digest data when relaunching. Available only for relaunch action. Default `0`.
		* SSH_PORT: Port used for SSH connection to remote host. Default `22`.
		* SSH_CONTROL_PERSIST: Number of seconds while SSH connection to remote host remain open (useful for short but frequent connections). Default `10`.
		\| Variable name \| Default value \| Description \|
		\| - \| - \| - \|
		\| DEPLOY_KEY \| - \| Private key used to authenticate, paired with a public key accepted by remote host. \|
		\| SSH_REMOTE \| - \| SSH user and hostname (DNS or IP) of remote host where you are going to deploy. \|
		\| STACK \| - \| Name of Docker stack (Swarm mode) or project (Compose mode) used to wrap deployed services. \|
		\| COMPOSE_FILE \| `compose.yaml` \| Name of service definition file. Multiple files are supported, separated by colon (`:`). \|
		\| DEFAULT_DEPLOY_FILES \| `compose.y*ml .env` \| Files needed for deployment. Used only if `DEPLOY_DIR_NAME` directory does not exist. \|
		\| DEPLOY_DIR_NAME \| `deploy` \| Name of directory containing files needed for deployment. If directory exists, `DEFAULT_DEPLOY_FILES` is ignored and all contents are copied to deployment target host. \|
		\| DEPLOY_PATH \| `~` \| Path in deployment target host where deployment directory (used to hold temporary files) will be created. \|
		\| ENV_PREFIX \| `DD_` \| Prefix used to identify variables to be defined in deployment target host environment and service, available there without this prefix. Change this if default value collides with the beginning of your variable names. \|
		\| ENV_SPACE_REPLACEMENT \| `<dd-space>` \| Unique string (change this if that is not true for you) used to replace spaces into variable values while handling them. \|
		\| FORCE_DOCKER_COMPOSE \| `0` \| Use always standard (Compose) mode instead of Docker Swarm, even if it is available at deployment target host. \|
		\| OMIT_CLEAN_DEPLOY \| `0` \| Leave at deployment target host deployment resources after doing a successful deploy. Useful when using bind mounts or Compose secrets (pointing to static content in deployment resources). \|
		\| SWARM_RESOLVE_IMAGE \| `always` \| Allows to edit the behaviour of the registry query to resolve image digests and supported platforms (`always`, `changed` or `never`). \|
		\| GREP_BIN \| `grep` \| Path to grep binary in deployment target host. \|
		\| REGISTRY_PASS \| - \| Docker registry password, corresponding to a user with read permissions. Required for private registry or repository. \|
		\| REGISTRY_URL \| - \| Docker registry address, where Docker must log in to retrieve images. Useful only when using private registry or repository. Default is empty, to use Docker Hub registry. \|
		\| REGISTRY_USER \| - \| Docker registry username, corresponding to a user with read permissions. Required for private registry or repository. \|
		\| SERVICES_TO_AUTH \| - \| Names of services which need authorization to access to private registry, separated by space. Default is empty, to use service names found into compose files with stack prefix (`<stack-name>_<service-name>`). \|
		\| SERVICE \| - \| Name of service to relaunch (`<stack-name>_<service-name>`). Available and required only for relaunch action. \|
		\| SERVICES_TO_CHECK \| - \| Names of services to check after deployment, separated by space. Default is empty, to use service names found into compose files with stack prefix (`<stack-name>_<service-name>`). \|
		\| SERVICES_TO_DEPLOY \| - \| Names of services to deploy, separated by space. Available only for standard (Compose) mode. Default is empty, to deploy all defined services. \|
		\| STATUS_CHECK_DELAY \| `120` \| Seconds to wait before check deployment. \|
		\| STATUS_CHECK_INTERVAL \| `20` \| Seconds to wait between check iterations. \|
		\| STATUS_CHECK_MIN_HITS \| `3` \| Minimum number of successful checks to consider deployment as successful. \|
		\| STATUS_CHECK_RETRIES \| `10` \| Maximum number of checks before considering deployment as failed. \|
		\| USE_IMAGE_DIGEST \| `0` \| Update service image using digest data when relaunching. Available only for relaunch action. \|
		\| SSH_PORT \| `22` \| Port used for SSH connection to remote host. \|
		\| SSH_CONTROL_PERSIST \| `10` \| Number of seconds while SSH connection to remote host remain open (useful for short but frequent connections). \|

		### Your services

		When using deploy action, you can configure your own services through variables:

		* Define any variable whose name is prefixed by `ENV_PREFIX` prefix:

		1. Set variable `docker run ... -e DD_ANY_NAME=value ... deploy`.
		2. `ANY_NAME` will be available into service containers with `value` value.

		* Pass any variable as deploy script parameter (without `ENV_PREFIX` prefix):

		1. Set parameter to deploy script: `docker run ... deploy ANY_NAME=value`.
		2. `ANY_NAME` will be available into service containers with `value` value.

		@@ -98,7 +92,7 @@ When using deploy action, you can configure your own services through variable

		```sh
		$ ls -a deploy
		. .. docker-compose.yml .env
		. .. compose.yaml .env

		$ export DEPLOY_KEY="
		-----BEGIN RSA PRIVATE KEY-----
		@@ -119,20 +113,20 @@ sIhl4aG94WSKaj6MdST5Dzt/0qbyJXCThChJbahWToou
		"

		$ docker run --rm --name docker-deploy \
		-e SSH_REMOTE=user@domain.net -e DEPLOY_KEY \
		-e STACK=example -e SERVICES_TO_CHECK=example_service-name \
		-e SSH_REMOTE=user@domain.net \
		-e DEPLOY_KEY \
		-e STACK=example \
		-e DD_VARIABLE_1="variable 1" \
		-v $(pwd)/deploy:/deploy \
		redmic/docker-docker-deploy \
		deploy VARIABLE_2="variable 2"
		```

		1. You must define the deploy configuration, a valid `docker-compose.yml` file at least.
		1. You must define the deploy configuration, a valid `compose.yaml` file at least.
		2. To authenticate, you must use a private key allowed in the remote host.
		3. Start service deployment. In this example:
		* to `domain.net` remote host
		* identified as `user`
		* authenticated through a RSA-1024 private key
		* into `example` stack
		* check service `example_service-name` deployment
		* with `VARIABLE_1` and `VARIABLE_2` set in service