S'avvicinava di l'annu novu. I zitelli in tuttu u paese avianu digià mandatu lettere à Santa Claus o fattu rigali per elli stessi, è u so esecutore principalu, unu di i principali rivenditori, si preparava per l'apoteosi di vendita. In dicembre, a carica nantu à u so centru di dati aumenta parechje volte. Per quessa, a cumpagnia hà decisu di mudernizà u centru di dati è mette in funziunamentu parechje decine di servitori novi invece di l'equipaggiu chì ghjunghje à a fine di a so vita di serviziu. Questu finisce a storia nantu à u sfondate di fiocchi di neve chì giranu, è u thriller principia.
L'equipaggiu ghjunghjenu à u situ parechji mesi prima di u piccu di vendita. U serviziu di l'operazioni, sicuru, sà cumu è ciò chì cunfigurà nantu à i servitori per portà in l'ambiente di produzzione. Ma avemu bisognu di automatizà questu è eliminà u fattore umanu. Inoltre, i servitori sò stati rimpiazzati prima di a migrazione di un settore di sistemi SAP chì eranu critichi per a cumpagnia.
A cumissioni di novi servitori era strettamente ligata à una scadenza. È u muvimentu significava mette in periculu sia a spedizione di un miliardo di rigali è a migrazione di sistemi. Ancu una squadra custituita da Babbu Frost è Santa Claus ùn pudia micca cambià a data - pudete trasferisce u sistema SAP per a gestione di magazzini solu una volta à l'annu. Da u 31 di dicembre à u 1 di ghjennaghju, i magazzini enormi di u retailer, in totale di 20 campi di football, fermanu u so travagliu per 15 ore. È questu hè l'unicu periodu di tempu per trasfurmà u sistema. Ùn avemu micca spaziu per l'errore in l'introduzione di servitori.
Lasciami esse chjaru: a mo storia riflette l'arnesi è u prucessu di gestione di cunfigurazione chì a nostra squadra usa.
U cumplessu di gestione di cunfigurazione hè custituitu da parechji livelli. U cumpunente chjave hè u sistema CMS. In l'operazione industriale, l'absenza di unu di i livelli inevitabbilmente portanu à miraculi dispiacenti.
Gestione di l'installazione OS
U primu livellu hè un sistema per gestisce a stallazione di sistemi operativi nantu à i servitori fisici è virtuali. Crea cunfigurazioni basi di OS, eliminendu u fattore umanu.
Utilizendu stu sistema, avemu ricevutu istanze di servitore standard cù OS adattatu per più automatizazione. Duranti u "pouring" anu ricivutu un settore minimu di utilizatori lucali è chjavi publichi SSH, è ancu una cunfigurazione OS consistente. Pudemu esse guarantiti di gestisce i servitori per mezu di u CMS è eramu sicuri chì ùn ci era micca sorprese "sottu" à u nivellu di u SO.
U compitu "massimu" per u sistema di gestione di l'installazione hè di cunfigurà automaticamente i servitori da u livellu BIOS / Firmware à u SO. Moltu quì dipende da l'equipaggiu è i travaglii di stallazione. Per l'equipaggiu eterogeneu, pudete cunsiderà . Se tuttu u hardware hè di un venditore, allora hè spessu più còmuda di utilizà strumenti di gestione pronti (per esempiu, HP ILO Amplifier, DELL OpenManage, etc.).
Per installà l'OS nantu à i servitori fisichi, avemu usatu u Cobbler ben cunnisciutu, chì definisce un settore di profili di installazione accunsentutu cù u serviziu di operazione. Quandu aghjunghje un novu servitore à l'infrastruttura, l'ingegnere hà ligatu l'indirizzu MAC di u servitore à u prufilu necessariu in Cobbler. Quandu u booting nantu à a reta per a prima volta, u servitore hà ricevutu un indirizzu tempurale è un novu OS. Allora hè stata trasferita à l'indirizzu VLAN / IP di destinazione è cuntinuò u travagliu quì. Iè, cambià a VLAN richiede u tempu è esige a coordinazione, ma furnisce una prutezzione supplementaria contra l'installazione accidentale di u servitore in un ambiente di produzzione.
Avemu creatu servitori virtuali basati nantu à mudelli preparati cù HashiСorp Packer. U mutivu era u listessu: per prevene i pussibuli errori umani quandu installate u SO. Ma, à u cuntrariu di i servitori fisici, Packer elimina a necessità di PXE, boot di rete è cambiamenti VLAN. Questu hà fattu più faciule è simplice per creà servitori virtuali.
Risu. 1. Gestisce a stallazione di sistemi operativi.
Gestisce i sicreti
Ogni sistema di gestione di cunfigurazione cuntene dati chì deve esse oculati da l'utilizatori ordinali, ma hè necessariu per preparà i sistemi. Quessi sò password per l'utilizatori lucali è i cunti di serviziu, chjavi di certificatu, diversi API Tokens, etc. Sò generalmente chjamati "secreti".
Se ùn avete micca determinatu da u principiu induve è cumu per almacenà sti sicreti, allora, secondu a gravità di e esigenze di sicurezza di l'infurmazioni, i seguenti metudi di almacenamentu sò prubabile:
- direttamente in u codice di cuntrollu di cunfigurazione o in i schedari in u repository;
- in strumenti di gestione di cunfigurazione specializati (per esempiu, Ansible Vault);
- in sistemi CI/CD (Jenkins/TeamCity/GitLab/etc.) o in sistemi di gestione di cunfigurazione (Ansible Tower/Ansible AWX);
- sicreti pò ancu esse trasferitu "manualmente". Per esempiu, sò disposti in un locu specificu, è dopu sò usati da i sistemi di gestione di cunfigurazione;
- diverse cumminazzioni di u sopra.
Ogni metudu hà i so svantaghji. U principale hè a mancanza di pulitiche per l'accessu à i sicreti: hè impussibile o difficiule di determinà quale pò utilizà certi sicreti. Un altru svantaghju hè a mancanza di auditing d'accessu è un ciclu di vita sanu. Cumu rimpiazzà rapidamente, per esempiu, una chjave publica chì hè scritta in u codice è in una quantità di sistemi cunnessi?
Avemu usatu u almacenamentu secretu centralizatu HashiCorp Vault. Questu ci hà permessu:
- mantene i sicreti sicuri. Sò criptati, è ancu s'ellu qualchissia accede à a basa di dati Vault (per esempiu, restaurà da una copia di salvezza), ùn puderanu micca leghje i sicreti guardati quì;
- urganizà pulitiche per l'accessu à i sicreti. Solu i sicreti "assignati" à elli sò dispunibuli per l'utilizatori è l'applicazioni;
- auditu accessu à i sicreti. Ogni azzioni cù sicreti sò registrati in u logu di auditu di Vault;
- urganizà un "ciculu di vita" cumpletu di travaglià cù sicreti. Puderanu esse creati, revocati, stabilisce una data di scadenza, etc.
- faciule d'integrazione cù altri sistemi chì necessitanu accessu à i sicreti;
- è ancu aduprà criptografia end-to-end, password una volta per u SO è a basa di dati, certificati di centri autorizati, etc.
Avà andemu à u sistema centrale d'autentificazione è d'autorizazione. Hè statu pussibule di fà senza, ma l'amministrazione di l'utilizatori in parechji sistemi cunnessi hè troppu micca trivial. Avemu cunfiguratu l'autentificazione è l'autorizazione attraversu u serviziu LDAP. Altrimenti, Vault avissi da emette continuamente è tene traccia di i tokens di autentificazione per l'utilizatori. È l'eliminazione è l'aghjunghje l'utilizatori diventeranu in una ricerca "aghju creatu / sguassatu stu contu d'utilizatore in ogni locu?"
Aghjunghjemu un altru livellu à u nostru sistema: gestione di secreti è autentificazione / auturizazione cintrali:
Risu. 2. Gestione di secreti.
Gestione di a cunfigurazione
Avemu ghjuntu à u core - u sistema CMS. In u nostru casu, questu hè una cumminazione di Ansible è Red Hat Ansible AWX.
Invece di Ansible, Chef, Puppet, SaltStack pò esse usatu. Avemu sceltu Ansible basatu annantu à parechji criteri.
- Prima, hè a versatilità. Un inseme di moduli pronti per u cuntrollu . È se ùn avete micca abbastanza, pudete cercà in GitHub è Galaxy.
- Siconda, ùn ci hè micca bisognu di installà è sustene l'agenti nantu à l'equipaggiu amministratu, pruvucà chì ùn interferiscenu micca cù a carica, è cunfirmà l'absenza di "segnalibri".
- In terzu, Ansible hà una bassa barriera à l'ingressu. Un ingegnere cumpetente scriverà un librettu di travagliu literalmente in u primu ghjornu di travaglià cù u pruduttu.
Ma Ansible solu in un ambiente di produzzione ùn era micca abbastanza per noi. Altrimenti, parechji prublemi sorgiranu cù restrizzione di l'accessu è audità l'azzioni di l'amministratori. Cumu limità l'accessu? Dopu tuttu, era necessariu per ogni dipartimentu di gestisce (leghjite: eseguite u playbook Ansible) "u so propiu" set di servitori. Cumu permette solu à certi impiegati di eseguisce libretti Ansible specifichi? O cumu seguità quale hà lanciatu u playbook senza stabilisce assai cunniscenze lucali nantu à i servitori è l'equipaggiu chì esegue Ansible?
A parte di u leone di tali prublemi hè risolta da Red Hat , o u so prughjettu upstream open-source . Hè per quessa chì avemu preferitu per u cliente.
È un toccu più à u ritrattu di u nostru sistema CMS. Ansible playbook deve esse guardatu in sistemi di gestione di repository di codice. L'avemu .
Allora, i cunfigurazioni stessi sò amministrati da una cumminazione di Ansible / Ansible AWX / GitLab (vede Fig. 3). Di sicuru, AWX / GitLab hè integratu cù un sistema di autentificazione unicu, è Ansible playbook hè integratu cù HashiCorp Vault. I cunfigurazioni entranu in l'ambiente di produzzione solu per Ansible AWX, in quale sò specificate tutte e "règuli di u ghjocu": quale pò cunfigurà ciò chì, induve uttene u codice di gestione di cunfigurazione per u CMS, etc.
Risu. 3. Gestione di cunfigurazione.
Gestione di teste
A nostra cunfigurazione hè presentata in forma di codice. Dunque, simu furzati à ghjucà cù e stesse regule cum'è i sviluppatori di software. Avemu bisognu di urganizà i prucessi di sviluppu, teste cuntinui, consegna è applicazione di codice di cunfigurazione à i servitori di produzzione.
Se questu ùn hè micca fattu immediatamente, i roli scritti per a cunfigurazione o cessanu di esse supportati è mudificati, o cessanu di esse lanciati in produzzione. A cura di stu dulore hè cunnisciuta, è hà pruvatu in stu prughjettu:
- ogni rolu hè cupartu da teste unità;
- e teste sò eseguite automaticamente ogni volta chì ci hè qualchì cambiamentu in u codice chì gestisce e cunfigurazioni;
- i cambiamenti in u codice di gestione di cunfigurazione sò liberati in l'ambiente di produzzione solu dopu avè passatu cù successu tutte e teste è a revisione di u codice.
U sviluppu di codice è a gestione di cunfigurazione sò diventati più calmi è più prevedibili. Per urganizà e teste cuntinue, avemu usatu u toolkit GitLab CI / CD, è hà pigliatu .
Ogni volta chì ci hè un cambiamentu in u codice di gestione di cunfigurazione, GitLab CI / CD chjama Molecule:
- verifica a sintassi di u codice,
- alza u containeru Docker,
- applicà u codice mudificatu à u containeru creatu,
- verifica u rolu per l'idempotenza è eseguite teste per stu codice (a granularità quì hè à u livellu di rolu ansible, vede Fig. 4).
Avemu furnitu cunfigurazioni à l'ambiente di produzzione utilizendu Ansible AWX. L'ingegneri di l'operazioni anu applicatu cambiamenti di cunfigurazione attraversu mudelli predefiniti. AWX indipindentamente "dumandatu" l'ultima versione di u codice da u ramu maestru GitLab ogni volta chì hè stata utilizata. In questu modu escludemu l'usu di codice micca testatu o anticu in l'ambiente di produzzione. Naturalmente, u codice hè intrutu in u ramu maestru solu dopu a prova, rivisione è appruvazioni.
Risu. 4. Test automaticu di roli in GitLab CI/CD.
Ci hè ancu un prublema assuciatu cù u funziunamentu di i sistemi di produzzione. In a vita reale, hè assai difficiuli di fà cambiamenti di cunfigurazione solu cù u codice CMS. Situazioni d'urgenza nascenu quandu un ingegnere deve cambià a cunfigurazione "qui è avà", senza aspittà per l'editura di codice, teste, appruvazioni, etc.
In u risultatu, per via di i cambiamenti manuali, discrepanzi appariscenu in a cunfigurazione nantu à u listessu tipu d'equipaggiu (per esempiu, i paràmetri di sysctl sò cunfigurati in modu diversu nantu à i nodi di cluster HA). O a cunfigurazione attuale nantu à l'equipaggiu differisce da quella specificata in u codice CMS.
Dunque, in più di teste cuntinue, cuntrollemu l'ambienti di produzzione per discrepanze di cunfigurazione. Avemu sceltu l'opzione più sèmplice: eseguisce u codice di cunfigurazione CMS in modu "corsa secca", vale à dì, senza applicà cambiamenti, ma cun notizia di tutte e discrepanzi trà a cunfigurazione prevista è attuale. Avemu implementatu questu eseguendu periodicamente tutti i playbooks Ansible cù l'opzione "-check" in i servitori di produzzione. Cum'è sempre, Ansible AWX hè rispunsevuli di lanciari è mantene u playbook à a data (vede Fig. 5):
Risu. 5. Verificate per discrepanzi di cunfigurazione in Ansible AWX.
Dopu i cuntrolli, AWX manda un rapportu di discrepanza à l'amministratori. Studianu a cunfigurazione problematica è poi riparanu per mezu di playbooks ajustati. Questu hè cumu mantene a cunfigurazione in l'ambiente di produzzione è u CMS hè sempre aghjurnatu è sincronizatu. Questu elimina "miraculi" sgradevoli quandu u codice CMS hè utilizatu nantu à i servitori di "produzione".
Avemu avà una strata di prova impurtante cumpostu da Ansible AWX / GitLab / Molecule (Figura 6).
Risu. 6. Test management.
Difficile ? Ùn discute micca. Ma un tali cumplessu di gestione di cunfigurazione hè diventatu una risposta cumpleta à parechje dumande ligati à l'automatizazione di a cunfigurazione di u servitore. Avà i servitori standard di un retailer anu sempre una cunfigurazione strettamente definita. CMS, à u cuntrariu di un ingegnere, ùn si scurdarà di aghjunghje i paràmetri necessarii, di creà utilizatori è di fà decine o centinaie di paràmetri necessarii.
Ùn ci hè micca "cunniscenza secreta" in i paràmetri di i servitori è l'ambienti oghje. Tutte e funzioni necessarie sò riflesse in u playbook. Ùn ci hè più creatività è vague istruzioni: "Installa cum'è l'Oracle normale, ma avete bisognu di specificà un paru di paràmetri sysctl è aghjunghje l'utilizatori cù l'UID necessariu. Dumandate à i picciotti in operazione, sanu».
A capacità di detectà discrepanze di cunfigurazione è di correggerle in modu proattivu furnisce tranquillità. Senza un sistema di gestione di cunfigurazione, questu generalmente pare diversu. I prublemi s'accumulanu finu à un ghjornu chì "sparanu" in a produzzione. Allora un debriefing hè realizatu, e cunfigurazioni sò verificate è corrette. È u ciculu si ripete dinò
E sicuru, avemu acceleratu u lanciamentu di i servitori in operazione da parechji ghjorni à ore.
Ebbè, a vigilia di u Capu di l'annu stessu, quandu i zitelli sbulicanu cù gioia i rigali è l'adulti facevanu auguri mentre i campanelli suonanu, i nostri ingegneri migravanu u sistema SAP à novi servitori. Ancu Santa Claus dicerà chì i migliori miraculi sò quelli chì sò ben preparati.
PS A nostra squadra spessu scontra u fattu chì i clienti volenu risolve i prublemi di gestione di cunfigurazione cum'è simpliciamente pussibule. Ideale, cum'è per magia - cù un strumentu. Ma in a vita tuttu hè più cumplicatu (sì, i balli d'argentu ùn sò micca stati rimandati di novu): avete da creà un prucessu tutale cù e strumenti chì sò cunvenuti per a squadra di u cliente.
Autore: Sergey Artemov, architettu dipartimentu "Jet Infosystems"
Source: www.habr.com