-
Notifications
You must be signed in to change notification settings - Fork 181
Meta issue-- production deployments #79
Comments
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:
Done, however we should really have another document that explains how to use RDS and S3.
Related to point 1 ^^
That's been ported over :)
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. |
moving to rc1 |
#199 would help out the s3 folks who are on aws |
Once that's implemented, yes we can add that to this doc. |
#180 would also help AWS folks |
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. |
This ongoing meta ticket will be moved to the |
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! |
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.
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...
The text was updated successfully, but these errors were encountered: