Deis Workflow's controller component relies on a PostgreSQL database to store platform state.
By default, Deis Workflow ships with the database component, which provides an in-cluster PostgreSQL database backed up to in-cluster or off-cluster object storage. Currently, for object storage, which is utilized by several Workflow components, only off-cluster solutions such as S3 or GCS are recommended in production environments. Experience has shown that many operators already opting for off-cluster object storage similarly prefer to host Postgres off-cluster as well, using Amazon RDS or similar. When excercising both options, a Workflow installation becomes entirely stateless, and is thus restored or rebuilt with greater ease should the need ever arise.
First, provision a PostgreSQL RDBMS using the cloud provider or other infrastructure of your choice. Take care to ensure that security groups or other firewall rules will permit connectivity from your Kubernetes worker nodes, any of which may play host to the Workflow controller component.
Take note of the following:
Within the off-cluster RDBMS, manually provision the following:
If you are able to log into the RDBMS as a superuser or a user with appropriate permissions, this process will typically look like this:
$ psql -h <host> -p <port> -d postgres -U <"postgres" or your own username> > create user <deis username; typically "deis"> with password '<password>'; > create database <database name; typically "deis"> with owner <deis username>; > \q
The Helm Classic chart for Deis Workflow can be easily configured to connect the Workflow controller component to an off-cluster PostgreSQL database.
helmc fetch deis/workflow-v2.7.0
tpl/generate_params.toml. Note that environment variables take precedence over settings in
DATABASE_HOSTto the hostname or public IP of your off-cluster PostgreSQL RDBMS.
DATABASE_PORTto the port listened to by your off-cluster PostgreSQL RDBMS-- typically
DATABASE_NAMEto the name of the database provisioned for use by Workflow's controller component-- typically
DATABASE_USERNAMEto the username of the database user that owns the database-- typically
DATABASE_PASSWORDto the password for the database user that owns the database.
helmc edit workflow-v2.7.0and look for the template file
[database]configuration section to properly reflect all connection details.
tpl/generate_params.toml, you do not need to (and must not) base64 encode any values, as the Helm Classic chart will automatically handle encoding as necessary.
helmc generate -x manifests workflow-v2.7.0
manifestsdirectory. You should see:
deis-controller-deployment.yamlcontains relevant connection details.
deis-database-secret-creds.yamlexists and contains base64 encoded database username and password.
You are now ready to
helmc install workflow-v2.7.0 as usual.