tsuru 1.6.0 released

We just released tsuru 1.6.0, with a lot of new features and bug fixes. Here are the most relevant ones — refer to the full release notes for more.

Platform versioning

A platform in tsuru consists of a docker image and a script that runs on each app deploy. Before this release, every time a platform was updated, the new image overrode the previous one, and the new image was used as base for every app using that platform. That means an update could break clients, and there was no way to use the previous image — unless you updated the platform again, setting the previous image.

Now, every time a platform is updated, tsuru tags a new version of it. The list of versions for a specific platform can be seen with:

$ tsuru platform info python
Name: python
Status: enabled
Images:
 - my-registry.example.com/tsuru/python:v2
 - my-registry.example.com/tsuru/python:v1

By default, every python app in this example will use the latest version, which is my-registry.example.com/tsuru/python:v2. But suppose that, in the update to python platform v2, pip version was updated from 9 to 10. This version stopped exposing pip internal packages. If you had an app that depended on these packages, its deploys wouldn't work anymore with python platform v2. A possible solution to this is updating the app to lock it to python platform v1:

$ tsuru app update -a myapp --platform python:v1
App "myapp" has been updated!

After you run this command, this app won't receive any more platform updates. These updates could include security fixes and other improvements, so locking an app to a specific platform version should be used just as a temporary solution for apps that break after an update.

Team tokens

In previous tsuru versions, if you wanted to configure a CI server to make deploys to your apps, you needed to use your own tsuru user token. This is not ideal, because that token is associated to that specific user, which could eventually leave the team and lose permission to deploy those apps. Also, that user could have too many permissions; a security breach in the CI server could be very dangerous.

Now it's possible to create a token associated to a team, not a user. To create it:

$ tsuru token create \
    --id my-ci-token \
    --team myteam \
    --description "CI token"
Token "my-ci-token" created: b3bc4ded93dd9a799874b564835d362aa1274be0e9511f29d3f78dc8517af176

By default, team tokens don't expire, but you could set an expiration for it, with the flag --expires 24h, for instance.

Now you can set the permissions that token will have (assuming you have created a role called deployer that has permission to deploy apps):

$ tsuru role assign deployer my-ci-token
Role successfully assigned!

The permissions a team token can get are limited to the roles of the user running this command.

To list all tokens (output truncated for better readability):

$ tsuru token list
+-------------+--------+-------------+--------------+------------+
| Token ID    | Team   | Description | Value        | Roles      |
+-------------+--------+-------------+--------------+------------+
| my-ci-token | myteam | CI token    | b3bc49325... | deployer() |
|             |        |             |              |            |
+-------------+--------+-------------+--------------+------------+

For more details on team tokens, check the documentation.

Event webhooks

Webhooks allow triggering a request every time a specific kind of event happens on tsuru. You could use this feature to be notified when your app deploy fails, or when a unit add event is successful, for example.

A practical example would be notifying a Slack channel every time an app is deployed:

$ tsuru event-webhook-create my-webhook \
    https://hooks.slack.com/services/... \
    -d "all successful deploys" \
    -t <my-team> \
    -m POST \
    -H Content-Type=application/x-www-form-urlencoded \
    -b 'payload={"text": "[{{.Kind.Name}}]: {{.Target.Type}} {{.Target.Value}}"}' \
    --success-only \
    --kind-name app.deploy

Event filters could be include other fields, and the hook request also supports other configurations. The request payload can be customized to include any field from the event. Refer to tsuru docs for more details.

OpenAPI specification

From now on, tsuru API is being documented with OpenAPI v2 specification. It's not complete yet, but we’re constantly updating it to add missing API calls. You can check tsuru API documentation in swaggerhub.

We're also generating a tsuru go client from the specs, which may be useful for Go apps that need to use tsuru API.

Improved Kubernetes support

Since version 1.3, tsuru supports Kubernetes as an app provisioner. This release includes a couple of important improvements and bugfixes, like:

• More reliable image build and deploy, by using a sidecar with deploy-agent to build the image
• Added support for deploy cancelation and rollback
• Improved healthcheck config options
• Added support to building apps and platforms in Kubernetes pools