Rancher Release - v1.4.0

Release v1.4.0

Versions

Supported Docker Versions

Docker 1.10.3
Docker 1.12.3-1.12.6

Kubernetes UI Changes

If you are currently using Kubernetes as your primary orchestration engine, starting in release v.1.4.0, you will see two major changes in our support of k8s.

  1. The default Rancher k8s UI will now be deprecated in favor of k8s’ dashboard UI and will be automatically be started and made available for each k8s environment. Over the latter half of 2016, we’ve seen tremendous contribution and growth of this general-purpose web UI and we feel that it now at stage a where it is stable and at feature parity with Rancher’s default UI. With 1.4, the Rancher k8s UI will no longer be available and k8s’ dashboard will be the preferred UI to manage your k8s resources.

  2. Our Rancher Catalog will also now be deprecated in favor of using k8s helm to deploy k8s charts and templates. Helm (and tiller) will both be automatically made available for each k8s environment. A convenient helm client will also be added to our out-of-the-box kubectl shell console for you to use as well.

Important

  • Starting with version 1.4.0, Rancher recommends using AWS ELBs.
  • After upgrading Rancher Server, please check your infrastructure stacks to make sure your services are up to date. If an “Upgrade Required” button is shown, you must upgrade to the latest service. Complete upgrading each individual infrastructure stack before moving on to the next stack.
  • For every Rancher release, we have moved to tagging specific load balancer images (i.e. rancher/lb-service-haproxy) for load balancer services. If you have upgraded from a previous version of Rancher and a newer load balancer image has been released, a symbol will appear next to the load balancer name to indicate a newer image is available for that Rancher version. It’s recommended to upgrade to this latest image for load balancers.
  • If you are upgrading from 1.1.x to v1.2.2, please read the v1.2.0 release notes on important notes about the upgrade.

Rancher Server Tags

Rancher server has 2 different tags. For each major release tag, we will provide documentation for the specific version.

  • rancher/server:latest tag will be our latest development builds. These builds will have been validated through our CI automation framework. These releases are not meant for deployment in production.
  • rancher/server:stable tag will be our latest stable release builds. This tag is the version that we recommend for production.

Please do not the releases with a rc{n} suffix. These rc builds are meant for the Rancher team to test out builds.

v1.4.0 has been tagged as rancher/server:latest.

Features

  • Webhooks [#619] - Rancher now supports the ability to generate webhooks for scaling up and down services. The framework also allows for easy contributions of more webhooks and we welcome our community to submit PR(s) for different webhook functionalities. Each webhook driver will automatically be made available via Rancher and integrated as part of the UI experience.
  • Network Policies [#3895] - Users can now modify the network policies on a per environment level. This will allow you to set the default network policies such as DENY or ALLOW ALL rules for any containers that are created within an environment. You will also be able to set more fine-grain rules, for example, that will allow you to allow intra-stack but prevent inter-stack network communications. NOTE: UI will be added to support this in our next release.
  • Multi-IP Host Scheduling [#7034] - Rancher now supports scheduling containers onto hosts that have more than one IP if the IPs are configured in Rancher.
  • Secrets Management - Experimental [#1269] - Rancher now supports the ability to create named secrets to be used in containers. Rancher interfaces with an encryption backend, by using either a local AES (Advanced Encryption Standard) key or Vault Transit, to securely store the values within Rancher.

Known Major Issues

  • Hosts in AWS created from v1.1.4 using the UI (aka docker-machine) are not cleaned up properly when deleted from the UI [#6750]
  • With self signed certs, using a remote kubectl client does not work automatically, but there is a workaround in the issue [#7235]
  • With self signed certs and Kubernetes, Helm operations are hanging [#7234]
  • When enabling multiple scheduler IPs, if a specified host IP that matches a scheduler IP is used when exposing a port or for a load balancer, it does not get scheduled on the host with that IP. [#7675]

Major Bug Fixes since v1.3.0

Rancher-Compose Downloads

Rancher CLI Downloads