Deis Workflow is a lightweight application platform that deploys and scales Twelve-Factor apps as containers across a Kubernetes cluster.
The Twelve-Factor App is a methodology for building modern applications that can be scaled across a distributed system.
We consider it an invaluable synthesis of much experience with software-as-a-service apps in the wild, especially on the Heroku platform.
Workflow is designed to run applications that adhere to the Twelve-Factor App methodology and best practices.
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 upon Kubernetes abstractions like Services, Replication Controllers and Pods to provide a developer-friendly UX, source to image, log aggregation, etc.
Workflow is shipped as a Kubernetes-native application, installable via Helm, so operators familiar with Kubernetes will feel right at home running Workflow.
For a detailed overview of Workflow components, see our component break down.
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. Supporting
multiple language runtimes via community buildpacks, building your application
in a container can be as easy as git push deis master.
Applications which are packaged via a buildpack are run in Docker containers as
part of the slugrunner process. View the slugrunner compoent
for more information.
Applications which use either a Dockerfile or reference an external Docker Image are launched unmodified.
Workflow is designed around the concept of an application, or app.
Applications can come in three forms:
- as collection of source files stored in a Git repository
- as a Dockerfile, which describes how to build your app
- a reference to an already built Docker Image, hosted on a remote Docker repository
Applications identified by a unique name for easy reference. If you do not specify a name when creating your application Workflow generates one for you. Workflow also tracks other related information for your application including any domain names, SSL Certificates and developer provided configuration.
The builder component processes incoming git push deis master requests
and manages your application packaging.
If your application is using a [buildpack][] builder will launch an ephemeral job to extract and execute the packaging instructions. The resulting application artifact is stored by the platform for execution during the run stage.
If instead, you provide a Dockerfile builder will use the instructions you have provided to build a Docker Image. The resulting artifact is stored in a Deis-managed registry which will be referenced during the run stage.
If you already have an external system building your application container you can simply reference that artifact. When using external Docker images the builder component doesn't attempt to repackage your app.
During the release stage, a build is combined with application configuration to create a new numbered release. New releases are created any time a new build is created or application configuration is changed. Tracking releases makes it easy to rollback 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 reference to the old release. Note that during the deploy, your application will be running in a mixed mode.
Workflow treats all persistent services such as databases, caches, storage, messaging systems, and other backing services as resources managed separtely from your application. This philosophy aligns with Twelve-Factor best practices.
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.