In oanpak IaC (Ynfrastruktuer as koade) bestiet net allinnich út de koade dy't opslein is yn it repository, mar ek út de minsken en prosessen dy't dizze koade omhinne. Is it mooglik om oanpakken fan softwareûntwikkeling oant ynfrastruktuerbehear en beskriuwing opnij te brûken? It soe in goed idee wêze om dit idee yn gedachten te hâlden wylst jo it artikel lêze.
Dit is in transkripsje fan myn op .
Dia's en fideo's
- Dry run 2019-04-24
Ynfrastruktuer as bash skiednis
Stel dat jo by in nij projekt komme, en se sizze jo: "wy hawwe Ynfrastruktuer as koade". Yn werklikheid docht bliken Ynfrastruktuer as bash skiednis of bygelyks Dokumintaasje as bash skiednis. Dit is in heul echte situaasje, bygelyks in ferlykbere saak waard beskreaun troch Denis Lysenko yn in taspraak , Hy fertelde hoe't se krigen in gearhingjende ynfrastruktuer foar it projekt út bash skiednis.
Mei wat winsk kinne wy dat sizze Ynfrastruktuer as bash skiednis dit is as koade:
- reproducibility: Jo kinne bash-skiednis nimme, de kommando's dêrwei útfiere, en jo kinne trouwens in wurkjende konfiguraasje krije as útfier.
- ferzje: do witst wa't kaam yn en wat se diene, wer, it is net in feit dat dit sil liede jo ta in wurkjende konfiguraasje by de útgong.
- skiednis: it ferhaal fan wa't wat die. allinich kinne jo it net brûke as jo de tsjinner ferlieze.
Wat moat ik dwaan?
Ynfrastruktuer as koade
Sels sa'n nuver gefal as Ynfrastruktuer as bash skiednis jo kinne it oan 'e earen lûke Ynfrastruktuer as koade, mar as wy wat yngewikkelder dwaan wolle as de goede âlde LAMP-tsjinner, sille wy ta de konklúzje komme dat dizze koade op ien of oare manier wizige, feroare, ferbettere wurde moat. Folgjende wolle wy beskôgje de parallellen tusken Ynfrastruktuer as koade en software ûntwikkeling.
DROECH
Op in projekt foar ûntwikkeling fan opslachsysteem wie d'r in subtaak : wy jouwe in nije release út - it moat wurde útrôle foar fierdere testen. De taak is heul ienfâldich:
- log hjir yn fia ssh en fier it kommando út.
- kopiearje de triem dêr.
- korrigearje de konfiguraasje hjir.
- begjinne de tsjinst dêr
- ...
- WINST!
Foar de beskreaune logika is bash mear dan genôch, foaral yn 'e iere stadia fan it projekt, as it krekt begjint. Dit , mar yn 'e rin fan' e tiid binne der fersiken om wat ferlykber te ynsetten, mar wat oars. It earste ding dat yn 't sin komt is copy-paste. En no hawwe wy al twa hiel ferlykbere skripts dy't hast itselde dogge. Yn 'e rin fan' e tiid groeide it oantal skripts, en wy waarden konfrontearre mei it feit dat d'r in bepaalde saaklike logika is foar it ynsetten fan in ynstallaasje dy't syngronisearre wurde moat tusken ferskate skripts, dit is frij yngewikkeld.
It docht bliken dat d'r sa'n praktyk is as DRY (Do not Repeat Yourself). It idee is om besteande koade opnij te brûken. It klinkt ienfâldich, mar wy kamen hjir net fuort. Yn ús gefal wie it in banaal idee: om konfiguraasjes te skieden fan skripts. Dy. saaklike logika fan hoe't de ynstallaasje wurdt ynset apart, configs apart.
SOLID foar CFM
Yn 'e rin fan' e tiid groeide it projekt en wie it ûntstean fan Ansible. De wichtichste reden foar syn uterlik is dat der ekspertize op it team en dat bash is net ûntwurpen foar komplekse logika. Ansible begon ek komplekse logika te befetsjen. Om foar te kommen dat komplekse logika yn gaos feroaret, binne d'r prinsipes fan koadeorganisaasje yn softwareûntwikkeling FÊST Ek, bygelyks, Grigory Petrov yn it rapport "Wêrom hat in IT-spesjalist in persoanlik merk nedich" ropt de fraach op dat in persoan is ûntwurpen op sa'n manier dat it makliker is foar him om te operearjen mei guon sosjale entiteiten, yn softwareûntwikkeling dizze binne objekten. As wy dizze twa ideeën kombinearje en trochgean mei te ûntwikkeljen, sille wy merke dat wy ek brûke kinne FÊST om it makliker te meitsjen om dizze logika yn 'e takomst te behâlden en te feroarjen.
It ienige ferantwurdlikensprinsipe
Elke klasse docht mar ien taak.
Gjin needsaak om koade te mingjen en monolityske godlike spaghetti-monsters te meitsjen. De ynfrastruktuer moat bestean út ienfâldige bakstiennen. It docht bliken dat as jo it Ansible-spielboek yn lytse stikken splitst, Ansible-rollen lêze, dan binne se makliker te ûnderhâlden.
It iepen sletten prinsipe
Iepen / sluten prinsipe.
- Iepen foar útwreiding: betsjut dat it gedrach fan in entiteit útwreide wurde kin troch nije entiteitstypen te meitsjen.
- Sletten foar feroaring: As gefolch fan it útwreidzjen fan it gedrach fan in entiteit, moatte gjin wizigingen makke wurde oan 'e koade dy't dizze entiteiten brûkt.
Yn earste ynstânsje hawwe wy de testynfrastruktuer op firtuele masines ynset, mar troch it feit dat de saaklike logika fan ynset apart wie fan 'e ymplemintaasje, hawwe wy sûnder problemen útrollen nei baremetall tafoege.
It Liskov Substitution Principle
Barbara Liskov syn ferfanging prinsipe. objekten yn in programma moatte ferfangber wêze mei eksimplaren fan har subtypen sûnder de juste útfiering fan it programma te feroarjen
As jo it breder sjogge, is it gjin skaaimerk fan in bepaald projekt dat dêr tapast wurde kin FÊST, It giet oer it algemien oer CFM, bygelyks, op in oar projekt is it nedich om in boxed Java-applikaasje yn te setten boppe op ferskate Java, applikaasjeservers, databases, OS, ensfh. Mei dit foarbyld sil ik fierdere prinsipes beskôgje FÊST
Yn ús gefal is d'r in oerienkomst binnen it ynfrastruktuerteam dat as wy de rol imbjava of oraclejava ynstalleare hawwe, dan hawwe wy in java-binêre útfierber. Dit is nedich omdat Upstream rollen binne ôfhinklik fan dit gedrach se ferwachtsje java. Tagelyk lit dit ús ien java-ymplemintaasje / ferzje ferfange troch in oare sûnder de logika fan applikaasje-ynset te feroarjen.
It probleem sit hjir yn it feit dat it net mooglik is om dit yn Ansible út te fieren, wêrtroch binnen it team guon ôfspraken ferskine.
It prinsipe fan ynterface segregaasje
Ynterface-skiedingsprinsipe: "In protte klantspesifike ynterfaces binne better dan ien ynterface foar algemiene doelen.
Yn earste ynstânsje, wy besocht te setten alle fariabiliteit fan applikaasje ynset yn ien Ansible playbook, mar it wie lestich te stypjen, en de oanpak as wy hawwe in eksterne ynterface oantsjutte (de klant ferwachtet haven 443), dan in ynfrastruktuer kin wurde gearstald út yndividuele bakstiennen foar in spesifike útfiering.
It prinsipe fan ôfhinklikens omkearing
It prinsipe fan ôfhinklikens omkearing. Modules op hegere nivo's moatte net ôfhinklik wêze fan modules op legere nivo's. Beide soarten modules moatte ôfhingje fan abstraksjes. Abstraksjes moatte net ôfhinklik wêze fan details. Details moatte ôfhingje fan abstraksjes.
Hjir sil it foarbyld basearre wêze op in antipattern.
- Ien fan de klanten hie in privee wolk.
- Wy besteld firtuele masines binnen de wolk.
- Mar troch de aard fan 'e wolk wie de ynset fan applikaasjes ferbûn oan hokker hypervisor de VM op wie.
Dy. Logika foar ynset fan applikaasjes op hege nivo streamde mei ôfhinklikens nei legere nivo's fan 'e hypervisor, en dit betsjutte problemen by it opnij brûken fan dizze logika. Doch it net op dizze manier.
Wikselwurking
Ynfrastruktuer as koade giet net allinnich oer koade, mar ek oer de relaasje tusken koade en minsken, oer ynteraksjes tusken ynfrastruktuerûntwikkelders.
Bus faktor
Litte wy oannimme dat jo Vasya hawwe op jo projekt. Vasya wit alles oer jo ynfrastruktuer, wat sil barre as Vasya ynienen ferdwynt? Dit is in heul echte situaasje, om't hy troch in bus oanriden wurde kin. Soms bart it. As dit bart en kennis oer de koade, syn struktuer, hoe't it wurket, uterlik en wachtwurden wurdt net ferdield ûnder it team, dan kinne jo tsjinkomme in oantal onaangename situaasjes. Om dizze risiko's te minimalisearjen en kennis binnen it team te fersprieden, kinne jo ferskate oanpak brûke
Pair Devopsing
It is net sa , dat de admins bier dronken, wachtwurden feroare, en in analoog fan pearprogrammearring. Dy. twa yngenieurs sitte by ien kompjûter, ien toetseboerd en begjinne tegearre jo ynfrastruktuer op te setten: in server opsette, in Ansible-rol skriuwe, ensfh. It klinkt moai, mar it slagge ús net. Mar spesjale gefallen fan dizze praktyk wurken. Der is in nije meiwurker oankommen, syn mentor nimt tegearre mei him in echte taak op, wurket en draacht kennis oer.
In oar spesjaal gefal is in ynsidint oprop. Tidens in probleem sammelet in groep fan de tsjinstfeinten en de belutsenen, ien lieder wurdt beneamd, dy't syn skerm dielt en de gedachte útstimt. Oare dielnimmers folgje de tinzen fan 'e lieder, spionearje op trúkjes fan' e konsole, kontrolearje dat se gjin rigel yn 'e log hawwe miste, en learje nije dingen oer it systeem. Dizze oanpak wurke faker as net.
Koade Resinsje
Subjektyf wie it effektiver om kennis te fersprieden oer de ynfrastruktuer en hoe't it wurket mei koadebeoardieling:
- De ynfrastruktuer wurdt beskreaun troch koade yn it repository.
- Feroarings komme yn in aparte branch.
- Tidens in fúzjefersyk kinne jo de delta sjen fan feroaringen yn 'e ynfrastruktuer.
It hichtepunt hjir wie dat de resinsinten ien foar ien selektearre waarden, neffens in skema, d.w.s. mei wat graad fan kâns silst klimme yn in nij stik ynfrastruktuer.
koade styl
Yn 'e rin fan' e tiid begûnen skeel te ferskinen by resinsjes, om't ... resinsinten hiene har eigen styl en de rotaasje fan resinsinten steapele se mei ferskate stilen: 2 spaasjes of 4, camelCase of snake_case. It wie net mooglik om dit fuort út te fieren.
- It earste idee wie om oan te rieden om linter te brûken, elkenien is ommers in yngenieur, elkenien is tûk. Mar ferskate bewurkers, OS, binne net handich
- Dit evoluearre yn in bot dy't skreau om te slackjen foar elke problematyske commit en hechte de linter-útfier. Mar yn de measte gefallen wiene der wichtiger dingen te dwaan en de koade bleau unfixed.
Griene Bouwmaster
De tiid giet foarby, en wy binne kommen ta de konklúzje dat commits dy't net trochjaan bepaalde tests kinne net tastien yn de master. Voila! Wy hawwe Green Build Master útfûn, dy't al in lange tiid yn softwareûntwikkeling wurdt beoefene:
- Yn in aparte branch is der ûntwikkeling.
- Tests rinne op dizze tried.
- As de tests mislearje, sil de koade it net yn 'e master meitsje.
It nimmen fan dit beslút wie heul pynlik, om't ... feroarsake in soad kontroverse, mar it wie it wurdich, omdat. Resinsjes begûn te ûntfangen oanfragen foar fúzjes sûnder ferskillen yn styl, en oer de tiid it oantal probleem gebieten begûn te ferminderjen.
IaC Testing
Neist stylkontrôle kinne jo oare dingen brûke, bygelyks om te kontrolearjen dat jo ynfrastruktuer wirklik kin ynsette. Of kontrolearje dat feroarings yn ynfrastruktuer net liede ta jildferlies. Wêrom kin dit nedich wêze? De fraach is kompleks en filosofysk, it is better om te beantwurdzjen mei in ferhaal dat op ien of oare manier in auto-scaler op Powershell wie dy't de grinsbetingsten net kontrolearre => mear VM's waarden makke as nedich => de klant hat mear jild útjûn as pland. Dit is net heul noflik, mar it soe heul mooglik wêze om dizze flater yn eardere stadia te fangen.
Men soe freegje kinne, wêrom meitsje komplekse ynfrastruktuer noch komplekser? Tests foar ynfrastruktuer, krekt as foar koade, geane net oer ferienfâldiging, mar oer witten hoe't jo ynfrastruktuer wurkje moat.
IaC Testing Piramide
IaC Testing: Statyske analyze
As jo de hiele ynfrastruktuer tagelyk ynsette en kontrolearje dat it wurket, kinne jo fine dat it in protte tiid nimt en in protte tiid fereasket. Dêrom moat de basis wat wêze dat fluch wurket, der is in protte fan, en it beslacht in protte primitive plakken.
Bash is lestich
Litte wy nei in triviale foarbyld sjen. selektearje alle bestannen yn 'e aktive map en kopiearje nei in oare lokaasje. It earste ding dat yn 't sin komt:
for i in * ; do
cp $i /some/path/$i.bak
doneWat as der in spaasje is yn 'e triemnamme? No, ok, wy binne tûk, wy witte hoe't wy sitaten brûke:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneGoed dien? Nee! Wat as der neat yn de map stiet, d.w.s. globbing sil net wurkje.
find . -type f -exec mv -v {} dst/{}.bak ;No goed dien? Nee... Fergetten wat der yn de triemnamme stean kin n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirStatyske analyze ark
It probleem fan 'e foarige stap koe wurde fongen doe't wy de sitaten ferjitten, hjirfoar binne d'r in protte remedies yn' e natuer , yn 't algemien binne d'r in protte, en wierskynlik kinne jo in linter fine foar jo stapel ûnder jo IDE.
Taal
Helpmiddel
bash
Ruby
python
tawinske
IaC Testing: Unit Tests
As wy seagen út it foarige foarbyld, linters binne net omnipotent en kin net wize op alle probleem gebieten. Fierder, nei analogy mei testen yn softwareûntwikkeling, kinne wy ienheidstests ûnthâlde. Wat daliks opkomt is , , , . Mar wat te dwaan mei ansible, chef, saltstack en oaren lykas harren?
Oan it begjin hawwe wy it oer FÊST en dat ús ynfrastruktuer út lytse bakstiennen bestean moat. Har tiid is kommen.
- De ynfrastruktuer is ferdield yn lytse bakstiennen, Bygelyks, Ansible rollen.
- In soarte fan omjouwing wurdt ynset, of it no docker is as in VM.
- Wy tapasse ús Ansible-rol op dizze testomjouwing.
- Wy kontrolearje dat alles wurke lykas wy ferwachte (wy rinne tests).
- Wy beslute ok of net ok.
IaC Testing: Unit Testing ark
Fraach, wat binne tests foar CFM? Jo kinne it skript gewoan útfiere, of jo kinne hjirfoar klearmakke oplossingen brûke:
CFM
Helpmiddel
Sible
holle
holle
sâltsteapel
Foarbyld foar testinfra, kontrolearjen dat brûkers test1, test2 bestean en binne yn in groep sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsWat te kiezen? De fraach is kompleks en dûbelsinnich, hjir is in foarbyld fan feroaringen yn projekten op github foar 2018-2019:
IaC Testing frameworks
De fraach ûntstiet: hoe te setten alles byinoar en lansearje it? Kinne as der in foldwaande oantal yngenieurs. Of jo kinne klearmakke oplossingen nimme, hoewol d'r net in protte fan binne:
CFM
Helpmiddel
Sible
holle
Terraform
Foarbyld fan wizigingen yn projekten op github foar 2018-2019:
Molecule vs. Testkeuken
Yn earste ynstânsje wy :
- Meitsje in VM parallel.
- Tapasse Ansible rollen.
- Run ynspeksje.
Foar 25-35 rollen wurke it 40-70 minuten, dat wie lang.
De folgjende stap wie de oergong nei jenkins/docker/ansible/molecule. Idiologysk is alles itselde
- Lint playbooks.
- Stel de rollen op.
- Launch container
- Tapasse Ansible rollen.
- Testinfra útfiere.
- Kontrolearje idempotency.
Linting foar 40 rollen en tests foar in tsiental begûn te nimmen oer 15 minuten.
Wat te kiezen hinget ôf fan in protte faktoaren, lykas de brûkte stapel, ekspertize yn it team, ensfh. hjir beslút elkenien foar harsels hoe't de ienheidstestfraach slute sil
IaC Testing: Yntegraasje Tests
De folgjende stap yn 'e testpiramide foar ynfrastruktuer sil yntegraasjetests wêze. Se binne fergelykber mei ienheidstests:
- De ynfrastruktuer is opdield yn lytse bakstiennen, bygelyks Ansible rollen.
- In soarte fan omjouwing wurdt ynset, of it no docker is as in VM.
- Foar dizze testomjouwing jilde in protte Oanfoljende rollen.
- Wy kontrolearje dat alles wurke lykas wy ferwachte (wy rinne tests).
- Wy beslute ok of net ok.
Rûchwei sprutsen, wy kontrolearje net de prestaasjes fan in yndividueel elemint fan it systeem lykas yn ienheid tests, wy kontrolearje hoe't de tsjinner is konfigurearre as gehiel.
IaC Testing: Ein oan ein Tests
Oan 'e top fan' e piramide wurde wy begroete troch End to End tests. Dy. Wy kontrolearje net de prestaasjes fan in aparte server, in apart skript, of in aparte bakstien fan ús ynfrastruktuer. Wy kontrolearje dat in protte servers mei-inoar ferbûn binne, ús ynfrastruktuer wurket sa't wy dat ferwachtsje. Spitigernôch haw ik noch noait klearmakke doaze oplossingen sjoen, wierskynlik om't ... De ynfrastruktuer is faak unyk en dreech te sjabloan en meitsje in ramt foar testen. Dêrtroch makket elkenien har eigen oplossingen. Der is in fraach, mar der is gjin antwurd. Dêrom sil ik jo fertelle wat d'r is om oaren te triuwe om gedachten te klinken of myn noas te wrijven yn it feit dat alles lang lyn foar ús útfûn is.
In projekt mei in rike skiednis. It wurdt brûkt yn grutte organisaasjes en wierskynlik hat elk fan jo yndirekt paden mei krúst. De applikaasje stipet in protte databases, yntegraasjes, ensfh. Wisten hoe't de ynfrastruktuer der útsjen kin, is in protte docker-compose-bestannen, en witten hokker tests moatte wurde útfierd yn hokker omjouwing Jenkins is.
Dizze regeling wurke nochal lang, oant yn it ramt wy hawwe net besocht dit oer te bringen nei Openshift. De konteners bliuwe itselde, mar de startomjouwing is feroare (hallo DRY wer).
It ûndersyksidee gie fierder, en yn openshift fûnen se sa'n ding as APB (Ansible Playbook Bundle), wêrmei jo kennis kinne pakke oer hoe't jo ynfrastruktuer yn in kontener kinne ynsette. Dy. der is in repeatable, testable punt fan kennis oer hoe te ynsette de ynfrastruktuer.
Dit alles klonk goed oant wy in heterogene ynfrastruktuer rûnen: wy hiene Windows nedich foar testen. As gefolch, de kennis fan wat, wêr, hoe te ynsette, en test is yn jenkins.
Konklúzje
Ynfrastruktuer as Code is
- Koade yn 'e repository.
- Minske ynteraksje.
- Ynfrastruktuer testen.
keppelings
- Dry run 2019-04-24
- &
Boarne: www.habr.com