Ĝi alproksimiĝis al la Nova Jaro. Infanoj tra la tuta lando jam sendis leterojn al Patro Kristnasko aŭ faris donacojn por si, kaj ilia ĉefa ekzekutisto, unu el la ĉefaj podetalistoj, prepariĝis por la apoteozo de la vendo. En decembro, la ŝarĝo sur ĝia datumcentro pliiĝas plurfoje. Tial la kompanio decidis modernigi la datumcentron kaj funkciigi plurajn dekojn da novaj serviloj anstataŭ ekipaĵoj, kiuj atingis la finon de sia funkcidaŭro. Tio finas la rakonton kontraŭ la fono de kirliĝantaj neĝeroj, kaj la suspensfilmo komenciĝas.
La ekipaĵo alvenis al la loko plurajn monatojn antaŭ la pinto de vendo. La operacia servo, kompreneble, scias kiel kaj kion agordi sur la serviloj por alporti ilin en la produktadmedion. Sed ni bezonis aŭtomatigi ĉi tion kaj forigi la homan faktoron. Krome, la serviloj estis anstataŭigitaj antaŭ la migrado de aro de SAP-sistemoj kiuj estis kritikaj por la firmao.
La ekfunkciigo de novaj serviloj estis strikte ligita al limdato. Kaj movi ĝin signifis endanĝerigi kaj la sendon de miliardo da donacoj kaj la migradon de sistemoj. Eĉ teamo konsistanta el Patro Frost kaj Santa Claus ne povis ŝanĝi la daton - vi povas transdoni la SAP-sistemon por mastrumado de magazenoj nur unufoje jare. De la 31-a de decembro ĝis la 1-a de januaro, la grandegaj magazenoj de la komercisto, entute la grandeco de 20 futbalkampoj, ĉesas sian laboron dum 15 horoj. Kaj ĉi tiu estas la sola tempodaŭro por movi la sistemon. Ni ne havis lokon por eraro dum enkondukado de serviloj.
Mi estu klara: mia rakonto reflektas la ilojn kaj agordajn administradprocezon kiujn nia teamo uzas.
La komplekso pri agorda administrado konsistas el pluraj niveloj. La ŝlosila komponanto estas la CMS-sistemo. En industria funkciado, la foresto de unu el la niveloj neeviteble kondukus al malagrablaj mirakloj.
Administrado de instalado de OS
La unua nivelo estas sistemo por administri la instaladon de operaciumoj sur fizikaj kaj virtualaj serviloj. Ĝi kreas bazajn OS-agordojn, forigante la homan faktoron.
Uzante ĉi tiun sistemon, ni ricevis normajn servilojn kun OS taŭga por plia aŭtomatigo. Dum la "verŝado" ili ricevis minimuman aron da lokaj uzantoj kaj publikaj SSH-ŝlosiloj, same kiel konsekvencan OS-agordon. Ni povus esti garantiitaj administri la servilojn per la CMS kaj estis certaj, ke ne estas surprizoj "malsupre" ĉe la OS-nivelo.
La "maksimuma" tasko por la instala administradsistemo estas aŭtomate agordi servilojn de la BIOS/Firmware-nivelo ĝis la OS. Multo ĉi tie dependas de la ekipaĵo kaj aranĝotaskoj. Por heterogenaj ekipaĵoj, vi povas konsideri . Se la tuta aparataro estas de unu vendisto, tiam estas ofte pli oportune uzi pretajn mastrumajn ilojn (ekzemple HP ILO Amplifier, DELL OpenManage, ktp.).
Por instali la OS sur fizikaj serviloj, ni uzis la konatan Cobbler, kiu difinas aron da instalprofiloj interkonsentitaj kun la operacia servo. Aldonante novan servilon al la infrastrukturo, la inĝeniero ligis la MAC-adreson de la servilo al la postulata profilo en Cobbler. Kiam ekfunkciigis tra la reto por la unua fojo, la servilo ricevis provizoran adreson kaj freŝan OS. Tiam ĝi estis transdonita al la cela VLAN/IP-adresado kaj daŭrigis laboron tie. Jes, ŝanĝi VLAN postulas tempon kaj postulas kunordigon, sed ĝi provizas plian protekton kontraŭ hazarda instalado de la servilo en produktadmedio.
Ni kreis virtualajn servilojn surbaze de ŝablonoj preparitaj per HashiСorp Packer. La kialo estis la sama: malhelpi eblajn homajn erarojn instalante la OS. Sed, kontraste kun fizikaj serviloj, Packer forigas la bezonon de PXE, relanĉo kaj VLAN-ŝanĝoj. Ĉi tio faciligis kaj simpligis krei virtualajn servilojn.
Rizo. 1. Administri la instaladon de operaciumoj.
Administrado de sekretoj
Ajna agorda administradsistemo enhavas datumojn, kiuj devus esti kaŝitaj de ordinaraj uzantoj, sed necesas por prepari sistemojn. Ĉi tiuj estas pasvortoj por lokaj uzantoj kaj servokontoj, atestilŝlosiloj, diversaj API-Tokens, ktp. Ili estas kutime nomitaj "sekretoj."
Se vi ne determinas ekde la komenco, kie kaj kiel konservi ĉi tiujn sekretojn, tiam, laŭ la severeco de la informsekurecaj postuloj, verŝajne la sekvaj konservaj metodoj estas:
- rekte en la agorda kontrolo-kodo aŭ en dosieroj en la deponejo;
- en specialigitaj agordaj administradiloj (ekzemple, Ansible Vault);
- en CI/KD-sistemoj (Jenkins/TeamCity/GitLab/ktp.) aŭ en agordaj administradsistemoj (Ansible Tower/Ansible AWX);
- sekretoj ankaŭ povas esti transdonitaj "mane". Ekzemple, ili estas aranĝitaj en specifa loko, kaj tiam ili estas uzataj de agordaj administradsistemoj;
- diversaj kombinoj de la supre.
Ĉiu metodo havas siajn proprajn malavantaĝojn. La ĉefa estas la manko de politikoj por aliro al sekretoj: estas neeble aŭ malfacile determini, kiu povas uzi iujn sekretojn. Alia malavantaĝo estas la manko de alirkontrolado kaj plena vivociklo. Kiel rapide anstataŭigi, ekzemple, publikan ŝlosilon, kiu estas skribita en la kodo kaj en kelkaj rilataj sistemoj?
Ni uzis la centralizitan sekretan stokadon HashiCorp Vault. Ĉi tio permesis al ni:
- konservi sekretojn sekuraj. Ili estas ĉifritaj, kaj eĉ se iu akiras aliron al la datumbazo Vault (ekzemple, restarigante ĝin de sekurkopio), ili ne povos legi la sekretojn tie konservitajn;
- organizi politikojn por aliro al sekretoj. Nur la sekretoj "asignitaj" al ili estas disponeblaj por uzantoj kaj aplikaĵoj;
- revizia aliro al sekretoj. Ĉiuj agoj kun sekretoj estas registritaj en la auditorio de Vault;
- organizi plenkreskan "vivciklon" de laboro kun sekretoj. Ili povas esti kreitaj, revokitaj, agordi limdaton, ktp.
- facile integrebla kun aliaj sistemoj, kiuj bezonas aliron al sekretoj;
- kaj ankaŭ uzu fin-al-finan ĉifradon, unufojajn pasvortojn por la OS kaj datumbazo, atestiloj de rajtigitaj centroj, ktp.
Nun ni transiru al la centra aŭtentikiga kaj rajtiga sistemo. Eblis malhavi ĝin, sed administri uzantojn en multaj rilataj sistemoj estas tro sensignifa. Ni agordis aŭtentikigon kaj rajtigon per la LDAP-servo. Alie, Vault devus senĉese elsendi kaj konservi trakon de aŭtentigaj signoj por uzantoj. Kaj forigi kaj aldoni uzantojn fariĝus serĉo "ĉu mi kreis/forviŝis ĉi tiun uzantkonton ĉie?"
Ni aldonas alian nivelon al nia sistemo: administrado de sekretoj kaj centra aŭtentigo/rajtigo:
Rizo. 2. Sekreta administrado.
Administrado de agordo
Ni atingis la kernon - la CMS-sistemo. En nia kazo, ĉi tio estas kombinaĵo de Ansible kaj Red Hat Ansible AWX.
Anstataŭ Ansible, Chef, Puppet, SaltStack povas esti uzata. Ni elektis Ansible laŭ pluraj kriterioj.
- Unue, ĝi estas ĉiuflankeco. Aro da pretaj moduloj por kontrolo . Kaj se vi ne havas sufiĉe da ĝi, vi povas serĉi sur GitHub kaj Galaxy.
- Due, ne necesas instali kaj subteni agentojn sur administritaj ekipaĵoj, pruvi, ke ili ne malhelpas la ŝarĝon, kaj konfirmi la foreston de "legosignoj".
- Trie, Ansible havas malaltan barieron al eniro. Kompetenta inĝeniero skribos laborlibron laŭvorte en la unua tago de laboro kun la produkto.
Sed Ansible sole en produktadmedio ne sufiĉis por ni. Alie, multaj problemoj ekestus kun limigado de aliro kaj kontrolado de la agoj de administrantoj. Kiel limigi aliron? Post ĉio, estis necese, ke ĉiu fako administru (legu: ruli la Ansible-ludlibron) "sia propra" aro da serviloj. Kiel permesi nur iujn dungitojn ruli specifajn ludlibrojn de Ansible? Aŭ kiel spuri kiu lanĉis la ludlibron sen instali multajn lokajn scion sur serviloj kaj ekipaĵoj kurantaj Ansible?
La plej granda parto de tiaj aferoj estas solvita de Red Hat , aŭ lia malfermfonta kontraŭflua projekto . Tial ni preferis ĝin por la kliento.
Kaj ankoraŭ unu tuŝo al la portreto de nia CMS-sistemo. Ansible-ludlibro devas esti konservita en kodaj deponejoj-administradsistemoj. Ni havas ĝin .
Do, la agordoj mem estas administritaj per kombinaĵo de Ansible/Ansible AWX/GitLab (vidu Fig. 3). Kompreneble, AWX/GitLab estas integrita kun ununura aŭtentikiga sistemo, kaj Ansible-ludlibro estas integrita kun HashiCorp Vault. Agordoj eniras la produktadmedion nur per Ansible AWX, en kiu ĉiuj "ludaj reguloj" estas specifitaj: kiu povas agordi kion, kie akiri la agordan administran kodon por la CMS, ktp.
Rizo. 3. Administrado de agordo.
Testadministrado
Nia agordo estas prezentita en kodformo. Tial ni estas devigitaj ludi laŭ la samaj reguloj kiel programistoj. Ni bezonis organizi la procezojn de disvolviĝo, kontinua testado, livero kaj aplikado de agorda kodo al produktaj serviloj.
Se tio ne estas tuj farita, tiam la roloj skribitaj por la agordo aŭ ĉesos esti subtenataj kaj modifitaj, aŭ ĉesus esti lanĉitaj en produktado. La kuraco por ĉi tiu doloro estas konata, kaj ĝi pruvis sin en ĉi tiu projekto:
- ĉiu rolo estas kovrita per unuotestoj;
- testoj ruliĝas aŭtomate kiam ajn estas ajna ŝanĝo en la kodo kiu administras la agordojn;
- ŝanĝoj en la agorda administra kodo estas liberigitaj en la produktadmedion nur post sukcese trapaso de ĉiuj testoj kaj koda revizio.
Koda evoluo kaj agorda administrado fariĝis pli trankvilaj kaj antaŭvideblaj. Por organizi kontinuan testadon, ni uzis la ilaron GitLab CI/CD, kaj prenis .
Kiam ajn estas ŝanĝo en la agorda administra kodo, GitLab CI/CD nomas Molecule:
- ĝi kontrolas la kodan sintakson,
- levas la Docker-ujon,
- aplikas la modifitan kodon al la kreita ujo,
- kontrolas la rolon por idempotenco kaj faras testojn por ĉi tiu kodo (la granulareco ĉi tie estas ĉe la ansible rolnivelo, vidu Fig. 4).
Ni liveris agordojn al la produktadmedio uzante Ansible AWX. Operaciaj inĝenieroj aplikis agordajn ŝanĝojn per antaŭdifinitaj ŝablonoj. AWX sendepende "petis" la lastan version de la kodo de la GitLab majstra branĉo ĉiufoje kiam ĝi estis uzata. Tiel ni ekskludis la uzon de neprovita aŭ malmoderna kodo en la produktadmedio. Nature, la kodo eniris la majstran branĉon nur post testado, revizio kaj aprobo.
Rizo. 4. Aŭtomata testado de roloj en GitLab CI/CD.
Estas ankaŭ problemo asociita kun la funkciado de produktadsistemoj. En la reala vivo, estas tre malfacile fari agordajn ŝanĝojn per CMS-kodo sole. Krizaj situacioj aperas kiam inĝeniero devas ŝanĝi la agordon "ĉi tie kaj nun", sen atendado de kodoredaktado, testado, aprobo ktp.
Kiel rezulto, pro manaj ŝanĝoj, diferencoj aperas en la agordo sur la sama speco de ekipaĵo (ekzemple, sysctl-agordoj estas agordita malsame sur HA-clusternodoj). Aŭ la reala agordo sur la ekipaĵo diferencas de tiu specifita en la CMS-kodo.
Tial, krom kontinua testado, ni kontrolas produktadmediojn por agordaj diferencoj. Ni elektis la plej simplan opcion: ruli la agordan kodon de CMS en reĝimo "seka kurado", tio estas, sen apliki ŝanĝojn, sed kun sciigo pri ĉiuj diferencoj inter la planita kaj reala agordo. Ni efektivigis ĉi tion periode kurante ĉiujn Ansible-ludlibrojn kun la opcio "—check" sur produktaj serviloj. Kiel ĉiam, Ansible AWX respondecas pri lanĉo kaj teni la ludlibron ĝisdatigita (vidu Fig. 5):
Rizo. 5. Kontroloj por agordaj diferencoj en Ansible AWX.
Post kontroloj, AWX sendas malkongruan raporton al administrantoj. Ili studas la probleman agordon kaj poste riparas ĝin per alĝustigitaj ludlibroj. Jen kiel ni konservas la agordon en la produktadmedio kaj la CMS ĉiam estas ĝisdatigita kaj sinkronigita. Ĉi tio forigas malagrablajn "miraklojn" kiam CMS-kodo estas uzata sur "produktadaj" serviloj.
Ni nun havas gravan testan tavolon konsistantan el Ansible AWX/GitLab/Molecule (Figuro 6).
Rizo. 6. Testa administrado.
Malfacila? Mi ne kverelas. Sed tia komplekso de agorda administrado fariĝis ampleksa respondo al multaj demandoj ligitaj al la aŭtomatigo de servila agordo. Nun la normaj serviloj de podetalisto ĉiam havas strikte difinitan agordon. CMS, male al inĝeniero, ne forgesos aldoni la necesajn agordojn, krei uzantojn kaj plenumi dekojn aŭ centojn da postulataj agordoj.
Ne ekzistas "sekreta scio" en la agordoj de serviloj kaj medioj hodiaŭ. Ĉiuj necesaj funkcioj estas reflektitaj en la ludlibro. Ne plu kreemo kaj neklaraj instrukcioj: "Instalu ĝin kiel ordinara Oracle, sed vi devas specifi kelkajn sysctl-agordojn kaj aldoni uzantojn kun la bezonata UID. Demandu la ulojn en operacio, ili scias".
La kapablo detekti agordajn diferencojn kaj korekti ilin proaktive donas trankvilon. Sen agorda administra sistemo, ĉi tio kutime aspektas malsama. Problemoj amasiĝas ĝis unu tagon ili "pafas" en produktadon. Tiam debriefing estas farita, konfiguracioj estas kontrolitaj kaj korektitaj. Kaj la ciklo denove ripetas
Kaj kompreneble ni akcelis la lanĉon de serviloj en funkciadon de pluraj tagoj ĝis horoj.
Nu, en la silvestro mem, kiam infanoj ĝoje malvolvis donacojn kaj plenkreskuloj faris dezirojn dum la sonoradoj sonis, niaj inĝenieroj migris la SAP-sistemon al novaj serviloj. Eĉ Patro Niko diros, ke la plej bonaj mirakloj estas tiuj, kiuj estas bone preparitaj.
PS Nia teamo ofte renkontas la fakton, ke klientoj volas solvi problemojn pri agorda administrado kiel eble plej simple. Ideale, kvazaŭ per magio - per unu ilo. Sed en la vivo ĉio estas pli komplika (jes, arĝentaj kugloj ne estis liveritaj denove): vi devas krei tutan procezon uzante ilojn konvenajn por la teamo de la kliento.
Aŭtoro: Sergey Artemov, faka arkitekto "Jetaj Infosistemoj"
fonto: www.habr.com