tsuru.yaml¶
tsuru.yaml is a special file located in the root of the application. The name of
the file may be tsuru.yaml
or tsuru.yml
.
This file is used to describe certain aspects of your app. Currently it describes information about deployment hooks and deployment time health checks. How to use this features is described below.
Deployment hooks¶
tsuru provides some deployment hooks, like restart:before
, restart:after
and build
. Deployment hooks allow developers to run commands before and after
some commands.
Here is an example about how to declare this hooks in your tsuru.yaml file:
hooks:
restart:
before:
- python manage.py generate_local_file
after:
- python manage.py clear_local_cache
build:
- python manage.py collectstatic --noinput
- python manage.py compress
tsuru supports the following hooks:
restart:before
: this hook lists commands that will run before the unit is restarted. Commands listed in this hook will run once per unit. For instance, imagine there’s an app with two units and thetsuru.yaml
file listed above. The command python manage.py generate_local_file would run two times, once per unit.restart:after
: this hook is like before-each, but runs after restarting a unit.build
: this hook lists commands that will be run during deploy, when the image is being generated.
Healthcheck¶
You can declare a health check in your tsuru.yaml file. This health check will be called during the deployment process and tsuru will make sure this health check is passing before continuing with the deployment process.
If tsuru fails to run the health check successfully it will abort the deployment
before switching the router to point to the new units, so your application will
never be unresponsive. You can configure the maximum time to wait for the
application to respond with the docker:healthcheck:max-time
config.
Here is how you can configure a health check in your yaml file:
healthcheck:
path: /healthcheck
scheme: http
method: GET
status: 200
match: .*OKAY.*
allowed_failures: 0
use_in_router: false
router_body: content
healthcheck:path
: Which path to call in your application. This path will be called for each unit. It is the only mandatory field, if it’s not set your health check will be ignored.healthcheck:scheme
: Which scheme to use. Defaults to http.healthcheck:method
: The method used to make the http request. Defaults to GET.healthcheck:status
: The expected response code for the request. Defaults to 200.healthcheck:match
: A regular expression to be matched against the request body. If it’s not set the body won’t be read and only the status code will be checked. This regular expression uses Go syntax and runs with.
matching\n
(s
flag).healthcheck:allowed_failures
: The number of allowed failures before that the health check consider the application as unhealthy. Defaults to 0.healthcheck:use_in_router
: Whether this health check path should also be registered in the router. Please, ensure that the check is consistent to prevent units being disabled by the router. Defaults to false. When an app has no explicit healthcheck or use_in_router is false a default healthcheck is configured.healthcheck:router_body
: body passed to the router whenuse_in_router
is true.healthcheck:timeout_seconds
: The timeout for each healthcheck call in seconds. Defaults to 60 seconds.healthcheck:interval_seconds
: Exclusive to thekubernetes
provisioner. The interval in seconds between each active healthcheck call ifuse_in_router
is set to true. Defaults to 10 seconds.healthcheck:force_restart
: Exclusive to thekubernetes
provisioner. Whether the unit should be restarted afterallowed_failures
consecutive healthcheck failures. (Sets the liveness probe in the Pod.)