In che modo Juju "coesiste" con Chef, portando il processo di automazione "un passo avanti"?

Da questo post è chiaro che Juju si trova ad un livello diverso rispetto a Chef Server. Juju si trova a livello di orchestrazione o di servizio , mentre Chef si siede maggiormente sul singolo server o livello di configurazione .

In una delle principali pagine di Juju di Canonical , si afferma che Juju è progettato per "coesistere" con strumenti come Chef e Puppet, portando il processo "un passo avanti". Ho analizzato Internet nelle ultime settimane su questo argomento e non riesco a trovare una buona spiegazione di come , tuttavia, uno strumento come Chef coesisterà con Juju.

Quindi, per scomporre la domanda generale nel titolo: (particolare interesse per Juju a lavorare insieme con uno Chef Server)

• Qual è un esempio di fascino "scritto in Chef"? È semplicemente un incantesimo scritto in bash che poi chiama il chef-solocomando? Se è così, un incantatore può chiamare il chef-clientcomando per lavorare di concerto con un Chef Server?
• Dov'è la sovrapposizione tra Juju e Chef? Ad esempio, il fascino di apache2 ha il suo config-changedgancio in cui apporta modifiche di configurazione che, nel mondo dello Chef, avrebbero luogo in una ricetta applicando un file modello. Se un incantesimo Juju dovesse funzionare insieme a un libro di cucina dello Chef sulla distribuzione di un servizio apache2 (cluster) sembrerebbe quasi che un incantesimo "chef apache2" dovrebbe essere scritto in modo da poter separare i compiti. In questo caso, il fascino di apache2 nel Charm Store sarebbe poco utile.
• Se hai ruoli Chef applicati a nodi (unità di servizio) distribuiti / gestiti da Juju e il tuo amministratore di sistema decide di modificare le regole del firewall per un particolare ruolo del server e lo fa nel ruolo Chef, Juju sovrascriverà mai quelle modifiche?
• Più semplicemente, Juju può essere un wrapper Chef Server, come Ironfan ?

Considero Chef Server come il come, mentre Juju può fare il come , ma porta anche ciò che è sul tavolo. Ciò significa che è possibile interrogare e agire sul reale stato attuale dei servizi e delle macchine. Non puoi farlo in Chef Server. Il mio obiettivo è portare la consapevolezza di Juju e la capacità di orchestrazione del servizio in un'infrastruttura gestita da Chef Server.

Sembra quasi che debba essere scritto un intero set di incantesimi in cui tutte le attività / informazioni di configurazione gestite dallo Chef vengono tralasciate.

Mi piacerebbe sentire le opinioni di qualcuno di Canonical (come Jorge Castro) e di Opscode (come A. Jacob o J. Timberman).

domande fantastiche!

il tl; dr

Vorrei dividere le tue domande su un paio di commenti ... prima di tutto, ecco un paio di approcci generali per l'integrazione di chef e juju:

• i ganci per ciondoli possono utilizzare ricette chef esistenti che eseguono lo stile solo su unità di servizio (consigliato)

• le unità di servizio juju si registrano con uno chef-server esistente usando un servizio subordinato chef-node

Queste idee non sono ancora state implementate / testate per lo chef, ma esistono equivalenti di marionette.

la risposta ... non così breve

Ecco un po 'più di una ripartizione di due approcci per l'integrazione di chef e juju:

Juju come top-dog

Qui juju gestisce lo spettacolo. Il valore più grande che juju fornisce è il coordinamento degli eventi durante la gestione della configurazione distribuita ... da qui il moniker "orchestrazione di servizio". Gli incantesimi Juju sono costituiti da ganci che vengono chiamati da juju "al momento giusto" durante il coordinamento della gestione dei servizi. L'implementazione di questi hook è praticamente aperta. Sono script di shell, codice sorgente, manifest di marionette o ... ricette di chef.

Juju suddivide parti di qualsiasi servizio configurato in:

• "installazione" .. i bit specifici per l'installazione di un particolare servizio su un nodo

• "relazione" .. i bit di configurazione necessari per mettere in relazione quel servizio con qualche altro servizio

La chiave per utilizzare le ricette dello chef come implementazioni hook è esattamente questo ... devi assicurarti che le ricette che stai utilizzando rispettino questa separazione delle preoccupazioni. Altrimenti, non c'è nulla che impedisca l'uso di libri di cucina pronti all'uso. Puoi sfruttare le ricette esistenti che hai impiegato tempo / denaro per sviluppare .... Devi solo assicurarti di poter chiamare le cose specifiche della relazione separatamente dalle cose specifiche dell'installazione.

Abbiamo bisogno di alcuni esempi di questo, ma penso che sarà popolare lo chef b / c ha un ottimo dsl, un ottimo strumento di templating ed è molto più piacevole da usare rispetto a bash quando si scrive una configurazione complessa. Per una semplice configurazione, le ricette dello chef sono un po 'eccessive, quindi questo metodo di integrazione è praticamente il migliore di entrambi i mondi ... e ha delle gambe serie che vanno avanti.

Chef come top-dog

L'idea qui è quella di integrare i servizi juju in un'infrastruttura gestita chef-server esistente. Per fare ciò, dovresti scrivere un incantesimo subordinato chef-nodo. Questo servizio subordinato verrebbe collegato ai servizi juju primari e registrerebbe effettivamente questi servizi come nodi (in ruoli particolari) con il server chef. I componenti secondari possono essere collegati all'avvio del servizio juju o in qualsiasi momento durante il ciclo di vita di ciascun servizio.

Sto pensando che sarebbe abbastanza simile al sub-burattino-nodo. Tutte le chiavi, i ruoli, ecc. Necessari sarebbero specificati tramite la configurazione del fascino subordinato chef-nodo. Vorrei iniziare da lì. Un approccio più sofisticato sarebbe per il sub-chef-nodo di interrogare sia il servizio principale a cui è collegato sia il suo chef-server per determinare dinamicamente i ruoli, ma sarebbe un po 'più difficile che specificarli nella configurazione per il sub.

opinioni

Consiglio vivamente il metodo 1 sopra, se possibile. Avere il livello di coordinamento sopra gli strumenti di configurazione probabilmente funzionerà bene a lungo termine. Inutile dire che le infrastrutture del mondo reale potrebbero essere una combinazione o una variazione di entrambi gli approcci per un periodo di tempo ... specialmente durante la migrazione. La coesistenza pianificata con il metodo 2 funzionerebbe probabilmente solo se i componenti gestiti da entrambi gli strumenti fossero in qualche modo ortogonali tra loro. Non sono sicuro di come sarebbe. Forse juju e chef gestiscono servizi separati relativamente disaccoppiati? Ho il sospetto che potrebbe funzionare bene per consentire a Juju di gestire i servizi primari e far sì che lo chef gestisca più aspetti dell'infrastruttura. Boh. Questa è una discussione un po 'più lunga :)

Nota a margine ... puoi anche usare juju per gestire lo stesso chef-server ... anche grandi installazioni complesse per chef-server. Ultimamente non ho guardato il fascino dello chef-server, ma se attualmente non gestisce la suddivisione in livelli e la separazione dei servizi, allora può sicuramente essere fatto.

Mi piacerebbe vedere altri esempi di entrambi i tipi di integrazione dello chef menzionati sopra ... è stato nella mia lista dei desideri / cose da fare per un po ', ma deve ancora saltare abbastanza in alto in priorità per essere fatto ... per favore aiutatemi se sei interessato!

ok, questa è una buona dose di sconclusioni:) ... cominciamo da lì, quindi possiamo andare più in dettaglio nei blocchi di commenti successivi.