🥇Ansible: Flytja 120 sýndarvélar úr CoreOS yfir í CentOS eftir 18 mánuði

Þetta er afrit af ræðunni DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

Þetta er saga verkefnis sem notaði sjálfskrifað stillingarstjórnunarkerfi og hvers vegna flutningurinn yfir í Ansible tók 18 mánuði.

Dagur nr. -ХХХ: Fyrir upphafið

Upphaflega samanstóð uppbyggingin af mörgum aðskildum gestgjöfum sem keyrðu Hyper-V. Að búa til sýndarvél þurfti mörg skref: að setja diskana á réttan stað, skrá DNS, panta DHCP, setja VM uppsetninguna í git geymsluna. Þetta ferli var að hluta til vélvætt, en til dæmis var VM dreift milli véla með höndunum. En, til dæmis, forritarar gætu leiðrétt VM stillingar í git og beitt henni með því að endurræsa VM.

Sérsniðin stillingarstjórnunarlausn

Upprunalega hugmyndin, grunar mig, hafi verið hugsuð sem IaC: margar ríkisfangslausar VMs sem núllstilla ástand sitt þegar þær eru endurræstar. Hvað var VM stillingarstjórnun? Skipulega lítur það einfalt út:

Stöðugt MAC var neglt niður fyrir VM.
ISO með CoreOS og ræsidiskur var tengdur við VM.
CoreOS ræsir sérsniðnarhandritið með því að hlaða því niður af vefþjóninum byggt á IP þess.
Handritið halar niður VM stillingum í gegnum SCP byggt á IP tölu.
Fótklæði systemd einingaskráa og fótklútur af bash forskriftum eru ræst.

Þessi lausn hafði mörg augljós vandamál:

CoreOS ISO hefur verið úrelt.
Mikið af flóknum sjálfvirkum aðgerðum og töfrum við að flytja/búa til VM.
Erfiðleikar við uppfærslu og hvenær þörf er á ákveðinni útgáfu af hugbúnaði. Jafnvel skemmtilegra með kjarnaeiningum.
VM var ekki þannig aflað án gagna, þ.e. VMs birtust með diski með viðbótarnotendagögnum.
Einhver var stöðugt að klúðra ósjálfstæði kerfiseininga og CoreOS myndi frjósa við endurræsingu. Það var erfitt að ná þessu með því að nota tiltæk verkfæri í CoreOS.
Leyndarmálastjórnun.
Það var enginn CM. Það voru bash og YML stillingar fyrir CoreOS.

Til að beita VM stillingunum þarftu að endurræsa hana, en hún gæti ekki endurræst. Það virðist vera augljóst vandamál, en það eru engir viðvarandi diskar - það er hvergi hægt að vista annála. Jæja, allt í lagi, við skulum reyna að bæta við kjarnahleðsluvalkostinum svo að annálarnir verði sendir. En nei, hversu flókið þetta er allt saman.

Dagur #0: Viðurkenna vandamálið

Það var venjulegur þróunarinnviði: jenkins, prófunarumhverfi, eftirlit, skrásetning. CoreOS var hannað til að hýsa k8s klasa, þ.e. vandamálið var hvernig CoreOS var notað. Fyrsta skrefið var að velja stafla. Við sættum okkur við:

CentOS sem grunndreifingu, því Þetta er sú dreifing sem næst er í framleiðsluumhverfi.
Ansible fyrir stillingarstjórnun, vegna þess var umfangsmikil athugun á því.
Jenkins sem ramma til að gera sjálfvirkan ferla sem fyrir eru, vegna þess að það hefur þegar verið virkt notað fyrir þróunarferli
Há-V sem sýndarvæðingarvettvangur. Það eru ýmsar ástæður sem fara út fyrir svið sögunnar, en í stuttu máli - við getum ekki notað skýin, við verðum að nota okkar eigin vélbúnað.

Dagur nr. 30: Lagfæring gildandi samninga - Samningar sem kóða

Þegar stokkurinn var kominn á hreint hófst undirbúningur fyrir flutninginn. Laga fyrirliggjandi samninga í formi kóða (Samningar sem kóða!). Umskipti verkamannavinna -> vélvæðing -> sjálfvirkni.

1. Stilla VMs

Ansible stendur sig frábærlega í þessu. Með lágmarks líkamshreyfingum geturðu tekið stjórn á VM stillingum:

Búðu til git geymslu.
Við setjum lista yfir VM í birgðum, stillingum í leikbókum og hlutverkum.
Við erum að setja upp sérstakan jenkins þræl sem þú getur keyrt Ansible frá.
Við búum til starf og stillum Jenkins.

Fyrsta ferlið er tilbúið. Samningarnir eru fastir.

2. Búðu til nýjan VM

Allt hér var ekki mjög þægilegt. Það er ekki mjög þægilegt að búa til VM á Hyper-V frá Linux. Ein af tilraununum til að vélvæða þetta ferli var:

Ansbile tengist í gegnum WinRM við Windows hýsilinn.
Ansible keyrir powershell skriftu.
Powershell forskrift býr til nýjan VM.
Með því að nota Hyper-V/ScVMM, þegar VM er búið til í gestastýrikerfinu, er hýsingarheitið stillt.
Þegar DHCP leigusamningurinn er uppfærður sendir VM hýsingarheitið sitt.
Stöðluð ddns & dhcp samþætting á lénsstýringarhliðinni stillir DNS færsluna.
Þú getur bætt VM við birgðahaldið þitt og stillt það með Ansible.

3.Create VM sniðmát

Þeir fundu ekki upp neitt hér - þeir tóku pakka.

Bættu pakkaranum, kickstart config við git geymsluna.
Að setja upp sérstakan jenkins þræl með hyper-v og Packer.
Við búum til starf og stillum Jenkins.

Hvernig þessi hlekkur virkar:

Packer býr til tóman VM og tekur upp ISO.
VM ræsir, Packer setur skipunina inn í ræsiforritið til að nota kickstart skrána okkar af disklingi eða http.
Anaconda er hleypt af stokkunum með stillingum okkar og upphaflegri stýrikerfisstillingu er lokið.
Packer bíður eftir því að VM verði tiltækt.
Packer inni í VM keyrir ansible í staðbundnum ham.
Ansible notar nákvæmlega sömu hlutverk og það virkar í skrefi #1.
Packer flytur út VM sniðmátið.

Dagur #75: Endurnýjaðu samkomulagið án þess að rjúfa = Próf ansible + Testkitchen

Það er kannski ekki nóg að fanga venjur í kóða. Þegar öllu er á botninn hvolft, ef í ins og outs ferlisins þú vilt breyta einhverju, getur þú brotið eitthvað. Þess vegna, þegar um innviði er að ræða, birtist prófun á einmitt þessum innviðum. Til að samstilla þekkingu innan teymisins byrjuðum við að prófa Ansible hlutverk. Ég ætla ekki að fara ítarlega því... það er grein sem lýsir atburðum á þeim tímapunkti Prófaðu mig hvort þú getur eða dreymir YML forritara um að prófa Ansible?(spoiler þetta var ekki lokaútgáfan og síðar varð allt flóknara Hvernig á að byrja að prófa Ansible, endurskoða verkefnið á einu ári og ekki klikka).

Dagur #130: Kannski CentOSÞarf ekki +ansible? Kannski openshift?

Við verðum að skilja að ferlið við að kynna innviði var ekki það eina og það voru hliðar undirverkefni. Til dæmis kom beiðni um að ræsa forritið okkar í openshift og þetta leiddi til rannsókna í meira en eina viku Við ræsum forritið í Openshift og berum saman núverandi verkfæri sem hægði á flutningsferlinu. Niðurstaðan kom í ljós að openshift nær ekki öllum þörfum þú þarft alvöru vélbúnað, eða að minnsta kosti getu til að spila með kjarnanum.

Dagur #170: Opin vakt hentar ekki, við skulum taka áhættu með Windows Azure-pakkinn?

Hyper-V er ekki mjög notendavænt og SCVMM gerir það ekki mikið betra. En það er til slíkt. Windows Azure Pack, sem er viðbót við SCVMM og hermir eftir Azure. Í raun virðist varan yfirgefin: skjölunin er strjál og full af biluðum tenglum. Hins vegar skoðuðum við hana líka á meðan við könnuðum möguleika á að einfalda skýjalíf okkar.

Dagur #250: Windows Azure Pack er ekki frábært. Við höldum okkur við SCVMM.

Windows Azure Pack leit efnilegt út en ákveðið var að færa ekki WAP með öllum sínum flækjum inn í kerfið vegna óþarfa eiginleika og halda sig við SCVMM.

Dagur #360: Að borða fílinn stykki fyrir stykki

Aðeins ári síðar var vettvangurinn til að flytja til tilbúinn og flutningsferlið hófst. Í þessu skyni var sett SMART verkefni. Við skoðuðum allar VM-tölvurnar og byrjuðum að finna út stillingarnar einn í einu, lýsa henni í Ansible og hylja hana með prófunum.

Dagur #450: Hvers konar kerfi fékkstu?

Ferlið sjálft er ekki áhugavert. Það er venja, það má taka fram að flestar stillingar voru tiltölulega einfaldar eða ísómorfnar og samkvæmt Pareto meginreglunni þurftu 80% af VM stillingunum 20% af tímanum. Samkvæmt sömu reglu fór 80% af tímanum í að undirbúa flutninginn og aðeins 20% í flutninginn sjálfan.