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.
See issues #647 and #1136 for more details.
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 theport-allocator configuration documentation for
instructions on how to choose the tsuru allocator.
This is related to issue #1072.
Bug 修复
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 app-create.
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-remove command now rebalance all containers in removed host.
You also have a flag, --no-rebalance, to not rebalance thes containers. #1246
Add --disable flag in docker-node-update command. 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).
向后兼容改进 (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”: