Nêzîkbûnek IaC (Binesaziya wekî Kodê) ne tenê ji koda ku di depoyê de tê hilanîn, di heman demê de ji kes û pêvajoyên ku vê kodê dorpêç dikin jî pêk tê. Ma gengaz e ku meriv nêzîkatiyên ji pêşkeftina nermalavê bigire heya rêveberiya binesaziyê û şirovekirinê ji nû ve bikar bîne? Dema ku hûn gotarê dixwînin dê fikrek baş be ku hûn vê ramanê di hişê xwe de bigirin.

Ev transkripta min e performansa li ser DevopsConf 2019-05-28.

Slides û vîdyoyan

Versiyonek îngilîzî
Guhertoya rûsî
Rêza hişk 2019-04-24 SpbLUG
Vîdyo (RU) ji DevopsConf 2019-05-28
Vîdyo(RU) ji DINS DevOps EVENING 2019-06-20
Slides

Binesaziya wekî dîroka bash

Bifikirin ku hûn hatine projeyek nû, û ew ji we re dibêjin: "Em hene Binesazî wekî Kod". Di rastiyê de derdikeve holê Binesaziya wekî dîroka bash an wek nimûne Belgekirin wekî dîroka bash. Ev rewşek pir rast e, mînakî, bûyerek bi vî rengî ji hêla Denis Lysenko ve di axaftinekê de hate vegotin Meriv çawa tevaya binesaziyê biguhezîne û bi xew ve dest pê bike, wî got ku wan çawa binesaziyek hevgirtî ji bo projeyê ji dîroka bash wergirt.

Bi hin xwestekan em dikarin bibêjin Binesaziya wekî dîroka bash ev wekî kodê ye:

dubarebûn: Hûn dikarin dîroka bash bigirin, fermanan ji wir bimeşînin, û dibe ku hûn, bi awayê, veavakirinek xebitandinê wekî encamek bistînin.
versioning: Hûn dizanin kî hat hundur û wan çi kir, dîsa, ne rastiyek e ku ev ê we berbi veavakirinek xebatê ya li derketinê ve bibe.
dîrok: çîroka kê çi kir. tenê heke hûn serverê winda bikin hûn ê nikaribin wê bikar bînin.

Ez çi bikim?

Binesazî wekî Kod

Hetta halekî ecêb wek Binesaziya wekî dîroka bash tu dikarî bi guhan bikişînî Binesazî wekî Kod, lê gava ku em dixwazin ji servera LAMP-a kevn a baş tiştek tevlihevtir bikin, em ê bigihîjin wê encamê ku ev kod pêdivî ye ku bi rengekî were guheztin, guheztin, başkirin. Piştre em dixwazin paralelên di navbera wan de binirxînin Binesazî wekî Kod û pêşveçûna nermalavê.

ZÛHA

Li ser projeyek pêşkeftina pergala hilanînê, binekariyek hebû periyodîk SDS-ê mîheng bikin: Em serbestberdanek nû derdixin - pêdivî ye ku ew ji bo ceribandinên din were derxistin. Karê pir hêsan e:

bi rêya ssh-ê li vir têkevin û fermanê bicîh bînin.
pelê li wir kopî bikin.
veavakirina vir rast bike.
li wir dest bi xizmetê bike
...
PROFIT!

Ji bo mantiqa diyarkirî, bash ji têrtir e, nemaze di qonaxên destpêkê yên projeyê de, dema ku ew nû dest pê dike. Ev ne xerab e ku hûn bash bikar bînin, lê bi demê re daxwaz hene ku tiştek mîna, lê hinekî cûda were bicîh kirin. Yekem tiştê ku tê bîra me kopî-paste ye. Û naha me du nivîsarên pir dişibin hev hene ku hema hema heman tiştî dikin. Bi demê re, hejmara senaryoyan mezin bû, û em bi vê rastiyê re rû bi rû man ku ji bo sazkirina sazkirinek ku pêdivî ye ku di navbera nivîsarên cihêreng de were hevdengkirin, mantiqek karsaziyê heye.

Derket holê ku pratîkek wekî DRY (Xwe Dubare Nekin) heye. Fikir ev e ku koda heyî ji nû ve bikar bîne. Ew hêsan xuya dike, lê em tavilê nehatin vê yekê. Di doza me de, ew ramanek banal bû: veqetandina mîhengan ji nivîsan. Ewan. mantiqa karsaziyê ya ku çawa sazkirinê ji hev veqetandî tête bicîh kirin, ji hev veqetandî dike.

SOLID ji bo CFM

Bi demê re proje mezin bû û berdewamiya xwezayî derketina Ansible bû. Sedema sereke ya xuyangkirina wê ev e ku pisporiya tîmê heye û ew bash ne ji bo mantiqa tevlihev hatî çêkirin. Ansible jî dest pê kir ku mantiqa tevlihev dihewîne. Ji bo ku mentiqê tevlihev neguhere kaosê, di pêşkeftina nermalavê de prensîbên organîzekirina kodê hene LISERXWE Di heman demê de, wek nimûne, Grigory Petrov di raporta "Çima pisporek IT-ê pêdivî bi marqeya kesane heye" de ev pirs kir ku kesek bi vî rengî hatî sêwirandin ku ji wî re hêsantir e ku bi hin saziyên civakî re bixebite, di pêşkeftina nermalavê de van nesne ne. Ger em van her du ramanan bigihînin hev û pêşvebirina wan bidomînin, em ê bibînin ku em jî dikarin bikar bînin LISERXWE da ku di pêşerojê de parastin û guherandina vê mantiqê hêsantir bike.

Prensîba Berpirsiyariya Yekane

Her çînek tenê karekî pêk tîne.

Ne hewce ye ku kodê tevlihev bikin û cinawirên spaghetti yên xwedayî yên monolîtîk çêbikin. Binesaz divê ji kerpîçên sade pêk were. Derket holê ku heke hûn pirtûka lîstikê ya Ansible li perçeyên piçûk veqetînin, rolên Ansible bixwînin, wê hingê domandina wan hêsantir e.

Prensîba Girtî ya Vekirî

Prensîba vekirî / girtî.

Ji dirêjkirinê re vekirî: tê vê wateyê ku tevgera saziyek bi afirandina celebên hebûnek nû dikare were dirêj kirin.
Ji guherînê re girtî: Di encama dirêjkirina tevgera saziyekê de, divê di koda ku wan saziyan bikar tîne de ti guhertin çênebe.

Di destpêkê de, me binesaziya ceribandinê li ser makîneyên virtual bi cih kir, lê ji ber ku mantiqa karsaziya bicîhkirinê ji pêkanînê veqetandî bû, me bêyî pirsgirêk li baremetall-ê vekir.

Prensîba Biguherîna Liskov

Prensîba veguherîna Barbara Liskov. tiştên di bernameyekê de divê bi mînakên jêr-tîpên xwe ve bêne guheztin bêyî guheztina pêkanîna rast a bernameyê.

Ger hûn bi berfirehî lê binêrin, ew ne taybetmendiyek projeyek taybetî ye ku li wir were sepandin LISERXWE, ew bi gelemperî li ser CFM-ê ye, mînakî, li ser projeyek din hewce ye ku serîlêdanek Java ya qutkirî li ser cûrbecûr Java, serverên serîlêdanê, databases, OS, hwd were bicîh kirin. Bi karanîna vê nimûneyê, ez ê prensîbên din binirxînim LISERXWE

Di doza me de, di nav tîmê binesaziyê de peymanek heye ku heke me rola imbjava an oraclejava saz kiribe, wê hingê me îcrakarek binary java heye. Ev pêwîst e ji ber Rolên jorîn bi vê tevgerê ve girêdayî ne; Di heman demê de, ev rê dide me ku bêyî guheztina mantiqa bicîhkirina serîlêdanê yek pêkanîn / guhertoyek java bi ya din re biguhezînin.

Pirsgirêk li vir di rastiyê de ye ku ne gengaz e ku meriv vê yekê di Ansible de bicîh bike, wekî encamek hin peyman di nav tîmê de xuya dibin.

Prensîba Veqetandina Navberê

Prensîba veqetandina navberê: "Gelek navgînên xerîdar-taybet ji yek navberek-armanca gelemperî çêtir in.

Di destpêkê de, me hewl da ku hemî cûrbecûr veguheztina serîlêdanê têxin nav yek pirtûka lîstikê ya Ansible, lê piştgirîkirina wê dijwar bû, û nêzîkatiya dema ku me navgînek derveyî diyar kir (mişterî li benda porta 443-ê ye), wê hingê binesaziyek dikare ji kesane were berhev kirin. tuxle ji bo pêkanîna taybet.

Prensîba Veguheztina Pêwendiyê

Prensîba veguherandina girêdayîbûnê. Divê modulên di astên bilind de bi modulên di astên jêrîn de venegerin. Divê her du celeb modul bi abstractionan ve girêdayî bin. Pêdivî ye ku abstraction bi hûrguliyan ve girêdayî nebin. Pêdivî ye ku hûrgulî bi abstractions ve girêdayî be.

Li vir mînak dê li ser bingehek antîpattern be.

Yek ji xerîdaran ewrek taybet hebû.
Me makîneyên virtual di hundurê ewr de ferman da.
Lê ji ber xwezaya ewr, bicîhkirina serîlêdanê bi kîjan hîpervisorê ve girêdayî bû VM.

Ewan. Mantiqa bicihkirina serîlêdanê ya asta bilind bi girêdanên bi astên jêrîn ên hîpervisor re diherikî, û ev tê wateya pirsgirêkan dema ku vê mantiqê ji nû ve bi kar bîne. Bi vî awayî nekin.

Tesîra li serhev

Binesaziya wekî kod ne tenê li ser kodê ye, lê di heman demê de di derbarê têkiliya kod û mirovan de, di derbarê danûstendinên di navbera pêşdebirên binesaziyê de ye.

Faktora otobusê

Ka em bifikirin ku we Vasya li ser projeya we heye. Vasya di derbarê binesaziya we de her tiştî dizane, ger Vasya ji nişka ve winda bibe dê çi bibe? Ev rewşek pir rast e, ji ber ku dikaribû otobusek li wî bixista. Carinan dibe. Ger ev diqewime û zanîna li ser kodê, strukturê wê, ka ew çawa dixebite, xuyang û şîfre di nav tîmê de belav nebe, wê hingê dibe ku hûn bi gelek rewşên ne xweş re rû bi rû bibin. Ji bo kêmkirina van xetereyan û belavkirina zanînê di nav tîmê de, hûn dikarin nêzîkatiyên cihêreng bikar bînin

Pair Devopsing

Ne wek e wek henekekê, ku rêvebiran bîra vexwarin, şîfre guheztin, û bernamesaziyek cotek analog. Ewan. du endezyar li ser yek komputerê, yek klavyeyê rûnin û bi hev re dest bi sazkirina binesaziya xwe dikin: sazkirina serverek, nivîsandina rolek Ansible, hwd. Deng xweş e, lê ji me re nexebitî. Lê rewşên taybetî yên vê pratîkê dixebitin. Karmendek nû tê, şêwirmendê wî bi wî re peywirek rastîn digire, dixebite û zanînê vediguhezîne.

Bûyerek din a taybet banga bûyerê ye. Di dema pirsgirêkekê de, komek ji kesên li ser erk û kesên ku tevlî dibin kom dibin, serokek tê tayînkirin, ku dîmendera xwe parve dike û dengbêjiya ramanê dike. Beşdarên din ramanên rêber dişopînin, li ser hîleyên ji konsolê sîxuriyê dikin, kontrol dikin ku wan rêzek di têketinê de winda nekiriye, û li ser pergalê tiştên nû fêr dibin. Ev nêzîkatî pir caran kar dikir.

Review Code

Bi subjektîf, belavkirina zanyariyê di derbarê binesaziyê de û çawa ew bi karanîna vekolîna kodê dixebite bandorkertir bû:

Binesaziya di depoyê de bi kodê tê vegotin.
Guhertin di şaxek cuda de çêdibin.
Di dema daxwazek yekbûnê de, hûn dikarin deltaya guhertinên di binesaziyê de bibînin.

Li vir xala balkêş ew bû ku nirxandêr yek bi yek, li gorî bernameyek, yanî. bi îhtîmalek hindek hûn ê hilkişin nav binesaziyek nû.

Code Style

Bi demê re, di dema nirxandinan de pevçûnan dest pê kir, ji ber ku ... rexnegiran şêwaza xwe hebû û zivirîna nirxanderan ew bi şêwazên cihêreng li hev kirin: 2 cîh an 4, camelCase an snake_case. Ne pêkan bû ku ev yek di cih de were pêkanîn.

Fikra yekem ev bû ku meriv bikar anîna linterê pêşniyar bike, jixwe, her kes endezyar e, her kes jîr e. Lê edîtorên cihêreng, OS, ne rehet in
Ev di nav botekek ku ji bo her peywirdariyek pirsgirêkek sist dinivîse û hilberîna lînterê pê ve girêdide veguherî. Lê di pir rewşan de tiştên girîngtir hebûn ku bêne kirin û kod bêserûber ma.

Kesk Build Master

Dem derbas dibe, û em gihîştin wê encamê ku kiryarên ku hin ceribandinan derbas nakin, nekarin destûr bidin axayê. Voila! Me Green Build Master îcad kir, ku ji demek dirêj ve di pêşkeftina nermalavê de tête pratîk kirin:

Pêşveçûn di şaxek cuda de pêk tê.
Testên li ser vê mijarê têne meşandin.
Ger ceribandin bisernekevin, kod wê nekeve nav masterê.

Girtina vê biryarê pir bi êş bû, ji ber ku ... bû sedema gelek nîqaşan, lê hêja bû, ji ber ku ... Vekolîn dest bi wergirtina daxwazên yekbûnê kirin bêyî cûdahiya şêwazê, û bi demê re hejmara deverên pirsgirêk dest pê kir kêm bû.

Testkirina IaC

Ji bilî kontrolkirina şêwazê, hûn dikarin tiştên din bikar bînin, mînakî, da ku kontrol bikin ka binesaziya we bi rastî dikare were bicîh kirin. An jî kontrol bikin ku guhertinên di binesaziyê de dê nebin sedema windakirina drav. Çima dibe ku ev hewce be? Pirs tevlihev û felsefî ye, çêtir e ku meriv bi çîrokek bersiv bide ku bi rengekî li ser Powershell-ê oto-pîvanerek hebû ku şert û mercên sînor kontrol nekir => ji hewcedariyê zêdetir VM hatin afirandin => xerîdar ji plansaziyê bêtir drav xerc kir. Ev ne pir xweş e, lê di qonaxên berê de meriv dikare vê xeletiyê bigire.

Mirov dikare bipirse, çima binesaziya kompleks hîn tevlihevtir dike? Testên ji bo binesaziyê, mîna kodê, ne li ser hêsankirinê ne, lê li ser zanibin ka binesaziya we çawa divê bixebite.

Pyramid Testing IaC

Testkirina IaC: Analîza Statîk

Ger hûn bi yekcarî tevahî binesaziyê bicîh bikin û kontrol bikin ku ew dixebite, hûn dikarin bibînin ku ew pir dem digire û pir dem hewce dike. Ji ber vê yekê, bingeh divê tiştek be ku zû bixebite, ew pir heye, û ew gelek cîhên primitive vedigire.

Bash zehmet e

Werin em li mînakek piçûk binêrin. di pelrêça heyî de hemî pelan hilbijêrin û li cîhek din kopî bikin. Yekem tiştê ku tê bîra min:

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

Heke di nav navê pelê de cîhek hebe? Welê, ok, em jîr in, em dizanin ka meriv çîtan çawa bikar tîne:

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

Aferîn? Na! Heke di pelrêçê de tiştek tune be, i.e. globbing dê nexebite.

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

Baş e niha? Na... Ji bîr kir ku di navê pelê de çi dikare hebe n.

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

Amûrên analîzkirina statîk

Pirsgirêka gava berê dema ku me qiseyan ji bîr kir dikare were girtin, ji bo vê yekê di xwezayê de gelek derman hene Shellcheck, bi gelemperî gelek ji wan hene, û bi îhtîmalek mezin hûn dikarin di binê IDE-ya xwe de ji bo stûyê xwe lînterek bibînin.

Ziman
Hacet

bash
Shellcheck

Cewher
RuboCop

python
Pîlint

ansible
Ansible Lint

Testkirina IaC: Testên Yekîneyê

Wekî ku me ji mînaka berê jî dît, lînter ne hêzdar in û nikarin hemî deverên pirsgirêkê destnîşan bikin. Wekî din, bi analogî bi ceribandina di pêşkeftina nermalavê de, em dikarin ceribandinên yekîneyê bi bîr bînin. Ev yek yekser tê bîra mirov shunit, junit, rspec, pytest. Lê bi ansible, chef, saltstack û yên wekî wan re çi bikin?

Di destpêkê de me li ser axivî LISERXWE û divê binesaziya me ji kerpîçên biçûk pêk were. Dema wan hatiye.

Binesaziya li kerpîçên piçûk tê dabeş kirin, mînakî, rolên Ansible.
Cûreyek hawîrdorê tête bicîh kirin, be ew docker an VM be.
Em rola xwe ya Ansible li vê hawîrdora ceribandinê bicîh dikin.
Em kontrol dikin ku her tişt wekî ku me hêvî dikir xebitî (em ceribandinan dimeşînin).
Em biryar didin baş e yan na.

Testkirina IaC: Amûrên Testkirina Yekîneyê

Pirs, testên ji bo CFM çi ne? Hûn dikarin bi tenê skrîptê bimeşînin, an jî hûn dikarin ji bo vê çareseriyên amade bikar bînin:

CFM
Hacet

Ansible
Testinfra

ser
Inspect

ser
Serverspec

saltstack
Goss

Mînak ji bo testinfra, kontrolkirina ku bikarhêneran test1, test2 hene û di komekê de ne 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

Çi hilbijêre? Pirs tevlihev û nezelal e, li vir mînakek guheztina projeyên li ser github ji bo 2018-2019 heye:

Çarçoveyên Testkirina IaC

Pirs derdikeve holê: meriv çawa hemî li hev kom bike û bide destpêkirin? Kanîn bigire û bi xwe bike eger hejmareke têra endezyaran hebin. An jî hûn dikarin çareseriyên amade bistînin, her çend ji wan ne pir in:

CFM
Hacet

Ansible
Molekul

ser
Kitchen Test

Terraform
Terratest

Nimûneya guhertinên projeyên li ser github ji bo 2018-2019:

Molekul vs. Testkitchen

Di destpêkê de em ceribandina ceribandinê bikar anîn:

VM-yek paralel biafirînin.
Rolên Ansible bicîh bikin.
Teftîşê bimeşînin.

Ji bo 25-35 rolan 40-70 deqîqe xebitî, ku dirêj bû.

Pêngava paşîn veguhertina jenkins / docker / ansible / molekul bû. Ji aliyê îdyolojîk ve her tişt wek hev e

Lint playbooks.
Rolan rêz bikin.
Konteynirê dest pê bike
Rolên Ansible bicîh bikin.
Testinfra bimeşînin.
Nerazîbûnê kontrol bikin.

Linting ji bo 40 rolan û testên ji bo dozen dest pê kir bi qasî 15 hûrdem.

Hilbijartina çi bi gelek faktoran ve girêdayî ye, wek stûna ku tê bikar anîn, pisporiya tîmê, hwd. li vir her kes bi xwe biryar dide ka meriv çawa pirsa ceribandina Yekîneyê bigire

Testkirina IaC: Testên Yekbûnê

Pêngava din a pîramîda ceribandina binesaziyê dê ceribandinên entegrasyonê be. Ew dişibin testên Unit:

Binesaziya li kerpîçên piçûk tê dabeş kirin, mînakî rolên Ansible.
Cûreyek hawîrdorê tête bicîh kirin, be ew docker an VM be.
Ji bo vê hawîrdora testê bicîh bikin gelek Rolên berbiçav.
Em kontrol dikin ku her tişt wekî ku me hêvî dikir xebitî (em ceribandinan dimeşînin).
Em biryar didin baş e yan na.

Bi gelemperî, em performansa hêmanek ferdî ya pergalê wekî di ceribandinên yekîneyê de kontrol nakin, em kontrol dikin ka server bi tevahî çawa tête mîheng kirin.

Testkirina IaC: Testên Dawî heta Dawî

Li serê pîramîdê em bi ceribandinên End-to End-ê têne silav kirin. Ewan. Em performansa serverek veqetandî, skrîptek veqetandî, an binesaziyek cihêreng a binesaziya xwe kontrol nakin. Em kontrol dikin ku gelek server bi hev ve girêdayî ne, binesaziya me wekî ku em jê hêvî dikin dixebite. Mixabin, min tu carî çareseriyên qutkirî yên amade nedîtiye, dibe ku ji ber ... Binesaziya bi gelemperî bêhempa û dijwar e ku meriv şablon bike û çarçoveyek ceribandinê biafirîne. Di encamê de, her kes çareseriyên xwe diafirîne. Daxwaz heye, lê bersiv tune. Ji ber vê yekê, ez ê ji we re bibêjim ka çi heye da ku kesên din bihêlin ku ramanên dengdar bihêlin an pozê xwe bişewitînin di vê rastiyê de ku her tişt berî me berê berê hate kifş kirin.

Projeyek bi dîrokek dewlemend. Ew di rêxistinên mezin de tê bikar anîn û dibe ku her yek ji we nerasterast rê li ber wê girtiye. Serlêdan gelek databas, entegrasyon, hwd piştgirî dike. Fêrbûna binesaziya ku dibe ku xuya bike gelek pelên docker-compose e, û zanîna ku Jenkins di kîjan jîngehê de kîjan ceribandinan bimeşîne.

Ev plan ji bo demek pir dirêj xebitî, heya ku di çarçoveyê de lêkolîn me hewl nedaye ku vê veguhezînin Openshift. Konteynir wek xwe dimînin, lê hawîrdora destpêkirinê guherî (dîsa silav DRY).

Fikra lêkolînê pêşdetir çû, û di openshift de wan tiştek wekî APB (Ansible Playbook Bundle) dît, ku dihêle hûn zanyariyan li ser ka meriv çawa binesaziyê di nav konteynerê de bi cih dike, berhev bike. Ewan. e a dubarekirin, xala testable zanîna li ser çawa binesaziya binesaziya.

Hemî ev deng baş bû heya ku em ketin binesaziyek heterojen: me ji bo ceribandinan hewceyê Windows-ê bû. Wekî encamek, zanîna çi, li ku, çawa were danîn, û ceribandin di jenkins de ye.

Xelasî

Binesaziya wekî Code ye

Kod di depoyê de.
Têkiliya mirovan.
testkirina binesaziyê.

girêdan

Source: www.habr.com

Tiştê ku ez ji ceribandina 200 Xetên Koda Binesaziyê fêr bûm