tsurud 0.12.0 release notes¶
Welcome to tsurud 0.12.0!
Main new features¶
Lean containers: this is definitely the big feature of this release. With lean containers, we’ve dropped Circus, making application images smaller, and containers faster. Improving resource usage.
Application containers won’t run tsuru-unit-agent anymore either. It’s still used during the deployment process, but it’s not competing with the application process anymore.
Instead of having one agent inside each unit, Docker nodes will now have one agent collecting information about containers running in the node. This agent is named bs. The default behavior of tsuru is to create the bs container before running operation in the node. It should work out-of-the-box after the update, but you can tune bs configuration, customizing the Docker image for running it or configuring it to use Unix socket instead of TCP for Docker API communication (which is safer).
tsuru will create and manage at least one container per Procfile entry. Users are now able to manage the amount of units for each process.
Latest tsuru-admin release includes commands for managing bs configuration.
There are now three kinds of pools: by team, public and default. Team’s pool are segregated by teams, and cloud administrator should set teams in this pool manually. This pool are just accessible by team’s members.
Public pools are accessible by any user. It can be used to segregate machines that have specific hardware.
Default pool are for experimentation and low profile apps, like service dashboard and “in development” apps. This is the old fallback pool, but with an explicit flag.
New router available: vulcand (thanks Dan Carley). Vulcand is a powerful reverse proxy, with SNI based TLS support. This is the first step on being able to configure TLS on applications (see issue #1206).
It’s now possible to choose between Hipache, Galeb (which is still partially open source) and Vulcand.
Users are now able to change the plan of an application. tsuru will handle changes in the router and in other plan-defined application resources (i.e. memory, swap and CPU shares) #1181
Introduce a custom port allocator on tsuru. This allocator replaces the default port allocation provided by Docker, offering a way of persisting the port of a container after restarts.
The motivation behind this feature is making sure the host port mapped to one container never changes, even after restarting docker daemon or rebooting the host. This way, we can always be sure that routers are pointing to a valid address.
The default behavior is to stick to the Docker allocator, please refer to the port-allocator configuration documentation for instructions on how to choose the tsuru allocator.
This is related to issue #1072.
- Properly handle suffixes when adding a CNAME to an application (thanks Leandro Souza). #1215
- Improve safety in app-restart and other containers related operations. #1188
- Admin users can now delete any teams. #1232
- Prevent service instances orphaning by not allowing a team that is the owner of a service instance to be removed. #1236
- Properly handle key overriding on key management functions. Previously, when a user added a new key reusing a name, tsuru created the new key with the given name and body, letting the old body as an orphan key, making it impossible to remove the old key or associate it to another user. #1249
- Unbind is now atomic, meaning that it’s safer to service administrators to trust on tsuru service operations being all-or-nothing. #1253
- Fix error message on app-create when pool doesn’t exist. #1257
Now tsuru doesn’t try to start stopped/errored containers when containers move. #1186
app-shell now uses WebSocket for communication between the tsuru client and the API. This allows app-shell to be used behind proxies that support WebSocket (e.g. nginx). For more details, see #1162.
tsuru will always use the segregate scheduler, the round robin scheduler has been disabled. In order to get a similar behavior, cloud admins can create a single pool and set it as the default pool, so users don’t need to choose the pool on
tsuru is now compatible with Docker 1.8.x. There was a small change in the Docker API, changing the way of handling mount points, which affected shared file systems.
Node auto-scaling now support multi-step scaling, meaning that when scaling up or down, it might add or remove multiple nodes at once. This reduces lock content on applications and the amount of containers rebalance runnings.
Support for Docker Registry API v2 (also known as Docker Distribution).
Application logs are now collected via WebSocket as well. Each Docker node connects to the tsuru API once, and then streams logs from all containers in the node.
Change application tokens so they never expire.
The EC2 IaaS now supports tagging. #1094
Add configuration options for timeouts in the Redis pubsub connection (use for real time logging, a.k.a.
tsuru app-log -f).
Add a heartbeat for keeping connections open during platform-add and platform-update (thanks Richard Knop).
Improve error reporting in the user API (thanks Dan Hilton).
Change the behavior of unit-remove and app-remove handlers so they don’t run in background.
Enforce memory limits on Docker nodes when auto-scale is disabled. Now, whenever node auto-scaling is disabled, tsuru will enforce the max memory policy because this will trigger an error and someone will have to manually add a new node to allow new units to be created. #1251
docker-node-removecommand now rebalance all containers in removed host. You also have a flag,
--no-rebalance, to not rebalance thes containers. #1246
docker-node-updatecommand. This flag tag your node as disabled in cluster. #1246
General improvements in the documentation:
- add documentation about the /healthcheck/ endpoint (thanks Dan Carley)
- improvements to router documentation pages (thanks Dan Carley)
- fix code snippets in the services documentation page (thanks Leandro Souza)
- typo and broken link fixes and structural improvements across all the documentation (thanks Dan Hilton).
Backward incompatible changes (action needed)¶
- As tsuru now creates containers per processes, whenever an application has more than one process, tsuru will forward requests to the process named “web”. So, in a Procfile like the one below, “api” should be replaced with “web”:
api: ./start-api worker1: ./start-worker1 worker2: ./start-worker2
- You should change your fallback pool to default pool and to do that you
can run a
tsuru-admin pool-update pool_name --default=true
- tsr has been renamed to tsurud. Please update any procedures and workflows (including upstart and other init scripts).