Workflow is comprised of a number of small, independent services that combine to create a distributed PaaS. All Workflow components are deployed as services (and associated controllers) in your Kubernetes cluster. If you are interested we have a more detailed exploration of the [Workflow architecture][architecture.md].
All of the componentry for Workflow is built with composability in mind. If you need to customize one of the components for your specific deployment or need the functionality in your own project we invite you to give it a shot!
The controller component is an HTTP API server. Among other functions, the
controller contains the scheduler, which decides where to run app containers.
The deis command-line client interacts with this component.
The database component is a PostgreSQL server used to store durable platform state. Backups and WAL logs are pushed to the Store through WAL-E. When the database is restarted, backups are fetched and replayed from Store so no data is lost.
The builder component uses a Git server to process Application builds. The builder:
- Receives incoming
git pushrequests over SSH - Authenticates the user via SSH key fingerprint
- Authorizes the user's access to write to the Git repository
- Builds a new
Dockerimage from the updated git repository - Adds the latest Config to the resulting Docker image
- Pushes the new Docker image to the platform's Registry
- Triggers a new Release through the Controller
!!! note The builder component does not incorporate Config directly into the images it produces. A Release is a pairing of an application image with application configuration maintained separately in the Deis Database. Once a new Release is generated, a new set of containers is deployed across the platform automatically.
The registry component hosts Docker images on behalf of the platform. Image data is stored by Store.
The router component uses Nginx to route traffic to application containers.
The Store component uses Minio by default to store data for Deis components which need to store state, including the Registry and the Database.
If you are using Minio as the Store, it is highly recommended that the Store's data is backed by a persistent volume in the event of complete failure. See Backing up and Restoring Data for more information.