- From: Vladimir Skubriev <
>
- To:
- Subject: [chef] What are possible uses cases of chef-repo for me ?
- Date: Fri, 06 Dec 2013 18:00:22 +0400
I think that all chef server must be easily recovers, then we need in
chef-repo all necessary information.
By default I have all, but without attention to the documentation remain
clients, nodes(most dynamic essence's in infrastructure automation) and
users.
For example we lost chef-server and it's information. What's next?
We have boostrapped clients to old server. How to quickly bootstrap them
again with a new server?
I can create an existing chef-server with chef-solo and chef-server
installation recipe very fastly.
But what's next ?
I must remember (or view my notes) nodes fqdn's for bootstrap them.
Bootstrap them. Set them runlists. Regenerate chef-vault databags with
new public keys of nodes.
Why not script this in some files? What do you think?
And place this files in chef-repo git, but exclude them for upload to
chef-server(chefignore), and add them to git (git add .chefvault, git
add .chefclients and somthing else)
I read about spiceweasel, but I think that it mostly for deploy some
separately clusters with a copule of nodes fastly in a one command.
Unlike my case - Is gradually develop their infrastructure and keep
everything in one place in VCS.
What other pitfalls there when you reinstall the chef-server from
scratch with existing chef-repo ?
Or may be more sensible question how to store node information in
chef-repo ?
Because I want to store everything about our infrastructure in one
place. Why not ?
Why I must think every time about what and where is placed. I think this
is a horror.
When you necessary data is distributed over several programs, formats,
places etc.
For example now I used keepassx for store passwords, Using chef data
bags to store the same passwords instead of store all sensitive
information in a one place under VCS?
--
Best regards,
CVision Lab System Administrator
Vladmir Skubriev
- [chef] What are possible uses cases of chef-repo for me ?, Vladimir Skubriev, 12/06/2013
Archive powered by MHonArc 2.6.16.