Ilikuwa inakaribia Mwaka Mpya. Watoto kote nchini walikuwa tayari wametuma barua kwa Santa Claus au kujitolea zawadi, na mtekelezaji wao mkuu, mmoja wa wauzaji wakuu, alikuwa akijiandaa kwa apotheosis ya mauzo. Mnamo Desemba, mzigo kwenye kituo chake cha data huongezeka mara kadhaa. Kwa hivyo, kampuni iliamua kufanya kituo cha data cha kisasa na kuweka seva kadhaa mpya badala ya vifaa ambavyo vilikuwa vikifikia mwisho wa maisha yake ya huduma. Hii inamaliza hadithi dhidi ya mandhari ya theluji zinazozunguka, na msisimko huanza.

Vifaa vilifika kwenye tovuti miezi kadhaa kabla ya kilele cha mauzo. Huduma ya uendeshaji, bila shaka, inajua jinsi na nini cha kusanidi kwenye seva ili kuwaleta katika mazingira ya uzalishaji. Lakini tulihitaji kuhariri hii na kuondoa sababu ya kibinadamu. Kwa kuongezea, seva zilibadilishwa kabla ya uhamishaji wa seti ya mifumo ya SAP ambayo ilikuwa muhimu kwa kampuni.

Kuagizwa kwa seva mpya kulifungamanishwa kabisa na tarehe ya mwisho. Na kuihamisha kulimaanisha kuhatarisha usafirishaji wa zawadi bilioni na uhamiaji wa mifumo. Hata timu inayojumuisha Baba Frost na Santa Claus haikuweza kubadilisha tarehe - unaweza kuhamisha mfumo wa SAP kwa usimamizi wa ghala mara moja tu kwa mwaka. Kuanzia Desemba 31 hadi Januari 1, maghala makubwa ya muuzaji, kwa jumla ya ukubwa wa uwanja wa mpira wa miguu 20, huacha kazi yao kwa saa 15. Na hii ndio kipindi pekee cha wakati wa kusonga mfumo. Hatukuwa na nafasi ya makosa wakati wa kutambulisha seva.

Niseme wazi: hadithi yangu inaonyesha zana na mchakato wa usimamizi wa usanidi ambao timu yetu hutumia.

Mchanganyiko wa usimamizi wa usanidi una viwango kadhaa. Sehemu kuu ni mfumo wa CMS. Katika operesheni ya viwandani, kutokuwepo kwa moja ya viwango bila shaka kunaweza kusababisha miujiza isiyofurahisha.

Usimamizi wa ufungaji wa OS

Ngazi ya kwanza ni mfumo wa kusimamia ufungaji wa mifumo ya uendeshaji kwenye seva za kimwili na za kawaida. Inaunda usanidi wa msingi wa OS, kuondoa sababu ya kibinadamu.

Kwa kutumia mfumo huu, tulipokea hali za kawaida za seva na Mfumo wa Uendeshaji unaofaa kwa uwekaji otomatiki zaidi. Wakati wa "kumwaga" walipokea seti ya chini ya watumiaji wa ndani na funguo za SSH za umma, pamoja na usanidi thabiti wa OS. Tunaweza kuhakikishiwa kudhibiti seva kupitia CMS na tulikuwa na uhakika kwamba hapakuwa na mambo ya kushangaza "chini chini" katika kiwango cha OS.

Kazi "ya juu" ya mfumo wa usimamizi wa usakinishaji ni kusanidi seva kiotomatiki kutoka kiwango cha BIOS/Firmware hadi OS. Mengi hapa inategemea vifaa na kazi za usanidi. Kwa vifaa tofauti, unaweza kuzingatia REDFISH API. Ikiwa vifaa vyote vinatoka kwa muuzaji mmoja, basi mara nyingi ni rahisi zaidi kutumia zana za usimamizi zilizopangwa tayari (kwa mfano, HP ILO Amplifier, DELL OpenManage, nk).

Ili kufunga OS kwenye seva za kimwili, tulitumia Cobbler inayojulikana, ambayo inafafanua seti ya wasifu wa usakinishaji uliokubaliwa na huduma ya uendeshaji. Wakati wa kuongeza seva mpya kwenye miundombinu, mhandisi alifunga anwani ya MAC ya seva kwenye wasifu unaohitajika katika Cobbler. Wakati wa kuanzisha mtandao kwa mara ya kwanza, seva ilipokea anwani ya muda na OS mpya. Kisha ikahamishiwa kwa anwani inayolengwa ya VLAN/IP na kuendelea na kazi huko. Ndiyo, kubadilisha VLAN inachukua muda na inahitaji uratibu, lakini hutoa ulinzi wa ziada dhidi ya usakinishaji wa ajali wa seva katika mazingira ya uzalishaji.

Tumeunda seva pepe kulingana na violezo vilivyotayarishwa kwa kutumia HashiСorp Packer. Sababu ilikuwa sawa: kuzuia makosa iwezekanavyo ya kibinadamu wakati wa kufunga OS. Lakini, tofauti na seva za kimwili, Packer huondoa hitaji la PXE, uanzishaji wa mtandao, na mabadiliko ya VLAN. Hii imefanya iwe rahisi na rahisi kuunda seva pepe.

Mchele. 1. Kusimamia ufungaji wa mifumo ya uendeshaji.

Kusimamia siri

Mfumo wowote wa usimamizi wa usanidi una data ambayo inapaswa kufichwa kutoka kwa watumiaji wa kawaida, lakini inahitajika kuandaa mifumo. Haya ni manenosiri ya watumiaji wa ndani na akaunti za huduma, funguo za cheti, Tokeni mbalimbali za API, n.k. Kwa kawaida huitwa "siri".

Ikiwa hautaamua tangu mwanzo wapi na jinsi ya kuhifadhi siri hizi, basi, kulingana na ukali wa mahitaji ya usalama wa habari, njia zifuatazo za uhifadhi zinawezekana:

• moja kwa moja katika msimbo wa udhibiti wa usanidi au kwenye faili kwenye hifadhi;
• katika zana maalum za usimamizi wa usanidi (kwa mfano, Ansible Vault);
• katika mifumo ya CI/CD (Jenkins/TeamCity/GitLab/etc.) au katika mifumo ya usimamizi wa usanidi (Ansible Tower/Ansible AWX);
• siri zinaweza pia kuhamishwa "kwa mikono". Kwa mfano, zimewekwa katika eneo maalum, na kisha hutumiwa na mifumo ya usimamizi wa usanidi;
• mchanganyiko mbalimbali wa hapo juu.

Kila njia ina hasara zake. Jambo kuu ni ukosefu wa sera za upatikanaji wa siri: haiwezekani au vigumu kuamua ni nani anayeweza kutumia siri fulani. Ubaya mwingine ni ukosefu wa ukaguzi wa ufikiaji na mzunguko kamili wa maisha. Jinsi ya kuchukua nafasi ya haraka, kwa mfano, ufunguo wa umma ambao umeandikwa katika kanuni na katika idadi ya mifumo inayohusiana?

Tulitumia hifadhi ya siri ya kati ya HashiCorp Vault. Hii ilituruhusu:

• weka siri salama. Zimesimbwa kwa njia fiche, na hata mtu akipata ufikiaji wa hifadhidata ya Vault (kwa mfano, kwa kuirejesha kutoka kwa chelezo), hataweza kusoma siri zilizohifadhiwa hapo;
• panga sera za kupata siri. Siri tu "zinazotolewa" kwao zinapatikana kwa watumiaji na programu;
• ukaguzi wa upatikanaji wa siri. Vitendo vyovyote vilivyo na siri vinarekodiwa kwenye logi ya ukaguzi wa Vault;
• panga "mzunguko wa maisha" kamili wa kufanya kazi na siri. Wanaweza kuundwa, kufutwa, kuweka tarehe ya kumalizika muda, nk.
• rahisi kuunganisha na mifumo mingine inayohitaji upatikanaji wa siri;
• na pia utumie usimbaji fiche wa mwanzo hadi mwisho, nywila za mara moja za OS na hifadhidata, vyeti vya vituo vilivyoidhinishwa, nk.

Sasa hebu tuendelee kwenye mfumo mkuu wa uthibitishaji na uidhinishaji. Iliwezekana kufanya bila hiyo, lakini kusimamia watumiaji katika mifumo mingi inayohusiana sio jambo dogo sana. Tumesanidi uthibitishaji na uidhinishaji kupitia huduma ya LDAP. Vinginevyo, Vault italazimika kutoa na kufuatilia mara kwa mara tokeni za uthibitishaji kwa watumiaji. Na kufuta na kuongeza watumiaji kungegeuka kuwa pambano "je, nilifungua/kufuta akaunti hii ya mtumiaji kila mahali?"

Tunaongeza kiwango kingine kwenye mfumo wetu: usimamizi wa siri na uthibitishaji/uidhinishaji wa kati:

Mchele. 2. Usimamizi wa siri.

Usimamizi wa usanidi

Tulifika kwenye msingi - mfumo wa CMS. Kwa upande wetu, hii ni mchanganyiko wa Ansible na Red Hat Ansible AWX.

Badala ya Ansible, Chef, Puppet, SaltStack inaweza kutumika. Tulichagua Ansible kulingana na vigezo kadhaa.

• Kwanza, ni versatility. Seti ya moduli zilizotengenezwa tayari kwa udhibiti inavutia. Na ikiwa huna ya kutosha, unaweza kutafuta kwenye GitHub na Galaxy.
• Pili, hakuna haja ya kufunga na kusaidia mawakala kwenye vifaa vinavyosimamiwa, kuthibitisha kwamba hawaingilii na mzigo, na kuthibitisha kutokuwepo kwa "alamisho".
• Tatu, Ansible ina kizuizi cha chini cha kuingia. Mhandisi mwenye uwezo ataandika kitabu cha kucheza kinachofanya kazi siku ya kwanza ya kufanya kazi na bidhaa.

Lakini Ansible peke yake katika mazingira ya uzalishaji haikutosha kwetu. Vinginevyo, matatizo mengi yangetokea kwa kuzuia upatikanaji na ukaguzi wa vitendo vya wasimamizi. Jinsi ya kuzuia ufikiaji? Baada ya yote, ilikuwa ni lazima kwa kila idara kusimamia (soma: endesha kitabu cha kucheza cha Ansible) seti "yake" ya seva. Jinsi ya kuruhusu wafanyikazi fulani tu kuendesha vitabu maalum vya kucheza? Au jinsi ya kufuatilia ni nani aliyezindua kitabu cha kucheza bila kusanidi maarifa mengi ya ndani kwenye seva na vifaa vinavyoendesha Ansible?

Sehemu kubwa ya maswala kama haya hutatuliwa na Red Hat Ansible Tower, au mradi wake wa chanzo huria cha juu AWX inayowezekana. Ndio maana tuliipendelea kwa mteja.

Na mguso mmoja zaidi kwa picha ya mfumo wetu wa CMS. Kitabu cha kucheza kinachofaa kinapaswa kuhifadhiwa katika mifumo ya udhibiti wa hazina ya msimbo. Tunayo GitLab CE.

Kwa hivyo, usanidi wenyewe unasimamiwa na mchanganyiko wa Ansible/Ansible AWX/GitLab (ona Mchoro 3). Bila shaka, AWX/GitLab imeunganishwa na mfumo mmoja wa uthibitishaji, na kitabu cha kucheza cha Ansible kimeunganishwa na HashiCorp Vault. Mipangilio huingia katika mazingira ya uzalishaji tu kwa njia ya Ansible AWX, ambayo "sheria zote za mchezo" zimetajwa: ni nani anayeweza kusanidi nini, wapi kupata msimbo wa usimamizi wa usanidi wa CMS, nk.

Mchele. 3. Usimamizi wa usanidi.

Usimamizi wa mtihani

Usanidi wetu umewasilishwa kwa fomu ya msimbo. Kwa hiyo, tunalazimika kucheza na sheria sawa na watengenezaji wa programu. Tulihitaji kupanga michakato ya ukuzaji, majaribio ya mara kwa mara, utoaji na utumiaji wa msimbo wa usanidi kwa seva za uzalishaji.

Hili lisipofanywa mara moja, basi majukumu yaliyoandikwa kwa ajili ya usanidi yatakoma kuungwa mkono na kurekebishwa, au yatakoma kuzinduliwa katika toleo la umma. Tiba ya maumivu haya inajulikana, na imejidhihirisha katika mradi huu:

• kila jukumu linafunikwa na vipimo vya kitengo;
• majaribio huendeshwa kiotomatiki wakati wowote kuna mabadiliko yoyote katika msimbo unaodhibiti usanidi;
• mabadiliko katika msimbo wa usimamizi wa usanidi hutolewa katika mazingira ya uzalishaji tu baada ya kufaulu majaribio yote na ukaguzi wa msimbo.

Uundaji wa kanuni na usimamizi wa usanidi umekuwa tulivu na unaotabirika zaidi. Ili kupanga majaribio endelevu, tulitumia zana ya zana ya GitLab CI/CD, na kuchukua Molekuli Ansible.

Wakati wowote kuna mabadiliko katika msimbo wa usimamizi wa usanidi, GitLab CI/CD huita Molekuli:

• inakagua syntax ya msimbo,
• inainua chombo cha Docker,
• hutumia nambari iliyorekebishwa kwenye kontena iliyoundwa,
• hukagua jukumu la kutokuwa na uwezo na huendesha majaribio ya msimbo huu (granularity hapa iko katika kiwango cha jukumu kinachofaa, ona Mtini. 4).

Tuliwasilisha usanidi kwa mazingira ya uzalishaji kwa kutumia AWX Ansible. Wahandisi wa uendeshaji walitumia mabadiliko ya usanidi kupitia violezo vilivyoainishwa awali. AWX "iliomba" kwa kujitegemea toleo jipya zaidi la msimbo kutoka kwa tawi kuu la GitLab kila inapotumiwa. Kwa njia hii tulitenga matumizi ya msimbo ambao haujajaribiwa au uliopitwa na wakati katika mazingira ya uzalishaji. Kwa kawaida, msimbo uliingia tawi la bwana tu baada ya kupima, ukaguzi na idhini.

Mchele. 4. Upimaji otomatiki wa majukumu katika GitLab CI/CD.

Pia kuna tatizo linalohusiana na uendeshaji wa mifumo ya uzalishaji. Katika maisha halisi, ni vigumu sana kufanya mabadiliko ya usanidi kupitia msimbo wa CMS pekee. Hali za dharura hutokea wakati mhandisi lazima abadilishe usanidi "hapa na sasa", bila kusubiri uhariri wa msimbo, majaribio, idhini, nk.

Matokeo yake, kutokana na mabadiliko ya mwongozo, kutofautiana huonekana katika usanidi wa aina moja ya vifaa (kwa mfano, mipangilio ya sysctl imeundwa tofauti kwenye nodes za nguzo za HA). Au usanidi halisi kwenye vifaa hutofautiana na ule ulioainishwa katika msimbo wa CMS.

Kwa hivyo, pamoja na majaribio ya kuendelea, tunaangalia mazingira ya uzalishaji kwa utofauti wa usanidi. Tulichagua chaguo rahisi zaidi: kuendesha msimbo wa usanidi wa CMS katika hali ya "kukimbia kavu", yaani, bila kutumia mabadiliko, lakini kwa taarifa ya tofauti zote kati ya usanidi uliopangwa na halisi. Tulitekeleza hili kwa kuendesha vitabu vyote vya kucheza vya Ansible mara kwa mara kwa chaguo la "-angalia" kwenye seva za uzalishaji. Kama kawaida, Ansible AWX ina jukumu la kuzindua na kusasisha kitabu cha kucheza (ona Mchoro 5):

Mchele. 5. Huangalia utofauti wa usanidi katika Ansible AWX.

Baada ya ukaguzi, AWX hutuma ripoti ya hitilafu kwa wasimamizi. Wanasoma usanidi wenye matatizo na kisha kuurekebisha kupitia vitabu vya kucheza vilivyorekebishwa. Hivi ndivyo tunavyodumisha usanidi katika mazingira ya uzalishaji na CMS huwa imesasishwa na kusawazishwa kila wakati. Hii huondoa "miujiza" isiyopendeza wakati msimbo wa CMS unatumiwa kwenye seva za "uzalishaji".

Sasa tuna safu muhimu ya majaribio inayojumuisha Ansible AWX/GitLab/Molecule (Mchoro 6).

Mchele. 6. Usimamizi wa mtihani.

Ngumu? sibishani. Lakini tata kama hiyo ya usimamizi wa usanidi imekuwa jibu la kina kwa maswali mengi yanayohusiana na otomatiki ya usanidi wa seva. Sasa seva za kawaida za muuzaji kila wakati zina usanidi uliobainishwa kabisa. CMS, tofauti na mhandisi, haitasahau kuongeza mipangilio muhimu, kuunda watumiaji na kufanya kadhaa au mamia ya mipangilio inayohitajika.

Hakuna "maarifa ya siri" katika mipangilio ya seva na mazingira leo. Vipengele vyote muhimu vinaonyeshwa kwenye kitabu cha kucheza. Hakuna ubunifu zaidi na maagizo yasiyoeleweka: "Isakinishe kama Oracle ya kawaida, lakini unahitaji kutaja mipangilio kadhaa ya sysctl na kuongeza watumiaji na UID inayohitajika. Waulize watu wanaofanya kazi, wanajua'.

Uwezo wa kugundua hitilafu za usanidi na kuzirekebisha kwa vitendo hutoa amani ya akili. Bila mfumo wa usimamizi wa usanidi, hii kawaida inaonekana tofauti. Matatizo hujilimbikiza hadi siku moja "hupiga" katika uzalishaji. Kisha mazungumzo yanafanywa, usanidi unakaguliwa na kusahihishwa. Na mzunguko unarudia tena

Na bila shaka, tuliharakisha uzinduzi wa seva kufanya kazi kutoka siku kadhaa hadi saa.

Kweli, katika Mkesha wa Mwaka Mpya wenyewe, wakati watoto walipokuwa wakifungua zawadi kwa furaha na watu wazima walipokuwa wakifanya matakwa wakati milio ya kengele ilipiga, wahandisi wetu walihamisha mfumo wa SAP hadi kwenye seva mpya. Hata Santa Claus atasema kwamba miujiza bora ni ile iliyoandaliwa vizuri.

PS Timu yetu mara nyingi hukutana na ukweli kwamba wateja wanataka kutatua matatizo ya usimamizi wa usanidi kwa urahisi iwezekanavyo. Kwa kweli, kana kwamba kwa uchawi - na zana moja. Lakini katika maisha kila kitu ni ngumu zaidi (ndiyo, risasi za fedha hazikutolewa tena): unapaswa kuunda mchakato mzima kwa kutumia zana ambazo zinafaa kwa timu ya mteja.

Mwandishi: Sergey Artemov, mbunifu wa idara Suluhisho za DevOps "Jet Infosystems"

Chanzo: mapenzi.com