Un approcciu IaC (Infrastruttura cum'è Code) ùn hè micca solu di u codice chì hè guardatu in u repository, ma ancu di e persone è prucessi chì circundanu stu codice. Hè pussibule riutilizà approcci da u sviluppu di software à a gestione di l'infrastruttura è a descrizzione? Saria una bona idea di mantene sta idea in mente mentre leghjite l'articulu.
Questa hè una trascrizione di u mo nantu .
Slides è video
- Corsa secca 2019-04-24
L'infrastruttura cum'è a storia di bash
Supponete chì vene à un novu prughjettu, è vi dicenu: "avemu Infrastruttura cum'è Codice". In a realità si trova L'infrastruttura cum'è a storia di bash o per esempiu Documentazione cum'è storia di bash. Questa hè una situazione assai reale, per esempiu, un casu simili hè statu descrittu da Denis Lysenko in un discorsu , hà dettu cumu avè una infrastruttura coherente per u prugettu da a storia di bash.
Cù qualchì desideriu, pudemu dì chì L'infrastruttura cum'è a storia di bash questu hè cum'è codice:
- riproducibilità: Pudete piglià a storia di bash, eseguite i cumandamenti da quì, è pudete, per via, uttene una cunfigurazione di travagliu cum'è output.
- versioning: sapete quale hè ghjuntu è ciò chì anu fattu, di novu, ùn hè micca un fattu chì questu vi purterà à una cunfigurazione di output di travagliu.
- storia: a storia di quale hà fattu chì. solu ùn puderete micca aduprà s'ellu perde u servitore.
Chì deve fà?
Infrastruttura cum'è Codice
Ancu un casu cusì stranu cum'è L'infrastruttura cum'è a storia di bash pudete tirà per l'arechje Infrastruttura cum'è Codice, Ma quandu vulemu fà qualcosa di più cumplicatu chè u bonu servitore LAMP anticu, avemu da vene à a cunclusione chì stu codice deve esse in qualchì modu mudificatu, cambiatu, migliuratu. In seguitu, vulemu cunsiderà i paralleli trà Infrastruttura cum'è Codice è u sviluppu di software.
SECCA
Nantu à un prughjettu di sviluppu di u sistema di almacenamentu, ci era una subtask : pubblichemu una nova versione - deve esse lanciata per più teste. U compitu hè assai sèmplice:
- accede quì via ssh è eseguite u cumandimu.
- copià u schedariu quì.
- corregge a cunfigurazione quì.
- principià u serviziu quì
- ...
- Prufittu!
Per a logica descritta, bash hè più cà abbastanza, soprattuttu in i primi fasi di u prugettu, quandu hè ghjustu principiatu. Questu , ma cù u tempu ci sò dumande per implementà qualcosa simili, ma un pocu sfarente. A prima cosa chì vene in mente hè copia-incolla. È avà avemu digià dui scripts assai simili chì facenu quasi a stessa cosa. À u tempu, u nùmeru di script hà crisciutu, è avemu avutu cun u fattu chì ci hè una certa logica cummerciale per implementà una installazione chì deve esse sincronizata trà e diverse script, questu hè abbastanza cumplicatu.
Risulta chì ci hè una tale pratica cum'è D.R.Y. (Ùn ripetite micca). L'idea hè di riutilizà u codice esistente. Sembra simplice, ma ùn avemu micca ghjuntu à questu subitu. In u nostru casu, era una idea banale: per separà i cunfigurazioni da i script. Quelli. logica cummerciale di cumu l'installazione hè implementata separatamente, cunfigurazione separatamente.
S.O.L.I.D. per CFM
À u tempu, u prughjettu hà crisciutu è era l'emergenza di Ansible. U mutivu principale di a so apparizione hè chì ci hè un sapè fà nantu à a squadra è chì bash ùn hè micca pensatu per una logica cumplessa. Ansible hà ancu cuminciatu à cuntene una logica cumplessa. Per impediscenu a logica cumplessa di trasfurmà in u caosu, ci sò principii per urganizà codice in u sviluppu di software SOLIDA Inoltre, per esempiu, Grigory Petrov in u rapportu "Perchè un specialista in l'informatica hà bisognu di una marca persunale" hà suscitatu a quistione chì una persona hè cuncepita in tale manera chì hè più faciule per ellu per operà cù alcune entità suciali, in u sviluppu di software queste sò oggetti. Se unimu sti dui idee è cuntinuemu à sviluppà, avemu nutatu chì pudemu ancu aduprà SOLIDA per fà più faciule di mantene è mudificà sta logica in u futuru.
U Principiu di Responsabilità Unicu
Ogni classe eseguisce solu un compitu.
Ùn ci hè bisognu di mischjà codice è fà mostri spaghetti divini monolitici. L'infrastruttura deve esse composta da brique simplici. Risulta chì, se dividite u Ansible playbook in pezzi chjuchi, leghje roli Ansible, allora sò più faciuli di mantene.
U principiu Open Closed
Principiu apertu / chjusu.
- Apertu à l'estensione: significa chì u cumpurtamentu di una entità pò esse allargata creendu novi tipi di entità.
- Chiusu per cambià: In u risultatu di l'estensione di u cumpurtamentu di una entità, ùn deve esse micca cambiatu à u codice chì usa queste entità.
Inizialmente, avemu implementatu l'infrastruttura di prova nantu à e macchine virtuali, ma per via di u fattu chì a logica cummerciale di implementazione era separata da l'implementazione, avemu aghjustatu rolling out à baremetall senza prublemi.
U principiu di sustituzione di Liskov
Principiu di sustituzzioni di Barbara Liskov. l'uggetti in un prugramma deve esse rimpiazzabili cù istanze di i so sottotipi senza cambià l'esekzione curretta di u prugramma
S'è vo circate più largamente, ùn hè micca una funzione di ogni prughjettu particulare chì pò esse appiicata quì SOLIDA, Si tratta in generale di CFM, per esempiu, nantu à un altru prughjettu hè necessariu di implementà una applicazione Java boxed in cima à diversi Java, servitori di applicazioni, basa di dati, OS, etc. Utilizendu questu esempiu, cunsideraghju più principii SOLIDA
In u nostru casu, ci hè un accordu in u squadra di l'infrastruttura chì se avemu installatu u rolu imbjava o oraclejava, allora avemu un eseguibile binariu java. Questu hè necessariu perchè I roli upstream dipendenu da stu cumpurtamentu; aspettanu java. À u listessu tempu, questu ci permette di rimpiazzà una implementazione / versione java cù una altra senza cambià a logica di implementazione di l'applicazione.
U prublema quì si trova in u fattu chì hè impussibile di implementà questu in Ansible, per via di quale alcuni accordi appariscenu in a squadra.
U principiu di segregazione di l'interfaccia
Principiu di separazione di l'interfaccia: "Parechje interfacce specifiche di u cliente sò megliu cà una interfaccia generale.
Inizialmente, avemu pruvatu à mette tutta a variabilità di implementazione di l'applicazioni in un Ansible playbook, ma era difficiule di sustene, è l'approcciu quandu avemu una interfaccia esterna specifica (u cliente aspetta u portu 443), allora una infrastruttura pò esse assemblata da individuu. mattoni per una implementazione specifica.
U principiu di l'inversione di a dependenza
U principiu di l'inversione di dependenza. I moduli à i livelli più alti ùn deve micca dipende di i moduli à i livelli più bassi. I dui tipi di moduli devenu dipende da astrazioni. L'astrazzioni ùn deve micca dipende di i dettagli. I dettagli devenu dipende da l'astrazioni.
Quì l'esempiu serà basatu annantu à un antipattern.
- Unu di i clienti avia un nuvulu privatu.
- Avemu urdinatu macchine virtuali in u nuvulu.
- Ma per via di a natura di u nuvulu, l'implementazione di l'applicazioni hè stata ligata à quale ipervisore era VM.
Quelli. A logica di implementazione di l'applicazioni d'altu livellu scorriva cù dipendenze à i livelli più bassi di l'ipervisore, è questu significava prublemi quandu si riutilizava sta logica. Ùn fate micca cusì.
Interaction
L'infrastruttura cum'è codice ùn hè micca solu nantu à u codice, ma ancu nantu à a relazione trà u codice è e persone, nantu à l'interazzione trà i sviluppatori di l'infrastruttura.
Fattore di autobus
Assumimu chì avete Vasya nantu à u vostru prughjettu. Vasya sapi tuttu di a vostra infrastruttura, chì succede se Vasya sparisce subitu? Questa hè una situazione assai reale, perchè puderia esse culpitu da un autobus. Calchì volta succede. Se questu succede è a cunniscenza di u codice, a so struttura, cumu si travaglia, l'apparenza è e password ùn hè micca distribuitu trà a squadra, pudete scontru una quantità di situazioni spiacevoli. Per minimizzà questi risichi è distribuisce a cunniscenza in a squadra, pudete aduprà diversi approcci
Coppia Devopsing
Ùn hè micca cum'è , chì l'amministratori beviu a biera, cambiavanu password, è un analogu di prugrammazione di coppia. Quelli. dui ingegneri si mettenu à un computer, un teclatu è cumincianu à stallà a vostra infrastruttura inseme: stabilisce un servitore, scrive un rolu Ansible, etc. Sembra bellu, ma ùn hà micca travagliatu per noi. Ma i casi spiciali di sta pratica hà travagliatu. Un novu impiigatu vene, u so mentore assume un veru compitu inseme cun ellu, travaglia è trasfirì a cunniscenza.
Un altru casu particulari hè una chjamata incidente. Durante un prublema, un gruppu di quelli chì sò in turnu è quelli chì participanu si riuniscenu, un capu hè numinatu, chì sparte u so screnu è voce u trenu di pensamentu. Altri participanti seguitanu i pinsamenti di u capimachja, spia i trucchi da a cunsola, verificate chì ùn anu micca mancatu una linea in u logu, è amparà cose novi nantu à u sistema. Stu approcciu hà travagliatu più spessu chè micca.
Revisione di Codice
Subjettivamenti, era più efficau per sparghje a cunniscenza di l'infrastruttura è cumu si travaglia cù a revisione di codice:
- L'infrastruttura hè descritta da u codice in u repository.
- I cambiamenti sò in un ramu separatu.
- Durante una dumanda di fusione, pudete vede u delta di cambiamenti in l'infrastruttura.
U puntu culminante quì hè chì i critichi sò stati scelti unu per unu, secondu un calendariu, i.e. cù un certu gradu di probabilità vi cullà in un novu pezzu di infrastruttura.
stile di codice
À u tempu, i squabbles cuminciaru à apparisce durante e recensioni, perchè ... i revisori avianu u so propiu stile è a rotazione di i revisori li stack with different styles: 2 spazii o 4, camelCase o snake_case. Ùn era micca pussibule di implementà questu subitu.
- A prima idea era di ricumandà l'usu di linter, dopu tuttu, tutti sò un ingegnere, tutti sò intelligenti. Ma diverse editori, OS, ùn sò micca convenienti
- Questu hà evolutu in un bot chì hà scrittu à slack per ogni prublemu problematicu è hà attaccatu l'output di linter. Ma in a maiò parte di i casi, ci era cose più impurtanti per fà è u codice restava micca solu.
Green Build Master
U tempu passa, è avemu ghjuntu à a cunclusione chì l'impegni chì ùn passanu micca certi testi ùn ponu esse permessi in u maestru. Voila! Avemu inventatu Green Build Master, chì hè statu praticatu in u sviluppu di software per un bellu pezzu:
- U sviluppu hè in corso in una filiera separata.
- I testi sò in corso nantu à questu filu.
- Sì i testi fallenu, u codice ùn farà micca in u maestru.
Piglià sta decisione hè stata assai dolorosa, perchè ... hà causatu assai polemiche, ma ne valeva a pena, perchè... Reviews accuminciaru a riceve richieste di fusioni senza diffirenzii in u stilu, è cù u tempu u numeru di zoni prublemi cuminciaru a diminuì.
Test IaC
In più di u cuntrollu di stile, pudete aduprà altre cose, per esempiu, per verificà chì a vostra infrastruttura pò esse implementata. O verificate chì i cambiamenti in l'infrastruttura ùn portanu micca à a perdita di soldi. Perchè questu puderia esse necessariu? A quistione hè cumplessa è filusòfica, hè megliu per risponde cù una storia chì in qualchì modu ci era un auto-scaler in Powershell chì ùn hà micca verificatu e cundizioni di cunfini => più VMs sò stati creati di ciò chì necessariu => u cliente hà spesu più soldi di ciò chì hà previstu. Questu ùn hè micca assai piacevule, ma saria abbastanza pussibule di catturà stu errore in tappe prima.
Puderia dumandà, perchè rende l'infrastruttura cumplessa ancu più cumplessa? I testi per l'infrastruttura, cum'è per u codice, ùn sò micca di simplificazione, ma di sapè cumu si deve travaglià a vostra infrastruttura.
IaC Testing Piramide
Test IaC: Analisi statica
Se implementate tutta l'infrastruttura in una volta è verificate chì funziona, pudete truvà chì ci vole assai tempu è richiede assai tempu. Dunque, a basa deve esse qualcosa chì travaglia rapidamente, ci hè assai, è copre assai lochi primitivi.
Bash hè difficiule
Fighjemu un esempiu triviale. selezziunà tutti i fugliali in u cartulare attuale è copià in un altru locu. A prima cosa chì vene in mente:
for i in * ; do
cp $i /some/path/$i.bak
doneE se ci hè un spaziu in u nome di u schedariu? Ebbè, ok, simu intelligenti, sapemu cumu utilizà virgulette:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneBè fatta? Innò! Chì s'ellu ùn ci hè nunda in u cartulare, i.e. globbing ùn funziona micca.
find . -type f -exec mv -v {} dst/{}.bak ;Ben fattu avà ? No... Scurdate ciò chì pò esse in u nome di u schedariu n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirStrumenti di analisi statica
U prublema da u passu precedente puderia esse chjappu quandu avemu scurdatu di i quotes, per questu ci sò assai rimedii in natura , in generale ci sò assai di elli, è assai prubabile pudete truvà un linter per a vostra pila sottu u vostru IDE.
lingua
Tool
bash
Ruby
pitone
ansible
Test IaC: Test di unità
Cumu avemu vistu da l'esempiu precedente, linters ùn sò micca omnipotenti è ùn ponu micca indicà tutte e zone problematiche. Inoltre, per analogia cù e teste in u sviluppu di software, pudemu ricurdà e teste di unità. Ciò chì vene subitu in mente hè , , , . Ma chì fà cù ansible, chef, saltstack è altri cum'è elli?
À u principiu, avemu parlatu SOLIDA è chì a nostra infrastruttura deve esse custituita di mattoni chjuchi. U so tempu hè ghjuntu.
- L'infrastruttura hè divisa in picculi mattoni, per esempiu, roli Ansible.
- Qualchese tipu d'ambiente hè implementatu, sia docker o VM.
- Applicamu u nostru rolu Ansible à questu ambiente di prova.
- Avemu verificatu chì tuttu hà travagliatu cum'è l'aspittavamu (eseguimu testi).
- Decidiamu bè o micca bè.
IaC Testing: Strumenti di test di unità
Quistione, chì sò e teste per CFM? Pudete simpricimenti eseguisce u script, o pudete aduprà suluzioni pronti per questu:
CFM
Tool
Ansible
testa
testa
saline
Esempiu per testinfra, cuntrollà chì l'utilizatori test1, test2 esistenu è sò in un gruppu sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsCosa à sceglie? A quistione hè cumplessa è ambigua, quì hè un esempiu di cambiamenti in i prughjetti in github per 2018-2019:
Quadri di teste IaC
A quistione hè: cumu si mette tuttu inseme è lancià? Can s'ellu ci hè un numeru abbastanza di ingegneri. O pudete piglià suluzioni pronti, ancu s'ellu ùn ci sò assai assai:
CFM
Tool
Ansible
testa
Terraform
Esempiu di cambiamenti in i prughjetti nantu à github per 2018-2019:
Molécule vs. A cucina di prova
In principiu noi :
- Crea una VM in parallelu.
- Applica roli Ansible.
- Eseguite l'ispezione.
Per i roli 25-35 hà travagliatu 40-70 minuti, chì era longu.
U passu prossimu era a transizione à jenkins/docker/ansible/molecule. Idiologicamente tuttu hè listessu
- Lint playbooks.
- Allineate i roli.
- Lanciari u containeru
- Applica roli Ansible.
- Run testinfra.
- Verificate l'idempotenza.
Linting per 40 roli è testi per una decina hà cuminciatu à piglià circa 15 minuti.
Chì sceglite dipende di parechji fatturi, cum'è a pila utilizata, sapè fà in a squadra, etc. quì ognunu decide per sè stessu cumu chjude a quistione di a prova di unità
Test IaC: Test di Integrazione
U prossimu passu in a piramide di teste di l'infrastruttura serà testi di integrazione. Sò simili à e teste di unità:
- L'infrastruttura hè divisa in picculi mattoni, per esempiu roli Ansible.
- Qualchese tipu d'ambiente hè implementatu, sia docker o VM.
- Per questu ambiente di prova applica parechje Ruoli Ansible.
- Avemu verificatu chì tuttu hà travagliatu cum'è l'aspittavamu (eseguimu testi).
- Decidiamu bè o micca bè.
À pocu pressu, ùn cuntrollemu micca a prestazione di un elementu individuale di u sistema cum'è in teste di unità, cuntrollemu cumu u servitore hè cunfiguratu in tuttu.
Test IaC: Testi di punta à punta
À a cima di a piramide simu salutati da e teste End to End. Quelli. Ùn avemu micca verificatu u rendiment di un servitore separatu, un script separatu, o un mattone separatu di a nostra infrastruttura. Avemu verificatu chì parechji servitori cunnessi inseme, a nostra infrastruttura funziona cum'è l'aspettemu. Sfurtunatamente, ùn aghju mai vistu suluzioni scatuli pronti, probabilmente perchè... L'infrastruttura hè spessu unica è difficiuli di mudellu è di creà un quadru per a prova. In u risultatu, ognunu crea e so solu suluzione. Ci hè una dumanda, ma ùn ci hè risposta. Dunque, vi dicu ciò chì ci hè per spinghje l'altri à sonà pinsamenti o strofinate u mo nasu in u fattu chì tuttu hè statu inventatu assai fà prima di noi.
Un prughjettu cù una storia ricca. Hè utilizatu in grande urganisazione è probabilmente ognunu di voi hà indirettu attraversatu i camini cun ellu. L'applicazione supporta parechje basa di dati, integrazioni, etc. Sapendu ciò chì l'infrastruttura pò esse cum'è hè assai di docker-compose files, è sapendu chì teste per eseguisce in quale ambiente hè Jenkins.
Stu schema hà travagliatu per un bellu pezzu, finu à in u quadru ùn avemu micca pruvatu à trasfiriri questu à Openshift. I cuntenituri restanu listessi, ma l'ambiente di lanciamentu hè cambiatu (salutu D.R.Y. di novu).
L'idea di ricerca andò più in là, è in openshift anu truvatu una cosa cum'è APB (Ansible Playbook Bundle), chì vi permette di imballà a cunniscenza di cumu implementà l'infrastruttura in un containeru. Quelli. ci hè un puntu di cunniscenza ripetibile è verificabile nantu à cumu implementà l'infrastruttura.
Tuttu chistu sonava bè finu à chì avemu intruduciutu in una infrastruttura eterogenea: avemu bisognu di Windows per teste. In u risultatu, a cunniscenza di ciò chì, induve, cumu implementà è teste hè in jenkins.
cunchiusioni
Infrastruttura cum'è Code hè
- Codice in u repository.
- Interazione umana.
- Test di l'infrastruttura.
ligami
- Corsa secca 2019-04-24
- &
Source: www.habr.com