Find the official installation docs for v2.23 at teamhephy.com.
May 31, 2016 UPDATE: Jan 2, 2023
Deis Workflow is an open source Platform as a Service (PaaS) that makes it easy to deploy and manage applications on your own servers. Workflow builds on Kubernetes and Docker to provide a lightweight PaaS with a Heroku-inspired workflow.
Deis Workflow is the second major release of the Deis PaaS.
In this miniseries we’ll go over the basics of Deis Workflow. That includes: why you’d want to use Workflow, a conceptual overview, a look at architecture and components, and finally, how to install Workflow on a Kubernetes cluster.
There are five main reasons you might want to use Workflow:
Fast and easy. Supercharge your team with a platform that deploys applications as fast as you can create them. No Kubernetes knowledge is needed.
You can deploy anything. Deploy any language, framework, or Dockerfile with a simple
git push. Use
deis pull to move existing Docker images through your team’s development CI/CD pipeline.
Scale effortlessly. Your application can be scaled up or down with a single command that handles everything for you:
Open source. Avoid vendor lock-in with an open source platform that runs on public cloud, private cloud, or bare metal. Contribute to the project if you want to add features and help us set direction.
The latest technology. Benefit from the latest distributed systems technology thanks to a platform that is constantly evolving.
The Twelve-Factor app is a template for building modern applications that can be scaled across a distributed system. This approach is a distillation of years worth of experience working with Software as a Service (SaaS) apps on the Heroku platform.
Workflow, like most Platforms as a Service, is designed to run applications that adhere to the Twelve-Factor App approach. However, legacy apps can still run on Deis. They just need some extra attention to get things working.
Docker is an open source project to build, ship, and run any application as a lightweight, portable, self-sufficient container.
If you have not yet converted your application to containers, Workflow provides a simple and straightforward “source to Docker image” capability.
Because Workflow supports multiple language runtimes via Heroku buildpacks, building your app in a container can be as easy as
git push deis master.
Applications packaged via a Heroku buildpack are run in Docker containers as part of the slugrunner process. Applications which use either a Dockerfile or reference an external Docker Image are launched unmodified.
Kubernetes is an open-source cluster manager developed by Google and donated to the Cloud Native Compute Foundation. Kubernetes manages all the activity on your cluster, including: desired state convergence, stable service addresses, health monitoring, service discovery, and DNS resolution.
Workflow builds on Kubernetes, leveraging this functionality to provide simple, developer-friendly app deployment.
Workflow is shipped as a Kubernetes-native application. It’s installable via Helm Classic so systems engineers and operators familiar with Kubernetes will feel right at home running Workflow.
The platform and your applications run in dedicated Kubernetes namespaces, nicely separating workloads.
Using Kubernetes services and replication controllers, Workflow deploys new versions of your app with zero downtime.
If you have workloads that aren’t managed by Workflow, you can easily connect them through Kubernetes’ baked in service discovery.
Workflow is designed around the concept of an application, or app.
Apps can come in three forms:
Apps are identified by a unique name, for easy reference. If you do not specify a name when creating your app, Workflow generates one for you.
Workflow also tracks other app information, including domain names, SSL certificates, and other config provided via environment variables.
The diagram below shows the App’s workflow:
The builder component processes incoming
git push deis master requests and manages your application packaging. Like so:
New releases are created every time a new build is created or application configuration is changed.
So, for example, you could alter your config like so:
$ deis config:set REDIS_MASTER_SERVICE_HOST=redis-master.default -a guestbook
When you do this, Workflow will build, release, and run a new version of the app with that config. And by “version”, we mean: every release is assigned a version number. Versioning every release makes it easy to roll back to any previous release.
The run stage is responsible for deploying the new release to the underlying Kubernetes cluster.
The run stage launches a new replication controller which references the new release. By managing the desired replica count, Workflow orchestrates a zero-downtime, rolling update of your application. Once successfully updated, Workflow removes the last references to the old release.
That during the deploy, your application will be running in a mixed mode. The old and the new replication controllers will run at the same. When the new version of your app is up and running, the old replication controller is stopped.
Workflow treats all persistent services (such as databases, caches, storage, messaging systems, and other backing services) as resources managed separately from your application. This aligns with the Twelve-Factor approach.
Applications are attached to backing services using environment variables.
Because applications are decoupled from backing services, apps are free to scale up independently, to use services provided by other apps, or to switch to external or third-party vendor services.
Helm Classic, the package manager for Kubernetes, is a great way to install and set up some of those backing services.
Deis Workflow is a Heroku-inspired Platform as a Service that builds on Kubernetes and Docker. It is fast and easy to use. You can deploy anything you like. Release are versioned and rollbacks are simple. You can scale up and down effortlessly. And it is 100% open source, using the latest distributed systems technology
In part two of this miniseries, we’ll look at how Workflow is architected and composed from multiple independent components.