Ito ay isang transcript ng talumpati ΠΈ .
Ito ang kwento ng isang proyekto na gumamit ng self-written na configuration management system at kung bakit inabot ng 18 buwan ang paglipat sa Ansible.
Araw Blg. -Π₯Π₯Π₯: Bago ang simula
Sa una, ang imprastraktura ay binubuo ng maraming hiwalay na host na nagpapatakbo ng Hyper-V. Ang paglikha ng isang virtual machine ay nangangailangan ng maraming hakbang: paglalagay ng mga disk sa tamang lugar, pagrehistro ng DNS, pagreserba ng DHCP, paglalagay ng configuration ng VM sa git repository. Ang prosesong ito ay bahagyang mekanisado, ngunit halimbawa, ang mga VM ay ipinamahagi sa pagitan ng mga host sa pamamagitan ng kamay. Ngunit, halimbawa, maaaring itama ng mga developer ang configuration ng VM sa git at ilapat ito sa pamamagitan ng pag-reboot ng VM.
Solusyon sa Pamamahala ng Custom na Configuration
Ang orihinal na ideya, pinaghihinalaan ko, ay naisip bilang IaC: maraming stateless VM na nagre-reset ng kanilang estado sa zero kapag na-reboot. Ano ang pamamahala ng pagsasaayos ng VM? Sa eskematiko, mukhang simple ito:
- Isang static na MAC ang ipinako para sa VM.
- Ang isang ISO na may CoreOS at isang boot disk ay konektado sa VM.
- Inilunsad ng CoreOS ang customization script sa pamamagitan ng pag-download nito mula sa WEB server batay sa IP nito.
- Dina-download ng script ang configuration ng VM sa pamamagitan ng SCP batay sa IP address.
- Ang footcloth ng systemd unit files at ang footcloth ng bash script ay inilunsad.
Ang solusyon na ito ay may maraming halatang problema:
- Ang CoreOS ISO ay hindi na ginagamit.
- Napakaraming kumplikadong automated na pagkilos at mahika kapag lumilipat/gumawa ng mga VM.
- Kahirapan sa pag-update at kapag kailangan ang isang partikular na bersyon ng software. Mas masaya sa mga kernel module.
- Ang mga VM ay hindi nakuha nang walang data, i.e. Lumitaw ang mga VM na may isang disk na may naka-mount na karagdagang data ng user.
- May isang taong patuloy na nagwawasak sa mga dependency ng systemd unit at ang CoreOS ay mag-freeze kapag nagre-reboot. Mahirap mahuli ito gamit ang mga magagamit na tool sa CoreOS.
- Pamamahala ng mga lihim.
- Walang CM. May mga bash at YML config para sa CoreOS.
Upang ilapat ang configuration ng VM, kailangan mong i-reboot ito, ngunit maaaring hindi ito mag-reboot. Tila isang halatang problema, ngunit walang patuloy na mga disk - wala kahit saan upang i-save ang mga log. Well, ok, subukan nating idagdag ang kernel loading option para maipadala ang mga log. Pero hindi, gaano kakomplikado ang lahat.
Araw #0: Kilalanin ang problema
Ito ang karaniwang imprastraktura ng pag-unlad: jenkins, mga kapaligiran sa pagsubok, pagsubaybay, pagpapatala. Idinisenyo ang CoreOS para sa pagho-host ng mga k8s cluster, ibig sabihin. ang problema ay kung paano ginamit ang CoreOS. Ang unang hakbang ay ang pagpili ng isang stack. Nakipag-ayos kami sa:
- CentOS bilang base distribution, dahil Ito ang pinakamalapit na pamamahagi sa mga kapaligiran ng produksyon.
- Ansible para sa pamamahala ng pagsasaayos, dahil nagkaroon ng malawak na pagsusuri dito.
- Jenkins bilang isang balangkas para sa pag-automate ng mga umiiral na proseso, dahil ito ay aktibong ginagamit para sa mga proseso ng pag-unlad
- Hyper-V bilang isang virtualization platform. Mayroong ilang mga kadahilanan na lampas sa saklaw ng kwento, ngunit sa madaling salita - hindi natin magagamit ang mga ulap, dapat nating gamitin ang sarili nating hardware.
Araw Blg. 30: Pag-aayos ng mga umiiral na kasunduan - Mga Kasunduan bilang Kodigo
Nang malinaw na ang stack, nagsimula ang paghahanda para sa paglipat. Pag-aayos ng mga umiiral na kasunduan sa anyo ng code (Mga Kasunduan bilang Code!). Transisyon manu-manong paggawa -> mekanisasyon -> automation.
1. I-configure ang mga VM
Ang Ansible ay gumagawa ng isang mahusay na gawain nito. Sa pinakamababang paggalaw ng katawan, maaari mong kontrolin ang mga configuration ng VM:
- Lumikha ng isang git repository.
- Inilalagay namin ang listahan ng mga VM sa imbentaryo, mga configuration sa mga playbook at mga tungkulin.
- Nagse-set up kami ng isang espesyal na alipin ng jenkins kung saan maaari mong patakbuhin ang Ansible.
- Lumilikha kami ng trabaho at kino-configure si Jenkins.
Ang unang proseso ay handa na. Ang mga kasunduan ay naayos na.
2. Gumawa ng bagong VM
Ang lahat dito ay hindi masyadong maginhawa. Ito ay hindi masyadong maginhawa upang lumikha ng mga VM sa Hyper-V mula sa Linux. Ang isa sa mga pagtatangka na gawing makina ang prosesong ito ay:
- Kumokonekta ang Ansbile sa pamamagitan ng WinRM sa host ng windows.
- Ang Ansible ay nagpapatakbo ng isang script ng powershell.
- Lumilikha ang Powershell script ng bagong VM.
- Gamit ang Hyper-V/ScVMM, kapag gumagawa ng VM sa guest OS, naka-configure ang hostname.
- Kapag ina-update ang DHCP lease, ipinapadala ng VM ang hostname nito.
- Ang karaniwang pagsasama ng ddns at dhcp sa panig ng Domain Controller ay nagko-configure sa DNS record.
- Maaari kang magdagdag ng VM sa iyong imbentaryo at i-configure ito gamit ang Ansible.
3.Gumawa ng VM template
Wala silang naimbento dito - kumuha sila ng packer.
- Idagdag ang packer, kickstart config sa git repository.
- Pagse-set up ng isang espesyal na alipin ng jenkins na may hyper-v at Packer.
- Lumilikha kami ng trabaho at kino-configure si Jenkins.
Paano gumagana ang link na ito:
- Lumilikha ang Packer ng isang walang laman na VM at kinuha ang ISO.
- Ang VM boots, ipinapasok ng Packer ang command sa bootloader upang gamitin ang aming kickstart file mula sa isang floppy disk o http.
- Inilunsad ang Anaconda sa aming config, at tapos na ang paunang pagsasaayos ng OS.
- Hinihintay ng Packer na maging available ang VM.
- Ang Packer sa loob ng VM ay tumatakbo sa lokal na mode.
- Ginagamit ng Ansible ang eksaktong parehong mga tungkulin na ginagawa nito sa hakbang #1.
- Ini-export ng Packer ang template ng VM.
Araw #75: Refactor ang kasunduan nang walang paglabag = Test ansible + Testkitchen
Maaaring hindi sapat ang pagkuha ng mga convention sa code. Pagkatapos ng lahat, kung sa loob at labas ng proseso ay gusto mong baguhin ang isang bagay, maaari mong masira ang isang bagay. Samakatuwid, sa kaso ng imprastraktura, lilitaw ang pagsubok sa mismong imprastraktura na ito. Upang i-synchronize ang kaalaman sa loob ng team, sinimulan naming subukan ang mga tungkulin ng Ansible. Hindi na ako magpapalalim dahil... mayroong isang artikulo na naglalarawan ng mga kaganapan sa puntong iyon ng oras (spoiler hindi ito ang huling bersyon at kalaunan ay naging mas kumplikado ang lahat ).
Araw #130: Baka hindi kailangan ang CentOS+ansible? baka openshift?
Dapat nating maunawaan na ang proseso ng pagpapakilala ng imprastraktura ay hindi lamang isa at mayroong mga side subproject. Halimbawa, dumating ang isang kahilingan upang ilunsad ang aming aplikasyon sa openshift at nagresulta ito sa pananaliksik nang higit sa isang linggo na nagpabagal sa proseso ng paglipat. Ang resulta ay lumabas na ang openshift ay hindi sumasaklaw sa lahat ng mga pangangailangan; kailangan mo ng tunay na hardware, o hindi bababa sa kakayahang maglaro sa kernel.
Araw #170: Hindi angkop ang Openshift, makipagsapalaran tayo sa Windows Azure Pack?
Ang Hyper-V ay hindi masyadong palakaibigan, hindi ito pinapaganda ng SCVMM. Ngunit mayroong isang bagay tulad ng Windows Azure Pack, na isang add-on sa SCVMM at ginagaya ang Azure. Ngunit sa katotohanan, ang produkto ay mukhang inabandona: ang dokumentasyon ay may mga sirang link at napakakaunti. Ngunit bilang bahagi ng pag-aaral ng mga opsyon para sa pagpapasimple ng buhay ng ating ulap, tiningnan din nila ito.
Araw #250: Hindi masyadong maganda ang Windows Azure Pack. Nananatili kami sa SCVMM
Mukhang may pag-asa ang Windows Azure Pack, ngunit napagpasyahan na huwag dalhin ang WAP kasama ang mga kumplikado nito sa system para sa kapakanan ng mga hindi kinakailangang feature at nanatili sa SCVMM.
Araw #360: Pagkain ng elepante nang pira-piraso
Pagkalipas lamang ng isang taon, handa na ang plataporma para sa paglipat at nagsimula na ang proseso ng paglipat. Para sa layuning ito, isang SMART na gawain ang itinakda. Sinuri namin ang lahat ng mga VM at sinimulang alamin ang pagsasaayos ng isa-isa, ilarawan ito sa Ansible, at takpan ito ng mga pagsubok.
Araw #450: Anong uri ng sistema ang nakuha mo?
Ang proseso mismo ay hindi kawili-wili. Ito ay nakagawian, mapapansin na ang karamihan sa mga pagsasaayos ay medyo simple o isomorphic at ayon sa prinsipyo ng Pareto, 80% ng mga pagsasaayos ng VM ay nangangailangan ng 20% ββng oras. Sa parehong prinsipyo, 80% ng oras ang ginugol sa paghahanda ng paglipat at 20% lamang sa paglipat mismo.
Araw #540: Pangwakas
Ano ang nangyari sa loob ng 18 buwan?
- Ang mga kasunduan ay naging isang code.
- Manu-manong paggawa -> Mekanisasyon -> Pag-aautomat.
Links
Pinagmulan: www.habr.com