Nêzîkî sersalê bû. Zarokan li çaraliyê welêt berê ji Santa Claus re name şandin an jî diyarî ji xwe re çêkirin, û îcrakarê wan ê sereke, yek ji firotgehên mezin, ji bo apotheoza firotanê amade dikir. Di Kanûnê de, barkirina li ser navenda daneya wê çend caran zêde dibe. Ji ber vê yekê, pargîdaniyê biryar da ku navenda daneyê nûjen bike û li şûna alavên ku digihîje dawiya jiyana xwe ya karûbarê, bi dehan serverên nû bixe kar. Ev çîrok li hember paşpirtikên berfê yên zivirî diqede, û thriller dest pê dike.

Amûr çend meh beriya pezbûna firotanê gihîştin malperê. Karûbarê operasyonan, bê guman, dizane ku çawa û çi li ser serveran mîheng bike da ku wan bîne hawîrdora hilberînê. Lê me hewce kir ku vê yekê otomatîk bikin û faktora mirovî ji holê rakin. Digel vê yekê, server berî koçkirina komek pergalên SAP-ê yên ku ji bo pargîdaniyê krîtîk bûn hatin guheztin.

Destpêkirina serverên nû bi zexmî bi muhletê ve girêdayî bû. Û veguheztina wê tê wateya ku hem şandina mîlyar diyarî û hem jî koçkirina pergalan dixe xetereyê. Tewra tîmek ku ji Bav Frost û Santa Claus pêk tê nekare tarîxê biguhezîne - hûn dikarin salê tenê carekê pergala SAP-ê ji bo rêveberiya depoyê veguhezînin. Ji 31ê Kanûna Pêşiyê heta 1ê Çileyê embarên mezin ên firoşyarê ku bi giştî 20 qadên futbolê ne, 15 saetan karê xwe radiwestînin. Û ev yek tenê heyama ji bo veguhestina pergalê ye. Di danasîna pêşkêşkeran de cihê xeletiyê tunebû.

Bila ez zelal bibêjim: çîroka min amûr û pêvajoya rêveberiya vesazkirinê ya ku tîmê me bikar tîne nîşan dide.

Kompleksa rêveberiya vesazkirinê ji çend astan pêk tê. Beşa sereke pergala CMS ye. Di xebata pîşesaziyê de, nebûna yek ji astê bê guman dê bibe sedema mûcîzeyên ne xweş.

rêveberiya sazkirina OS

Asta yekem pergalek ji bo birêvebirina sazkirina pergalên xebitandinê li ser serverên laşî û virtual e. Ew mîhengên bingehîn ên OS-ê diafirîne, faktora mirovî ji holê radike.

Bi karanîna vê pergalê, me mînakên servera standard ên bi OS-ya ku ji bo otomasyona bêtir guncan e werdigirin. Di dema "rijandinê" de wan komek hindiktirîn bikarhênerên herêmî û mifteyên giştî yên SSH, û her weha veavakirinek OS-ya domdar wergirtin. Me garantî kir ku em serveran bi navgîniya CMS-ê ve bi rêve bibin û pê bawer bûn ku di asta OS-ê de "jêr jêr" çu surprîz tune.

Karê "herî zêde" ji bo pergala rêveberiya sazkirinê ev e ku bixweber serveran ji asta BIOS/Firmware berbi OS-ê veava bike. Pir li vir bi alav û karên sazkirinê ve girêdayî ye. Ji bo amûrên heterojen, hûn dikarin bifikirin REDFISH API. Ger hemî hardware ji yek firoşkarê be, wê hingê pir caran hêsantir e ku meriv amûrên rêveberiyê yên amade bikar bîne (mînak, HP ILO Amplifier, DELL OpenManage, hwd.).

Ji bo sazkirina OS-ê li ser pêşkêşkerên laşî, me Cobbler-a naskirî bikar anî, ku komek profîlên sazkirinê yên ku bi karûbarê xebitandinê re hatine pejirandin destnîşan dike. Dema ku serverek nû li binesaziyê zêde kir, endezyar navnîşana MAC ya serverê bi profîla pêdivî ya li Cobbler ve girêda. Dema ku yekem car li ser torê boot kirin, server navnîşek demkî û OS-ya nû wergirt. Dûv re ew veguheztin navnîşana VLAN / IP-ya mebest û li wir xebata xwe domand. Erê, guhertina VLAN dem digire û hevrêziyê hewce dike, lê ew parastina zêde li dijî sazkirina xeletî ya serverê di hawîrdorek hilberînê de peyda dike.

Me li ser şablonên ku bi karanîna HashiСorp Packer hatine amadekirin serverên virtual afirandin. Sedem heman bû: ji bo pêşîgirtina xeletiyên mirovî yên gengaz dema sazkirina OS-ê. Lê, berevajî serverên laşî, Packer hewcedariya PXE, bootkirina torê, û guhertinên VLAN ji holê radike. Vê yekê çêkirina serverên virtual hêsantir û hêsan kiriye.

Birinc. 1. Birêvebirina sazkirina pergalên xebitandinê.

Birêvebirina sirên

Pergalek rêveberiya vesazkirinê daneyên ku divê ji bikarhênerên asayî veşêrin dihewîne, lê ji bo amadekirina pergalên pêdivî ye. Vana şîfreyên bikarhênerên herêmî û hesabên karûbar, mifteyên sertîfîkayê, Tokenên API yên cihêreng, hwd. Bi gelemperî ji wan re "veşartî" tê gotin.

Ger hûn ji destpêkê ve diyar nekin ku li ku û çawa van razan hilînin, wê hingê, li gorî hişkiya daxwazên ewlehiya agahdariyê, rêbazên hilanînê yên jêrîn îhtîmal in:

• rasterast di koda kontrolê ya veavakirinê de an di pelên di depoyê de;
• di amûrên rêveberiya mîhengê yên pispor de (mînak, Ansible Vault);
• di pergalên CI / CD de (Jenkins / TeamCity / GitLab / hwd.) an di pergalên rêveberiya vesazkirinê de (Ansible Tower / Ansible AWX);
• veşartî jî dikarin "bi destan" werin veguheztin. Mînakî, ew li cîhek diyarkirî têne danîn, û dûv re ew ji hêla pergalên rêveberiya vesazkirinê ve têne bikar anîn;
• combinations cuda yên li jor.

Her rêbaz kêmasiyên xwe hene. Ya sereke nebûna polîtîkayên ji bo gihîştina razan e: ne gengaz e an jî dijwar e ku meriv diyar bike ka kî dikare hin razan bikar bîne. Dezavantajek din jî nebûna kontrolkirina gihîştinê û çerxa jiyanê ya tevahî ye. Meriv çawa zû biguhezîne, mînakî, mifteyek gelemperî ku di kodê de û di hejmarek pergalên têkildar de hatî nivîsandin?

Me hilanîna veşartî ya navendî HashiCorp Vault bikar anî. Vê yekê destûr da me:

• sirên ewle biparêzin. Ew şîfrekirî ne, û hetta kesek bigihîje databasa Vault (mînak, bi vegerandina wê ji hilanînê), ew ê nikaribin nehêniyên li wir hatine hilanîn bixwînin;
• polîtîkayên ji bo gihîştina razan organîze bikin. Tenê razên ku ji wan re "veqetandin" ji bikarhêner û serlêdanan re peyda dibin;
• ketina kontrolê ya veşartî. Her kiryarên bi nehênî di têketina kontrolê ya Vault de têne tomar kirin;
• "çerxa jiyanê" ya bêkêmasî ya xebata bi razan organîze bike. Ew dikarin bêne afirandin, betal kirin, tarîxek qedandinê destnîşan bikin, hwd.
• hêsan e ku meriv bi pergalên din ên ku hewceyê gihîştina razan in re têkildar bibe;
• û her weha şîfrekirina dawî-bi-dawî, şîfreyên yek carî ji bo OS û databasê, sertîfîkayên navendên destûrdar, hwd.

Naha em werin ser pergala pejirandin û destûrnameyê ya navendî. Dikaribû bêyî wê were kirin, lê rêvebirina bikarhêneran di gelek pergalên têkildar de pir ne hindik e. Me bi karûbarê LDAP-ê verastkirin û destûrname mîheng kiriye. Wekî din, Vault neçar e ku bi domdarî nîşaneyên erêkirinê ji bo bikarhêneran derxîne û bişopîne. Û jêbirin û zêdekirina bikarhêneran dê vegere lêgerînek "ma min ev hesabê bikarhêner li her derê çêkir / jêbirin?"

Em astek din li pergala xwe zêde dikin: rêveberiya veşartî û pejirandina navendî / destûr:

Birinc. 2. Rêveberiya Secrets.

birêvebirina veavakirina

Em gihîştin bingehê - pergala CMS. Di doza me de, ev yek ji Ansible û Red Hat Ansible AWX e.

Li şûna Ansible, Chef, Puppet, SaltStack dikare were bikar anîn. Me Ansible li ser çend pîvanan hilbijart.

• Ya yekem, ew pirreng e. Komek modulên amade ji bo kontrolê bi heybet e. Û heke têra we tune be, hûn dikarin li GitHub û Galaxy bigerin.
• Ya duyemîn, ne hewce ye ku ajanên li ser amûrên rêvebirinî saz bikin û piştgirî bikin, îspat bikin ku ew bi barkirinê re destwerdanê nakin, û nebûna "nîşanan" piştrast bikin.
• Ya sêyemîn, Ansible xwedan astengiyek kêm a têketinê ye. Endezyarek jêhatî dê di roja yekem a xebatê de bi hilberê re pirtûkek lîstikê binivîsîne.

Lê Ansible tenê di hawirdora hilberînê de têra me nekir. Wekî din, dê bi sînordarkirina gihîştinê û kontrolkirina kiryarên rêveberan re gelek pirsgirêk derkevin. Meriv çawa gihîştinê sînordar dike? Beriya her tiştî, pêdivî bû ku her beş rêvebirin (bixwîne: pirtûka lîstika Ansible bimeşîne) komek serverên "xwe". Meriv çawa dihêle tenê hin karmendan pirtûkên lîstikên Ansible yên taybetî bimeşînin? An jî meriv çawa bişopîne ka kê pirtûka lîstikê dest pê kiriye bêyî ku gelek zanyariyên herêmî li ser server û alavên ku Ansible dixebitin saz bikin?

Para şêr a pirsgirêkên wiha ji aliyê Red Hat ve tê çareserkirin Birca Ansible, an projeya wî ya jorîn-çavkaniya vekirî Ansible AWX. Ji ber vê yekê me ew ji bo xerîdar tercîh kir.

Û yek pêwendiyek din ji portreya pergala meya CMS re. Pirtûka lîstika Ansible divê di pergalên rêveberiya depoya kodê de were hilanîn. Me heye GitLab CE.

Ji ber vê yekê, veavakirin bixwe ji hêla berhevokek Ansible/Ansible AWX/GitLab ve têne rêve kirin (binihêre Fig. 3). Bê guman, AWX / GitLab bi pergalek pejirandinê ya yekane re yekgirtî ye, û pirtûka lîstika Ansible bi HashiCorp Vault re yekbûyî ye. Veavakirin tenê bi navgîniya Ansible AWX-ê ve dikevin hawîrdora hilberînê, ku tê de hemî "qanûnên lîstikê" têne destnîşan kirin: kî dikare çi mîheng bike, li ku derê koda rêveberiya vesazkirinê ji bo CMS-ê bigire, hwd.

Birinc. 3. Birêvebiriya veavakirinê.

Rêveberiya testê

Veavakirina me di forma kodê de tê pêşkêş kirin. Ji ber vê yekê, em neçar in ku wekî pêşdebirên nermalavê bi heman qaîdeyan bilîzin. Pêwîstiya me bi organîzekirina pêvajoyên pêşkeftinê, ceribandina domdar, radestkirin û sepandina koda vesazkirinê ji serverên hilberînê re hebû.

Ger ev tavilê neyê kirin, wê hingê rolên ku ji bo veavakirinê hatine nivîsandin an dê piştgirî û guheztin rawestin, an jî dê di hilberînê de neyên destpêkirin. Dermanê vê êşê tê zanîn û di vê projeyê de xwe îspat kiriye:

• her rol ji hêla testên yekîneyê ve tê vegirtin;
• îmtîhan bixweber têne xebitandin dema ku di koda ku veavakirinan birêve dibe de guherînek çêbibe;
• Guhertinên di koda rêveberiya mîhengê de tenê piştî ku bi serfirazî hemî ceribandin û vekolîna kodê derbas dibin di hawîrdora hilberînê de têne berdan.

Pêşveçûn û rêveberiya konfigurasyonê ya kodê aramtir û pêşbîntir bûye. Ji bo organîzekirina ceribandina domdar, me amûra GitLab CI/CD bikar anî, û girt Molekula Ansible.

Kengê ku di koda rêveberiya vesazkirinê de guhertinek çêbibe, GitLab CI/CD bangî Molecule dike:

• ew hevoksaziya kodê kontrol dike,
• konteynera Docker bilind dike,
• koda guhertî li konteynera hatî afirandin bicîh tîne,
• rola bêhêzbûnê kontrol dike û ji bo vê kodê ceribandinan dimeşîne (li vira hûrgulî di asta rola bêkêmasî de ye, li Fig. 4 binêre).

Me bi karanîna Ansible AWX veavakirin radestî hawîrdora hilberînê kir. Endezyarên Operasyonê bi navgîniya şablonên pêşwext guheztinên mîhengê sepandin. AWX her gava ku hate bikar anîn bi serbixwe guhertoya herî dawî ya kodê ji şaxê masterê GitLab "daxwaz kir". Bi vî rengî me di hawîrdora hilberînê de karanîna koda neceribandinî an kevnar derxist holê. Bi xwezayî, kod tenê piştî ceribandin, vekolîn û pejirandinê ket şaxê master.

Birinc. 4. Testkirina otomatîkî ya rolan di GitLab CI/CD de.

Pirsgirêka xebitandina pergalên hilberînê jî heye. Di jiyana rast de, pir dijwar e ku meriv bi tenê bi koda CMS-ê guheztinên mîhengê bike. Rewşên acîl çêdibin dema ku endezyarek pêdivî ye ku mîhengê "li vir û nuha" biguhezîne, bêyî ku li benda guherandina kodê, ceribandin, pejirandin, hwd.

Wekî encamek, ji ber guheztinên destan, nakokî di veavakirinê de li ser heman celebê alavan xuya dibin (mînak, mîhengên sysctl li ser girêkên koma HA-yê cûda têne mîheng kirin). An jî veavakirina rastîn a li ser amûrê ji ya ku di koda CMS-ê de hatî destnîşan kirin cûda dibe.

Ji ber vê yekê, ji bilî ceribandina domdar, em hawîrdorên hilberînê ji bo nakokiyên mîhengê kontrol dikin. Me vebijarka herî hêsan hilbijart: koda veavakirina CMS-ê di moda "raza hişk" de xebitandin, ango bêyî sepandina guhertinan, lê bi agahdarkirina hemî nakokiyên di navbera veavakirina plansazkirî û rastîn de. Me vê yekê bi rêvekirina periyodîk hemî pirtûkên lîstikê yên Ansible bi vebijarka "-kontrol" li ser pêşkêşkerên hilberînê bicîh kir. Mîna her gav, Ansible AWX ji destpêkirin û nûvekirina pirtûka lîstikê berpirsiyar e (binihêre Fig. 5):

Birinc. 5. Di Ansible AWX de nakokiyên veavakirinê kontrol dike.

Piştî kontrolê, AWX raporek nerazîbûnê ji rêveberan re dişîne. Ew veavakirina pirsgirêkê dixwînin û dûv re wê bi navgîniya pirtûkên lîstikê yên verastkirî rast dikin. Bi vî rengî em veavakirinê di hawîrdora hilberînê de diparêzin û CMS her gav nûve û hevdem e. Dema ku koda CMS-ê li ser serverên "hilberîn"ê tê bikar anîn, ev "mûcîzeyên" ne xweş ji holê radike.

Naha me qatek ceribandinek girîng heye ku ji Ansible AWX / GitLab / Molecule pêk tê (Wêne 6).

Birinc. 6. Rêveberiya testê.

Asteng? Ez nîqaş nakim. Lê kompleksek wusa ya rêveberiya mîhengê bûye bersivek berfireh ji gelek pirsên ku bi otomatîkkirina mîhenga serverê ve girêdayî ne. Naha serverên standard ên firotgehek her gav xwedan mîhengek hişk diyarkirî ne. CMS, berevajî endezyarek, dê ji bîr neke ku mîhengên pêwîst lê zêde bike, bikarhêneran biafirîne û bi dehan an bi sedan mîhengên pêwîst pêk bîne.

Di mîhengên server û hawîrdoran de îro "zanîna veşartî" tune. Hemî taybetmendiyên pêwîst di pirtûka lîstikê de têne xuyang kirin. Êdî afirînerî û rêwerzên nezelal nema: "Wê mîna Oracle-a birêkûpêk saz bikin, lê hûn hewce ne ku çend mîhengên sysctl diyar bikin û bikarhênerên bi UID-ya pêwîst lê zêde bikin. Ji xortên operasyonê bipirsin, ew dizanin".

Kapasîteya tespîtkirina nakokiyên mîhengê û rastkirina wan bi proaktîf aramiya hişê peyda dike. Bêyî pergala rêveberiya mîhengê, ev bi gelemperî cûda xuya dike. Pirsgirêk kom dibin heya ku rojek ew di hilberînê de "bişkînin". Dûv re debriefing tê kirin, veavakirin têne kontrol kirin û rast kirin. Û çerx dîsa dubare dike

Û bê guman, me destpêkirina serveran ji çend rojan heya demjimêran bilez kir.

Welê, şeva sersalê bixwe, dema ku zarokan bi kêfxweşî diyariyan vedikirin û mezinan jî xwestekên xwe dikirin, endezyarên me pergala SAP-ê koçî serverên nû kirin. Tewra Santa Claus jî dê bibêje ku mucîzeyên herî baş ew in ku baş hatine amadekirin.

PS Tîmê me bi gelemperî rastî vê yekê tê ku xerîdar dixwazin pirsgirêkên rêveberiya mîhengê bi qasî ku gengaz çareser bikin. Bi îdeal, wekî bi sêrbaz - bi yek amûr. Lê di jiyanê de her tişt tevlihevtir e (erê, guleyên zîvîn dîsa nehatin radest kirin): pêdivî ye ku hûn pêvajoyek tevahî bi karanîna amûrên ku ji bo tîmê xerîdar rehet in biafirînin.

Nivîskar: Sergey Artemov, mîmarê beşê çareseriyên DevOps "Jet Infosystems"

Source: www.habr.com