| Lots of good information here but it is still not enough for a production setup IMHO. There is a great need of good source of production setups. In open source software this seems to be the secret that no one is willing to reveal. I tried to setup a kubernetes cluster from scratch a while ago and soon I was browsing the source code for answers. Openstack is the same, you need to understand a lot about the inner workings before you can even attempt to setup something for production. There is always a simple "this shell script starts your own <name your tech here> cluster in vagrant" but it is still not a production setup. And even if this article is the "hard way" it describes: > This is being done for ease of use. In production you should strongly consider generating individual TLS certificates for each component." And it does not mention that the crucial part is the common name field in the certificate maps to the user name that is the magic information that I once needed. I sincerely appreciate this article but production setup is still a long learning experience away. |
- If it's too easy to set up, nobody will hire us to make it work.
- Implement a kickass setup dirt cheap for some big-name company, so we can claim they use it in production. Yeah we tweaked it so it bears little resemblance to the original product, and only fits an incredibly narrow use case, but nobody stands to benefit from blogging about that.
- Better ship with a configuration file that isn't production ready.
- Did I say one? Better have three configuration files, each duplicated in distribution-dependent directories (in some cases), needing manual sync between servers to prevent catastrophic data loss.
- Remember not to publish the program that checks for errors in configuration; half of our income would disappear.
- Benchmark with a configuration file that nobody would use in production, but looks really impressive when taken out of context.
- People want transactions, remember to claim support (and if you must, explain somewhere in the fine print that a transaction can only span a single operation on exactly one document, and btw. is precisely none of A, C, I or D).
- Somewhere on the front page, it should say how we can support petabytes of data (and it performs very well, as long as you write all your data in one batch, never modify it, keep it all in memory, and turn off persistence).
- Never give away answers online. Answer every question about configuration with "it depends".
- Don't release a new version without renaming a few configuration options. Be "backwards compatible" by ignoring unknown, obsolete and misspelled options.