Hau hitzaldiaren transkripzioa da ΠΈ .
Hau da, norberak idatzitako konfigurazio-kudeaketa sistema erabili zuen proiektu baten istorioa eta zergatik hartu zuen Ansiblera 18 hilabete pasatzeak.
Egun zenbakia -Π₯Π₯Π₯: Hasi baino lehen
Hasieran, azpiegiturak Hyper-V exekutatzen zuten ostalari ezberdin asko zituen. Makina birtual bat sortzeak urrats asko behar zituen: diskoak leku egokian jartzea, DNS erregistratzea, DHCP erreserbatzea, VM konfigurazioa git biltegian jartzea. Prozesu hau partzialki mekanizatu zen, baina adibidez, VM-ak ostalarien artean eskuz banatzen ziren. Baina, adibidez, garatzaileek git-en VM konfigurazioa zuzendu eta aplikatu VM-a berrabiaraziz.
Konfigurazio pertsonalizatua kudeatzeko irtenbidea
Jatorrizko ideia, susmoa dut, IaC gisa pentsatu zen: estaturik gabeko VM asko berrabiarazitakoan egoera zerora berrezartzen dutenak. Zer zen VM konfigurazio kudeaketa? Eskematikoki erraza dirudi:
- MAC estatiko bat iltzatu zen VMrako.
- CoreOS eta abio-disko bat dituen ISO bat VMra konektatuta zeuden.
- CoreOS-ek pertsonalizazio scripta abiarazten du WEB zerbitzaritik deskargatuz bere IP-aren arabera.
- Scriptak VM konfigurazioa deskargatzen du SCP bidez IP helbidean oinarrituta.
- Systemd unitate-fitxategien oinetakoa eta bash scripten oinetakoa abiarazten dira.
Irtenbide honek arazo nabari asko zituen:
- CoreOS ISO zaharkituta geratu da.
- Ekintza automatizatu eta magia konplexu asko VM-ak migratzean/sortzean.
- Eguneratzeko zailtasuna eta softwarearen bertsio jakin bat behar denean. Are dibertigarriagoa nukleoko moduluekin.
- VM-ak ez ziren horrela lortu daturik gabe, hau da. VM-ak erabiltzailearen datu gehigarriak muntatuta zituen disko batekin agertu ziren.
- Norbaitek sistemaren unitateen mendekotasunak izorratzen zituen etengabe eta CoreOS izoztu egingo zen berrabiaraztean. Zaila izan zen hori harrapatzea CoreOS-en dauden tresnak erabiliz.
- Sekretuen kudeaketa.
- Ez zegoen CMrik. CoreOSerako bash eta YML konfigurazioak zeuden.
VM konfigurazioa aplikatzeko, berrabiarazi behar duzu, baina baliteke ez berrabiarazi. Arazo nabaria dirudi, baina ez dago disko iraunkorrik - ez dago erregistroak gordetzeko inon. Beno, ados, saia gaitezen nukleoa kargatzeko aukera gehitzen, erregistroak bidaliko dira. Baina ez, zein konplikatua den dena.
0. eguna: ezagutu arazoa
Ohiko garapen azpiegitura zen: jenkins, proba-inguruneak, monitorizazioa, erregistroa. CoreOS k8s klusterrak ostatatzeko diseinatu zen, hau da. arazoa CoreOS nola erabiltzen zen zen. Lehen urratsa pila bat aukeratzea izan zen. Honekin finkatu ginen:
- CentOS oinarrizko banaketa gisa, zeren Hau da ekoizpen-inguruneetatik hurbilen dagoen banaketa.
- Ansible konfigurazio kudeaketarako, zeren azterketa zabala egin zen.
- Jenkins dauden prozesuak automatizatzeko esparru gisa, zeren dagoeneko aktiboki erabili da garapen prozesuetarako
- Hyper-V birtualizazio plataforma gisa. Istorioaren esparrutik haratago doazen hainbat arrazoi daude, baina laburbilduz: ezin ditugu hodeiak erabili, gure hardwarea erabili behar dugu.
30. eguna: Lehendik dauden hitzarmenak finkatzea - ββHitzarmenak Kode gisa
Pila garbi zegoenean, mugimendurako prestaketak hasi ziren. Kode moduan dauden akordioak finkatzea (Hitzarmenak Kode gisa!). Trantsizioa eskuzko lana -> mekanizazioa -> automatizazioa.
1. Konfiguratu VM-ak
Ansiblek lan handia egiten du horretan. Gutxieneko gorputz mugimenduekin VM konfigurazioen kontrola hartu dezakezu:
- Sortu git biltegi bat.
- VM-en zerrenda inbentarioan, konfigurazioak playbooketan eta rolak jartzen ditugu.
- Jenkins esklabo berezi bat konfiguratzen ari gara eta bertatik Ansible exekutatu dezakezu.
- Lan bat sortzen dugu eta Jenkins konfiguratzen dugu.
Lehen prozesua prest dago. Hitzarmenak finkoak dira.
2. Sortu VM berria
Hemen dena ez zen oso erosoa. Ez da oso erosoa Linuxetik Hyper-V-en VM-ak sortzea. Prozesu hau mekanizatzeko saiakera bat izan zen:
- Ansbile WinRM bidez konektatzen da Windows ostalariarekin.
- Ansiblek powershell script bat exekutatzen du.
- Powershell script-ak VM berri bat sortzen du.
- Hyper-V/ScVMM erabiliz, sistema eragile gonbidatuan VM bat sortzean, ostalari-izena konfiguratzen da.
- DHCP errentamendua eguneratzean, VM-ak bere ostalari-izena bidaltzen du.
- Domeinu-kontrolatzailearen aldean ddns eta dhcp integrazio estandarrak DNS erregistroa konfiguratzen du.
- VM bat gehi dezakezu zure inbentarioan eta konfiguratu Ansible-rekin.
3.Sortu VM txantiloia
Hemen ez zuten ezer asmatu - paketatzaile bat hartu zuten.
- Gehitu paketzailea, kickstart konfigurazioa git biltegian.
- Hyper-v eta Packer-ekin jenkins esklabo berezi bat konfiguratzea.
- Lan bat sortzen dugu eta Jenkins konfiguratzen dugu.
Esteka honek nola funtzionatzen duen:
- Packer-ek VM huts bat sortzen du eta ISOa jasotzen du.
- VM-k abiarazten du, Packer-ek komandoa sartzen du abio-kargatzailean gure kickstart fitxategia diskete batetik edo http-tik erabiltzeko.
- Anaconda gure konfigurazioarekin abiarazten da eta hasierako sistema eragilearen konfigurazioa eginda dago.
- Packer-ek VM-a erabilgarri egon arte itxaroten du.
- VM barruko Packer-ek modu lokalean ansible exekutatzen du.
- Ansiblek #1 urratsean lan egiten dituen rol berdinak erabiltzen ditu.
- Packer-ek VM txantiloia esportatzen du.
75. eguna: birfaktorea akordioa hautsi gabe = Test ansible + Testkitchen
Baliteke konbentzioak kodean atzematea nahikoa ez izatea. Azken finean, prozesuaren barnean zerbait aldatu nahi baduzu, zerbait hautsi dezakezu. Beraz, azpiegituren kasuan, azpiegitura horren probak agertzen dira. Taldean ezagutzak sinkronizatzeko, Ansible rolak probatzen hasi ginen. Ez naiz sakonduko, zeren... garai horretako gertaerak deskribatzen dituen artikulu bat dago (spoiler hau ez zen azken bertsioa eta geroago dena zaildu egin zen ).
130. eguna: agian CentOS+ansible ez da beharrezkoa? agian txanda irekia?
Ulertu behar dugu azpiegiturak ezartzeko prozesua ez zela bakarra izan eta alboko azpiproiektuak egon zirela. Adibidez, gure aplikazioa txanda irekian abiarazteko eskaera bat etorri zen eta honek astebete baino gehiagoko ikerketa eragin zuen horrek moteldu zuen mugimendu prozesua. Ondorioz, openshift-ek ez ditu behar guztiak estaltzen; benetako hardwarea behar duzu, edo gutxienez kernelarekin jolasteko gaitasuna.
170. eguna: Openshift ez da egokia, aprobetxa dezagun Windows Azure Pack-ekin?
Hyper-V ez da oso atsegina, SCVMM-k ez du asko hobetzen. Baina Windows Azure Pack bezalako gauza bat dago, SCVMMren gehigarri bat dena eta Azure imitatzen duena. Baina, egia esan, produktuak abandonatuta dirudi: dokumentazioak loturak hautsi ditu eta oso urria da. Baina gure hodeiaren bizitza sinplifikatzeko aukeren azterketaren barruan, hori ere aztertu zuten.
250. eguna: Windows Azure Pack ez da oso ona. SCVMMn jarraitzen dugu
Windows Azure Pack itxaropentsua zirudien, baina bere konplexutasunekin WAP sistemara ez ekartzea erabaki zen, alferrikako funtzioen mesedetan eta SCVMMrekin geratu zen.
360. eguna: Elefantea zatiz pieza jatea
Handik urtebetera pasatzeko plataforma prest zegoen eta mugitzeko prozesua hasi zen. Horretarako, zeregin SMART bat ezarri zen. VM guztiak egiaztatu eta konfigurazioa banan-banan asmatzen hasi ginen, Ansible-n deskribatzen eta probekin estaltzen.
450. eguna: Zein sistema mota lortu duzu?
Prozesua bera ez da interesgarria. Errutina da, konfigurazio gehienak nahiko sinpleak edo isomorfoak zirela eta Pareto printzipioaren arabera, VM konfigurazioen % 80ak denboraren % 20 behar zuen. Printzipio beraren arabera, denboraren % 80 mugimendua prestatzen eman zen eta % 20 bakarrik mugimenduan bertan.
540. eguna: finala
Zer gertatu zen 18 hilabetean?
- Akordioak kode bihurtu ziren.
- Eskuzko lana -> Mekanizazioa -> automatizazioa.
Loturak
Iturria: www.habr.com