Bližila se Nova godina. Djeca diljem zemlje već su poslala pisma Djedu Mrazu ili sama sebi izradila darove, a njihov glavni izvršitelj, jedan od većih trgovaca, pripremao se za apoteozu rasprodaja. U prosincu se opterećenje podatkovnog centra povećava nekoliko puta. Stoga je tvrtka odlučila modernizirati podatkovni centar i pustiti u rad nekoliko desetaka novih poslužitelja umjesto opreme koja je bila pri kraju radnog vijeka. Time završava priča u pozadini kovitlajućih pahulja i počinje triler.

Oprema je stigla na gradilište nekoliko mjeseci prije vrhunca prodaje. Operativna služba, naravno, zna kako i što konfigurirati na poslužiteljima kako bi ih dovela u produkcijsko okruženje. Ali morali smo ovo automatizirati i eliminirati ljudski faktor. Osim toga, poslužitelji su zamijenjeni prije migracije niza SAP sustava koji su bili ključni za tvrtku.

Puštanje u pogon novih poslužitelja bilo je strogo vezano uz rok. A njegovo premještanje značilo je ugrožavanje i isporuke milijarde darova i migracije sustava. Čak ni tim koji se sastoji od Djeda Mraza i Djeda Mraza nije mogao promijeniti datum - SAP sustav za upravljanje skladištem možete prenijeti samo jednom godišnje. Od 31. prosinca do 1. siječnja velika skladišta trgovca, ukupno veličine 20 nogometnih igrališta, obustavljaju rad na 15 sati. I to je jedino vremensko razdoblje za pomicanje sustava. Prilikom uvođenja servera nismo imali mjesta za pogreške.

Da budem jasan: moja priča odražava alate i proces upravljanja konfiguracijom koje naš tim koristi.

Kompleks upravljanja konfiguracijom sastoji se od nekoliko razina. Ključna komponenta je CMS sustav. U industrijskom radu, odsutnost jedne od razina neizbježno bi dovela do neugodnih čuda.

Upravljanje instalacijom OS-a

Prva razina je sustav za upravljanje instalacijom operativnih sustava na fizičkim i virtualnim poslužiteljima. Stvara osnovne konfiguracije OS-a, eliminirajući ljudski faktor.

Korištenjem ovog sustava dobili smo standardne instance poslužitelja s OS-om pogodnim za daljnju automatizaciju. Tijekom "lijevanja" dobili su minimalni skup lokalnih korisnika i javnih SSH ključeva, kao i dosljednu konfiguraciju OS-a. Mogli smo zajamčeno upravljati poslužiteljima putem CMS-a i bili smo sigurni da nema iznenađenja "dolje" na razini OS-a.

"Maksimalni" zadatak za sustav upravljanja instalacijom je automatsko konfiguriranje poslužitelja od razine BIOS-a/firmwarea do OS-a. Ovdje mnogo ovisi o opremi i zadacima postavljanja. Za heterogenu opremu, možete razmotriti REDFISH API. Ako je sav hardver od jednog dobavljača, tada je često praktičnije koristiti gotove alate za upravljanje (na primjer, HP ILO Amplifier, DELL OpenManage, itd.).

Za instalaciju OS-a na fizičke poslužitelje koristili smo dobro poznati Cobbler koji definira skup instalacijskih profila dogovorenih s operativnim servisom. Prilikom dodavanja novog poslužitelja u infrastrukturu, inženjer je povezao MAC adresu poslužitelja s traženim profilom u Cobbleru. Prilikom prvog dizanja preko mreže poslužitelj je dobio privremenu adresu i novi OS. Zatim je prebačen na ciljano VLAN/IP adresiranje i tamo je nastavio s radom. Da, promjena VLAN-a zahtijeva vrijeme i koordinaciju, ali pruža dodatnu zaštitu od slučajne instalacije poslužitelja u proizvodnom okruženju.

Kreirali smo virtualne poslužitelje na temelju predložaka pripremljenih pomoću HashiSorp Packera. Razlog je bio isti: spriječiti moguće ljudske pogreške prilikom instaliranja OS-a. No, za razliku od fizičkih poslužitelja, Packer eliminira potrebu za PXE-om, pokretanjem mreže i promjenama VLAN-a. To je olakšalo i pojednostavilo stvaranje virtualnih poslužitelja.

Riža. 1. Upravljanje instalacijom operativnih sustava.

Upravljanje tajnama

Svaki sustav upravljanja konfiguracijom sadrži podatke koji bi trebali biti skriveni od običnih korisnika, ali su potrebni za pripremu sustava. To su lozinke za lokalne korisnike i račune usluga, ključevi certifikata, razni API tokeni itd. Obično se nazivaju “tajne”.

Ako od samog početka ne odredite gdje i kako pohraniti te tajne, onda su, ovisno o ozbiljnosti zahtjeva za informacijsku sigurnost, vjerojatni sljedeći načini pohrane:

• izravno u konfiguracijskom kontrolnom kodu ili u datotekama u repozitoriju;
• u specijaliziranim alatima za upravljanje konfiguracijom (na primjer, Ansible Vault);
• u CI/CD sustavima (Jenkins/TeamCity/GitLab/itd.) ili u sustavima za upravljanje konfiguracijom (Ansible Tower/Ansible AWX);
• tajne se također mogu prenijeti "ručno". Na primjer, postavljeni su na određeno mjesto, a zatim ih koriste sustavi upravljanja konfiguracijom;
• razne kombinacije navedenog.

Svaka metoda ima svoje nedostatke. Glavni je nedostatak pravila za pristup tajnama: nemoguće je ili teško odrediti tko može koristiti određene tajne. Još jedan nedostatak je nedostatak revizije pristupa i punog životnog ciklusa. Kako brzo zamijeniti npr. javni ključ koji je zapisan u kodu i nizu povezanih sustava?

Koristili smo centraliziranu tajnu pohranu HashiCorp Vault. To nam je omogućilo:

• čuvaj tajne na sigurnom. Oni su šifrirani, pa čak i ako netko dobije pristup Vault bazi podataka (na primjer, vraćajući je iz sigurnosne kopije), neće moći pročitati tajne koje su tamo pohranjene;
• organizirati politike za pristup tajnama. Korisnicima i aplikacijama dostupne su samo tajne koje su im "dodijeljene";
• revizijski pristup tajnama. Sve radnje s tajnama bilježe se u dnevniku revizije trezora;
• organizirati punopravni "životni ciklus" rada s tajnama. Mogu se kreirati, opozvati, postaviti datum isteka itd.
• lako se integrira s drugim sustavima koji trebaju pristup tajnama;
• a također koristiti end-to-end enkripciju, jednokratne lozinke za OS i bazu podataka, certifikate ovlaštenih centara itd.

Sada prijeđimo na središnji sustav provjere autentičnosti i autorizacije. Bilo je moguće bez toga, ali administriranje korisnika u mnogim povezanim sustavima nije trivijalno. Konfigurirali smo autentifikaciju i autorizaciju putem LDAP usluge. U suprotnom, Vault bi morao kontinuirano izdavati i pratiti tokene za provjeru autentičnosti za korisnike. A brisanje i dodavanje korisnika pretvorilo bi se u potragu "jesam li kreirao/izbrisao ovaj korisnički račun posvuda?"

Našem sustavu dodajemo još jednu razinu: upravljanje tajnama i centralna autentifikacija/autorizacija:

Riža. 2. Upravljanje tajnama.

Konfiguracijski menadžment

Došli smo do srži - CMS sustava. U našem slučaju, ovo je kombinacija Ansible i Red Hat Ansible AWX.

Umjesto Ansiblea mogu se koristiti Chef, Puppet, SaltStack. Odabrali smo Ansible na temelju nekoliko kriterija.

• Prvo, to je svestranost. Skup gotovih modula za kontrolu impresivno je. A ako ga nemate dovoljno, možete pretraživati ​​na GitHubu i Galaxyju.
• Drugo, nema potrebe instalirati i podržavati agente na upravljanoj opremi, dokazati da ne ometaju opterećenje i potvrditi odsutnost "oznaka".
• Treće, Ansible ima niske barijere za ulazak. Kompetentni inženjer će napisati radnu knjigu doslovce prvog dana rada s proizvodom.

Ali sam Ansible u proizvodnom okruženju nije nam bio dovoljan. Inače bi se pojavili mnogi problemi s ograničavanjem pristupa i revizijom radnji administratora. Kako ograničiti pristup? Uostalom, bilo je potrebno da svaki odjel upravlja (čitaj: pokreće Ansible playbook) "svojim" skupom poslužitelja. Kako dopustiti samo određenim zaposlenicima da pokreću određene Ansible playbooks? Ili kako pratiti tko je pokrenuo playbook bez postavljanja puno lokalnog znanja o poslužiteljima i opremi koja pokreće Ansible?

Lavovski udio takvih problema rješava Red Hat Ansible toranj, ili njegov uzvodni projekt otvorenog koda Ansible AWX. Zato smo ga preferirali za kupca.

I još jedan detalj portretu našeg CMS sustava. Ansible playbook trebao bi biti pohranjen u sustavima za upravljanje spremištem koda. Imamo ga GitLab CE.

Dakle, samim konfiguracijama upravlja kombinacija Ansible/Ansible AWX/GitLab (vidi sl. 3). Naravno, AWX/GitLab integriran je s jedinstvenim sustavom provjere autentičnosti, a Ansible playbook integriran je s HashiCorp Vaultom. Konfiguracije ulaze u produkcijsko okruženje samo kroz Ansible AWX, u kojem su navedena sva “pravila igre”: tko može što konfigurirati, gdje dobiti kod za upravljanje konfiguracijom za CMS itd.

Riža. 3. Upravljanje konfiguracijom.

Upravljanje testovima

Naša konfiguracija je predstavljena u obliku koda. Stoga smo prisiljeni igrati po istim pravilima kao i programeri softvera. Trebali smo organizirati procese razvoja, kontinuiranog testiranja, isporuke i primjene konfiguracijskog koda na produkcijske poslužitelje.

Ako se to ne učini odmah, tada bi uloge napisane za konfiguraciju ili prestale biti podržane i modificirane ili bi se prestale pokretati u proizvodnji. Lijek za ovu bol je poznat, a dokazao se u ovom projektu:

• svaka je uloga pokrivena jediničnim testovima;
• testovi se pokreću automatski kad god dođe do bilo kakve promjene u kodu koji upravlja konfiguracijama;
• promjene koda za upravljanje konfiguracijom puštaju se u produkcijsko okruženje tek nakon uspješnog prolaska svih testova i pregleda koda.

Razvoj koda i upravljanje konfiguracijom postali su mirniji i predvidljiviji. Za organiziranje kontinuiranog testiranja koristili smo GitLab CI/CD alat i uzeli Anzibilna molekula.

Kad god dođe do promjene koda za upravljanje konfiguracijom, GitLab CI/CD poziva Molecule:

• provjerava sintaksu koda,
• podiže Docker spremnik,
• primjenjuje modificirani kod na stvoreni spremnik,
• provjerava ulogu za idempotenciju i pokreće testove za ovaj kod (granularnost je ovdje na razini anzibilne uloge, vidi sliku 4).

Isporučili smo konfiguracije u proizvodno okruženje koristeći Ansible AWX. Operativni inženjeri primijenili su konfiguracijske promjene putem unaprijed definiranih predložaka. AWX je neovisno "tražio" najnoviju verziju koda od glavne grane GitLaba svaki put kada je korišten. Na taj smo način isključili korištenje neprovjerenog ili zastarjelog koda u produkcijskom okruženju. Naravno, kod je ušao u master granu tek nakon testiranja, pregleda i odobrenja.

Riža. 4. Automatsko testiranje uloga u GitLab CI/CD.

Postoji i problem povezan s radom proizvodnih sustava. U stvarnom životu vrlo je teško napraviti promjene konfiguracije samo putem CMS koda. Hitne situacije nastaju kada inženjer mora promijeniti konfiguraciju "ovdje i sada", bez čekanja na uređivanje koda, testiranje, odobrenje itd.

Kao rezultat toga, zbog ručnih promjena, pojavljuju se odstupanja u konfiguraciji na istoj vrsti opreme (na primjer, sysctl postavke su drugačije konfigurirane na čvorovima HA klastera). Ili se stvarna konfiguracija na opremi razlikuje od one navedene u CMS kodu.

Stoga, osim kontinuiranog testiranja, provjeravamo proizvodna okruženja radi odstupanja u konfiguraciji. Odabrali smo najjednostavniju opciju: pokretanje konfiguracijskog koda CMS-a u "dry run" modu, odnosno bez primjene promjena, ali uz obavijest o svim odstupanjima između planirane i stvarne konfiguracije. To smo implementirali povremenim pokretanjem svih Ansible playbook-ova s ​​opcijom “—check” na proizvodnim poslužiteljima. Kao i uvijek, Ansible AWX odgovoran je za pokretanje i ažuriranje priručnika (vidi sliku 5):

Riža. 5. Provjerava nedosljednosti konfiguracije u Ansible AWX.

Nakon provjera, AWX šalje izvješće o odstupanju administratorima. Oni proučavaju problematičnu konfiguraciju i zatim je popravljaju kroz prilagođene priručnike. Na taj način održavamo konfiguraciju u proizvodnom okruženju i CMS je uvijek ažuran i sinkroniziran. Ovo eliminira neugodna "čuda" kada se CMS kod koristi na "produkcijskim" poslužiteljima.

Sada imamo važan sloj testiranja koji se sastoji od Ansible AWX/GitLab/Molecule (Slika 6).

Riža. 6. Upravljanje testom.

teško? ne raspravljam. Ali takav kompleks upravljanja konfiguracijom postao je sveobuhvatan odgovor na mnoga pitanja vezana uz automatizaciju konfiguracije poslužitelja. Sada standardni poslužitelji trgovaca uvijek imaju strogo definiranu konfiguraciju. CMS, za razliku od inženjera, neće zaboraviti dodati potrebne postavke, kreirati korisnike i izvršiti desetke ili stotine potrebnih postavki.

Danas nema "tajnog znanja" u postavkama poslužitelja i okruženja. Sve potrebne značajke prikazane su u priručniku. Nema više kreativnosti i nejasnih uputa: “Instalirajte ga kao obični Oracle, ali trebate navesti nekoliko sysctl postavki i dodati korisnike sa potrebnim UID-om. Pitaj dečke u operaciji, oni znaju".

Sposobnost otkrivanja odstupanja u konfiguraciji i njihovog proaktivnog ispravljanja pruža bezbrižnost. Bez sustava za upravljanje konfiguracijom ovo obično izgleda drugačije. Problemi se gomilaju dok jednog dana ne “pucaju” u proizvodnju. Zatim se provodi debrifing, konfiguracije se provjeravaju i ispravljaju. I ciklus se opet ponavlja

I naravno, ubrzali smo puštanje servera u rad s nekoliko dana na sate.

Pa, na samu novogodišnju noć, kada su djeca radosno odmatala darove, a odrasli željeli želje dok su zvona udarala, naši su inženjeri migrirali SAP sustav na nove poslužitelje. Čak će i Djed Mraz reći da su najbolja čuda ona koja su dobro pripremljena.

PS Naš tim se često susreće s činjenicom da korisnici žele riješiti probleme upravljanja konfiguracijom što je jednostavnije moguće. Idealno, kao čarolijom - s jednim alatom. Ali u životu je sve kompliciranije (da, srebrni meci nisu ponovno isporučeni): morate stvoriti cijeli proces pomoću alata koji su prikladni za tim kupca.

Autor: Sergej Artemov, arhitekt odjela DevOps rješenja "Jet Infosustavi"

Izvor: www.habr.com