Meta issue-- production deployments

[krancour]

This page is currently a placeholder: https://github.com/deis/docs-v2/blob/master/src/managing-workflow/production-deployments.md

I want to start a simple checklist here of recommendations we must document for anyone wishing to run Workflow in production. I invite others to edit this.

• Must: Use off-cluster object storage (or else everything is ephemeral!). Should include a link to object storage configuration page.
• Recommended: Use off-cluster Postgres?
• Highly recommended: Secure the Workflow cluster using an SSL wildcard cert
• Recommended: Generate a unique dhparam for the router (to further harden Diffie Hellman key exchange)

Do we want to make any recommendations re: the k8s clusters themselves? Or is this not our concern? Example: speaking to @slack today, I believe we intend in our dog-fooding cluster to have the k8s worker nodes live in private subnets. I don't know of any pre-baked zero-to-k8s solutions that account for that... so is it worth mentioning? Or maybe is it worth having a whole separate checklist for things like this and articulating that "A Deis Workflow cluster is only as good as the Kubernetes cluster you run it on. Here are some considerations..."

Discuss... discuss...

[bacongobbler]

for reference, I PR'd #141 that tackles a few of these concepts by porting over most of the v1 documentation. So far to address your points:

Use off-cluster object storage (or else everything is ephemeral!). Should include a link to object storage configuration page.

Done, however we should really have another document that explains how to use RDS and S3.

Recommended: Use off-cluster Postgres?

Related to point 1 ^^

Highly recommended: Secure the Workflow cluster using an SSL wildcard cert

That's been ported over :)

Recommended: Generate a unique dhparam for the router (to further harden Diffie Hellman key exchange)

That has not been documented, though if you have any input or could point to some documentation on how one would go and generate their own unique dhparam, that would be greatly appreciated.

As for recommendations on how the network topology should work, I think we need to "sip our own champagne" first and figure out how we want to handle that internally before recommending topology best practices.

[jchauncey]

moving to rc1

[sstarcher]

#199 would help out the s3 folks who are on aws

[bacongobbler]

Once that's implemented, yes we can add that to this doc.

[arschles]

#180 would also help AWS folks

[jgmize]

The Cluster Ops SIG has started on an early draft of a reference architecture doc that may be helpful for this. The document and subsequent discussion was heavily informed by the ideas in coreos/coreos-kubernetes#340 but aims to be more generic. If anyone is interested in participating, please make suggestions on the document, or even better join some of the weekly public meetings for live discussion. Ideally this collaboration would result in improvements to the admin guide and the Deis docs could link to that where appropriate and focus on Deis specifics.

[vdice]

This ongoing meta ticket will be moved to the v2.0 milestone

[bacongobbler]

This was actually finished in #141 but it didn't close this issue. Anyone can now make PRs against that doc or open separate issues to address their use case. Closing!