Gli strumenti di gestione della configurazione sono appropriati da utilizzare come strumenti di distribuzione?

Sul retro della mia risposta alla domanda: in che modo DevOps può aiutare a migliorare le procedure di impegno software? Tensibai aveva la domanda:

Cosa richiederebbe Capistrano in cima al burattino o allo chef?

La mia risposta è stata quella di pubblicare un link all'articolo di Noah Gibbs "Abbiamo bisogno sia di Capistrano che di Chef?" . Personalmente, sottoscrivo ancora l'opinione di Noè secondo cui è più appropriato:

• utilizzare uno strumento di distribuzione specializzato come Capistrano per le distribuzioni.
• utilizzare uno strumento di gestione della configurazione specializzato come Chef per la gestione della configurazione.

L'approccio fondamentale che ogni tipo di strumento utilizza per completare il suo compito è molto diverso:

• Strumenti di gestione della configurazione : riguardano la creazione e il mantenimento dello stato desiderato di un sistema, sono intrinsecamente idempotenti in natura. Esempi di strumenti di gestione della configurazione sono Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

• Strumenti di distribuzione : si tratta di distribuire versioni di software in un ambiente di hosting, forniscono funzionalità per mantenere più versioni del software su più macchine e gestire quale versione è "attuale", sono intrinsecamente di natura imperativa. Esempi di strumenti di distribuzione sono Capistrano , Octopus Deploy , Deployer e Command.io .

Credo che gli strumenti di gestione della configurazione possano svolgere il lavoro di strumenti di distribuzione e nel caso di Immutable Infrastructure siano lo strumento più appropriato per il lavoro poiché non è necessario mantenere le versioni del software sulla destinazione.

Domanda: gli strumenti di gestione della configurazione come Chef, Ansible e Puppet sono maturati al punto da essere in grado di soddisfare sia i modelli idempotenti sia quelli imperativi?

In tale contesto, la consulenza tipica dovrebbe essere immediatamente applicabile: utilizzare lo strumento giusto per il lavoro.

Ma poi non puoi nemmeno ignorare al giorno d'oggi la tendenza quasi virulenta degli strumenti software di estendere la funzionalità in campi più o meno correlati e diventare effettivamente set di strumenti per vari motivi: caratteristiche interessanti da avere, espandere la base di clienti, accumulare più entrate, ecc.

Ad esempio, molti strumenti di gestione dei file includono funzionalità di visualizzazione delle immagini e molti strumenti di elaborazione delle immagini includono funzionalità di gestione dei file. Puoi spostare i file e visualizzare le immagini con uno degli strumenti, spesso ugualmente bene.

Per questo motivo è possibile che intere parti del processo di sviluppo del software siano coperte / sovrapposte da più strumenti (set) anche se le loro caratteristiche / capacità principali differiscono.

Quindi si riduce davvero all'esatta funzionalità che vuoi ottenere nel tuo particolare processo e quanto bene uno strumento o l'altro fa il lavoro nel tuo contesto . Soggettività / preferenze / convenienza incluse.

Rendere questa domanda principalmente basata sull'opinione;)

Gli strumenti di gestione della configurazione vengono utilizzati per portare un sistema in uno stato noto. Gli strumenti di distribuzione distribuiscono nuovi file di programma e dati di programma su un sistema. Alla fine della giornata, entrambi i tipi di strumenti combinano:

• Determina lo stato corrente del sistema.
• Trasferisci file sul sistema.
• Aggiungi o modifica i dati persistenti (ad es. File di configurazione, dati del database, impostazioni del registro)
• Avvia o riavvia i programmi.

Gli strumenti di gestione della configurazione hanno linguaggi dichiarativi che specificano lo stato del sistema. Gli strumenti di distribuzione hanno linguaggi imperativi che dicono al sistema di fare le cose. Una persona DevOps deve fare entrambe le cose.

Utilizzando lo strumento di distribuzione Capistrano, è goffo usare la sua lingua per dire al sistema di assicurarsi che il web server sia attivo. È necessario emettere un comando per riavviare il server Web e un altro per verificare se il server Web è attivo. È un kludge portare il web server in uno stato noto.

Usando lo strumento di gestione della configurazione Ansible, è difficile riavviare un server web. La lingua consente di indicare al server Web di essere "attivo", ma se si desidera specificamente che venga riavviato, è necessario impostare lo stato su "riavviato". Ma non esiste un modo semplice per verificare se il server Web è stato riavviato. Questo è un kludge in Ansible per abilitare operazioni una tantum.

Alcune persone preferiscono fare entrambi i tipi di lavori con un solo strumento e lavorare intorno ai bordi grezzi. Altre persone preferiscono avere due strumenti per fare quasi la stessa cosa, ma senza bordi irregolari. Per rispondere alla domanda, "adeguatezza" è una questione di gusti. Questa risposta spiega perché.

TL; DR : basta usare Ansbile, è sia uno strumento di configurazione che di distribuzione :)

Esistono diversi tipi di distribuzione:

• Basato su applicazioni (file, pacchetti di archivi)

• Basato su container (include VM, Habitat, LXC, Docker)

• Basato su funzioni (Micro servizi / Lambdas / Funzioni)

Suppongo che in questo caso parliamo solo di aggiornamenti delle applicazioni sui server.

Per la distribuzione è necessario che si verifichino due cose:

1. I file o i pacchetti corretti devono essere spostati sul server.
2. Gli stati di configurazione e di servizio devono cambiare.

Ora per (1) è possibile utilizzare più strategie:

• Archivi artefatti / Sincronizzazione
• Archivi di pacchetti / Gestori di pacchetti
• Sistema di controllo versione / Aggiornamento + Compilazione (facoltativo)
• Protocolli di trasferimento file (scp, rsync, ftp)
• Strumenti di distribuzione

Per il (2) è possibile utilizzare:

• Strumenti di gestione della configurazione
• Strumenti di distribuzione

Pertanto, sebbene gli strumenti di distribuzione siano un modo per eseguire la distribuzione tutto in uno, non sono sempre la strategia migliore. A volte si desidera utilizzare la combinazione di questi modi per la distribuzione. Molto probabilmente già usi già i gestori di pacchetti almeno sui tuoi server. Molto probabilmente esegui comunque strumenti di configurazione. Il problema con alcuni degli strumenti di configurazione era una corretta orchestrazione tra più server, ma ora anche Chef e Puppet possono farlo abbastanza bene. Ansible è sempre stato bravo in questo.

Per esperienza personale , ho usato tutte le combinazioni, ma attualmente utilizziamo Capistrano per la distribuzione e la sincronizzazione Ansible per la gestione della configurazione e VCS e repository di pacchetti per i trasferimenti di file, ma ci sono problemi con Capistrano e stiamo pianificando di spostarci da unify su Ansible sia per la distribuzione, la manutenzione e la gestione della configurazione.

La distribuzione delle applicazioni è difficile da definire perché presenta molti sotto-problemi. I sistemi di gestione della configurazione sono eccellenti nelle attività di modellazione che sono convergenti e funzionano con "qual è lo stato desiderato del sistema". Nel contesto della distribuzione di app, questo è ottimo per cose come la distribuzione di bit su una macchina, la gestione dei file di configurazione e l'impostazione dei servizi di sistema. Ciò per cui è estremamente negativo sono le cose intrinsecamente procedurali, in particolare le migrazioni dei database e il riavvio dei servizi. Di solito cerco di inserire la logica convergente in Chef e di lasciare che uno strumento procedurale esterno (di solito Fabric nel mio caso) gestisca i pochi bit rimanenti, nonché sequenziare le convergenze effettive.

Quindi, in sostanza, dovresti usare entrambi per i pezzi in cui sono i migliori.

Per il software e la distribuzione di codice su un server esistente o all'interno di un contenitore Docker, la risposta è relativamente semplice: no, non hai bisogno di entrambi, ma potresti volere entrambi se un altro strumento o utilità aggiunge valore ed è lo strumento giusto per il lavoro , tuttavia le cose si complicano quando si distribuiscono server e sistemi operativi.

Un valore aggiunto di una mentalità DevOps è trattare l'infrastruttura come codice e spesso implementare o distruggere macchine virtuali o persino bare metal in un ambiente altamente elasticizzato. Il sistema di gestione della configurazione non è in grado di avviare e avviare facilmente il server per te e non può gestire repository, pacchetti e aggiornamenti / patch per te durante e dopo le distribuzioni o, in alcuni casi, licenze e diritti.

Per Amazon Web Services, questo è piuttosto convenientemente gestibile dalle API per la maggior parte, ma per quelli di noi che devono gestire i propri data center, questa non è un'opzione. Per questo motivo il Foreman progetto (e Red Hat che ri-marche questo ) hanno trovato necessario fascio Katello , Candlepin e un gestore di configurazione come Ansible, Foreman o Puppet insieme quando si distribuisce il Katello Scenario .

Quindi, mentre potresti essere in grado di cavartela usando gli strumenti di gestione della configurazione per distribuzioni di codice software sul lato Dev della casa, oltre sul lato Ops, ci sono diversi casi in cui la risposta è un clamoroso "no, gli strumenti di gestione della configurazione non lo sono appropriato da usare come strumento di spiegamento "Ciò richiederebbe una seria reinvenzione della ruota ed è poco pratico. È invece necessario utilizzare gli strumenti di gestione della configurazione per avviare le distribuzioni in un altro strumento.