S'acostava l'Any Nou. Els nens d'arreu del país ja havien enviat cartes al Pare Noel o s'havien fet regals, i el seu principal marmessor, un dels principals comerciants, es preparava per a l'apoteosi de les vendes. Al desembre, la càrrega del seu centre de dades augmenta diverses vegades. Per això, l'empresa va decidir modernitzar el centre de dades i posar en funcionament diverses desenes de nous servidors en comptes d'equips que arribaven al final de la seva vida útil. Això acaba la història amb el teló de fons de flocs de neu remolins i comença el thriller.
L'equip va arribar al lloc diversos mesos abans del pic de vendes. El servei d'operacions, per descomptat, sap com i què configurar als servidors per portar-los a l'entorn de producció. Però calia automatitzar-ho i eliminar el factor humà. A més, els servidors es van substituir abans de la migració d'un conjunt de sistemes SAP que eren crítics per a l'empresa.
La posada en marxa de nous servidors estava estrictament lligada a un termini. I moure'l va suposar posar en perill tant l'enviament de mil milions de regals com la migració de sistemes. Fins i tot un equip format per Father Frost i Santa Claus no va poder canviar la data: només podeu transferir el sistema SAP per a la gestió del magatzem una vegada a l'any. Del 31 de desembre a l'1 de gener, els enormes magatzems del minorista, amb un total de 20 camps de futbol, aturan la seva feina durant 15 hores. I aquest és l'únic període de temps per moure el sistema. No vam tenir marge d'error a l'hora d'introduir servidors.
Deixeu-me que sigui clar: la meva història reflecteix les eines i el procés de gestió de la configuració que utilitza el nostre equip.
El complex de gestió de la configuració consta de diversos nivells. El component clau és el sistema CMS. En el funcionament industrial, l'absència d'un dels nivells portaria inevitablement a miracles desagradables.
Gestió de la instal·lació del SO
El primer nivell és un sistema de gestió de la instal·lació de sistemes operatius en servidors físics i virtuals. Crea configuracions bàsiques del sistema operatiu, eliminant el factor humà.
Mitjançant aquest sistema, vam rebre instàncies de servidor estàndard amb un sistema operatiu adequat per a una major automatització. Durant el "abocament" van rebre un conjunt mínim d'usuaris locals i claus públiques SSH, així com una configuració coherent del sistema operatiu. Estàvem garantits per gestionar els servidors a través del CMS i estàvem segurs que no hi havia sorpreses "a sota" a nivell del sistema operatiu.
La tasca "màxima" per al sistema de gestió d'instal·lacions és configurar automàticament els servidors des del nivell de BIOS/Firmware fins al sistema operatiu. Molt aquí depèn de l'equip i les tasques de configuració. Per a equips heterogenis, podeu considerar . Si tot el maquinari és d'un mateix proveïdor, sovint és més convenient utilitzar eines de gestió ja fetes (per exemple, HP ILO Amplifier, DELL OpenManage, etc.).
Per instal·lar el SO en servidors físics, hem utilitzat el conegut Cobbler, que defineix un conjunt de perfils d'instal·lació pactats amb el servei d'operació. En afegir un nou servidor a la infraestructura, l'enginyer va vincular l'adreça MAC del servidor al perfil requerit a Cobbler. En arrencar a través de la xarxa per primera vegada, el servidor va rebre una adreça temporal i un sistema operatiu nou. A continuació, es va transferir a l'adreçament VLAN/IP objectiu i es va continuar treballant allà. Sí, canviar la VLAN requereix temps i coordinació, però proporciona protecció addicional contra la instal·lació accidental del servidor en un entorn de producció.
Hem creat servidors virtuals basats en plantilles preparades amb HashiСorp Packer. El motiu era el mateix: evitar possibles errors humans en instal·lar el sistema operatiu. Però, a diferència dels servidors físics, Packer elimina la necessitat de PXE, arrencada de xarxa i canvis de VLAN. Això ha fet que sigui més fàcil i senzill crear servidors virtuals.
Arròs. 1. Gestió de la instal·lació de sistemes operatius.
Gestió de secrets
Qualsevol sistema de gestió de configuració conté dades que s'han d'ocultar als usuaris normals, però que són necessàries per preparar els sistemes. Es tracta de contrasenyes per a usuaris locals i comptes de servei, claus de certificat, diversos testimonis d'API, etc. Normalment s'anomenen "secrets".
Si no determineu des del principi on i com emmagatzemar aquests secrets, aleshores, depenent de l'estricte dels requisits de seguretat de la informació, són probables els mètodes d'emmagatzematge següents:
- directament al codi de control de configuració o als fitxers del repositori;
- en eines de gestió de configuració especialitzades (per exemple, Ansible Vault);
- en sistemes CI/CD (Jenkins/TeamCity/GitLab/etc.) o en sistemes de gestió de configuració (Ansible Tower/Ansible AWX);
- els secrets també es poden transferir "manualment". Per exemple, es distribueixen en una ubicació especificada i després són utilitzats pels sistemes de gestió de configuració;
- diverses combinacions de les anteriors.
Cada mètode té els seus propis desavantatges. La principal és la manca de polítiques d'accés als secrets: és impossible o difícil determinar qui pot utilitzar determinats secrets. Un altre desavantatge és la manca d'auditoria d'accés i un cicle de vida complet. Com substituir ràpidament, per exemple, una clau pública que està escrita al codi i en diversos sistemes relacionats?
Hem utilitzat l'emmagatzematge secret centralitzat HashiCorp Vault. Això ens va permetre:
- guarda els secrets. Estan xifrats i, fins i tot si algú accedeix a la base de dades de Vault (per exemple, restaurant-la des d'una còpia de seguretat), no podrà llegir els secrets emmagatzemats allà;
- organitzar polítiques d'accés als secrets. Només els secrets "assignats" a ells estan disponibles per als usuaris i aplicacions;
- auditar l'accés als secrets. Qualsevol acció amb secrets es registra al registre d'auditoria de Vault;
- organitzar un "cicle de vida" complet de treball amb secrets. Es poden crear, revocar, establir una data de caducitat, etc.
- fàcil d'integrar amb altres sistemes que necessiten accés a secrets;
- i també utilitzar xifratge d'extrem a extrem, contrasenyes d'un sol ús per al sistema operatiu i la base de dades, certificats de centres autoritzats, etc.
Ara passem al sistema central d'autenticació i autorització. Era possible prescindir-ne, però administrar usuaris en molts sistemes relacionats no és massa trivial. Hem configurat l'autenticació i l'autorització mitjançant el servei LDAP. En cas contrari, Vault hauria d'emetre i fer un seguiment contínu dels testimonis d'autenticació dels usuaris. I suprimir i afegir usuaris es convertiria en una recerca "he creat/suprimit aquest compte d'usuari a tot arreu?"
Afegim un altre nivell al nostre sistema: gestió de secrets i autenticació/autorització central:
Arròs. 2. Gestió de secrets.
Gestió de la configuració
Hem arribat al nucli: el sistema CMS. En el nostre cas, es tracta d'una combinació d'Ansible i Red Hat Ansible AWX.
En lloc d'Ansible, es pot utilitzar Chef, Puppet, SaltStack. Hem escollit Ansible en funció de diversos criteris.
- En primer lloc, és la versatilitat. Un conjunt de mòduls preparats per al control . I si no en tens prou, pots cercar a GitHub i Galaxy.
- En segon lloc, no cal instal·lar i donar suport als agents en equips gestionats, demostrar que no interfereixen amb la càrrega i confirmar l'absència de "marcadors".
- En tercer lloc, Ansible té una barrera d'entrada baixa. Un enginyer competent escriurà un manual de treball literalment el primer dia de treball amb el producte.
Però Ansible sol en un entorn de producció no ens va ser suficient. En cas contrari, sorgirien molts problemes amb la restricció de l'accés i l'auditoria de les accions dels administradors. Com restringir l'accés? Al cap i a la fi, era necessari que cada departament gestionés (llegiu: executeu el llibre de jugades Ansible) "el seu propi" conjunt de servidors. Com permetre que només determinats empleats executin llibres de jugades Ansible específics? O com fer un seguiment de qui va llançar el llibre de jugades sense configurar molts coneixements locals en servidors i equips que executen Ansible?
La part del lleó d'aquests problemes és resolta per Red Hat , o el seu projecte de codi obert upstream . Per això ho preferim pel client.
I un toc més al retrat del nostre sistema CMS. El llibre de jugades Ansible s'ha d'emmagatzemar als sistemes de gestió de dipòsits de codi. El tenim .
Per tant, les configuracions en si es gestionen mitjançant una combinació d'Ansible/Ansible AWX/GitLab (vegeu la figura 3). Per descomptat, AWX/GitLab està integrat amb un únic sistema d'autenticació i el llibre de jocs Ansible està integrat amb HashiCorp Vault. Les configuracions entren a l'entorn de producció només a través d'Ansible AWX, en el qual s'especifiquen totes les "regles del joc": qui pot configurar què, on obtenir el codi de gestió de configuració per al CMS, etc.
Arròs. 3. Gestió de la configuració.
Gestió de proves
La nostra configuració es presenta en forma de codi. Per tant, estem obligats a jugar amb les mateixes regles que els desenvolupadors de programari. Necessitava organitzar els processos de desenvolupament, proves contínues, lliurament i aplicació del codi de configuració als servidors de producció.
Si això no es fa immediatament, els rols escrits per a la configuració deixaran de ser compatibles i modificats, o deixaran de llançar-se en producció. La cura per a aquest dolor és coneguda i s'ha demostrat en aquest projecte:
- cada rol està cobert per proves unitàries;
- les proves s'executen automàticament sempre que hi ha algun canvi en el codi que gestiona les configuracions;
- els canvis en el codi de gestió de configuració s'alliberen a l'entorn de producció només després de superar amb èxit totes les proves i la revisió del codi.
El desenvolupament de codi i la gestió de la configuració s'han tornat més tranquils i més previsibles. Per organitzar les proves contínues, vam utilitzar el conjunt d'eines CI/CD de GitLab i vam prendre .
Sempre que hi ha un canvi en el codi de gestió de configuració, GitLab CI/CD crida a Molecule:
- comprova la sintaxi del codi,
- aixeca el contenidor Docker,
- aplica el codi modificat al contenidor creat,
- comprova la funció de la idempotència i executa proves per a aquest codi (la granularitat aquí és al nivell de rol ansible, vegeu la figura 4).
Hem lliurat configuracions a l'entorn de producció mitjançant Ansible AWX. Els enginyers d'operacions van aplicar canvis de configuració mitjançant plantilles predefinides. AWX va "sol·licitar" de manera independent l'última versió del codi a la branca mestra de GitLab cada vegada que s'utilitzava. D'aquesta manera vam excloure l'ús de codi no provat o obsolet a l'entorn de producció. Naturalment, el codi va entrar a la branca mestra només després de la prova, la revisió i l'aprovació.
Arròs. 4. Prova automàtica de rols a GitLab CI/CD.
També hi ha un problema associat al funcionament dels sistemes de producció. A la vida real, és molt difícil fer canvis de configuració només mitjançant el codi CMS. Les situacions d'emergència sorgeixen quan un enginyer ha de canviar la configuració "aquí i ara", sense esperar a l'edició del codi, prova, aprovació, etc.
Com a resultat, a causa dels canvis manuals, apareixen discrepàncies en la configuració del mateix tipus d'equip (per exemple, la configuració del sysctl es configura de manera diferent als nodes del clúster HA). O la configuració real de l'equip difereix de l'especificada al codi CMS.
Per tant, a més de les proves contínues, comprovem les discrepàncies de configuració dels entorns de producció. Hem escollit l'opció més senzilla: executar el codi de configuració del CMS en mode “execució en sec”, és a dir, sense aplicar canvis, però amb notificació de totes les discrepàncies entre la configuració prevista i la real. Ho vam implementar executant periòdicament tots els llibres de jugades d'Ansible amb l'opció "—comprova" als servidors de producció. Com sempre, Ansible AWX és responsable de llançar i mantenir el llibre de jugades actualitzat (vegeu la figura 5):
Arròs. 5. Comprova si hi ha discrepàncies de configuració a Ansible AWX.
Després de les comprovacions, AWX envia un informe de discrepància als administradors. Estudien la configuració problemàtica i després la solucionen mitjançant llibres de jugades ajustats. Així mantenim la configuració a l'entorn de producció i el CMS està sempre actualitzat i sincronitzat. Això elimina els "miracles" desagradables quan s'utilitza codi CMS en servidors de "producció".
Ara tenim una capa de prova important que consisteix en Ansible AWX/GitLab/Molecule (figura 6).
Arròs. 6. Gestió de proves.
Difícil? No discuteixo. Però aquest complex de gestió de la configuració s'ha convertit en una resposta integral a moltes preguntes relacionades amb l'automatització de la configuració del servidor. Ara, els servidors estàndard d'un minorista sempre tenen una configuració estrictament definida. CMS, a diferència d'un enginyer, no oblidarà afegir la configuració necessària, crear usuaris i realitzar desenes o centenars de configuracions necessàries.
Actualment no hi ha "coneixement secret" a la configuració dels servidors i entorns. Totes les característiques necessàries es reflecteixen al llibre de jugades. No més creativitat i instruccions vagues: "Instal·leu-lo com a Oracle normal, però heu d'especificar un parell de paràmetres de sysctl i afegir usuaris amb l'UID requerit. Pregunteu als nois en funcionament, ja ho saben».
La capacitat de detectar discrepàncies de configuració i corregir-les de manera proactiva proporciona tranquil·litat. Sense un sistema de gestió de configuració, això normalment sembla diferent. Els problemes s'acumulen fins que un dia arriben a la producció. A continuació, es realitza un debriefing, es revisen i es corregeixen les configuracions. I el cicle es repeteix de nou
I, per descomptat, vam accelerar el llançament dels servidors en funcionament de diversos dies a hores.
Bé, la nit de Cap d'Any mateix, quan els nens estaven amb alegria desembolicant regals i els adults demanaven desitjos mentre sonaven les campanades, els nostres enginyers van migrar el sistema SAP a nous servidors. Fins i tot el Pare Noel dirà que els millors miracles són els que estan ben preparats.
PS El nostre equip sovint es troba amb el fet que els clients volen resoldre els problemes de gestió de la configuració de la manera més senzilla possible. Idealment, com per art de màgia, amb una sola eina. Però a la vida tot és més complicat (sí, no es van tornar a lliurar bales de plata): has de crear tot un procés utilitzant eines convenients per a l'equip del client.
Autor: Sergey Artemov, arquitecte del departament "Jet Infosystems"
Font: www.habr.com