Lähenemine IaC (Infrastructure as Code) ei koosne ainult hoidlasse salvestatavast koodist, vaid ka seda koodi ümbritsevatest inimestest ja protsessidest. Kas on võimalik taaskasutada lähenemisviise alates tarkvaraarendusest kuni infrastruktuuri haldamise ja kirjeldamiseni? Seda mõtet oleks hea artikli lugemise ajal meeles pidada.

See on minu ärakiri etendused edasi DevopsConf 2019.

Slaidid ja videod

Angielski versioon
Vene versioon
Kuivsõit 2019-04-24 SpbLUG
Video (RU) DevopsConfist 2019
Video(RU) DINS DevOpsist ÕHTU 2019-06-20
Slaidid

Infrastruktuur kui bash ajalugu

Oletame, et tulete uue projekti juurde ja nad ütlevad teile: "Meil on Infrastruktuur koodina". Tegelikkuses selgub Infrastruktuur kui bash ajalugu või näiteks Dokumentatsioon kui bash ajalugu. See on väga reaalne olukord, näiteks kirjeldas sarnast juhtumit Deniss Lõssenko oma kõnes Kuidas kogu taristu välja vahetada ja rahulikult magama hakata, rääkis ta, kuidas nad said bash ajaloost projekti jaoks sidusa infrastruktuuri.

Teatud soovi korral võime seda öelda Infrastruktuur kui bash ajalugu see on nagu kood:

reprodutseeritavus: Sa võid võtta bashi ajaloo, käivitada sealt käsud ja võid, muide, saada väljundiks toimiva konfiguratsiooni.
versioonide koostamine: teate, kes sisse tuli ja mida nad tegid, jällegi pole tõsiasi, et see viib teid väljapääsu juures töötavasse konfiguratsiooni.
lugu: lugu sellest, kes mida tegi. ainult te ei saa seda kasutada, kui serveri kaotate.

Mida teha?

Infrastruktuur koodina

Isegi selline kummaline juhtum nagu Infrastruktuur kui bash ajalugu saate seda kõrvadest tõmmata Infrastruktuur koodina, aga kui tahame teha midagi keerulisemat kui vana hea LAMP-server, siis jõuame järeldusele, et seda koodi tuleb kuidagi muuta, muuta, täiustada. Järgmisena tahaksime kaaluda paralleele Infrastruktuur koodina ja tarkvaraarendus.

KUIV

Salvestussüsteemi arendusprojektis oli alamülesanne SDS-i perioodiliselt konfigureerida: anname välja uue versiooni – see tuleb edasiseks testimiseks välja anda. Ülesanne on äärmiselt lihtne:

logige siia ssh kaudu sisse ja käivitage käsk.
kopeerige fail sinna.
paranda siin konfiguratsiooni.
käivitage seal teenus
...
KASUM!

Kirjeldatud loogika jaoks on bash enam kui piisav, eriti projekti algfaasis, kui see alles algab. See pole paha, et sa bashi kasutad, kuid aja jooksul esitatakse taotlusi juurutada midagi sarnast, kuid veidi erinevat. Esimene asi, mis meelde tuleb, on copy-paste. Ja nüüd on meil juba kaks väga sarnast skripti, mis teevad peaaegu sama asja. Aja jooksul skriptide arv kasvas ja me seisime silmitsi tõsiasjaga, et installimise juurutamiseks on teatud äriloogika, mida tuleb erinevate skriptide vahel sünkroonida, see on üsna keeruline.

Selgub, et on olemas selline tava nagu KUIV (Ära korda ennast). Idee on olemasoleva koodi taaskasutamine. See kõlab lihtsalt, kuid me ei jõudnud selleni kohe. Meie puhul oli see banaalne idee: eraldada konfiguratsioonid skriptidest. Need. äriloogika selle kohta, kuidas installatsioon juurutatakse eraldi, konfiguratsioonid eraldi.

SOLID CFM-i jaoks

Aja jooksul projekt kasvas ja loomulik jätk oli Ansible tekkimine. Selle väljanägemise peamine põhjus on see, et meeskonnal on asjatundlikkus ja et bash pole loodud keeruka loogika jaoks. Ansible hakkas sisaldama ka keerulist loogikat. Vältimaks keerulise loogika muutumist kaoseks, on tarkvaraarenduses koodi korrastamise põhimõtted TAHKE Ka näiteks Grigori Petrov tõstatas raportis “Miks vajab IT-spetsialist persoonibrändi” küsimuse, et inimene on kujundatud nii, et tal on lihtsam mõne sotsiaalse olemiga opereerida, tarkvaraarenduses need on objektid. Kui ühendame need kaks ideed ja jätkame nende arendamist, märkame, et saame ka kasutada TAHKE et seda loogikat oleks edaspidi lihtsam säilitada ja muuta.

Ühtse vastutuse põhimõte

Iga klass täidab ainult ühte ülesannet.

Pole vaja koodi segada ja teha monoliitseid jumalikke spagetikoletisi. Taristu peaks koosnema lihtsatest tellistest. Selgub, et kui Ansible mänguraamat väikesteks tükkideks jagada, Ansible rollid läbi lugeda, siis on neid lihtsam hooldada.

Avatud suletud põhimõte

Avatud/suletud põhimõte.

Laiendamiseks avatud: tähendab, et olemi käitumist saab laiendada uute olemitüüpide loomisega.
Muudatuste jaoks suletud: olemi käitumise laiendamise tulemusena ei tohiks neid olemeid kasutavas koodis muudatusi teha.

Esialgu juurutasime testtaristu virtuaalsetele masinatele, kuid kuna juurutamise äriloogika oli juurutusest eraldiseisev, lisasime ilma probleemideta baremetalli juurutamise.

Liskovi asenduspõhimõte

Barbara Liskovi asenduspõhimõte. programmis olevad objektid peavad olema asendatavad nende alamtüüpide eksemplaridega ilma programmi õiget täitmist muutmata

Kui vaadata laiemalt, siis see ei ole ühegi konkreetse projekti omadus, mida seal rakendada saaks TAHKE, üldiselt on tegemist CFM-iga, näiteks mõne teise projekti puhul on vaja juurutada karbis Java rakendus erinevate Java, rakendusserverite, andmebaaside, OS-i jne peale. Seda näidet kasutades kaalun edasisi põhimõtteid TAHKE

Meie puhul on taristumeeskonna sees kokkulepe, et kui oleme installinud imbjava või oraclejava rolli, siis meil on Java binaarne käivitatav fail. See on vajalik, sest Ülesvoolu rollid sõltuvad sellest käitumisest, mida nad ootavad. Samas võimaldab see meil asendada ühe java juurutamise/versiooni teisega ilma rakenduse juurutamise loogikat muutmata.

Probleem seisneb siin selles, et Ansibles pole seda võimalik rakendada, mille tulemusena tekivad meeskonnasisesed kokkulepped.

Liidese eraldamise põhimõte

Liideste eraldamise põhimõte: "Paljud kliendipõhised liidesed on paremad kui üks üldotstarbeline liides.

Algselt proovisime panna kogu rakenduse juurutamise varieeruvuse ühte Ansible mänguraamatusse, kuid seda oli raske toetada ja lähenemine, kui meil on määratud väline liides (klient ootab porti 443), siis saab infrastruktuuri kokku panna individuaalsest tellised konkreetse teostuse jaoks.

Sõltuvuste inversiooni põhimõte

Sõltuvuste inversiooni põhimõte. Kõrgemate tasemete moodulid ei tohiks sõltuda madalamate tasemete moodulitest. Mõlemat tüüpi moodulid peavad sõltuma abstraktsioonidest. Abstraktsioonid ei tohiks sõltuda üksikasjadest. Üksikasjad peavad sõltuma abstraktsioonidest.

Siin põhineb näide antimustril.

Ühel klientidest oli privaatpilv.
Tellisime virtuaalsed masinad pilve sisse.
Kuid pilve olemuse tõttu oli rakenduse juurutamine seotud sellega, millise hüperviisoriga VM oli sisse lülitatud.

Need. Kõrgetasemeline rakenduste juurutamise loogika liikus koos sõltuvustega hüperviisori madalamatele tasemetele ja see tähendas probleeme selle loogika taaskasutamisel. Ärge tehke seda sel viisil.

Koostoime

Infrastruktuur kui kood ei tähenda ainult koodi, vaid ka koodi ja inimeste vahelist suhet, infrastruktuuri arendajate vahelist suhtlust.

Bussi tegur

Oletame, et teie projektis on Vasya. Vasya teab teie infrastruktuurist kõike, mis juhtub, kui Vasya äkki kaob? See on väga reaalne olukord, sest ta võib bussilt löögi saada. Mõnikord juhtub. Kui see juhtub ja teadmised koodi, selle ülesehituse, selle toimimise, välimuse ja paroolide kohta ei jagu meeskonna vahel, siis võib ette tulla mitmeid ebameeldivaid olukordi. Nende riskide minimeerimiseks ja teadmiste levitamiseks meeskonnas saate kasutada erinevaid lähenemisviise

Paar Devopsing

Ei ole nagu naljana, et adminnid jõid õlut, vahetasid paroole ja paarisprogrammeerimise analoogi. Need. kaks inseneri istuvad ühe arvuti, ühe klaviatuuri taha ja alustavad koos oma infrastruktuuri seadistamist: serveri seadistamine, Ansible rolli kirjutamine jne. See kõlab kenasti, kuid see ei töötanud meie jaoks. Kuid selle praktika erijuhud töötasid. Tuleb uus töötaja, tema mentor võtab koos temaga reaalse ülesande, töötab ja annab teadmisi edasi.

Teine erijuhtum on juhtumikõne. Probleemi ajal koguneb grupp valvesolijaid ja asjaosalisi, määratakse üks juht, kes jagab oma ekraani ja annab välja mõttekäigu. Teised osalejad jälgivad juhi mõtteid, luuravad konsoolist näpunäiteid, kontrollivad, et nad pole logis ühtegi rida vahele jätnud ja õpivad süsteemi kohta uusi asju. See lähenemisviis töötas sagedamini kui mitte.

Koodi ülevaade

Subjektiivselt oli tõhusam levitada teadmisi infrastruktuuri ja selle toimimise kohta koodiülevaatuse abil:

Infrastruktuuri kirjeldatakse hoidlas koodiga.
Muudatused toimuvad eraldi harus.
Ühinemistaotluse ajal näete infrastruktuuri muudatuste deltat.

Tipphetk oli siin see, et retsensente valiti ükshaaval, ajakava järgi, s.o. teatud tõenäosusega ronite uude infrastruktuuri.

Koodi stiil

Aja jooksul hakkasid ülevaatuste käigus tekkima tülid, sest... arvustajatel oli oma stiil ja arvustajate vaheldumine pani neile erinevaid stiile: 2 tühikut või 4, camelCase või snake_case. Seda ei olnud võimalik kohe rakendada.

Esimene mõte oli soovitada linterit kasutada, kõik on ju insenerid, kõik on targad. Kuid erinevad toimetajad, OS, pole mugavad
See arenes robotiks, mis kirjutas iga probleemse toimepanemise korral lõdvaks ja ühendas linteri väljundi. Enamasti oli aga tähtsamaid asju teha ja kood jäi parandamata.

Roheline ehitusmeister

Aeg möödub ja oleme jõudnud järeldusele, et kohustusi, mis teatud teste ei läbi, ei saa masterisse lubada. Voila! Leiutasime Green Build Masteri, mida on tarkvaraarenduses juba pikka aega praktiseeritud:

Arendus käib eraldi harus.
Selles lõimes testid käivad.
Kui testid ebaõnnestuvad, ei jõua kood ülemseadmesse.

Selle otsuse tegemine oli väga valus, sest... tekitas palju poleemikat, kuid see oli seda väärt, sest... Ülevaated hakkasid saama ühinemistaotlusi ilma stiilierinevusteta ja aja jooksul hakkas probleemsete kohtade arv vähenema.

IaC testimine

Lisaks stiilikontrollile saate kasutada muid asju, näiteks kontrollida, kas teie infrastruktuur saab ka tegelikult kasutusele võtta. Või kontrollige, et infrastruktuuri muutmine ei too kaasa rahakaotust. Miks võib seda vaja minna? Küsimus on keeruline ja filosoofiline, parem on vastata jutuga, et Powershellil oli kuidagi automaatne skaler, mis ei kontrollinud piirtingimusi => VM-e loodi rohkem kui vaja => klient kulutas plaanitust rohkem raha. See ei ole eriti meeldiv, kuid see viga oleks varasematel etappidel täiesti võimalik.

Võib küsida, miks teha keerulist infrastruktuuri veelgi keerulisemaks? Infrastruktuuri testid, nagu ka koodi, ei seisne lihtsustamises, vaid selles, et teada saada, kuidas teie infrastruktuur peaks töötama.

IaC testimispüramiid

IaC testimine: staatiline analüüs

Kui juurutate kogu infrastruktuuri korraga ja kontrollite selle toimimist, võite avastada, et see võtab palju aega ja nõuab palju aega. Seetõttu peab aluseks olema midagi, mis töötab kiiresti, seda on palju ja see katab palju primitiivseid kohti.

Bash on keeruline

Vaatame triviaalset näidet. valige kõik praeguses kataloogis olevad failid ja kopeerige need teise asukohta. Esimene asi, mis pähe tuleb:

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

Mis siis, kui failinimes on tühik? Noh, ok, me oleme targad, me teame, kuidas kasutada jutumärke:

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

Hästi tehtud? Ei! Mis siis, kui kataloogis pole midagi, st. globutamine ei tööta.

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

Kas nüüd on hästi tehtud? Ei... Unustasin, mis failinimes olla võib n.

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

Staatilise analüüsi tööriistad

Eelmise sammu probleem võib tabada, kui unustasime tsitaadid, selleks on looduses palju abinõusid Shellcheck, üldiselt on neid palju ja suure tõenäosusega leiate oma virna jaoks oma IDE alt linteri.

Keel
Vahend

sisse lööma
Shellcheck

rubiin
RuboCop

püüton
pülint

ansible
Ansible Lint

IaC testimine: ühiktestid

Nagu eelmisest näitest nägime, ei ole linterid kõikvõimsad ega suuda kõiki probleemseid kohti välja tuua. Lisaks võime analoogselt tarkvaraarenduse testimisega meenutada ühikuteste. Mis kohe meelde tuleb, on shunit, junit, rspec, pytest. Aga mida teha ansible, chef, saltstacki ja teiste sarnastega?

Kohe alguses rääkisime sellest TAHKE ja et meie infrastruktuur peaks koosnema väikestest tellistest. Nende aeg on kätte jõudnud.

Taristu on jagatud väikesteks tellisteks, näiteks Ansible rollideks.
Kasutusele on võetud mingisugune keskkond, olgu selleks siis dokkija või virtuaalne arvuti.
Rakendame selles testkeskkonnas oma Ansible rolli.
Kontrollime, kas kõik toimis ootuspäraselt (käitame testid).
Otsustame, kas on hästi või mitte.

IaC testimine: üksuse testimise tööriistad

Küsimus, millised on CFM-i testid? Võite skripti lihtsalt käivitada või kasutada selleks valmislahendusi:

CFM
Vahend

Võimalik
Testinfra

peakokk
Inspek

peakokk
ServerSpec

soolakuhi
Goss

Näide testinfra jaoks, mis kontrollib, et kasutajad test1, test2 eksisteerivad ja on grupis 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

Mida valida? Küsimus on keeruline ja mitmetähenduslik, siin on näide muudatustest githubi projektides aastatel 2018–2019:

IaC testimise raamistikud

Tekib küsimus: kuidas see kõik kokku panna ja käivitada? Saab võta ja tee ise kui on piisav arv insenere. Või võite võtta valmislahendused, kuigi neid pole väga palju:

CFM
Vahend

Võimalik
Molekul

peakokk
Testi köök

Terraform
Terratest

Näide muudatustest projektides Githubis aastatel 2018–2019:

Molekul vs. Testköök

Esialgu meie proovisin kasutada testkööki:

Looge paralleelselt VM.
Rakendage Ansible rolle.
Käivitage ülevaatus.

25-35 rolli puhul töötas see 40-70 minutit, mis oli pikk.

Järgmine samm oli üleminek jenkinsile/dockerile/ansible/molecule. Idioloogiliselt on kõik sama

Lint mänguraamatud.
Reastage rollid.
Käivitage konteiner
Rakendage Ansible rolle.
Käivitage testinfra.
Kontrollige idempotentsust.

Linting 40 rolli jaoks ja testid tosina jaoks hakkasid kestma umbes 15 minutit.

See, mida valida, sõltub paljudest teguritest, nagu kasutatav pinu, meeskonna teadmised jne. siin otsustab igaüks ise, kuidas üksuse testimise küsimus sulgeda

IaC testimine: integratsioonitestid

Järgmine samm infrastruktuuri testimise püramiidis on integratsioonitestid. Need on sarnased ühikutestidega:

Taristu on jagatud väikesteks tellisteks, näiteks Ansible rollid.
Kasutusele on võetud mingisugune keskkond, olgu selleks siis dokkija või virtuaalne arvuti.
Selle testikeskkonna jaoks kehtivad komplekt Võimalikud rollid.
Kontrollime, kas kõik toimis ootuspäraselt (käitame testid).
Otsustame, kas on hästi või mitte.

Jämedalt öeldes ei kontrolli me süsteemi üksiku elemendi toimivust nagu ühikutestide puhul, vaid kontrollime, kuidas server on konfigureeritud tervikuna.

IaC testimine: otsast lõpuni testid

Püramiidi tipus tervitavad meid End to End testid. Need. Me ei kontrolli eraldi serveri, eraldi skripti või oma infrastruktuuri eraldi tellise toimivust. Kontrollime, et paljud serverid oleksid omavahel ühendatud, meie infrastruktuur töötab ootuspäraselt. Kahjuks pole ma kunagi näinud valmis kastilahendusi, ilmselt seetõttu... Infrastruktuur on sageli ainulaadne ning seda on keeruline mallindada ja testimiseks raamistikku luua. Selle tulemusena loob igaüks ise oma lahendused. Nõudmine on olemas, aga vastust pole. Seetõttu räägin teile, mis on selleks, et sundida teisi mõtlema või hõõruma oma nina sellesse, et kõik leiutati ammu enne meid.

Rikkaliku ajalooga projekt. Seda kasutatakse suurtes organisatsioonides ja tõenäoliselt on igaühel teist sellega kaudselt teed ristunud. Rakendus toetab paljusid andmebaase, integratsioone jne. Teades, milline infrastruktuur välja näeb, on palju dokkerite koostamise faile ja teadmine, milliseid teste millises keskkonnas käivitada, on Jenkins.

See skeem töötas päris kaua, kuni raamidesse teadustöö me pole proovinud seda Openshifti üle kanda. Konteinerid jäävad samaks, kuid käivituskeskkond on muutunud (tere KUIV jälle).

Uurimisidee läks kaugemale ja openshiftis leidsid nad sellise asja nagu APB (Ansible Playbook Bundle), mis võimaldab konteinerisse pakkida teadmised infrastruktuuri juurutamise kohta. Need. infrastruktuuri kasutuselevõtu kohta on korratav ja testitav teadmiste punkt.

Kõik see kõlas hästi, kuni sattusime heterogeensesse infrastruktuuri: vajasime testide jaoks Windowsi. Selle tulemusena on teadmised selle kohta, mida, kus, kuidas juurutada ja testida, jenkinsis.

Järeldus

Taristu nagu kood on

Kood hoidlas.
Inimeste suhtlus.
Infrastruktuuri testimine.

lingid

Allikas: www.habr.com

Mida ma õppisin 200 000 infrastruktuuri koodirea testimisel