What are possible uses cases of chef-repo for me?


#1

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


#2

Look into “knife download /” and automating pulling down all that data
and putting it into a repository for backup.

I’d probably suggest that you have a chef-repo for humans to interact
with and change content and then have that uploaded to the server, then
have a chef-download repo where you keep backups and keep the two
responsibilities in separate repos. You could keep it all in one
location, but you’ll probably want to be pushing data from
roles/data_bags/etc into the servers, while pulling down
nodes/clients/etc from the server for backups, and you’ll need to work
out how to keep those responsibilities straight.

On 12/6/13 6:00 AM, Vladimir Skubriev wrote:

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?


#3

Check out “knife server backup” and “knife server restore” via the
knife-server plugin [1]

[1] http://fnichol.github.io/knife-server/
On Dec 6, 2013 6:32 PM, “Lamont Granquist” lamont@opscode.com wrote:

Look into “knife download /” and automating pulling down all that data and
putting it into a repository for backup.

I’d probably suggest that you have a chef-repo for humans to interact with
and change content and then have that uploaded to the server, then have a
chef-download repo where you keep backups and keep the two responsibilities
in separate repos. You could keep it all in one location, but you’ll
probably want to be pushing data from roles/data_bags/etc into the servers,
while pulling down nodes/clients/etc from the server for backups, and
you’ll need to work out how to keep those responsibilities straight.

On 12/6/13 6:00 AM, Vladimir Skubriev wrote:

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?