The Kubernetes-native platform (v2).
The Package manager for Kubernetes.
The Kubernetes-native Service Broker.
A variety of Deis Workflow components rely on an object storage system to do their work including storing application slugs, Docker images and database logs.
Deis Workflow ships with Minio by default, which provides in-cluster, ephemeral object storage. This means that if the Minio server crashes, all data will be lost. Therefore, Minio should be used for development or testing only.
Every component that relies on object storage uses two inputs for configuration:
The helm chart for Deis Workflow can be easily configured to connect Workflow components to off-cluster object storage. Deis Workflow currently supports Google Compute Storage, Amazon S3, Azure Blob Storage and OpenStack Swift Storage.
Create storage buckets for each of the Workflow subsystems:
Depending on your chosen object storage you may need to provide globally unique bucket names.
If you provide credentials with sufficient access to the underlying storage, Workflow components will create the buckets if they do not exist.
If applicable, generate credentials that have create and write access to the storage buckets created in Step 1.
If you are using AWS S3 and your Kubernetes nodes are configured with appropriate IAM API keys via InstanceRoles, you do not need to create API credentials. Do, however, validate that the InstanceRole has appropriate permissions to the configured buckets!
If you haven't already added the Helm repo, do so with
helm repo add deis https://charts.deis.com/workflow
Operators should configure object storage by editing the Helm values file before running
helm install. To do so:
helm inspect values deis/workflow | sed -n '1!p' > values.yaml
global/storageparameter to reference the platform you are using, e.g.
You do not need to base64 encode any of these values as Helm will handle encoding automatically.
You are now ready to run
helm install deis/workflow --namespace deis -f values.yaml using your desired object storage.