About Service life-cycle management
Cloud 66 provides an orchestration engine to roll out Docker images to your servers and initialize containers from them. This is what is provided for you from start to finish:
- Bring up your containers
- Port forwarding
- Load balancing
- Health checks
- Graceful draining and shutdown of workers
- Traffic switching
- Deployment rollbacks (version control)
Deploying your stack
The above can be summarized as the life-cycle management of your containers, which occurs with each new deployment of your application. For example, if you have a simple stack running
web services, this is what happens when you redeploy your stack (as pertains to the life-cycle management of your containers):
- Your latest code is pulled from Git and new images are built (on BuildGrid).
- These images are rolled out to your Docker cluster.
- Containers are initialized from these images, with all relevant environment variables and internal networking made available to them.
- If and when your health checks are successful, your old containers are gracefully drained and traffic is switched to the new containers (on the specified port(s)).
There are a number of directives you can set in your service configuration to customize your container life-cycle management:
health option allows you to specify one of two types of checks on your containers - readiness checks, and liveness checks. Both checks define a set of rules that are used to determine whether your application is currently healthy. For instance, you can check that the application is responding on an HTTP endpoint; or a post-initialization file is present.
Readiness health checks are used to determine if your newly started containers are ready to replace the old containers. Until the new containers are ready, the old containers will not be killed, and the new containers will not be served traffic. This effectively provides zero down-time deployments.
Liveness health checks, on the other hand, are used to continuously monitor your application once it’s already running. If your application fails a liveness check, it will be restarted - this is useful for issues that can not be resolved otherwise.
The rules below are available to both health checks - note that you aren’t required to specify all options. Any options not used will use their default values.
- type (string, defaults to ‘http’): Accepted values are http, https, tcp, and exec.
- endpoint (string, defaults to ‘/’): The endpoint tested for status. Only for the http, and the https types.
- command (string, no default): The command executed to test for status. Must return exit-code 0. Only for the exec type.
- timeout (integer, defaults to 5): Maximum time in seconds to wait for a health check to complete.
- success_threshold (integer, defaults to 1): Number of consecutive successes to be considered healthy.
- failure_threshold (integer, defaults to 1): Number of consecutive failures to be considered unhealthy.
- initial_delay (integer, defaults to 1): Time in seconds to wait after container has started before starting liveness checks.
- period (integer, defaults to 5): Number of seconds between each consecutive health check.
- port (integer, defaults to container port): The port to run the health check against. Only for the http, https, and tcp types.
- http_headers (array, defaults to ): Custom headers to add for HTTP traffic. Only for the http, and https types. Contains an array of hashes with the name and value keys, both of string type.
You can also use the default health rules with
health: default, or explicitly disable health checking by leaving the
health option out or specifying
This is a signal that is sent to the existing containers of the service before the new containers are started during deployment. An example could be
USR1 - but it depends on what your container is running as to which signals make sense.
This is a stop sequence that is executed on your running containers before they are shut down. It is a sequence of wait times and signals to send to the process. If the sequence completes and the container is still running, a force kill will be sent. For example:
The example above, we’ll wait 1 minute before sending the USR2 signal, then wait 30 seconds before sending the USR1 signal, and then wait 50 seconds before we force a kill. These are some examples of duration values that
pre_stop_sequence can use -
1m (1 minute),
30s (30 seconds) and
1h (1 hour).
Valid time values are
s for seconds,
m for minutes and
h for hours. Valid signal values for a signal are (without the quotes):
In some cases, you may want to make sure that a service is only started if another service is started. The
requires option allows you to set such dependencies. For example:
Restart on deploy
A boolean value to indicate whether the containers of this service should be restarted during deployment (set to true by default).
Sets the duration between the Docker
KILL signals when Docker stop is run and a container is stopped.