Ky është një përmbledhje e fjalimit në dhe .
Kjo është historia e projektit, në të cilin u përdor një sistem i shkruar nga vetë për menaxhimin e konfigurimeve dhe si u zgjat kalimi në Ansible për 18 muaj.
Dita â -XXX: Para fillimit
Fillimisht, infrastruktura përbënte një numër hostesh të veçuar 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 i mekanizuar, por për shembull, makinat virtuale shpërndaheshin midis hosteve manualisht. Megjithatë, për shembull, zhvilluesit mund të modificonin konfigurimin e VM në git dhe ta aplikonin duke rinisur VM.
Zgjidhje e Personalizuar për Menaxhimin e Konfigurimeve
Ideja fillestare, e dyshoj, ishte menduar si IaC: shumë VM pa gjendje, të cilat, pas rinisjes, e rikthenin gjendjen e tyre në null. Si dukej menaxhimi i konfigurimeve të VM? Schematisht duket thjeshtë:
- Për VM, u vendos një MAC statik.
- VM-at u lidhën me ISO me CoreOS dhe diskun e bërë për t'u ngarkuar.
- CoreOS nis një skript personalizimi duke e shkarkuar atë nga një server WEB në bazë të IP-së së tij.
- Skripti shkarkon përmes SCP konfigurimin e VM duke u bazuar në adresën IP.
- Nisin një sërë skedarësh systemd unit dhe një sërë skriptesh bash.
Ky zgjidhje kishte shumë probleme të dukshme:
- ISO në CoreOS ishte e deprecated.
- Shumë veprime dhe magji të ndërlikuara gjatë migrimit/krijimi të VM.
- Vështirësi në përditësim dhe kur është e nevojshme të ketë një version të caktuar të softuerit. Edhe më zbavitëse me modulet e bërthamës.
- VM-të nuk ishin aq pa të dhëna, pra, dolën VM që patën disqe të montuara me të dhëna nga përdoruesit përveç kësaj.
- Përherë dikush bënte gabime me varësitë e unit systemd dhe në rinisjen e CoreOS ngeciste. Ishte problematike të kapje këtë me mjetet ekzistuese në CoreOS.
- Menaxhimi i sekreteve.
- CM pothuajse nuk kishte. Kishim bash dhe konfigurime YML të CoreOS.
PĂ«r tĂ« aplikuar konfigurimin e VM, ishte e nevojshme ta rinisje, por ajo mund tĂ« mos rinisej. Dukej si njĂ« problem i qartĂ«, por nuk kishte disqe tĂ« vazhdueshme â nuk kishte ku tĂ« ruhej logun. MirĂ«, le tĂ« pĂ«rpiqemi tĂ« shtojmĂ« opsione tĂ« ngarkesĂ«s sĂ« bĂ«rthamĂ«s qĂ« logjet tĂ« dĂ«rgoheshin. Por jo, sa e komplikuar ishte gjithçka.
Dita â0: Pranimi i problemit
Ishte një infrastrukturë e zakonshme zhvillimi: jenkins, ambientet testuese, monitorimet, registry. CoreOS ishte menduar për hostimin e klastereve k8s, pra problemi ishte se si përdorej CoreOS. Hapi i parë ishte zgjedhja e stack-ut. Ne u ndalëm tek:
- CentOS si distribucion bazik, pasi është distribuicioni më i afërt me ambientet e prodhimit.
- Ansible për menaxhimin e konfigurimeve, pasi kishte një ekspertizë të gjerë për të.
- Jenkins si një framework automatik për proceset ekzistuese, pasi ishte tashmë aktivisht i përdorur për proceset e zhvillimit.
- Hyper-V si platformĂ« virtualizimi. Ka disa arsye, tĂ« cilat dalin pĂ«rtej tregimit, por nĂ«se e pĂ«rmbledhim â nuk mund tĂ« pĂ«rdorim cloud, duhet tĂ« pĂ«rdorim harduerin tonĂ«.
Dita â30: FiksojmĂ« marrĂ«veshjet ekzistuese â Agreements as Code
Kur u kuptua stack-u, filloi përgatitja për transferimin. Fiksimi i marrëveshjeve ekzistuese në formën e kodit (Agreements as Code!). Kalimi punë manuale -> makinazhuar -> automatizimi.
1. Konfiguro VMs
Ansible e bën këtë detyrë mjaft mirë. Me minimumin e lëvizjeve mund të marrim në menaxhim konfigurimet e VM-ve:
- Krijojmë një repository git.
- Vendosim listën e VM-ve në inventory, konfigurimet në playbooks dhe role.
- Konfigurojmë një jenkins slave të veçantë nga e cila mund të nisnim ansible.
- Krijojmë një job, konfigurojmë Jenkins.
Procesi i parë është gati. Marrëveshjet janë fikse.
2. Krijo VM të re
Këtu nuk ishte shumë e lehtë. Nga Linux nuk është shumë e lehtë të krijosh VM në Hyper-V. Një nga përpjekjet për të makinizuar këtë proces ishte:
- Ansible lidhet përmes WinRM me hostin windows.
- Ansible ekzekuton skriptin powershell.
- Skripti Powershell krijon një VM të re.
- Me mjete Hyper-V/ScVMM gjatë krijimit të VM-së në OS të mysafirëve, konfiguroni hostname.
- VM në azhurnimin e DHCP lease dërgon hostname-in e saj.
- Integrimi i zakonshëm ddns & dhcp në anën e Domain Controller konfiguron regjistrin DNS.
- Mund të shtoni VM në inventar dhe të konfiguroni Ansible për të.
3. Krijo template të VM
KĂ«tu nuk u shpik asgjĂ« â morĂ«m packer.
- NĂ« repository git vendosim konfigurimin e packer, kickstart.
- Konfigurojmë një jenkins slave të veçantë me hyper-v dhe Packer.
- Krijojmë një job, konfigurojmë Jenkins.
Si funksionon ky bashkëpunim:
- Packer krijon një VM bosh, lidh ISO.
- VM ngarkohet, Packer fut në ngarkues komandën për të përdorur skedarin tonë kickstart nga disku ose http.
- Anaconda me konfigurimin tonë nis inicializimin e OS.
- Packer pret në dispozicionin e VM-së.
- Packer brenda VM-së nis ansible në modin lokal.
- Ansible pĂ«rdor tĂ« njĂ«jtat role si nĂ« hapin â1.
- Packer eksporton ŃĐ°Đ±Đ»ĐŸĐœin e VM.
Dita â75: RiorganizojmĂ« marrĂ«veshjet pa prishur = Testo ansible + Testkitchen
Të ngulisim marrëveshjet në kod mund të mos jetë e mjaftueshme. Në fund të fundit, nëse në thellësi të procesit dëshiron të ndryshosh diçka, mund të prishësh diçka. Prandaj, në rastin e infrastrukturës kemi nevojë për testimin e kësaj infrastrukture. Për të sinkronizuar njohuritë brenda ekipit filluam të testonim rolet e Ansible. Nuk do të thellohem sepse ekziston një artikel që përshkruan ngjarjet në atë kohë. (spoiler, kjo nuk ishte versione përfundimtare dhe më vonë gjithçka u bë më komplekse) ).
Dita â130: A Ă«shtĂ« CentOS + ansible i panevojshĂ«m? Ndoshta openshift?
Duhet të kuptojmë se procesi i integrimit të infrastrukturës nuk ishte i vetmi dhe kishte projekte anësore. Për shembull, erdhi një kërkesë për të lançuar aplikacionin tonë në Openshift dhe kjo shkaktoi hulumtime që zgjatën më shumë se një javë. çfarë e ngadalësoi procesin e migrimit. Rezultati doli se openshift nuk mbulon të gjitha nevojat, është e nevojshme një hardware real, ose të paktën të kemi mundësinë të luajmë me kernelin.
Dita â170: Openshift nuk Ă«shtĂ« i pĂ«rshtatshĂ«m, a tĂ« rrezikojmĂ« me Windows Azure Pack?
Hyper-V nuk është shumë miqësor, SCVMM nuk e bën shumë më të mirë. Por ka një gjë të tillë si Windows Azure Pack, e cila është një shtresë mbi SCVMM dhe imiton Azure. Por realisht produkti duket i braktisur: dokumentacioni me lidhje të prishura dhe shumë i varfër. Por në kuadër të hulumtimit të mundësive për të lehtësuar jetën e cloud-it tonë e kemi shqyrtuar edhe atë.
Dita â250: Windows Azure Pack nuk Ă«shtĂ« shumĂ«. QĂ«ndrojmĂ« me SCVMM.
Windows Azure Pack dukej shumë premtues, por u vendos që 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: HamĂ« elefantin nĂ« copa.
Vetëm pas një viti platforma ku do të migronim ishte gati dhe filloi procesi i migrimit. Për këtë ishte vendosur një detyrë S.M.A.R.T. Përshkruam të gjitha VM-të dhe filluam të merremi me konfigurimin një nga një, ta përshkruajmë atë në Ansible dhe ta mbulojmë me teste.
Dita â450: ĂfarĂ« sistemi u krijua?
Procesi vetë nuk është i interesant. Ai është rutinë, mund të theksojmë se shumica e konfigurimeve ishin relativisht të thjeshta ose izomorfe dhe sipas parimit të Pareto, 80% e konfigurimeve kërkoi 20% të kohës. Në të njëjtin parim, 80% e kohës kaloi për përgatitjen e shpërnguljes dhe vetëm 20% për shpërnguljen vetë.
Dita â540: Finale
ĂfarĂ« ndodhi pĂ«r 18 muajt?
- Marrëveshjet u bënë kod.
- Puna manuale -> Mekanizimi -> Automatizimi.
Links
Burimi: habr.com
