Gestione della configurazione per "amministratori multipli a server singolo"

Abbiamo creato un server che esegue l'infrastruttura per una piccola associazione. Finora, abbiamo provato a gestire la configurazione con Ansible, ma non è stato un grande successo. Forse stiamo sbagliando.

In linea di principio, l'idea è che questo server rimarrà solo per la maggior parte del tempo, con le persone che aggiungono o cambiano le cose una volta su una luna blu. Ciò rende cruciale che tutto ciò che è configurato e in esecuzione sul server sia ben documentato e chiaro, poiché le persone che non amministrano frequentemente il sistema sono destinate a perdere la visione d'insieme (per non parlare dei dettagli). Inoltre, nel tempo, la composizione del gruppo di persone che amministrerà questo server cambierà (man mano che le persone escono e si uniscono al "comitato").

Abbiamo iniziato con un'installazione pulita, aggiungendo ruoli in ansible ogni volta che volevamo creare qualcosa (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Forse a causa della nostra inesperienza, ovviamente non siamo mai in grado di scrivere una serie di attività rispondibili esattamente come ne abbiamo bisogno in una sola volta, anche perché la configurazione è un po 'un processo di prova ed errore. Ciò significa che, in pratica, in genere configuriamo prima qualsiasi servizio desideriamo eseguire sul server , quindi traduciamo in attività rispondibili. Puoi vedere dove sta andando. Le persone dimenticano di testare il compito, o hanno paura di farlo a rischio di spezzare le cose, o peggio: dimentichiamo o trascuriamo di aggiungere cose per rispondere.

Oggi abbiamo poca fiducia che la configurazione ansible rifletta effettivamente ciò che è configurato sul server.

Attualmente vedo tre problemi principali:

• È difficile (leggere: non abbiamo un buon modo per) testare le attività rispondenti senza rischiare di rompere le cose.
• Aggiunge ulteriore lavoro per capire prima la configurazione desiderata, quindi capire come tradurla in attività rispondibili.
• (Idealmente) non lo usiamo abbastanza frequentemente per creare familiarità e routine.

Una considerazione importante qui è che per qualsiasi cosa finiamo per fare, dovrebbe essere facile per i nuovi arrivati ​​imparare le corde senza un sacco di pratica.

Esiste un'alternativa praticabile che fornisce ancora alcune garanzie e controlli (paragonabile all'unione dei file Ansible in alcuni master) che "configura le cose e annota ciò che hai fatto" non riesce a fornire?

EDIT: Abbiamo preso in considerazione l'impegno /etca git. Esiste un modo ragionevole per proteggere i segreti (chiavi private, ecc.) In quel modo, ma in qualche modo avere ancora il repository di configurazione esterno al server?

È sufficiente creare una VM di prova / gestione temporanea che è possibile utilizzare per convalidare le modifiche. Il tuo attuale metodo per eseguire manualmente le modifiche prima è irrimediabilmente rotto e destinato a fallire. Tu e il tuo team dovete impegnarvi a utilizzare CM in modo corretto e in parte è disponibile un sistema di test. Anche solo una VM vagabonda locale sarebbe sufficiente.

Questo non solo aiuterà a testare le nuove modifiche, ma fungerà anche da banco di prova per i nuovi dipendenti (o per i dipendenti più anziani che non usano il sistema da un po 'di tempo) per familiarizzare con la propria configurazione.

Per quanto riguarda mantenere / etc / in git: no, non farlo. Quella directory è solo una piccola parte di ciò che Ansible sta cambiando e avere git in atto incoraggerà solo le persone a fare cambiamenti locali.

Tieni i tuoi playbook rispondibili in git. Prendi in considerazione la possibilità di limitare le autorizzazioni in modo tale che solo tu puoi applicare le modifiche rispondenti al server live. Altri possono inviare richieste pull con le loro modifiche, che puoi rivedere e unire in master se appropriato.

Forse a causa della nostra inesperienza, ovviamente non siamo mai in grado di scrivere una serie di attività rispondibili esattamente come ne abbiamo bisogno in una sola volta, anche perché la configurazione è un po 'un processo di prova ed errore. Ciò significa che, in pratica, in genere configuriamo prima qualsiasi servizio desideriamo eseguire sul server, quindi traduciamo in attività rispondibili.

Mentre ci sono altri problemi (come non avere un ambiente di test), puoi fare un grande miglioramento non facendo questo .

Uno degli obiettivi principali di Ansible è quello di essere idempotente , il che significa che eseguire il tuo playbook più volte non dovrebbe cambiare nulla (a meno che tu non abbia cambiato i giochi). Pertanto, quando sto configurando un nuovo software, i miei passi sono:

1. Apporta modifiche alle attività Ansible.
2. Esegui il playbook.
3. Esaminare il sistema e, se non è corretto, tornare al passaggio 1.
4. Commetti le mie modifiche.

Se non pensi di scrivere la cosa corretta la prima volta in Ansible, scrivila comunque e itera su di essa fino a quando è corretta, proprio come qualsiasi altro codice. Ciò riduce notevolmente la possibilità di dimenticare di Ansiblize alcune modifiche apportate, poiché tutte le modifiche apportate erano già in Ansible ad un certo punto durante il processo di sviluppo.

Ansible ha un tempo di accelerazione prima di superare il precedente livello di produttività, ma una volta fatto lo stato del sistema è facile da assicurare. Le tue pratiche sembrano fuori sincrono con i tuoi obiettivi finali. Puoi essere produttivo con un set di strumenti CM, pur mantenendo solide pratiche ingegneristiche, ma ci vuole tempo per strutturarlo correttamente. Stai essenzialmente scambiando efficienza e facilità di implementazione, per stabilità e scalabilità aziendale. Allo stesso modo in cui un programmatore professionista esperto non scrive brutti hack, le conseguenze superano sempre i benefici.

Per i principianti potresti avere troppi cuochi, senza una chiara proprietà, se così si aspetta una tragedia dei beni comuni. Ogni priorità aziendale supererà ogni volta i problemi di ingegneria del sistema, a meno che non sia ampiamente disinnescata e ciò che rimane lasciato si riflette direttamente sull'ingegnere responsabile.

Un set di strumenti CM non è in grado di essere progettato dagli amministratori, questo è ciò che ho appena realizzato. Possono riutilizzare il lavoro esistente o POSSIBILMENTE estendere su una base solida, ma anche in questo caso richiederebbe un oneroso carico di applicazione delle pratiche. Ciò che un ingegnere può fare, semplicemente NON è ciò che un amministratore può fare. Molti concetti in Ansible sono quasi gli stessi di quelli in una base di codice, puoi insegnare ad un pitone Admin e aspettarti risultati competenti? No, sicuramente no, mi aspetterei un lavoro di hacking, quindi è necessario rendere l'attività abbastanza strutturata in modo che un lavoro di hacking sia sopportabile.

Quindi è necessario impostare le cose per il successo, progettare soluzioni per punti di amministrazione non necessaria. Scambia la complessità dei sistemi di basso livello per cose che un amministratore potrebbe effettivamente fare con successo. Un set di strumenti CM NON ti salverà da disallineamenti architettonici o di progettazione.

Quindi l'ordine è soggetto a modifiche, ovviamente perché l'implementazione dipende da quale percorso è meno dirompente per il tuo stato attuale.

1. Spostare qualsiasi lavoro di sistema relativo al flusso di lavoro correlato al business in un rundeck dedicato.

2. Suddividere le attività sulla scatola, potresti avere due o più scatole in una in questo momento.

3. Reimplementa il tuo CM in un modo più strutturato e segui le migliori pratiche rispondibili, i libri di gioco che rappresentano oggetti NON funzioni o ruoli. Ogni sistema dovrebbe essere descritto in un gioco.