tsuru.yaml

tsuru.yaml is a special file located in the root of the application. The name ofthe file may be tsuru.yaml or tsuru.yml.

This file is used to describe certain aspects of your app. Currently it describesinformation about deployment hooks and deployment time health checks. How to usethis features is described below.

Deployment hooks

tsuru provides some deployment hooks, like restart:before, restart:afterand build. Deployment hooks allow developers to run commands before and aftersome commands.

Here is an example about how to declare this hooks in your tsuru.yaml file:

  1. hooks:
  2.   restart:
  3.     before:
  4.       - python manage.py generate_local_file
  5.     after:
  6.       - python manage.py clear_local_cache
  7.   build:
  8.     - python manage.py collectstatic --noinput
  9.     - python manage.py compress

tsuru supports the following hooks:

  • restart:before: this hook lists commands that will run before the unit isrestarted. Commands listed in this hook will run once per unit. For instance,imagine there’s an app with two units and the tsuru.yaml file listed above.The command python manage.py generate_local_file would run two times, onceper unit.
  • restart:after: this hook is like before-each, but runs after restarting aunit.
  • build: this hook lists commands that will be run during deploy, when theimage is being generated.

Healthcheck

You can declare a health check in your tsuru.yaml file. This health check will becalled during the deployment process and tsuru will make sure this health check ispassing before continuing with the deployment process.

If tsuru fails to run the health check successfully it will abort the deploymentbefore switching the router to point to the new units, so your application willnever be unresponsive. You can configure the maximum time to wait for theapplication to respond with the docker:healthcheck:max-time config.

Here is how you can configure a health check in your yaml file:

  1. healthcheck:
  2.   path: /healthcheck
  3.   scheme: http
  4.   method: GET
  5.   status: 200
  6.   match: .*OKAY.*
  7.   allowed_failures: 0
  8.   use_in_router: false
  9.   router_body: content
  • healthcheck:path: Which path to call in your application. This path willbe called for each unit. It is the only mandatory field, if it’s not set yourhealth check will be ignored.
  • healthcheck:scheme: Which scheme to use. Defaults to http.
  • healthcheck:method: The method used to make the http request. Defaults toGET.
  • healthcheck:status: The expected response code for the request. Defaultsto 200.
  • healthcheck:match: A regular expression to be matched against the requestbody. If it’s not set the body won’t be read and only the status code will bechecked. This regular expression uses Go syntax and runs with . matching\n (s flag).
  • healthcheck:allowed_failures: The number of allowed failures before thatthe health check consider the application as unhealthy. Defaults to 0.
  • healthcheck:use_in_router: Whether this health check path should also beregistered in the router. Please, ensure that the check is consistent toprevent units being disabled by the router. Defaults to false. When an apphas no explicit healthcheck or use_in_router is false a default healthcheckis configured.
  • healthcheck:router_body: body passed to the router when use_in_routeris true.
  • healthcheck:timeout_seconds: The timeout for each healthcheck call inseconds. Defaults to 60 seconds.
  • healthcheck:interval_seconds: Exclusive to the kubernetesprovisioner. 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 the kubernetesprovisioner. Whether the unit should be restarted after allowed_failuresconsecutive healthcheck failures. (Sets the liveness probe in the Pod.)

原文: https://docs.tsuru.io/1.6/using/tsuru.yaml.html