Kjo është transcripti i fjalimit në dhe .
Kjo është historia e projektit, ku u përdor një sistem i personalizuar për menaxhimin e konfiguracioneve dhe pse kalimi në Ansible zgjati 18 muaj.
Dita â -XXX: Para fillimit
Fillimisht infrastruktura përbëhej nga shumë hoste të veçanta nën menaxhimin e Hyper-V. Krijimi i një makine virtuale kërkonte shumë veprime: vendosjen e disqeve në vendin e duhur, konfigurimin e DNS, rezervimin e DHCP, vendosjen e konfiguracionit të VM në një depo git. Ky proces ishte pjesërisht mekanizuar, por për shembull, VM-të shpërndaheshin mes hosteve me duar. Megjithatë, zhvilluesit mund të aplikonin ndryshimet në konfiguracionin e VM në git duke e ribërë atë pas një rindezjeje të VM.
Zgjidhje e Personalizuar për Menaxhimin e Konfiguracioneve
Ideja fillestare, besoj, ishte menduar si IaC: shumĂ« VM stateless, tĂ« cilat pas rindezjes resetonin gjendjen e tyre. ĂfarĂ« pĂ«rfshinte menaxhimi i konfiguracioneve tĂ« VM? Duket e thjeshtĂ« nĂ« katror:
- Për VM-të ishte vendosur MAC statik.
- VM-të ishin lidhur me ISO me CoreOS dhe diskun e ngarkesës.
- CoreOS ekzekuton skripti i personalizimit duke e shkarkuar atë nga serveri WEB në bazë të IP-së së tij.
- Skripti shkarkon përmes SCP konfigurimin e VM duke u bazuar në adresën IP.
- Aktivizohet një sërë skedarësh unit systemd dhe një sërë skriptesh bash.
Ky zgjidhje kishte shumë probleme të dukshme:
- ISO në CoreOS ishte e hequr.
- Shumë veprime të komplikuara automatizimi dhe magji gjatë migrimit/krijimit të VM.
- Vështirësi me përditësimin dhe kur kërkohej një version i caktuar të softuerit. Akoma më argëtuese me modulet e bërthamës.
- VM-të nuk rezultonin aq të pa të dhëna, dmth. u shfaqën VM me një disk të montuar me të dhëna përdoruesi përveç.
- Dikush gjithmonë gabonte me varësitë e unit systemd dhe në ri-nisjen CoreOS ngadalësohej. Ishte problem për të zbuluar këtë me mjetet ekzistuese në CoreOS.
- Menaxhimi i sekreteve.
- CM nuk ekzistonte faktikisht. Kishim bash dhe konfigurimet YML të CoreOS.
Për të aplikuar konfigurimin e VM-së duhet ta ri-nisim, por ajo mund të mos ri-niset. Megjithëse dukej si një problem i dukshëm, nuk kishte disqe persistente - nuk kishte ku të ruheshin log-et. Po mire, le të përpiqemi të shtojmë opsionet e ngarkimit të bërthamës për të dërguar log-et. Por jo, sa e vështirë është gjithçka.
Dita e parë: Pranimi i problemit
Ishte një infrastrukturë e zakonshme zhvillimi: jenkins, mjedise testimi, monitorime, registry. CoreOS ishte menduar për hostimin e klastereve k8s, domethënë, problemi ishte se si përdorej CoreOS. Hapi i parë ishte seçja e stekës. Ne vendosëm për:
- CentOS si distribucionin bazë, pasi është distribucioni më i afërt me mjediset e prodhimit.
- Ansible për menaxhimin e konfiguracioneve, pasi kishte një ekspertizë të gjerë.
- Jenkins si një kornizë automatizimi të proceseve ekzistuese, pasi ishte përdorur tashmë aktivisht për proceset e zhvillimit.
- Hyper-V si platformĂ« virtualizimi. Ka disa arsye qĂ« shkojnĂ« pĂ«rtej tregimit, por nĂ« mĂ«nyrĂ« tĂ« shkurtĂ«r â ne nuk mund tĂ« pĂ«rdorim cloud, duhet tĂ« pĂ«rdorim hardware-in tonĂ«.
Dita â30: Fiksimi i marrĂ«veshjeve ekzistuese â Agreements as Code
Kur u kuptua steka, filloi përgatitja për kalimin. Fiksimi i marrëveshjeve ekzistuese në formën e kodit (Agreements as Code!). Kalimi punë parapërgatitore -> mekanizimi -> automatizimi.
1. Konfiguroni VM-të
Ansible e menaxhon këtë detyrë shumë mirë. Me pak përpjekje, mund të nxjerrim nën kontroll konfiguracionet e VM-ve:
- Krijoni një repozitor git.
- Krijtojmë listën e VM-ve në inventory, konfigurimet në playbooks dhe role.
- Konfigurojmë një slave të veçantë të jenkins nga i cili mund të ekzekutojmë ansible.
- Krijojmë një punë, konfigurojmë Jenkins.
Procesi i parë është gati. Marrëveshjet janë fixuar.
2. Krijo VM të re
Isha paksa i pakënaqur. Nga Linux nuk ishte shumë e lehtë të krijoheshin VM në Hyper-V. Një nga përpjekjet për të mekanizuar këtë proces ishte:
- Ansible lidhet përmes WinRM me hostin windows.
- Ansible ekzekuton skenarin powershell.
- Skenari powershell krijon një VM të re.
- Me mjetet Hyper-V/ScVMM gjatë krijimit të VM-së në sistemin e ftuar, konfigurohet hostname.
- VM-ja, gjatë përditësimit të DHCP lease, dërgon hostname-n e saj.
- Integrimi i standardizuar i ddns & dhcp në anën e Domain Controller konfiguron regjistrimin DNS.
- Mund të shtoni VM në inventory dhe ta konfiguroni atë me Ansible.
3. Krijo template VM
KĂ«tu nuk bĂ«mĂ« asgjĂ« origjinale â pĂ«rdorĂ«m packer.
- Në depozitën git vendosim konfigurimin e packer, kickstart.
- Konfigurojmë një slave të veçantë të jenkins me hyper-v dhe Packer.
- Krijojmë një punë, konfigurojmë Jenkins.
Si funksionon kjo lidhje:
- Packer krijon një VM të zbrazët, lidh ISO-n.
- VM-ja ngarkohet, Packer jep komandën për të përdorur skedarin tonë kickstart nga disku ose http.
- Anaconda nis me konfigurimin tonë, bëhet konfigurimi fillestar i OS.
- Packer pret deri sa VM-ja të bëhet e aksesueshme.
- Packer brenda VM Đ·Đ°ĐżŃŃĐșĐ° ansible nĂ« modalitetin lokal.
- Ansible përdor të njëjtat role si në hapin nr. 1.
- Packer eksporton modelin e VM.
Dita nr. 75: Ristrukturojmë marrëveshjet pa thyer = Testo ansible + Testkitchen.
TĂ« fiksohesh marrĂ«veshjet nĂ« kod mund tĂ« mos mjaftojĂ«. Sepse nĂ«se nĂ« prapaskenĂ« dĂ«shiron tĂ« ndryshosh diçka â mund tĂ« thysh diçka. Prandaj nĂ« rastin e infrastrukturĂ«s, testimi i kĂ«saj infrastrukture paraqitet. PĂ«r tĂ« sinkronizuar njohuritĂ« brenda ekipit filluam tĂ« testojmĂ« rolet Ansible. Nuk do tĂ« thellojmĂ«, pasi ka njĂ« artikull qĂ« pĂ«rshkruan ngjarjet nĂ« atĂ« moment. (spoiler, ky nuk ishte versioni pĂ«rfundimtar dhe mĂ« vonĂ« gjithçka u bĂ« mĂ« e komplikuar). ).
Dita nr. 130: Ndoshta CentOS + ansible nuk është i nevojshëm? ndoshta openshift?
Duhet tĂ« kuptohet se procesi i integrimit tĂ« infrastrukturĂ«s nuk ishte e vetmja dhe kishte projekte anĂ«sore. PĂ«r shembull, erdhi njĂ« kĂ«rkesĂ« pĂ«r ta drejtuar aplikacionin tonĂ« nĂ« openshift dhe kjo rezultoi nĂ« kĂ«rkime pĂ«r mĂ« shumĂ« se njĂ« javĂ«. Ăka vonoi procesin e migrimit. Si rezultat, doli se Openshift nuk i plotĂ«son tĂ« gjitha nevojat, na nevojitet harduer i vĂ«rtetĂ«, ose tĂ« paktĂ«n mundĂ«sia pĂ«r tĂ« luajtur me kernelin.
Dita â170: Openshift nuk Ă«shtĂ« i pĂ«rshtatshĂ«m, a do tĂ« rrezikojmĂ« me Windows Azure Pack?
Hyper-V nuk është shumë miqësor, SCVMM nuk e bën atë shumë më të mirë. Por ekziston një gjë e tillë, Windows Azure Pack, e cila është një shtresë mbi SCVMM dhe i ngjan Azure. Por në realitet, produkti duket si i braktisur: dokumentacioni me lidhje të prishura dhe mjaft i varfër. Megjithatë, brenda hulumtimit të mundësive për të lehtësuar jetën tonë në cloud, e kemi shqyrtuar edhe atë.
Dita â250: Windows Azure Pack nuk Ă«shtĂ« shumĂ«. QĂ«ndrojmĂ« me SCVMM.
Windows Azure Pack dukej premtues, por u vendos të mos sjellim WAP me kompleksitetet e tij në sistem për shkak të veçorive të panevojshme dhe mbetëm me SCVMM.
Dita â360: Hame elefantin pjesĂ«-pjesĂ«.
Vetëm një vit më vonë platforma ku duhej të migronim ishte gati dhe filloi procesi i migrimit. Për këtë, u vendos një detyrë S.M.A.R.T. Shkruam të gjitha VM-të dhe filluam të merremi me konfiguracionin, ta përshkruajmë atë në Ansible, ta mbulojmë me teste.
Dita â450: ĂfarĂ« sistemi Ă«shtĂ« arritur?
Procesi nuk është interesant. Ai është rutinë; mund të theksohet se shumica e konfigurimeve ishin relativisht të thjeshta ose izomorfe, dhe sipas parimit të Pareto, 80% e konfigurimeve kërkuan 20% të kohës. Po ashtu, 80% e kohës u shpenzuan për përgatitjen e transferimit dhe vetëm 20% për vetë transferimin.
Dita â540: Finale
ĂfarĂ« ndodhi gjatĂ« 18 muajve?
- Marrëveshjet u bënë kod.
- Punë manuale -> Mekanizim -> Automatizimi.
Links
Burimi: habr.com
