Urte Berria hurbiltzen ari zen. Herrialde osoko haurrek jadanik gutunak bidali zizkioten Santa Clausi edo opariak egin zizkioten beren buruari, eta salmenten apoteosirako prestatzen ari zen haien arduradun nagusia, dendari nagusietako bat. Abenduan, bere datu-zentroaren karga hainbat aldiz handitzen da. Hori dela eta, konpainiak datu-zentroa modernizatzea eta zerbitzu-bizitzaren amaierara iristen ari ziren ekipoen ordez dozena bat zerbitzari berri martxan jartzea erabaki zuen. Honek elur malutaren atzealdean amaitzen du istorioa, eta thriller-a hasten da.

Ekipamendua salmenten gailurra baino hilabete batzuk lehenago iritsi zen gunera. Eragiketa-zerbitzuak, jakina, badaki nola eta zer konfiguratu zerbitzarietan produkzio ingurunera ekartzeko. Baina hori automatizatu eta giza faktorea ezabatu behar genuen. Horrez gain, zerbitzariak enpresarentzat funtsezkoak ziren SAP sistema multzo bat migratu aurretik ordezkatu ziren.

Zerbitzari berriak martxan jartzea epe bati zorrozki lotuta zegoen. Eta mugitzeak arriskuan jartzea ekarri zuen bai mila milioi opari bidaltzea bai sistemen migrazioa. Aita Frost eta Santa Claus-ek osatutako talde batek ere ezin izan du data aldatu - SAP sistema biltegia kudeatzeko urtean behin bakarrik transferi dezakezu. Abenduaren 31tik urtarrilaren 1era bitarte, dendariaren biltegi erraldoiek, guztira 20 futbol-zelaiko tamainakoak, 15 orduz gelditzen dute lana. Eta hau da sistema mugitzeko denbora-tarte bakarra. Zerbitzariak sartzerakoan ez genuen errorerako tarterik izan.

Argi esango dut: nire istorioak gure taldeak erabiltzen dituen tresnak eta konfigurazio kudeaketa prozesua islatzen du.

Konfigurazioa kudeatzeko konplexuak hainbat maila ditu. Funtsezko osagaia CMS sistema da. Eragiketa industrialean, mailaren bat ez egoteak, ezinbestean, mirari desatseginak ekarriko lituzke.

OS instalazioen kudeaketa

Lehenengo maila zerbitzari fisiko eta birtualetan sistema eragileen instalazioa kudeatzeko sistema bat da. Oinarrizko OS konfigurazioak sortzen ditu, giza faktorea ezabatuz.

Sistema hau erabiliz, automatizazio gehiagorako egokia den sistema eragilea duten zerbitzari-instantzia estandarrak jaso ditugu. "Isurketa" bitartean tokiko erabiltzaileen eta SSH gako publikoen gutxieneko multzoa jaso zuten, baita sistema eragilearen konfigurazio koherentea ere. Zerbitzariak CMS bidez kudeatzea ziurtatu genezake eta ziur geunden ez zegoela sorpresarik "behean" sistema eragilearen mailan.

Instalazioa kudeatzeko sistemaren "gehienezko" zeregina zerbitzariak automatikoki konfiguratzea da BIOS/Firmware mailatik OSra. Hemen asko ekipamenduaren eta konfigurazio zereginen araberakoa da. Ekipamendu heterogeneoetarako, kontuan hartu dezakezu REDFISH APIa. Hardware guztia saltzaile batekoa bada, sarritan erosoagoa da prest egindako kudeaketa tresnak erabiltzea (adibidez, HP ILO Amplifier, DELL OpenManage, etab.).

OS zerbitzari fisikoetan instalatzeko, Cobbler ezaguna erabili dugu, eragiketa zerbitzuarekin adostutako instalazio-profilen multzoa definitzen duena. Azpiegitura zerbitzari berri bat gehitzean, ingeniariak zerbitzariaren MAC helbidea Cobbler-en beharrezko profilarekin lotu zuen. Saretik lehen aldiz abiaraztean, zerbitzariak aldi baterako helbide bat eta sistema eragile berri bat jaso zituen. Ondoren, helburuko VLAN/IP helbidera transferitu zen eta lanean jarraitu zuen. Bai, VLAN aldatzeak denbora behar du eta koordinazioa eskatzen du, baina ekoizpen-ingurunean zerbitzaria ustekabean instalatzearen aurka babes gehigarria eskaintzen du.

HashiСorp Packer erabiliz prestatutako txantiloietan oinarritutako zerbitzari birtualak sortu ditugu. Arrazoia bera zen: sistema eragilea instalatzean giza akats posibleak saihestea. Baina, zerbitzari fisikoek ez bezala, Packer-ek PXE, sare abiarazte eta VLAN aldaketen beharra ezabatzen du. Horrek zerbitzari birtualak sortzea erraztu eta erraztu du.

Arroza. 1. Sistema eragileen instalazioa kudeatzea.

Sekretuak kudeatzea

Edozein konfigurazio kudeatzeko sistemak erabiltzaile arruntei ezkutatu beharreko datuak ditu, baina sistemak prestatzeko beharrezkoak direnak. Hauek tokiko erabiltzaileen eta zerbitzu-kontuen pasahitzak, ziurtagiri-gakoak, hainbat API-token, etab. "Sekretuak" deitu ohi dira.

Ez baduzu hasiera-hasieratik zehazten sekretu horiek non eta nola gorde, orduan, informazioaren segurtasun-baldintzen larritasunaren arabera, biltegiratze metodo hauek litekeena da:

• zuzenean konfigurazio-kontrol-kodean edo biltegiko fitxategietan;
• konfigurazioa kudeatzeko tresna espezializatuetan (adibidez, Ansible Vault);
• CI/CD sistemetan (Jenkins/TeamCity/GitLab/etab.) edo konfigurazio kudeaketa sistemetan (Ansible Tower/Ansible AWX);
• sekretuak “eskuz” ere transferi daitezke. Adibidez, toki zehatz batean jartzen dira, eta, ondoren, konfigurazio kudeatzeko sistemek erabiltzen dituzte;
• aurrekoen hainbat konbinazio.

Metodo bakoitzak bere desabantailak ditu. Nagusia sekretuetara sartzeko politikarik eza da: ezinezkoa edo zaila da sekretu batzuk nork erabil ditzakeen zehaztea. Beste desabantaila bat sarbide-ikuskaritza eta bizi-ziklo osoa ez izatea da. Nola ordezkatu azkar, adibidez, kodean eta erlazionatutako hainbat sistematan idatzita dagoen gako publiko bat?

HashiCorp Vault biltegiratze sekretu zentralizatua erabili dugu. Honek aukera eman zigun:

• gorde sekretuak seguru. Zifratuta daude, eta norbaitek Vault datu-baserako sarbidea lortzen badu ere (adibidez, babeskopia batetik leheneratuz), ezin izango ditu bertan gordetako sekretuak irakurri;
• sekretuak sartzeko politikak antolatu. Horiei “esleitutako” sekretuak soilik daude erabilgarri erabiltzaile eta aplikazioentzat;
• sekretuetarako sarbidea ikuskatzeko. Sekretuak dituzten ekintzak Vault-en auditoretza-erregistroan erregistratzen dira;
• sekretuak lantzeko “bizi-ziklo” oso bat antolatu. Sortu, baliogabetu, iraungitze-data ezarri, etab.
• sekretuetarako sarbidea behar duten beste sistemekin integratzeko erraza;
• eta, gainera, muturreko enkriptatzea, sistema eragilearen eta datu-basearen behin-behineko pasahitzak, baimendutako zentroen ziurtagiriak, etab.

Orain pasa gaitezen autentifikazio- eta baimen-sistema zentralera. Hori gabe egitea posible zen, baina erlazionatutako sistema askotan erabiltzaileak administratzea ez da hutsala. LDAP zerbitzuaren bidez autentifikazioa eta baimena konfiguratu ditugu. Bestela, Vault-ek etengabe jaulki eta jarraitu beharko lituzke erabiltzaileentzako autentifikazio-tokenak. Eta erabiltzaileak ezabatzeak eta gehitzeak "sortu al dut/ezabatu al dut erabiltzaile kontu hau nonahi?" bilaketa bihurtuko litzateke.

Gure sistemari beste maila bat gehitzen diogu: sekretuen kudeaketa eta autentifikazio/baimen zentrala:

Arroza. 2. Sekretuen kudeaketa.

Konfigurazioaren kudeaketa

Muinera iritsi gara: CMS sistemara. Gure kasuan, Ansible eta Red Hat Ansible AWX-en konbinazioa da.

Ansibleren ordez, Chef, Puppet, SaltStack erabil daiteke. Hainbat irizpideren arabera aukeratu dugu Ansible.

• Lehenik eta behin, aldakortasuna da. Kontrolerako prest dauden moduluen multzoa inpresioa egiten du. Eta nahikoa ez baduzu, GitHub eta Galaxy-n bilatu dezakezu.
• Bigarrenik, ez dago kudeatutako ekipoetan agenteak instalatu eta lagundu beharrik, kargarekin oztopatzen ez dutela frogatu eta "laster-markak" ez daudela baieztatu.
• Hirugarrenik, Ansiblek sartzeko oztopo baxua du. Ingeniari eskudun batek laneko liburu bat idatziko du literalki produktuarekin lan egiten duen lehen egunean.

Baina produkzio ingurune batean Ansible bakarrik ez zen nahikoa guretzat. Bestela, arazo asko sortuko lirateke sarbidea mugatzearekin eta administratzaileen ekintzak ikuskatzearekin. Nola mugatu sarbidea? Azken finean, departamentu bakoitzak zerbitzari multzo “bere” kudeatzea (irakur ezazu: exekutatu Ansible playbook) beharrezkoa zen. Nola baimendu langile jakin batzuek soilik Ansible-ko liburu zehatzak exekutatzeko? Edo nola jarraitu playbook-a nork abiarazi zuen Ansible exekutatzen duten zerbitzarietan eta ekipoetan tokiko ezagutza asko ezarri gabe?

Red Hat-ek konpontzen du horrelako arazoen lehoia Ansible Dorrea, edo bere kode irekiko upstream proiektua Ansible AWX. Horregatik nahiago genuen bezeroarentzat.

Eta ukitu bat gehiago gure CMS sistemaren erretratuari. Ansible playbook kode biltegiaren kudeaketa sistemetan gorde behar da. Badugu GitLab CE.

Beraz, konfigurazioak berak Ansible/Ansible AWX/GitLab konbinazio baten bidez kudeatzen dira (ikus 3. irudia). Jakina, AWX/GitLab autentifikazio sistema bakar batekin integratuta dago eta Ansible playbook HashiCorp Vault-ekin integratuta dago. Konfigurazioak Ansible AWX bidez soilik sartzen dira ekoizpen-ingurunean, eta bertan "jokoaren arau" guztiak zehazten dira: nork konfigura dezakeen zer, non lortu CMSaren konfigurazio-kudeaketa kodea, etab.

Arroza. 3. Konfigurazioaren kudeaketa.

Proben kudeaketa

Gure konfigurazioa kode moduan aurkezten da. Hori dela eta, software-garatzaileen arau berdinekin jokatzera behartuta gaude. Garapen-prozesuak, etengabeko probak, konfigurazio-kodearen entrega eta ekoizpen-zerbitzarietan aplikatzeko prozesuak antolatu behar genituen.

Hori berehala egiten ez bada, konfiguraziorako idatzitako rolak onartzen eta aldatzeari utziko lioke, edo ekoizpenean abian jartzeari utziko lioke. Min horren sendabidea ezagutzen da, eta frogatu du proiektu honetan:

• rol bakoitza unitate-probek estaltzen dute;
• probak automatikoki egiten dira konfigurazioak kudeatzen dituen kodean aldaketaren bat dagoen bakoitzean;
• konfigurazio-kudeaketako kodearen aldaketak produkzio-ingurunean askatzen dira proba guztiak eta kodea berrikustea arrakastaz gainditu ondoren.

Kodeen garapena eta konfigurazio kudeaketa lasaiago eta aurreikusgarriagoa bihurtu da. Etengabeko probak antolatzeko, GitLab CI/CD toolkit erabili genuen, eta hartu Molekula ansiblea.

Konfigurazioa kudeatzeko kodean aldaketa bat dagoen bakoitzean, GitLab CI/CD-k Molecule-ra deitzen du:

• kodearen sintaxia egiaztatzen du,
• Docker edukiontzia altxatzen du,
• aldatutako kodea aplikatzen dio sortutako edukiontziari,
• Idempotentziaren rola egiaztatzen du eta kode honen probak egiten ditu (hemen granulartasuna rol ansible mailan dago, ikus 4. irudia).

Konfigurazioak produkzio-ingurunean entregatu ditugu Ansible AWX erabiliz. Eragiketa-ingeniariek konfigurazio-aldaketak aplikatu zituzten aurrez zehaztutako txantiloien bidez. AWX-ek modu independentean "eskatu" zion kodearen azken bertsioa GitLab adar nagusitik erabiltzen zen bakoitzean. Horrela, probatu gabeko edo zaharkitutako kodea erabiltzea baztertu dugu produkzio ingurunean. Jakina, kodea adar nagusian sartu zen proba, berrikuspena eta onartu ondoren bakarrik.

Arroza. 4. Rolen proba automatikoa GitLab CI/CD-n.

Produkzio sistemen funtzionamenduarekin lotutako arazo bat ere badago. Bizitza errealean, oso zaila da CMS kodearen bidez soilik konfigurazio-aldaketak egitea. Larrialdi-egoerak sortzen dira ingeniari batek konfigurazioa "hemen eta orain" aldatu behar duenean, kodearen edizio, proba, onespen, etab.

Ondorioz, eskuzko aldaketen ondorioz, desadostasunak agertzen dira ekipo mota berean konfigurazioan (adibidez, sysctl ezarpenak modu ezberdinean konfiguratzen dira HA klusterreko nodoetan). Edo ekipoaren benetako konfigurazioa CMS kodean zehaztutakoaren desberdina da.

Hori dela eta, etengabeko probak egiteaz gain, ekoizpen-inguruneak konfigurazio-desberdintasunak dauden egiaztatzen dugu. Aukerarik errazena aukeratu dugu: CMS konfigurazio-kodea "exekutatu lehorrean" moduan exekutatu, hau da, aldaketarik aplikatu gabe, baina aurreikusitako eta benetako konfigurazioaren arteko desadostasun guztien berri emanez. Hau inplementatu dugu aldian-aldian Ansible playbook guztiak exekutatuta ekoizpen-zerbitzarietan "-check" aukerarekin. Beti bezala, Ansible AWX arduratzen da playbook abiarazi eta eguneratuta mantentzeaz (ikus 5. irudia):

Arroza. 5. Ansible AWX-en konfigurazio-desadostasunak egiaztatzen ditu.

Egiaztapenak egin ondoren, AWX-k desadostasun-txosten bat bidaltzen die administratzaileei. Konfigurazio problematikoa aztertzen dute eta gero konpontzen dute doitutako liburuen bidez. Horrela mantentzen dugu konfigurazioa produkzio-ingurunean eta CMS beti eguneratuta eta sinkronizatuta dago. Horrek "mirari" desatseginak ezabatzen ditu CMS kodea "ekoizpen" zerbitzarietan erabiltzen denean.

Orain Ansible AWX/GitLab/Molecule-k osatutako proba-geruza garrantzitsu bat dugu (6. irudia).

Arroza. 6. Proben kudeaketa.

Zaila? Ez dut argudiatzen. Baina konfigurazioaren kudeaketa konplexu hori zerbitzariaren konfigurazioaren automatizazioari lotutako galdera askoren erantzun integrala bihurtu da. Orain dendari baten zerbitzari estandarrek beti dute zorrozki definitutako konfigurazioa. CMS, ingeniari batek ez bezala, ez du ahaztuko beharrezko ezarpenak gehitzea, erabiltzaileak sortzea eta beharrezko dozenaka edo ehunka ezarpen egitea.

Gaur egun ez dago "ezagutza sekreturik" zerbitzarien eta inguruneen ezarpenetan. Beharrezko ezaugarri guztiak jolas liburuan islatzen dira. Ez dago sormen eta argibide lauso gehiago: "Instalatu Oracle arrunt bezala, baina sysctl ezarpen pare bat zehaztu eta erabiltzaileak gehitu behar dituzu beharrezko UIDa. Galdetu lanean ari diren mutilei, badakite'.

Konfigurazio-desadostasunak antzemateko eta modu proaktiboan zuzentzeko gaitasunak lasaitasuna ematen du. Konfigurazioa kudeatzeko sistemarik gabe, normalean itxura desberdina da. Arazoak pilatzen dira egun batean produkziora "tiro" egiten diren arte. Ondoren, debriefing bat egiten da, konfigurazioak egiaztatu eta zuzentzen dira. Eta zikloa berriro errepikatzen da

Eta, jakina, zerbitzariak martxan jartzea bizkortu genuen hainbat egunetatik orduetara.

Bada, Urtezahar gauean bertan, haurrak poz-pozik opariak ateratzen ari zirenean eta helduak desioak egiten ari zirenean, txirrinak jotzen zutenean, gure ingeniariek SAP sistema zerbitzari berrietara migratu zuten. Santa Claus-ek ere esango du miraririk onenak ondo prestatuta daudenak direla.

PS Gure taldeak askotan aurkitzen du bezeroek konfigurazio kudeaketa arazoak ahalik eta errazen konpondu nahi dituztela. Egokiena, magiaz bezala - tresna bakarrarekin. Baina bizitzan dena konplikatuagoa da (bai, zilarrezko balak ez ziren berriro entregatu): prozesu oso bat sortu behar duzu bezeroaren taldearentzat erosoak diren tresnak erabiliz.

Egilea: Sergey Artemov, saileko arkitektoa DevOps irtenbideak "Jet Infosystems"

Iturria: www.habr.com