Workflow now adds additional metadata to the application environment. This is useful for debugging application environments, can help with auditing, and might be something you want to include in an application health response.
We've cut new base images across the board which include fixes for the recent OpenSSL CVEs.
The logger component went to summer camp and cleaned up its act and is no longer using excessive cpu.
The best way to roll into the weekend is with fresh software, hot off the
presses. The Deis Workflow team just merged the final charts for 2.5!
We've got a ton of functionality packed into 2.5, so hold on to your horses!
Workflow 2.5 includes initial support for Kubernetes Horizontal Pod
Autoscaling. Which is not only a mouthful, but pretty neat to boot. Workflow
2.5's theme song is "Glassworks" by Philip Glass. I'm pretty sure this is what
a Horizontal Pod Autoscaler would sound like if it made noise.
Cast scale at the darkness...
Setting a scaling policy for your application is straightforward. Policies are
set per process-type, which allows developers to easily scale processes
The Kubernetes HorizontalPodAutoscaler (HPA) does require CPU limits to be set for
the application process type, so makes sure you set a limit:
Behind the scenes, the HorizontalPodAutoscaler (HPA) will spring into action, adding
or removing pods so that the average CPU utilization of your application processes
approach the CPU target.
There is a bit of nuance to the way HPAs work so spend a bit of time with the
Kubernetes documentation on the algorithm.
Viewing and removing scaling policies are simple CLI commands as well:
Autoscaling in Workflow should be considered Alpha and we would love your feedback!
Build Result Caching
Thanks to community member @jeroenvisser101
the Workflow build system now caches build results. This change greatly speeds
up the process on subsequent builds.
Enforce SSL Application by Application
Workflow 2.5 now allows developers to require TLS on a per-application basis.
Instead of a global setting in the router (via
router.deis.io/nginx.ssl.enforce), Workflow CLI has a few new tricks:
Now, connections on port 80 for this application will be be redirected with
HTTP status code 301 to the HTTPS version. Since this interaction occurs at the
edge router, developers aren't required to use application middleware to
To allow both HTTP and HTTPS traffic for an application (which is the default) use tls:disable:
Application-specific IP Address Whitelisting
Developers and operators who need to control access to applications by IP
address, Workflow 2.5 makes this process much easier!
Using the CLI developers may manage IP whitelisting per application:
Adding a whitelist to an application automatically rejects connections from any
un-listed address. Removing the last IP address from a whitelist returns the
application to the default behavior, which accepts connections from any IP
Full Release Changelogs
Workflow 2.5 changes are now available in the Workflow
documentation. No more
crawling through GitHub repositories or past blog posts to learn about changes.
Our next release is scheduled for September 28th, 2016. You can check out the 2.6
milestone on each of the component repositories, or take a gander at the
Another two weeks, another Workflow release. The 2.3 release brings with it
some internal release changes, improved private registry support, tools to call
for help, and faster deploys. You might say Papa's got a brand new bag.
Happy Tuesday, I hope everyone had a wonderful weekend! Before we struck out
for fun in the weekend sun we cut a hot and fresh release of Workflow. Arriving
as version 2.1 we've got lots of fixes and a few goodies to boot.
I am proud to announce the first stable release of Deis Workflow. This means the Deis community now considers Workflow suitable for production deployments. Deis Workflow is the first PaaS built on Kubernetes to reach this milestone.
Deis Workflow is the new name for our open source PaaS, and is the second major version of what we are now calling Deis v1.
Deis v1 is trusted in production by hundreds of companies, including Mozilla, The RealReal, Hearst Corporation, and dozens of others.
What did we change in version two?
Well, the most significant thing we did was re-platform from CoreOS Fleet to Kubernetes. The switch to Kubernetes gives us a stable cluster manager, a better scheduler, a smaller overall footprint, and a great Kubernetes community to work with.
We are excited to announce that we have recently cut a beta release for the next major release of Deis! As many of you know, for 2.0 we’ve decided to re-platform the PaaS from CoreOS’s Fleet onto Kubernetes. This gives us a stable cluster manager, a better scheduler, a smaller overall footprint (potentially a single machine!), and a great Kubernetes community to work with. This lets us focus our efforts on making it as easy as possible to deploy and scale your applications.
To borrow from the late, great David Bowie, beta brings along with it some Ch-ch-ch-ch-changes!
Helm 0.3.0 was released last week, and 0.3.1 was released this week with a few minor bug fixes.
The 0.3 release line of Helm introduces several improvements to linting. It also introduces two new Helm commands: helm generate and helm template. These pave the way for generic template support in Helm, and provide a plugin architecture for implementing arbitrary template engines. Also, Helm charts now have a source: field for specifying a URL to the source used to create the chart's resources.
In addition to these new features, many bugs in the 0.2 release line have been found and fixed. Several parts of the codebase have been refactored for easier maintainability and better testing.
We at Deis are really excited about Kubernetes. In fact, we're hard at work building Deis v2 on top of a Kubernetes base. During this integration, we developed a tool that we think seasoned Kubernetes users will enjoy, and newcomers can use as an onramp for running containerized applications. And today, we're thrilled to announce this new tool.
We call it Helm, and it's the first package manager for Kubernetes.
Inspired by Homebrew, apt, and npm, Helm is a tool for working with Kubernetes-powered applications. It works like this:
A Helm package is bundled up as a chart.
The charts are collected together in a repository that you can search. Helm uses git under the hood for storing and organizing chart data.
Using the helm tool, you can find, customize, manage and install these charts.
Helm makes it easy run apps and services inside Kubernetes.
We built Helm to help with two things.
First, we want to make it simple to share information about running common apps and services inside of Kubernetes. When we all share our charts, the Kubernetes community at large learns how best to work with Kubernetes. We share information and discover great ways of doing things. And we also make it easier for newcomers to get going. Helm is about growing Kubernetes.
Second, we want to make it easier for teams to manage their Kubernetes manifest files. So we created a tool that eases the process of collaborating on and keeping track of your team's charts. Start with widely available charts, customize them to your team's needs, and then store them in your own version control. Helm is about helping teams.
Kubernetes is a powerful platform. We want to make it easy to manage the apps and services you deploy.
Deis v1.12 is scheduled for release on Tuesday, November 3. The major component of this release is upgrading the Docker client from 1.5 to v1.8.3. We have been looking to rev the Docker version for some time now, as the older image format has caused issues for some users. Please refer to the upgrade documentation to assist in your cluster migration.
A full list of items in this release will be provided on November 3.
In case you missed it, Deis announced a unique "code-for-credit" partnership with our friends at DigitalOcean. As part of this partnership, DigitalOcean will provide free hosting credits to developers who have code merged into the mainline Deis project.
When new contributors submit a pull request, they will be automatically provided information on how to collect and redeem DigitalOcean credits once the pull request is merged. The amount of credit received by each contributor will be based on the value of each contribution, as determined by the Deis project maintainers.
Welcome to the new Deis.com website. This site provides a place for the extended Deis community to meet, gather information, and work together as we move Deis into production across the industry.
Things are moving fast! Since OpDemand joined Engine Yard, we have:
Massively expanded the team working on Deis (2x, and still growing)
Deployed our global support team to care for Deis deployments 24/7
Launched Deis PRO, featuring improved UX for clusters of containers
The entire Deis.com effort will be focused on building, extending, and supporting the Deis open source project. We value the community’s input and will continue the open roadmap process on our community website: Deis.io.
This is an exciting turning point for Deis. It is already been established as the leading platform for deploying containerized applications, with almost one million downloads total and over 1,000 downloads per day. It’s clear that hundreds of technical teams are deploying applications with the ease of use and reliability of Deis.
To support the success of Deis in the market, Engine Yard is now providing full 24/7 support that spans the globe. The Engine Yard support team is one of the best in the industry and is made up of engineers with years of experience supporting real-world large-scale production deployments.
Take a look at Deis.com and check out Deis PRO, our web based deployment tool for Deis on Amazon AWS. Deis PRO also comes with a number of support services that help you take your application from concept to production.
With a transparent roadmap and project planning process, we are committed to an “upstream first” policy that recognises the importance of the open source community. If you have any questions about this, please get in touch!
It’s your app, your way. We’re here to make the ops easy and reliable.
Today we are excited to announce a new partnership with NYI, a colocation provider that is now offering Deis-on-metal solutions to customers in New York, New Jersey, and throughout the Northeast. As you may already know, Engine Yard’s Deis is the leading Docker-based Platform-as-a-Service (PaaS) for deploying and managing distributed applications. As Deis has matured, we’ve seen more and more users running on bare metal. We’ve also learned containers on metal offer significant price benefits, consistent performance, and a strong security and compliance story.
As part of this partnership, NYI is providing Engine Yard with the power, space, and dedicated servers for a distributed systems lab that will be used to harden Deis for large-scale colocation environments. This lab will allow us to test failure modes, network partitions, and performance deltas between Deis releases. The lab will also help ensure container on metal solutions meet customer standards for high-performance, scalability, and high-availability.
We are excited to work with the NYI team to see Deis and containers on metal reach its full potential. If you're interested in an in-person demo at an NYI facility, or just want to learn more about Deis and containers on metal, please contact our customer success team.