Požiūris TAC (Infrastruktūra kaip kodas) susideda ne tik iš saugykloje saugomo kodo, bet ir iš žmonių bei procesų, kurie supa šį kodą. Ar galima pakartotinai panaudoti metodus nuo programinės įrangos kūrimo iki infrastruktūros valdymo ir aprašymo? Būtų gera idėja nepamiršti šios minties skaitant straipsnį.

Tai mano nuorašas spektakliai apie DevopsConf 2019-05-28.

Skaidrės ir vaizdo įrašai

Anglų versija
Rusų kalba
Sausas važiavimas 2019-04-24 SpbLUG
Vaizdo įrašas (RU) iš DevopsConf 2019-05-28
Vaizdo įrašas(RU) iš DINS DevOps VAKARAS 2019-06-20
skaidrės

Infrastruktūra kaip bash istorija

Tarkime, jūs ateisite į naują projektą ir jums pasakys: „Turime Infrastruktūra kaip kodas“. Realybėje pasirodo Infrastruktūra kaip bash istorija arba pavyzdžiui Dokumentacija kaip bash istorija. Tai labai reali situacija, pavyzdžiui, panašų atvejį savo kalboje aprašė Denisas Lysenko Kaip pakeisti visą infrastruktūrą ir pradėti kietai miegoti, jis papasakojo, kaip iš bash istorijos jie gavo nuoseklią projekto infrastruktūrą.

Su tam tikru noru galime tai pasakyti Infrastruktūra kaip bash istorija tai kaip kodas:

atkuriamumas: Galite paimti bash istoriją, paleisti komandas iš ten ir, beje, galite gauti veikiančią konfigūraciją kaip išvestį.
versijų kūrimas: jūs žinote, kas atėjo ir ką jie padarė, vėlgi, tai nėra faktas, kad tai nuves jus į veikiančią konfigūraciją prie išėjimo.
istorija: istorija apie tai, kas ką padarė. tik jūs negalėsite juo naudotis, jei prarasite serverį.

Ką daryti?

Infrastruktūra kaip kodas

Net toks keistas atvejis kaip Infrastruktūra kaip bash istorija galite traukti už ausų Infrastruktūra kaip kodas, bet kai norime padaryti ką nors sudėtingesnio nei senas geras LAMP serveris, padarysime išvadą, kad šį kodą reikia kažkaip modifikuoti, keisti, tobulinti. Toliau norėtume apsvarstyti paraleles tarp Infrastruktūra kaip kodas ir programinės įrangos kūrimas.

SAUSAS

Saugojimo sistemos kūrimo projekte buvo papildoma užduotis periodiškai konfigūruoti SDS: išleidžiame naują leidimą – jį reikia išleisti tolesniam bandymui. Užduotis labai paprasta:

prisijunkite čia per ssh ir vykdykite komandą.
nukopijuokite failą ten.
čia pataisykite konfigūraciją.
pradėti paslaugą ten
...
Pelnas!

Pagal aprašytą logiką bash yra daugiau nei pakankamai, ypač ankstyvose projekto stadijose, kai jis tik prasideda. Tai nėra blogai, kad naudojate bash, tačiau laikui bėgant atsiranda prašymų įdiegti kažką panašaus, bet šiek tiek kitokio. Pirmas dalykas, kuris ateina į galvą, yra kopijavimas-įklijavimas. Ir dabar jau turime du labai panašius scenarijus, kurie daro beveik tą patį. Laikui bėgant, scenarijų skaičius augo, ir mes susidūrėme su tuo, kad yra tam tikra verslo logika diegti diegimą, kurį reikia sinchronizuoti tarp skirtingų scenarijų, tai yra gana sudėtinga.

Pasirodo, yra tokia praktika kaip DRY (Do not Repeat Yourself). Idėja yra pakartotinai naudoti esamą kodą. Skamba paprastai, bet mes to neatėjome iš karto. Mūsų atveju tai buvo banali idėja: atskirti konfigūracijas nuo scenarijų. Tie. verslo logika, kaip diegimas diegiamas atskirai, konfigūracijos atskirai.

SOLID CFM

Laikui bėgant projektas išaugo ir natūralus tęsinys buvo Ansible atsiradimas. Pagrindinė jo atsiradimo priežastis yra ta, kad komanda turi patirties ir kad bash nėra sukurta sudėtingai logikai. Ansible taip pat pradėjo turėti sudėtingą logiką. Kad sudėtinga logika nevirstų chaosu, programinės įrangos kūrimo procese yra taikomi kodo organizavimo principai KIETAS Taip pat, pavyzdžiui, Grigorijus Petrovas pranešime „Kodėl IT specialistui reikalingas asmeninis prekės ženklas“ iškėlė klausimą, kad žmogus sukurtas taip, kad jam būtų lengviau dirbti su kai kuriais socialiniais subjektais, kuriant programinę įrangą šie yra objektai. Jei šias dvi idėjas sujungsime ir toliau jas plėtosime, pastebėsime, kad taip pat galime pasinaudoti KIETAS kad ateityje būtų lengviau išlaikyti ir keisti šią logiką.

Vienos atsakomybės principas

Kiekviena klasė atlieka tik vieną užduotį.

Nereikia maišyti kodo ir kurti monolitinių dieviškų spagečių monstrų. Infrastruktūra turėtų būti sudaryta iš paprastų plytų. Pasirodo, jei Ansible pjesę padalinsite į mažas dalis, perskaitysite „Ansible“ vaidmenis, tada juos lengviau prižiūrėti.

Atviras uždaras principas

Atviro/uždarymo principas.

Atvira plėtrai: reiškia, kad objekto veikimas gali būti išplėstas sukuriant naujus objektų tipus.
Uždaryta keisti: dėl objekto veikimo išplėtimo neturėtų būti daromi kodo, kuris naudoja tuos objektus, pakeitimų.

Iš pradžių mes įdiegėme bandomąją infrastruktūrą virtualiose mašinose, tačiau dėl to, kad diegimo verslo logika buvo atskirta nuo diegimo, be jokių problemų pridėjome diegimą į „baremetall“.

Liskovo pakeitimo principas

Barbaros Liskov pakeitimo principas. programos objektai turi būti pakeičiami jų potipių egzemplioriais, nekeičiant teisingo programos vykdymo

Jei pažvelgtume plačiau, tai nėra jokio konkretaus projekto bruožas, kurį būtų galima ten pritaikyti KIETAS, paprastai kalbama apie CFM, pavyzdžiui, kitame projekte būtina įdiegti įdėtą Java programą ant įvairių Java, programų serverių, duomenų bazių, OS ir kt. Remdamasis šiuo pavyzdžiu, apsvarstysiu tolesnius principus KIETAS

Mūsų atveju infrastruktūros komandoje yra susitarimas, kad jei įdiegėme „imbjava“ arba „oraclejava“ vaidmenį, tada turime „Java“ dvejetainį vykdomąjį failą. Tai būtina, nes Vaidmenys prieš srovę priklauso nuo tokio elgesio; jie tikisi java. Tuo pačiu metu tai leidžia pakeisti vieną Java diegimą / versiją kita, nekeičiant programos diegimo logikos.

Problema čia slypi tame, kad Ansible to įgyvendinti neįmanoma, dėl to komandoje atsiranda tam tikrų susitarimų.

Sąsajos atskyrimo principas

Sąsajos atskyrimo principas: „Daugelis su klientu susijusių sąsajų yra geresnės nei viena bendrosios paskirties sąsaja.

Iš pradžių bandėme sutalpinti visą taikomųjų programų diegimo įvairovę į vieną Ansible žaidimų knygą, tačiau tai buvo sunku palaikyti, o požiūris, kai turime išorinę sąsają, nurodyta (klientas tikisi 443 prievado), tada infrastruktūrą galima surinkti iš individualaus plytos konkrečiam įgyvendinimui.

Priklausomybės inversijos principas

Priklausomybės inversijos principas. Aukštesnio lygio moduliai neturėtų priklausyti nuo žemesnio lygio modulių. Abu modulių tipai turi priklausyti nuo abstrakcijų. Abstrakcijos neturėtų priklausyti nuo detalių. Išsami informacija turi priklausyti nuo abstrakcijų.

Čia pavyzdys bus pagrįstas antipatternu.

Vienas iš klientų turėjo privatų debesį.
Užsisakėme virtualias mašinas debesyje.
Tačiau dėl debesies pobūdžio programos diegimas buvo susietas su tuo, kuris hipervizorius buvo įjungtas VM.

Tie. Aukšto lygio taikomųjų programų diegimo logika tekėjo su priklausomybėmis į žemesnius hipervizoriaus lygius, o tai reiškė problemų pakartotinai naudojant šią logiką. Nedaryk taip.

Sąveika

Infrastruktūra kaip kodas yra ne tik kodas, bet ir ryšys tarp kodo ir žmonių, apie infrastruktūros kūrėjų sąveiką.

Autobuso faktorius

Tarkime, kad jūsų projekte yra Vasya. Vasja viską žino apie jūsų infrastruktūrą, kas bus, jei Vasja staiga dings? Tai labai reali situacija, nes jį gali partrenkti autobusas. Kartais taip nutinka. Jei taip atsitiks ir žinios apie kodą, jo struktūrą, kaip jis veikia, pasirodymus ir slaptažodžius nebus paskirstytos komandai, tuomet galite susidurti su daugybe nemalonių situacijų. Norėdami sumažinti šią riziką ir paskirstyti žinias komandoje, galite naudoti įvairius metodus

Pair Devopsing

Tai ne kaip kaip pokštas, kad adminai gėrė alų, keitė slaptažodžius ir porinio programavimo analogą. Tie. du inžinieriai susėda prie vieno kompiuterio, vienos klaviatūros ir kartu pradeda kurti infrastruktūrą: nustato serverį, rašo Ansible vaidmenį ir pan. Skamba gražiai, bet mums tai nepasiteisino. Tačiau ypatingi šios praktikos atvejai pasiteisino. Ateina naujas darbuotojas, jo mentorius kartu su juo imasi realios užduoties, dirba ir perduoda žinias.

Kitas ypatingas atvejis – incidento skambutis. Problemos metu susirenka budinčiųjų ir susijusių asmenų grupė, paskiriamas vienas vadovas, kuris dalijasi savo ekranu ir įgarsina mintis. Kiti dalyviai seka lyderio mintis, spjauna į gudrybes iš pulto, patikrina, ar nepraleido nė vienos eilutės žurnale, ir sužino naujų dalykų apie sistemą. Šis metodas pasiteisino dažniau nei ne.

Kodo peržiūra

Subjektyviai vertinant kodo peržiūrą, buvo efektyviau skleisti žinias apie infrastruktūrą ir jos veikimą:

Saugykloje infrastruktūra aprašoma kodu.
Pokyčiai vyksta atskirame filiale.
Sujungimo užklausos metu galite matyti infrastruktūros pakeitimų delta.

Svarbiausia čia buvo tai, kad recenzentai buvo atrenkami po vieną, pagal grafiką, t.y. su tam tikra tikimybe pateksite į naują infrastruktūros dalį.

Kodo stilius

Laikui bėgant peržiūrų metu ėmė kilti kivirčai, nes... recenzentai turėjo savo stilių, o recenzentų rotacija juos sujungė su skirtingais stiliais: 2 tarpai arba 4, camelCase arba snake_case. Nebuvo įmanoma to iš karto įgyvendinti.

Pirma mintis buvo rekomenduoti naudoti linterį, juk visi inžinieriai, visi protingi. Tačiau skirtingi redaktoriai, OS, nėra patogūs
Tai išsivystė į robotą, kuris rašė, kad atsilaisvintų kiekvienam probleminiam įvykdymui ir prijungdavo linter išvestį. Tačiau daugeliu atvejų buvo svarbesnių dalykų ir kodas liko nepataisytas.

Žaliosios statybos meistras

Laikas eina, ir mes padarėme išvadą, kad įsipareigojimai, kurie neišlaiko tam tikrų testų, negali būti įleisti į meistrą. Voila! Mes išradome Green Build Master, kuris ilgą laiką buvo praktikuojamas kuriant programinę įrangą:

Atskirame filiale vyksta plėtra.
Šioje temoje vykdomi testai.
Jei bandymai nepavyksta, kodas nepateks į pagrindinį kodą.

Šio sprendimo priėmimas buvo labai skausmingas, nes... sukėlė daug ginčų, bet buvo verta, nes... Atsiliepimai pradėjo gauti prašymų dėl susijungimų be stiliaus skirtumų, o laikui bėgant probleminių sričių skaičius pradėjo mažėti.

IaC testavimas

Be stiliaus tikrinimo, galite naudoti kitus dalykus, pavyzdžiui, patikrinti, ar jūsų infrastruktūra iš tikrųjų gali būti įdiegta. Arba patikrinkite, ar dėl infrastruktūros pakeitimų nebus prarasti pinigai. Kodėl to gali prireikti? Klausimas sudėtingas ir filosofinis, geriau atsakyti pasakojimu, kad Powershell kažkaip buvo automatinis skaleris, kuris netikrino ribinių sąlygų => buvo sukurta daugiau VM nei reikia => klientas išleido daugiau pinigų nei planavo. Tai nėra labai malonu, tačiau būtų visiškai įmanoma pastebėti šią klaidą ankstesniuose etapuose.

Galima paklausti, kodėl sudėtinga infrastruktūra turi būti dar sudėtingesnė? Infrastruktūros, kaip ir kodo, testai nėra skirti supaprastinimui, o žinoti, kaip jūsų infrastruktūra turėtų veikti.

IaC testavimo piramidė

IaC testavimas: statinė analizė

Jei iš karto įdiegsite visą infrastruktūrą ir patikrinsite, ar ji veikia, galite pastebėti, kad tai užima daug laiko ir reikalauja daug laiko. Todėl pagrindas turi būti kažkas, kas veikia greitai, jo yra daug, ir jis apima daug primityvių vietų.

Bašas yra sudėtingas

Pažvelkime į trivialų pavyzdį. pasirinkite visus failus dabartiniame kataloge ir nukopijuokite į kitą vietą. Pirmas dalykas, kuris ateina į galvą:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Ką daryti, jei failo pavadinime yra tarpas? Na, gerai, mes protingi, mokame naudoti kabutes:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Šauniai padirbėta? Ne! O jei kataloge nieko nėra, t.y. globojimas neveiks.

find . -type f -exec mv -v {} dst/{}.bak ;

Dabar gerai padaryta? Ne... Pamiršau, kas gali būti failo pavadinime n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Statinės analizės įrankiai

Ankstesnio veiksmo problema gali kilti, kai pamiršome citatas, nes gamtoje yra daug priemonių tam Shellcheck, apskritai jų yra daug, ir greičiausiai po savo IDE galite rasti dėklą.

Pasirinkite kalbą
Įrankis

bash
Shellcheck

rubinas
RuboCop

pitonas
Pylintas

įmanoma
Ansible Lint

IaC testavimas: vienetų testai

Kaip matėme iš ankstesnio pavyzdžio, tarpai nėra visagalis ir negali nurodyti visų probleminių sričių. Be to, pagal analogiją su testavimu kuriant programinę įrangą, galime prisiminti vienetinius testus. Kas iš karto ateina į galvą šunitas, junitas, rspec, klausimas. Bet ką daryti su ansible, chef, saltstack ir kitais panašiais į juos?

Pačioje pradžioje kalbėjome apie KIETAS ir kad mūsų infrastruktūra turėtų būti sudaryta iš mažų plytų. Jų laikas atėjo.

Infrastruktūra suskirstyta į mažas plytas, pavyzdžiui, Ansible vaidmenis.
Įdiegta tam tikra aplinka, nesvarbu, ar tai dokas, ar VM.
Šioje bandymo aplinkoje taikome savo Ansible vaidmenį.
Patikriname, ar viskas veikė taip, kaip tikėjomės (atliekame testus).
Nusprendžiame gerai ar ne.

IaC testavimas: vienetų testavimo įrankiai

Klausimas, kas yra CFM testai? Galite tiesiog paleisti scenarijų arba tam galite naudoti paruoštus sprendimus:

CFM
Įrankis

Galimas
Testinfra

Virėjas
Inspekc

Virėjas
Serverio specifikacija

druska
Goss

Testinfra pavyzdys, tikrinantis, kad vartotojai test1, test2 egzistuoja ir yra grupėje sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Ką rinktis? Klausimas sudėtingas ir dviprasmiškas, čia yra 2018–2019 m. github projektų pakeitimų pavyzdys:

IaC testavimo sistemos

Kyla klausimas: kaip visa tai sujungti ir paleisti? Gali imk ir daryk pats jei yra pakankamai inžinierių. Arba galite imtis paruoštų sprendimų, nors jų nėra labai daug:

CFM
Įrankis

Galimas
molekulė

Virėjas
Bandomoji virtuvė

Terraformas
Siaubingiausias

2018–2019 m. github projektų pakeitimų pavyzdys:

Molekulė vs. Bandomoji virtuvė

Iš pradžių mes bandė naudoti testkitchen:

Lygiagrečiai sukurkite VM.
Taikykite Ansible vaidmenis.
Vykdykite patikrinimą.

25–35 vaidmenys dirbo 40–70 minučių, o tai buvo ilga.

Kitas žingsnis buvo perėjimas prie jenkins/docker/ansible/molecule. Idiologiškai viskas yra taip pat

Pūkelių žaidimų knygelės.
Suderinkite vaidmenis.
Paleisti konteinerį
Taikykite Ansible vaidmenis.
Paleiskite testinfra.
Patikrinkite idempotenciją.

40 vaidmenų ir keliolikos išbandymai pradėjo užtrukti apie 15 minučių.

Ką pasirinkti, priklauso nuo daugelio veiksnių, pvz., naudojamo krūvos, komandos patirties ir kt. čia kiekvienas pats nusprendžia, kaip uždaryti vieneto testavimo klausimą

IaC testavimas: integravimo testai

Kitas infrastruktūros testavimo piramidės žingsnis bus integracijos testai. Jie yra panašūs į vieneto testus:

Infrastruktūra suskirstyta į mažas plytas, pavyzdžiui, Ansible vaidmenis.
Įdiegta tam tikra aplinka, nesvarbu, ar tai dokas, ar VM.
Taikoma šiai bandymo aplinkai daug Galimi vaidmenys.
Patikriname, ar viskas veikė taip, kaip tikėjomės (atliekame testus).
Nusprendžiame gerai ar ne.

Grubiai tariant, mes netikriname atskiro sistemos elemento veikimo, kaip vienetų testuose, mes tikriname, kaip sukonfigūruotas serveris kaip visuma.

IaC testavimas: nuo pabaigos iki pabaigos

Piramidės viršuje mus pasitinka testai nuo pabaigos iki galo. Tie. Mes netikriname atskiro serverio, atskiro scenarijaus ar atskiros infrastruktūros dalies veikimo. Tikriname, ar daug serverių yra sujungti, mūsų infrastruktūra veikia taip, kaip tikimės. Deja, niekada nemačiau paruoštų dėžutės sprendimų, tikriausiai dėl to, kad... Infrastruktūra dažnai yra unikali ir ją sunku sukurti ir sukurti testavimo sistemą. Dėl to kiekvienas kuria savo sprendimus. Yra paklausa, bet atsakymo nėra. Todėl aš jums pasakysiu, kas yra, kad paskatinčiau kitus mąstyti ar įtrinti nosį į tai, kad viskas buvo sugalvota seniai prieš mus.

Projektas su turtinga istorija. Jis naudojamas didelėse organizacijose ir tikriausiai kiekvienas iš jūsų netiesiogiai su juo susikirto. Programa palaiko daugybę duomenų bazių, integracijų ir kt. Žinant, kaip gali atrodyti infrastruktūra, reikia daug dokerio sukurtų failų, o žinant, kokius bandymus kokioje aplinkoje atlikti, yra Jenkins.

Ši schema veikė gana ilgą laiką, kol nebuvo numatyta tyrimas mes nebandėme to perkelti į Openshift. Konteineriai išlieka tie patys, bet pasikeitė paleidimo aplinka (labas DRY ir vėl).

Tyrimo idėja buvo tęsiama ir „Openshift“ metu jie rado tokį dalyką kaip APB (Ansible Playbook Bundle), leidžiantį supakuoti žinias, kaip įdiegti infrastruktūrą į konteinerį. Tie. yra pakartojamų, patikrinamų žinių apie infrastruktūros diegimą tašką.

Visa tai skambėjo gerai, kol nepatekome į nevienalytę infrastruktūrą: mums reikėjo „Windows“ testams. Dėl to žinios apie tai, ką, kur, kaip įdiegti ir išbandyti, yra jenkins.

Išvada

Infrastruktūra tokia, kokia yra kodas

Kodas saugykloje.
Žmogaus sąveika.
Infrastruktūros bandymai.

saitai

Šaltinis: www.habr.com

Ką sužinojau išbandęs 200 000 infrastruktūros kodo eilučių