Aliro IaC (Infrastrukturo kiel Kodo) konsistas ne nur el la kodo kiu estas stokita en la deponejo, sed ankaŭ el la homoj kaj procezoj kiuj ĉirkaŭas ĉi tiun kodon. Ĉu eblas reuzi alirojn de programaro ĝis infrastruktura administrado kaj priskribo? Estus bona ideo konservi ĉi tiun ideon en menso dum vi legas la artikolon.
Ĉi tio estas transskribo de mia sur .
Diapozitivoj kaj filmetoj
- Seka kurado 2019-04-24
Infrastrukturo kiel bash-historio
Supozu, ke vi venas al nova projekto, kaj ili diras al vi: “ni havas Infrastrukturo kiel Kodo". En realeco ĝi rezultas Infrastrukturo kiel bash-historio aŭ ekzemple Dokumentado kiel bash-historio. Ĉi tio estas tre reala situacio, ekzemple, similan kazon priskribis Denis Lysenko en parolado , li rakontis kiel ili akiris koheran infrastrukturon por la projekto de bash-historio.
Kun iom da deziro, ni povas diri tion Infrastrukturo kiel bash-historio ĉi tio estas kiel kodo:
- reproduktebleco: Vi povas preni bash-historion, ruli la komandojn de tie, kaj vi eble, cetere, ricevos funkciantan agordon kiel eligo.
- versionado: vi scias, kiu eniris kaj kion ili faris, denove, ne estas fakto, ke ĉi tio kondukos vin al funkcia agordo ĉe la eliro.
- historio: la rakonto pri kiu faris kion. nur vi ne povos uzi ĝin se vi perdos la servilon.
Kion mi faru?
Infrastrukturo kiel Kodo
Eĉ tia stranga kazo kiel Infrastrukturo kiel bash-historio vi povas tiri ĝin je la oreloj Infrastrukturo kiel Kodo, sed kiam ni volas fari ion pli komplikan ol la bona malnova LAMP-servilo, ni venos al la konkludo, ke ĉi tiu kodo devas esti iel modifita, ŝanĝita, plibonigita. Poste ni ŝatus konsideri la paralelojn inter Infrastrukturo kiel Kodo kaj evoluigo de programaro.
SEKA
En stoka sistemo evoluiga projekto, estis subtasko : ni publikigas novan eldonon - ĝi devas esti lanĉita por plua testado. La tasko estas ege simpla:
- ensalutu ĉi tie per ssh kaj plenumu la komandon.
- kopiu la dosieron tie.
- korektu la agordon ĉi tie.
- komenci la servon tie
- ...
- PROFITO!
Por la priskribita logiko, bash estas pli ol sufiĉa, precipe en la fruaj stadioj de la projekto, kiam ĝi ĵus komenciĝas. Ĉi tio , sed kun la tempo estas petoj por deploji ion similan, sed iomete malsaman. La unua afero, kiu venas al la menso, estas kopii-alglui. Kaj nun ni jam havas du tre similajn skriptojn, kiuj faras preskaŭ la samon. Kun la tempo, la nombro da skriptoj kreskis, kaj ni alfrontis la fakton, ke ekzistas certa komerca logiko por disfaldi instaladon, kiu devas esti sinkronigita inter malsamaj skriptoj, ĉi tio estas sufiĉe komplika.
Montriĝas, ke ekzistas tia praktiko kiel DRY (Ne Ripetu Vin). La ideo estas reuzi ekzistantan kodon. Ĝi sonas simple, sed ni ne tuj venis al ĉi tio. En nia kazo, ĝi estis banala ideo: apartigi agordojn de skriptoj. Tiuj. komerca logiko de kiel la instalado estas deplojita aparte, agordoj aparte.
SOLIDA por CFM
Kun la tempo la projekto kreskis kaj estis la apero de Ansible. La ĉefa kialo de ĝia aspekto estas ke ekzistas kompetenteco en la teamo kaj tiu bato ne estas desegnita por kompleksa logiko. Ansible ankaŭ komencis enhavi kompleksan logikon. Por malhelpi kompleksan logiko iĝi kaoso, ekzistas principoj por organizi kodon en programaro SOLIDA Ankaŭ, ekzemple, Grigory Petrov en la raporto "Kial IT-specialisto bezonas personan markon" levis la demandon, ke persono estas desegnita tiel, ke estas pli facile por li funkcii kun iuj sociaj entoj, en programaro ĉi tiuj estas objektoj. Se ni kombinas ĉi tiujn du ideojn kaj daŭre disvolvas ilin, ni rimarkos, ke ni ankaŭ povas uzi SOLIDA por faciligi konservi kaj modifi ĉi tiun logikon en la estonteco.
La Unua Responsableca Principo
Ĉiu klaso plenumas nur unu taskon.
Ne necesas miksi kodon kaj fari monolitajn diajn spagetajn monstrojn. La infrastrukturo devus konsisti el simplaj brikoj. Montriĝas, ke se vi dividas la Ansible-ludlibron en malgrandajn pecojn, legu Ansible-rolojn, tiam ili estas pli facile konserveblaj.
La Malferma Fermita Principo
Malferma/fermita principo.
- Malfermita al etendo: signifas ke la konduto de unuo povas esti etendita kreante novajn entotipojn.
- Fermita por ŝanĝi: Kiel rezulto de etendado de la konduto de unuo, neniuj ŝanĝoj devus esti faritaj al la kodo kiu uzas tiujn unuojn.
Komence, ni deplojis la testan infrastrukturon sur virtualaj maŝinoj, sed pro la fakto, ke la komerca logiko de deplojo estis aparta de la efektivigo, ni aldonis ruliĝon al baremetall senprobleme.
La Liskov-Anstataŭiga Principo
La anstataŭiga principo de Barbara Liskov. objektoj en programo devas esti anstataŭigeblaj kun okazoj de siaj subtipoj sen ŝanĝi la ĝustan ekzekuton de la programo
Se vi rigardas ĝin pli larĝe, ĝi ne estas trajto de iu aparta projekto, kiu povas esti aplikata tie SOLIDA, temas ĝenerale pri CFM, ekzemple, en alia projekto necesas disfaldi skatolan Java-aplikaĵon aldone al diversaj Java, aplikaĵserviloj, datumbazoj, OS, ktp. Uzante ĉi tiun ekzemplon, mi konsideros pliajn principojn SOLIDA
En nia kazo, ekzistas interkonsento ene de la infrastruktura teamo, ke se ni instalis la imbjava aŭ oraclejava rolon, tiam ni havas java binaran ruleblan. Ĉi tio estas necesa ĉar Kontraŭfluaj roloj dependas de ĉi tiu konduto; ili atendas javon. Samtempe, ĉi tio ebligas al ni anstataŭigi unu java efektivigon/version kun alia sen ŝanĝi la aplikaĵan deplojigan logikon.
La problemo ĉi tie kuŝas en tio, ke estas neeble efektivigi ĉi tion en Ansible, sekve de kio aperas iuj interkonsentoj ene de la teamo.
La Interfaca Apartigo-Principo
Interfaco-apartiga principo: "Multaj klient-specifaj interfacoj estas pli bonaj ol unu ĝeneraluzebla interfaco.
Komence, ni provis meti la tutan ŝanĝeblecon de aplikaĵa deplojo en unu Ansible-ludlibron, sed ĝi estis malfacile subteni, kaj la aliron kiam ni havas eksteran interfacon specifita (la kliento atendas havenon 443), tiam infrastrukturo povas esti kunvenita de individua. brikoj por specifa efektivigo.
La Dependa Inversio-Principo
La principo de dependeca inversio. Moduloj ĉe pli altaj niveloj ne devus dependi de moduloj ĉe pli malaltaj niveloj. Ambaŭ specoj de moduloj devas dependi de abstraktaĵoj. Abstraktaĵoj ne devus dependi de detaloj. Detaloj devas dependi de abstraktaĵoj.
Ĉi tie la ekzemplo estos bazita sur kontraŭŝablono.
- Unu el la klientoj havis privatan nubon.
- Ni mendis virtualajn maŝinojn ene de la nubo.
- Sed pro la naturo de la nubo, aplikaĵo deplojo estis ligita al kiu hiperviziero la VM estis ŝaltita.
Tiuj. Altnivela aplikaĵa deplojlogiko fluis kun dependecoj al pli malaltaj niveloj de la hiperviziero, kaj tio signifis problemojn dum reuzado de ĉi tiu logiko. Ne faru ĝin tiel.
interagado
Infrastrukturo kiel kodo temas ne nur pri kodo, sed ankaŭ pri la rilato inter kodo kaj homoj, pri interagoj inter infrastrukturaj programistoj.
Busfaktoro
Ni supozu, ke vi havas Vasya en via projekto. Vasja scias ĉion pri via infrastrukturo, kio okazos se Vasja subite malaperos? Ĉi tio estas tre reala situacio, ĉar li povus esti trafita de buso. Kelkfoje okazas. Se tio okazas kaj scio pri la kodo, ĝia strukturo, kiel ĝi funkcias, aspektoj kaj pasvortoj ne estas distribuitaj inter la teamo, tiam vi eble renkontos kelkajn malagrablajn situaciojn. Por minimumigi ĉi tiujn riskojn kaj distribui scion ene de la teamo, vi povas uzi diversajn alirojn
Paro Devopsing
Ne estas kiel , ke la administrantoj trinkis bieron, ŝanĝis pasvortojn, kaj analogon de parprogramado. Tiuj. du inĝenieroj sidiĝas ĉe unu komputilo, unu klavaro kaj komencas agordi vian infrastrukturon kune: starigi servilon, verki Ansible-rolon ktp. Ĝi sonas bele, sed ĝi ne funkciis por ni. Sed specialaj kazoj de ĉi tiu praktiko funkciis. Venas nova dungito, lia mentoro kunprenas realan taskon kune kun li, laboras kaj transdonas scion.
Alia speciala kazo estas okazaĵvoko. Dum problemo, grupo de deĵorantoj kaj tiuj implikitaj kolektas, unu gvidanto estas nomumita, kiu dividas sian ekranon kaj esprimas la penson. Aliaj partoprenantoj sekvas la pensojn de la gvidanto, spionas lertaĵojn de la konzolo, kontrolas, ke ili ne maltrafis linion en la protokolo kaj lernas novajn aferojn pri la sistemo. Ĉi tiu aliro funkciis pli ofte ol ne.
Kodo-Revizio
Subjektive, estis pli efika disvastigi scion pri la infrastrukturo kaj kiel ĝi funkcias uzante kodan revizion:
- La infrastrukturo estas priskribita per kodo en la deponejo.
- Ŝanĝoj okazas en aparta branĉo.
- Dum kunfanda peto, vi povas vidi la delton de ŝanĝoj en la infrastrukturo.
La kulminaĵo ĉi tie estis, ke la recenzistoj estis elektitaj unu post la alia, laŭ horaro, t.e. kun certa grado de probableco vi grimpos en novan pecon de infrastrukturo.
kodstilo
Kun la tempo, kvereloj komencis aperi dum recenzoj, ĉar... recenzistoj havis sian propran stilon kaj la rotacio de recenzistoj stakigis ilin per malsamaj stiloj: 2 spacoj aŭ 4, camelCase aŭ snake_case. Ne eblis efektivigi ĉi tion tuj.
- La unua ideo estis rekomendi uzi linter, ja ĉiuj estas inĝenieroj, ĉiuj estas inteligentaj. Sed malsamaj redaktiloj, OS, ne estas oportunaj
- Ĉi tio evoluis al bot, kiu skribis al malstreĉo por ĉiu problema komito kaj alfiksis la linter-produktaĵon. Sed plejofte estis pli gravaj aferoj por fari kaj la kodo restis nefiksita.
Verda Konstruo Majstro
La tempo pasas, kaj ni venis al la konkludo, ke komitoj kiuj ne trapasas iujn testojn ne povas esti permesitaj en la majstron. Voila! Ni inventis Green Build Master, kiu estas praktikata en programaro dum longa tempo:
- Evoluo estas en aparta branĉo.
- Testoj funkcias en ĉi tiu fadeno.
- Se la testoj malsukcesos, la kodo ne enigos ĝin en la majstron.
Fari ĉi tiun decidon estis tre dolora, ĉar... kaŭzis multe da diskutado, sed valoris, ĉar... Recenzoj komencis ricevi petojn por fuzioj sen diferencoj en stilo, kaj kun la tempo la nombro da problemaj areoj komencis malpliiĝi.
IaC Testado
Krom stilkontrolado, vi povas uzi aliajn aferojn, ekzemple, por kontroli, ke via infrastrukturo efektive povas disfaldi. Aŭ kontrolu, ke ŝanĝoj en infrastrukturo ne kondukos al perdo de mono. Kial ĉi tio povus esti bezonata? La demando estas kompleksa kaj filozofia, estas pli bone respondi per rakonto, ke iel estis aŭtomata skalo ĉe Powershell, kiu ne kontrolis la limkondiĉojn => pli da VM-oj estis kreitaj ol necese => la kliento elspezis pli da mono ol planite. Ĉi tio ne estas tre agrabla, sed estus tute eble kapti ĉi tiun eraron en pli fruaj stadioj.
Oni povus demandi, kial fari kompleksan infrastrukturon eĉ pli kompleksa? Testoj por infrastrukturo, same kiel por kodo, ne temas pri simpligo, sed pri scii kiel via infrastrukturo devus funkcii.
IaC Testa Piramido
IaC Testing: Statika Analizo
Se vi deplojas la tutan infrastrukturon samtempe kaj kontrolas, ke ĝi funkcias, vi eble trovos, ke ĝi bezonas multan tempon kaj postulas multan tempon. Tial, la bazo devas esti io kiu funkcias rapide, estas multe da ĝi, kaj ĝi kovras multajn primitivajn lokojn.
Bash estas malfacila
Ni rigardu bagatela ekzemplo. elektu ĉiujn dosierojn en la nuna dosierujo kaj kopiu al alia loko. La unua afero, kiu venas al la menso:
for i in * ; do
cp $i /some/path/$i.bak
doneKio se estas spaco en la dosiernomo? Nu, bone, ni estas saĝaj, ni scias kiel uzi citaĵojn:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneBone farita? Ne! Kio se estas nenio en la dosierujo, t.e. globbado ne funkcios.
find . -type f -exec mv -v {} dst/{}.bak ;Bone farita nun? Ne... Forgesis kio povas esti en la dosiernomo n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirStatikaj analiziloj
La problemo de la antaŭa paŝo povus esti kaptita kiam ni forgesis la citaĵojn, por ĉi tio ekzistas multaj rimedoj en la naturo , ĝenerale estas multaj el ili, kaj plej verŝajne vi povas trovi linter por via stako sub via IDE.
lingvo
ilo
bash
Rubeno
python
ansible
IaC Testing: Unuaj Testoj
Kiel ni vidis de la antaŭa ekzemplo, linters ne estas ĉiopovaj kaj ne povas montri ĉiujn problemajn areojn. Plue, per analogio kun testado en programaro, ni povas rememori unutestojn. Kio tuj venas al la menso estas , , , . Sed kion fari kun ansible, chef, saltstack kaj aliaj similaj al ili?
Je la komenco ni parolis SOLIDA kaj ke nia infrastrukturo konsistu el malgrandaj brikoj. Ilia tempo venis.
- La infrastrukturo estas dividita en malgrandajn brikojn, ekzemple, Ansible roloj.
- Ia medio estas deplojita, ĉu ĝi docker aŭ VM.
- Ni aplikas nian Ansible-rolon al ĉi tiu prova medio.
- Ni kontrolas, ke ĉio funkciis kiel ni atendis (ni faras testojn).
- Ni decidas bone aŭ ne bone.
IaC Testing: Unuecaj Testaj iloj
Demando, kio estas testoj por CFM? Vi povas simple ruli la skripton, aŭ vi povas uzi pretajn solvojn por ĉi tio:
cfm
ilo
Respondema
kapon
kapon
salstako
Ekzemplo por testinfra, kontrolante ke uzantoj test1, test2 ekzistas kaj estas en grupo sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsKion elekti? La demando estas kompleksa kaj ambigua, jen ekzemplo de ŝanĝoj en projektoj sur github por 2018-2019:
Kadroj de Testado de IaC
Estiĝas la demando: kiel kunmeti ĉion kaj lanĉi ĝin? Povas se estas sufiĉa nombro da inĝenieroj. Aŭ vi povas preni pretajn solvojn, kvankam ili ne estas tre multaj:
cfm
ilo
Respondema
kapon
Terraform
Ekzemplo de ŝanĝoj en projektoj sur github por 2018-2019:
Molekulo vs. Testkuirejo
Komence ni :
- Kreu VM paralele.
- Apliki Ansible-rolojn.
- Kuru inspektadon.
Por 25-35 roloj ĝi funkciis 40-70 minutojn, kio estis longa.
La sekva paŝo estis la transiro al jenkins/docker/ansible/molecule. Idiologie ĉio estas la sama
- Lint-ludlibroj.
- Vicigu la rolojn.
- Lanĉi ujon
- Apliki Ansible-rolojn.
- Rulu testinfra.
- Kontrolu idempotencon.
Linting por 40 roloj kaj testoj por dekduo komencis daŭri ĉirkaŭ 15 minutojn.
Kion elekti dependas de multaj faktoroj, kiel la stako uzata, kompetenteco en la teamo, ktp. ĉi tie ĉiuj mem decidas kiel fermi la Unutestan demandon
IaC Testing: Integrigaj Testoj
La sekva paŝo en la infrastruktura testa piramido estos integrigaj testoj. Ili similas al unuotestoj:
- La infrastrukturo estas dividita en malgrandajn brikojn, ekzemple Ansible-rolojn.
- Ia medio estas deplojita, ĉu ĝi docker aŭ VM.
- Por ĉi tiu prova medio apliki amaso da Ansible roloj.
- Ni kontrolas, ke ĉio funkciis kiel ni atendis (ni faras testojn).
- Ni decidas bone aŭ ne bone.
Malglate parolante, ni ne kontrolas la agadon de individua elemento de la sistemo kiel en unuotestoj, ni kontrolas kiel la servilo estas agordita entute.
IaC-Testado: Finaj Al Finaj Testoj
Ĉe la supro de la piramido ni estas salutitaj de Finaj ĝis Finaj provoj. Tiuj. Ni ne kontrolas la agadon de aparta servilo, aparta skripto aŭ aparta briko de nia infrastrukturo. Ni kontrolas, ke multaj serviloj konektitaj kune, nia infrastrukturo funkcias kiel ni atendas ĝin. Bedaŭrinde, mi neniam vidis pretajn skatolitajn solvojn, verŝajne ĉar... La infrastrukturo ofte estas unika kaj malfacile ŝablonebla kaj krei kadron por testado. Kiel rezulto, ĉiu kreas siajn proprajn solvojn. Estas postulo, sed ne ekzistas respondo. Tial mi diros al vi, kio estas por puŝi aliajn sonigi pensojn aŭ froti mian nazon en la fakto, ke ĉio estis elpensita antaŭ longe antaŭ ni.
Projekto kun riĉa historio. Ĝi estas uzata en grandaj organizaĵoj kaj verŝajne ĉiu el vi nerekte kruciĝis kun ĝi. La aplikaĵo subtenas multajn datumbazojn, integriĝojn, ktp. Scii kiel la infrastrukturo povus aspekti estas multaj docker-komponaj dosieroj, kaj scii kiuj testoj ruli en kiu medio estas Jenkins.
Ĉi tiu skemo funkciis dum sufiĉe longa tempo, ĝis en la kadro ni ne provis transdoni ĉi tion al Openshift. La ujoj restas la samaj, sed la lanĉmedio ŝanĝiĝis (saluton DRY denove).
La esplora ideo iris plu, kaj en malferma deĵoro ili trovis tian aferon kiel APB (Ansible Playbook Bundle), kiu permesas vin paki scion pri kiel disfaldi infrastrukturon en ujon. Tiuj. ekzistas ripetebla, testebla punkto de scio pri kiel deploji la infrastrukturon.
Ĉio ĉi sonis bone ĝis ni renkontis heterogenan infrastrukturon: ni bezonis Vindozon por provoj. Kiel rezulto, la scio pri kio, kie, kiel deploji kaj testi estas en jenkins.
konkludo
Infrastrukturo kiel Kodo estas
- Kodo en la deponejo.
- Homa interago.
- Infrastruktura testado.
ligoj
- Seka kurado 2019-04-24
- &
fonto: www.habr.com