Hello Happy Developers! We're excited to announce that Kontena 1.5.0 is now available.
You can find all the release details from the Kontena 1.5 Release Notes.
The Kontena Vault now uses a stronger key derived from the configured
VAULT_KEY for encrypting vault secrets. The configured
VAULT_KEY was previously truncated to the first 32 bytes, limiting the effective AES-CBC key strength to 128 bits for hexadecimal values, or 192 bits for base64-encoded values. Existing vault secrets will be re-encrypted using the stronger key on upgrade.
The Kontena Vault secrets are now encrypted using a random AES-CBC Initialization Vector (IV) that is randomized for each secret. The configured
VAULT_IV was previously used as a static IV shared across all encrypted secrets, but is no longer required. Existing vault secrets will be re-encrypted using randomized IVs on upgrade.
A potential XSS vulnerability in the "kontena master login --remote" code display has been fixed.
Options After Parameters
Commands that accept parameters now accept options also after the parameter. For example, these commands did not work before:
$ kontena stack deploy example-stack --help ERROR: too many arguments $ kontena stack rm example-stack --force ERROR: too many arguments
Note that if you need to use something that looks like an option as a parameter you need to use the common double dash
-- option break indicator:
$ kontena master ssh -- ls -al ERROR: Unrecognised option '-l' $ kontena master ssh -- ls -al $ kontena vault write -- SECRET --secret-password--
Kontena Stack Registry V2 API And The New 'meta' Fields
While mostly invisible to the end-user, the CLI stack registry API client is now using the completely rewritten stack registry and the V2 JSON-API it offers. The registry supports GZip responses, private stacks, server-side stack YAML validation and parsing of the new top level 'meta:' fields.
The meta fields can be used to add extra information to stacks published in the registry.
As the CLI HTTP client now supports GZip compressed responses, we have also added the option to enable compression in the Kontena Master API. To enable, set
KONTENA_SERVER_GZIP=true in the Master environment.
Drop Support For Ruby 2.1, Build Installer With Embedded Ruby 2.5.0
As the Ruby 2.1 branch has been out of development for almost a year now, it's time to upgrade if you already didn't.
The MacOS Kontena CLI installation package is now bundled with Ruby version 2.5.0
Ruby 2.2 is nearing its EOL at the end of March 2018.
Process Multiple Items In One Command
Many of the subcommands can now accept a list of items instead of just one. This is handy in shell scripts and one-liners, for example:
$ kontena vault ls -q | xargs kontena vault rm --force $ kontena vault rm --force $(kontena vault ls -q)
Master Authentication Token Descriptions
You can now add descriptions to the master authentication tokens:
$ kontena master token create -e 0 --description "deploy key" $ kontena master token ls ID TOKEN_TYPE TOKEN_LAST4 EXPIRES_IN SCOPES DESCRIPTION 5a8c275351d1a1001566a4ef bearer f539 never user deploy key
The agent now uses the port in health check definition when configuring the load balancer.
health_check: protocol: http uri: / port: 8000
The health check will now consider HTTP 3XX status codes as healthy.
Logging Service Instance Crash Events
The Kontena service events now include an
instance_crash event for service containers that exit unexpectedly. Compared to the existing
start_instance events, these events do not get logged for service deploys or manual service restarts.
TIME TYPE MESSAGE ... 2018-02-16T12:38:38.583Z instance_crash service test/client-1 instance exited with code 1, restarting (delay: 0s) (core-01)
When scheduling a service with an affinity like
service==api affinity, only the bare service names were previously matched without considering their stack scope. If multiple stacks had identically named services that match the affinity filter, then all of those external services would have been considered as matching candidates.
You can define a stack scoped affinity rule that matches a service in another stack as
service==stack-b/api. A service affinity filter such as
service==api will now only match a service named
api within the same stack.
The affinity filters can now also include regular expressions such as
Daemon Strategy Node Stickiness
When a service has been deployed using the daemon strategy and a node goes offline, the scheduler now keeps the existing instances on the nodes they were running on already.
NodeAll Online Node 2 Offline Before 1.5 Node 2 Offline With Kontena 1.5 1 instance-1 instance-1 instance-1 2 instance-2 3 instance-3 instance-2 instance-3 4 instance-4 instance-3 instance-2
Let's Encrypt Certificate Challenges
The Kontena Let's Encrypt certificate integration now supports http-01 challenges as a replacement for the disabled tls-sni-01 challenges.
Kontena provides the most easy-to-use, fully integrated solution for DevOps and software development teams to deploy, run, monitor and operate containers on the cloud. The underlying Kontena Platform technology is open source and available under Apache 2.0 license. It is used by hundreds of startups and software development teams working for some of the biggest enterprises in the world. www.kontena.io.
Image Credits: Chuttersnap on Unsplash.