Bližila se Nova godina. Djeca širom zemlje već su slala pisma Djeda Mrazu ili sama sebi pravila poklone, a njihov glavni izvršilac, jedan od najvećih trgovaca, pripremao se za apoteozu prodaje. U decembru se opterećenje njegovog data centra povećava nekoliko puta. Zbog toga je kompanija odlučila da modernizuje data centar i pusti u rad nekoliko desetina novih servera umesto opreme koja je bila na kraju svog radnog veka. Ovim se priča završava na pozadini uskovitlanih pahulja i počinje triler.

Oprema je stigla na lokaciju nekoliko mjeseci prije vrhunca prodaje. Operativni servis, naravno, zna kako i šta da konfiguriše na serverima kako bi ih uveo u proizvodno okruženje. Ali morali smo to automatizirati i eliminirati ljudski faktor. Osim toga, serveri su zamijenjeni prije migracije skupa SAP sistema koji su bili kritični za kompaniju.

Puštanje u rad novih servera bilo je strogo vezano za rok. A njegovo premještanje značilo je ugroziti i isporuku milijardu poklona i migraciju sistema. Čak ni tim koji čine Djed Mraz i Djed Mraz nije mogao promijeniti datum - SAP sistem za upravljanje skladištem možete prenijeti samo jednom godišnje. Od 31. decembra do 1. januara, ogromna skladišta maloprodaje, ukupne veličine 20 fudbalskih terena, prestaju sa radom na 15 sati. I ovo je jedini vremenski period za pomjeranje sistema. Nismo imali prostora za greške prilikom uvođenja servera.

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

Kompleks upravljanja konfiguracijom sastoji se od nekoliko nivoa. Ključna komponenta je CMS sistem. U industrijskom radu, odsustvo jednog od nivoa neminovno bi dovelo do neprijatnih čuda.

Upravljanje instalacijom OS-a

Prvi nivo je sistem za upravljanje instalacijom operativnih sistema na fizičkim i virtuelnim serverima. Kreira osnovne konfiguracije OS-a, eliminirajući ljudski faktor.

Koristeći ovaj sistem, dobili smo standardne serverske instance sa operativnim sistemom pogodnim za dalju automatizaciju. Tokom "presipanja" dobili su minimalan set lokalnih korisnika i javnih SSH ključeva, kao i konzistentnu konfiguraciju OS-a. Mogli smo biti zagarantovani da upravljamo serverima preko CMS-a i bili smo sigurni da nema iznenađenja „dole“ na nivou OS.

"Maksimalni" zadatak za sistem upravljanja instalacijom je da automatski konfiguriše servere od nivoa BIOS-a/Firmvera do OS-a. Mnogo toga ovisi o opremi i zadacima postavljanja. Za heterogenu opremu, možete razmotriti REDFISH API. Ako je sav hardver od jednog dobavljača, onda je često zgodnije koristiti gotove alate za upravljanje (na primjer, HP ILO Amplifier, DELL OpenManage, itd.).

Za instalaciju OS-a na fizičke servere koristili smo dobro poznati Cobbler, koji definira skup instalacionih profila dogovorenih sa servisom rada. Prilikom dodavanja novog servera infrastrukturi, inženjer je vezao MAC adresu servera sa potrebnim profilom u Cobbleru. Prilikom prvog pokretanja preko mreže, server je dobio privremenu adresu i novi OS. Zatim je prebačen na ciljno VLAN/IP adresiranje i tamo je nastavljen rad. Da, promena VLAN-a zahteva vreme i koordinaciju, ali pruža dodatnu zaštitu od slučajne instalacije servera u proizvodnom okruženju.

Napravili smo virtuelne servere na osnovu šablona pripremljenih pomoću HashiCorp Packer-a. Razlog je bio isti: spriječiti moguće ljudske greške prilikom instaliranja OS-a. Ali, za razliku od fizičkih servera, Packer eliminiše potrebu za PXE, podizanjem mreže i VLAN promjenama. Ovo je učinilo lakšim i jednostavnijim kreiranje virtuelnih servera.

Rice. 1. Upravljanje instalacijom operativnih sistema.

Upravljanje tajnama

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

Ako od samog početka ne odredite gdje i kako ćete pohraniti ove tajne, tada će, ovisno o ozbiljnosti zahtjeva sigurnosti informacija, vjerovatno sljedeće metode skladištenja:

• direktno u kontrolnom kodu konfiguracije ili u fajlovima u spremištu;
• u specijalizovanim alatima za upravljanje konfiguracijom (na primjer, Ansible Vault);
• u CI/CD sistemima (Jenkins/TeamCity/GitLab/itd.) ili u sistemima za upravljanje konfiguracijom (Ansible Tower/Ansible AWX);
• tajne se mogu prenositi i „ručnom kontrolom“. Na primjer, oni su postavljeni na određenoj lokaciji, a zatim ih koriste sistemi za upravljanje konfiguracijom;
• razne kombinacije gore navedenog.

Svaka metoda ima svoje nedostatke. Glavni je nedostatak politike pristupa tajnama: nemoguće je ili teško odrediti ko može koristiti određene tajne. Još jedan nedostatak je nedostatak revizije pristupa i punog životnog ciklusa. Kako brzo zamijeniti, na primjer, javni ključ koji je napisan u kodu i u nizu povezanih sistema?

Koristili smo centralizovano tajno skladište HashiCorp Vault. Ovo nam je omogućilo:

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

Sada pređimo na centralni sistem autentifikacije i autorizacije. Bilo je moguće bez toga, ali administriranje korisnika u mnogim povezanim sistemima je previše netrivijalno. Konfigurisali smo autentifikaciju i autorizaciju putem LDAP servisa. U suprotnom, Vault bi morao kontinuirano izdavati i pratiti tokene za autentifikaciju za korisnike. A brisanje i dodavanje korisnika pretvorilo bi se u potragu „da li sam posvuda kreirao/izbrisao ovaj korisnički nalog?“

Dodali smo još jedan nivo našem sistemu: upravljanje tajnama i centralnu autentifikaciju/autorizaciju:

Rice. 2. Upravljanje tajnama.

Upravljanje konfiguracijom

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

Umjesto Ansible-a mogu se koristiti Chef, Puppet, SaltStack. Ansible smo odabrali na osnovu nekoliko kriterijuma.

• Prvo, to je svestranost. Set gotovih modula za kontrolu to je impresivno. A ako ga nemate dovoljno, možete pretraživati ​​na GitHub i Galaxy.
• Drugo, nema potrebe instalirati i podržavati agente na upravljanoj opremi, dokazati da ne ometaju opterećenje i potvrditi odsustvo „markera“.
• Treće, Ansible ima nisku barijeru za ulazak. Kompetentni inženjer će napisati radnu knjigu bukvalno prvog dana rada sa proizvodom.

Ali sam Ansible u produkcijskom okruženju nije nam bio dovoljan. U suprotnom bi se pojavili mnogi problemi sa ograničavanjem pristupa i revizijom radnji administratora. Kako ograničiti pristup? Na kraju krajeva, bilo je neophodno da svako odeljenje upravlja (čitaj: pokreće Ansible playbook) „svojim“ skupom servera. Kako dozvoliti samo određenim zaposlenima da pokreću određene Ansible playbooks? Ili kako pratiti ko je pokrenuo playbook bez postavljanja puno lokalnog znanja o serverima i opremi koja pokreće Ansible?

Lavovski dio takvih problema rješava Red Hat Ansible Tower, ili njegov upstream projekat otvorenog koda Ansible AWX. Zato smo to preferirali za kupca.

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

Dakle, samim konfiguracijama se upravlja kombinacijom Ansible/Ansible AWX/GitLab (vidi sliku 3). Naravno, AWX/GitLab je integrisan sa jednim sistemom autentifikacije, a Ansible playbook je integrisan sa HashiCorp Vaultom. Konfiguracije ulaze u proizvodno okruženje samo preko Ansible AWX-a, u kojem su navedena sva “pravila igre”: ko šta može da konfiguriše, gde da dobije kod za upravljanje konfiguracijom za CMS, itd.

Rice. 3. Upravljanje konfiguracijom.

Upravljanje testom

Naša konfiguracija je predstavljena u obliku koda. Stoga smo primorani da igramo po istim pravilima kao i programeri softvera. Trebali smo organizirati procese razvoja, kontinuiranog testiranja, isporuke i primjene konfiguracijskog koda na proizvodne servere.

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

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

Razvoj koda i upravljanje konfiguracijom postali su mirniji i predvidljiviji. Da bismo organizovali kontinuirano testiranje, koristili smo GitLab CI/CD komplet alata i uzeli Ansible Molecule.

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

• provjerava sintaksu koda,
• podiže Docker kontejner,
• primjenjuje modificirani kod na kreirani kontejner,
• provjerava ulogu idempotencije i pokreće testove za ovaj kod (granularnost je ovdje na nivou ansible uloge, vidi sliku 4).

Isporučili smo konfiguracije u proizvodno okruženje koristeći Ansible AWX. Operativni inženjeri su primenili promene konfiguracije kroz unapred definisane šablone. AWX je nezavisno „zatražio“ najnoviju verziju koda od GitLab master grane svaki put kada je korišćen. Na ovaj način smo isključili upotrebu neprovjerenog ili zastarjelog koda u proizvodnom okruženju. Naravno, kod je ušao u glavnu granu tek nakon testiranja, pregleda i odobrenja.

Rice. 4. Automatsko testiranje uloga u GitLab CI/CD.

Postoji i problem vezan za rad proizvodnih sistema. U stvarnom životu, vrlo je teško napraviti promjene konfiguracije samo pomoću 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 konfigurisane na čvorovima HA klastera). Ili se stvarna konfiguracija na opremi razlikuje od one navedene u CMS kodu.

Stoga, pored kontinuiranog testiranja, provjeravamo proizvodna okruženja na odstupanja u konfiguraciji. Izabrali smo najjednostavniju opciju: pokretanje CMS konfiguracijskog koda u “dry run” modu, odnosno bez primjene promjena, ali uz obavijest o svim neslaganjima između planirane i stvarne konfiguracije. Ovo smo implementirali tako što smo povremeno pokretali sve Ansible playbookove sa opcijom “—check” na proizvodnim serverima. Kao i uvijek, Ansible AWX je odgovoran za pokretanje i ažuriranje priručnika (pogledajte sliku 5):

Rice. 5. Provjerava odstupanja u konfiguraciji u Ansible AWX.

Nakon provjere, AWX šalje izvještaj o neslaganju administratorima. Proučavaju problematičnu konfiguraciju, a zatim je popravljaju kroz prilagođene priručnike. Na ovaj način održavamo konfiguraciju u proizvodnom okruženju, a CMS je uvijek ažuriran i sinkroniziran. Ovo eliminiše neprijatna "čuda" kada se CMS kod koristi na "proizvodnim" serverima.

Sada imamo važan sloj za testiranje koji se sastoji od Ansible AWX/GitLab/Molecule (slika 6).

Rice. 6. Upravljanje testom.

Tesko? Ne raspravljam se. Ali takav kompleks upravljanja konfiguracijom postao je sveobuhvatan odgovor na mnoga pitanja vezana za automatizaciju konfiguracije servera. Sada standardni serveri trgovca uvijek imaju strogo definiranu konfiguraciju. CMS, za razliku od inženjera, neće zaboraviti dodati potrebna podešavanja, kreirati korisnike i izvršiti desetine ili stotine potrebnih postavki.

U postavkama servera i okruženja danas nema „tajnog znanja“. Sve potrebne karakteristike su prikazane u priručniku. Nema više kreativnosti i nejasnih uputa: “Instalirajte ga kao običan Oracle, ali morate odrediti nekoliko sysctl postavki i dodati korisnike sa potrebnim UID-om. Pitajte momke koji rade, oni znaju".

Sposobnost otkrivanja konfiguracijskih neslaganja i proaktivnog ispravljanja pruža bezbrižnost. Bez sistema za upravljanje konfiguracijom, ovo obično izgleda drugačije. Problemi se gomilaju sve dok jednog dana ne “pucaju” u proizvodnju. Zatim se vrši debrifing, konfiguracije se provjeravaju i ispravljaju. I ciklus se ponovo ponavlja

I naravno, ubrzali smo puštanje servera u rad sa nekoliko dana na nekoliko sati.

Pa, na samu novogodišnju noć, kada su djeca radosno odmotavala poklone, a odrasli smišljali želje uz zvonjavu, naši inženjeri su migrirali SAP sistem na nove servere. Čak će i Djed Mraz reći da su najbolja čuda ona koja su dobro pripremljena.

PS Naš tim se često susreće sa činjenicom da korisnici žele što jednostavnije riješiti probleme upravljanja konfiguracijom. Idealno, kao magijom - jednim alatom. Ali u životu je sve složenije (da, srebrni meci opet nisu isporučeni): morate kreirati cijeli proces koristeći alate koji su pogodni za tim kupca.

Autor: Sergej Artemov, arhitekta odeljenja DevOps rješenja "Jet Infosystems"

izvor: www.habr.com