Gestisci i libri di cucina per chef in un ambiente di squadra

Sto imparando lo chef e ho problemi a strutturare tutto per lavorare con il mio team.

Per i principianti, sembra che dovresti creare una cartella chef-repo, in cui archiverai e modificherai i libri di cucina usati per gestire i tuoi nodi.

Lavoro a vari progetti, e ognuno di essi è già sotto il controllo di Git Source. Idealmente, terrei una cartella chef-repo in ognuno dei miei progetti con quei libri di cucina, giusto?

Tuttavia, nella cartella chef-repo devo aggiungere una cartella di configurazione (.chef) con la mia configurazione di coltello e le mie convalide chiave, e queste sono specifiche per me. È normale aggiungere la cartella .chef al file gitignore?

Comprendo che i libri di cucina vengono caricati sul server chef per poi essere distribuiti. In che modo gli altri team separano la stadiazione dagli ambienti di produzione senza duplicare molto lavoro? Abbiamo una filiale principale che è la nostra filiale di produzione, una filiale di sviluppo che è la nostra filiale di gestione temporanea (riceve meno del 5% delle richieste del sito Web) e filiali di funzionalità. Il più delle volte, il ramo dev quando stable viene unito al ramo master. Come possiamo caricare i libri di cucina separatamente per poter avere due ambienti in modo separato?

Grazie per l'aiuto!

Lavoro con più progetti, quindi la soluzione di cjc non funzionerà per me. C'è anche un problema di configurazione comune vs personalizzata (gli indirizzi, ecc. Sono comuni all'azienda, c'è anche un po 'di magia nelle configurazioni). Lo schema su cui ho finalmente deciso è un po 'un trucco, ma è conveniente da usare.

Invece di globale ~/.chef, uso la sottodirectory '.chef' all'interno di chef-repo, che non è memorizzata in git (è aggiunta a .gitignore). Ho anche file di config/knife.rbfile che è registrato in Git e contiene una configurazione condivisa. Si inizia con questo frammento:

root_dir = File.join(File.dirname(__FILE__), '..')
%w(knife-secrets.rb knife-local.rb).each do |conf_name|
  conf = File.join(root_dir, ".chef", conf_name)
  Kernel::load(conf) if File.exists? conf
end

Carica file .chef/knife-local.rbcontenenti una configurazione personalizzata (nella versione base è solo una OPSCODE_USER='username'costante che verrà utilizzata in seguito, ma può contenere qualsiasi configurazione di coltello) e .chef/knife-secrets.rbche contiene segreti condivisi (chiavi AWS ecc.).

Al di sotto di questo, vi è una configurazione di coltello regolare che utilizza costanti definite in questi file, ad esempio:

client_key               "#{root_dir}/.chef/#{OPSCODE_USER}.pem"

In questo modo, ottengo la standardizzazione della configurazione dei coltelli in tutta l'azienda, il che a sua volta significa che qualsiasi frammento di codice o invocazione di coltelli condivisa in un wiki funzionerà per tutti. C'è abbastanza confusione e magia nel coltello stesso: configurazioni diverse non farebbero altro che peggiorare. Inoltre, tutti beneficiano di piccoli frammenti magici, come questo per knife sshutilizzare l'accesso configurato nell'utente~/.ssh/config

C'è anche un problema di segreti condivisi: chiave di convalida di chef server, chiavi AWS archiviate knife-secrets.rb, chiave privata SSH di EC2, chiavi di data bag crittografate e così via. Non vogliamo assolutamente che vengano archiviati nel repository o, in realtà, ovunque non siano crittografati in modo sicuro. Quindi distribuiamo questi file come .tar.gzfile, che è crittografato con GPG a tutti gli utenti dell'azienda e condiviso su Dropbox.

Configurare tutto questo sta diventando complicato e voglio che le persone del team utilizzino effettivamente la cosa, quindi c'è l'ultimo elemento: rake initattività che crea .chefdirectory, config/knife.rbcollegamenti simbolici lì, decodifica e decomprime il chef-secrets.tgzfile, si assicura che la chiave della piattaforma Opscode privata dell'utente sia lì e .chef/knife-local.rbsia correttamente configurato, collega i plug-in al coltello e imposta le autorizzazioni appropriate sulla directory e sui file all'interno. Questa attività è impostata in modo da poter essere eseguita in modo sicuro più volte su un repository già inizializzato (ad es. Per aggiornare segreti o plugin di coltello).

C'è anche un'attività di supporto che reimballa tutti i segreti, crittografa il tarball per tutti e lo copia in dropbox, per facilitare l'aggiunta di nuovi dipendenti o la modifica di segreti.

Per quanto riguarda più ambienti: Chef ha una funzione chiamata ambienti . Non l'ho ancora usato, ma dovrebbe fare quello che ti serve. È inoltre possibile separare rigorosamente l'ambiente di produzione (per evitare che gli sviluppatori dispongano di qualsiasi chiave correlata in qualche modo all'ambiente di produzione) disponendo di due organizzazioni Hosted Chef o Server Chef separati. Questo frammento di knife.rb mostra come configurare il coltello in un modo diverso in base al ramo attualmente estratto: puoi usarlo per impostare l'ambiente e l'URL del server chef. C'è anche un plugin per coltelli chiamato coltello-flusso , che fornisce un flusso di lavoro più completo, a due organizzazioni.

È necessario configurare due server Chef, uno per la produzione e uno per lo sviluppo. Il motivo è che nessun singolo server Chef può supportare lo sviluppo ramificato; anche con gli ambienti.

Oppure puoi abbandonare il concetto di server Chef e utilizzare chef-solo. Puoi conservare i tuoi libri di cucina in Git. Puoi ramificare e unire. Puoi ignorare i problemi con le credenziali del coltello perché non li userai più.

Non sarai in grado di utilizzare la ricerca dei coltelli o i data bag **. Ma alcune persone non hanno bisogno di quelle funzionalità comunque.

** Beh, in un certo senso puoi: http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

Ho due directory nella mia casa, .chef e chef-repo. Lo chef-repo è pronto. .Chef è una directory privata che è l'impostazione predefinita per il coltello. Non devi mettere i tuoi segreti da .chef in git; il coltello cercherà ~ / .chef.

La directory ~ / .chef non dovrebbe trovarsi nel repository git.

Ho una directory ~ / projects / sotto la quale conservo il repo del mio chef. In questo vanno le configurazioni dei miei server.

Il mio ultimo lavoro è stato come ingegnere di sistemi presso il negozio Ruby-on-Rails. Le nostre configurazioni nginx, vernice e rotaie (tra le altre) vanno nel repository chef, ma le app Rails stesse sono state conservate in repository git separati e sono state distribuite separatamente.

Il nostro ambiente di gestione temporanea era un singolo server che eseguiva l'intero ambiente di gestione temporanea. Questo non era l'ideale perché non assomigliava alla produzione dove Rails si assottigliava e il DB era su scatole separate. Quello che consiglierei è usare gli ambienti dello chef per separare la stadiazione e la produzione. (È così quando sono arrivato lì, e non ho il tempo di sistemarlo prima di partire.)