'N Benadering IaC (Infrastruktuur as Kode) bestaan nie net uit die kode wat in die bewaarplek gestoor word nie, maar ook uit die mense en prosesse wat hierdie kode omring. Is dit moontlik om benaderings van sagteware-ontwikkeling tot infrastruktuurbestuur en beskrywing te hergebruik? Dit sal 'n goeie idee wees om hierdie idee in gedagte te hou terwyl jy die artikel lees.
Dit is 'n transkripsie van my op .
Skyfies en video's
- Droëloop 2019-04-24
Infrastruktuur as bash geskiedenis
Gestel jy kom by 'n nuwe projek, en hulle sê vir jou: "ons het Infrastruktuur as kode". In werklikheid blyk dit Infrastruktuur as bash geskiedenis of byvoorbeeld Dokumentasie as bash geskiedenis. Dit is 'n baie werklike situasie, byvoorbeeld, 'n soortgelyke geval is deur Denis Lysenko in 'n toespraak beskryf , het hy vertel hoe hulle 'n samehangende infrastruktuur vir die projek uit die bash-geskiedenis gekry het.
Met 'n mate van begeerte kan ons dit sê Infrastruktuur as bash geskiedenis dit is soos kode:
- reproduceerbaarheid: Jy kan bash-geskiedenis neem, die opdragte van daar af uitvoer, en jy kan terloops 'n werkende konfigurasie as 'n uitvoer kry.
- weergawe: jy weet wie ingekom het en wat hulle gedoen het, weereens, dit is nie 'n feit dat dit jou na 'n werkende konfigurasie by die uitgang sal lei nie.
- история: die storie van wie wat gedoen het. net jy sal dit nie kan gebruik as jy die bediener verloor nie.
Wat om te doen?
Infrastruktuur as kode
Selfs so 'n vreemde geval soos Infrastruktuur as bash geskiedenis jy kan dit aan die ore trek Infrastruktuur as kode, maar wanneer ons iets meer ingewikkeld wil doen as die goeie ou LAMP-bediener, sal ons tot die gevolgtrekking kom dat hierdie kode op een of ander manier gewysig, verander, verbeter moet word. Vervolgens wil ons kyk na die parallelle tussen Infrastruktuur as kode en sagteware-ontwikkeling.
DROOG
Op 'n stoorstelselontwikkelingsprojek was daar 'n subtaak : ons stel 'n nuwe vrystelling vry - dit moet uitgerol word vir verdere toetsing. Die taak is uiters eenvoudig:
- meld hier aan via ssh en voer die opdrag uit.
- kopieer die lêer daarheen.
- korrigeer die konfigurasie hier.
- begin die diens daar
- ...
- WINS!
Vir die beskryfde logika is bash meer as genoeg, veral in die vroeë stadiums van die projek, wanneer dit net begin. Hierdie , maar met verloop van tyd is daar versoeke om iets soortgelyks te ontplooi, maar effens anders. Die eerste ding wat by jou opkom is copy-paste. En nou het ons reeds twee baie soortgelyke skrifte wat amper dieselfde doen. Met verloop van tyd het die aantal skrifte gegroei, en ons het gekonfronteer met die feit dat daar 'n sekere besigheidslogika is vir die implementering van 'n installasie wat gesinchroniseer moet word tussen verskillende skrifte, dit is nogal ingewikkeld.
Dit blyk dat daar so 'n praktyk is soos DRY (Moenie jouself herhaal nie). Die idee is om bestaande kode te hergebruik. Dit klink eenvoudig, maar ons het nie dadelik hiertoe gekom nie. In ons geval was dit 'n banale idee: om konfigurasies van skrifte te skei. Dié. besigheidslogika van hoe die installasie afsonderlik ontplooi word, konfigureer afsonderlik.
SOLID vir CFM
Met verloop van tyd het die projek gegroei en was die opkoms van Ansible. Die hoofrede vir sy voorkoms is dat daar kundigheid in die span is en dat bash nie vir komplekse logika ontwerp is nie. Ansible het ook komplekse logika begin bevat. Om te verhoed dat komplekse logika in chaos verander, is daar beginsels van kode-organisasie in sagteware-ontwikkeling SOLIED Ook, byvoorbeeld, Grigory Petrov in die verslag "Waarom het 'n IT-spesialis 'n persoonlike handelsmerk nodig" het die vraag geopper dat 'n persoon so ontwerp is dat dit vir hom makliker is om met sekere sosiale entiteite te werk, in sagteware-ontwikkeling voorwerpe is. As ons hierdie twee idees kombineer en voortgaan om dit te ontwikkel, sal ons agterkom dat ons ook kan gebruik SOLIED om dit makliker te maak om hierdie logika in die toekoms te handhaaf en te wysig.
Die Enkel Verantwoordelikheidsbeginsel
Elke klas voer slegs een taak uit.
Nie nodig om kode te meng en monolitiese goddelike spaghetti-monsters te maak nie. Die infrastruktuur moet uit eenvoudige stene bestaan. Dit blyk dat as jy die Ansible-speelboek in klein stukkies verdeel, Ansible-rolle lees, dan is dit makliker om te onderhou.
Die oop geslote beginsel
Oop/geslote beginsel.
- Oop vir uitbreiding: beteken dat die gedrag van 'n entiteit uitgebrei kan word deur nuwe entiteittipes te skep.
- Geslote vir verandering: As gevolg van die uitbreiding van die gedrag van 'n entiteit, moet geen veranderinge aan die kode gemaak word wat daardie entiteite gebruik nie.
Aanvanklik het ons die toetsinfrastruktuur op virtuele masjiene ontplooi, maar as gevolg van die feit dat die besigheidslogika van ontplooiing apart van die implementering was, het ons sonder enige probleme die uitrol na baremetall bygevoeg.
Die Liskov-vervangingsbeginsel
Barbara Liskov se substitusiebeginsel. voorwerpe in 'n program moet vervangbaar wees met gevalle van hul subtipes sonder om die korrekte uitvoering van die program te verander
As jy breër daarna kyk, is dit nie 'n kenmerk van enige spesifieke projek wat daar toegepas kan word nie SOLIED, gaan dit oor die algemeen oor CFM, byvoorbeeld, op 'n ander projek is dit nodig om 'n boks Java-toepassing bo-op verskeie Java, toepassingsbedieners, databasisse, OS, ens. Deur hierdie voorbeeld te gebruik, sal ek verdere beginsels oorweeg SOLIED
In ons geval is daar 'n ooreenkoms binne die infrastruktuurspan dat as ons die imbjava- of oraclejava-rol geïnstalleer het, ons 'n java-binêre uitvoerbare lêer het. Dit is nodig omdat Stroomop rolle is afhanklik van hierdie gedrag hulle verwag java. Terselfdertyd stel dit ons in staat om een Java-implementering/weergawe met 'n ander te vervang sonder om die toepassingsimplementeringslogika te verander.
Die probleem hier lê in die feit dat dit onmoontlik is om dit in Ansible te implementeer, as gevolg waarvan sommige ooreenkomste binne die span verskyn.
Die koppelvlak segregasie-beginsel
Interface-skeidingsbeginsel: “Baie kliëntspesifieke koppelvlakke is beter as een algemene koppelvlak.
Aanvanklik het ons probeer om al die veranderlikheid van toepassing-ontplooiing in een Ansible-speelboek te plaas, maar dit was moeilik om te ondersteun, en die benadering wanneer ons 'n eksterne koppelvlak gespesifiseer het (die kliënt verwag poort 443), dan kan 'n infrastruktuur saamgestel word uit individuele stene vir 'n spesifieke implementering.
Die afhanklikheidsinversiebeginsel
Die beginsel van afhanklikheidsomkering. Modules op hoër vlakke behoort nie afhanklik te wees van modules op laer vlakke nie. Beide tipes modules moet van abstraksies afhang. Abstraksies moet nie van besonderhede afhang nie. Besonderhede moet afhang van abstraksies.
Hier sal die voorbeeld gebaseer wees op 'n antipatroon.
- Een van die kliënte het 'n private wolk gehad.
- Ons het virtuele masjiene binne die wolk bestel.
- Maar as gevolg van die aard van die wolk, was toepassing-ontplooiing gekoppel aan watter hiperviser die VM was.
Dié. Hoëvlak toepassingsontplooiingslogika het met afhanklikhede na laer vlakke van die hipervisor gevloei, en dit het probleme meegebring met die hergebruik van hierdie logika. Moenie dit op hierdie manier doen nie.
interaksie
Infrastruktuur as kode gaan nie net oor kode nie, maar ook oor die verhouding tussen kode en mense, oor interaksies tussen infrastruktuurontwikkelaars.
Bus faktor
Kom ons neem aan dat jy Vasya op jou projek het. Vasya weet alles van jou infrastruktuur, wat sal gebeur as Vasya skielik verdwyn? Dit is 'n baie werklike situasie, want hy kan deur 'n bus getref word. Soms gebeur dit. As dit gebeur en kennis oor die kode, sy struktuur, hoe dit werk, voorkoms en wagwoorde nie onder die span versprei word nie, kan jy 'n aantal onaangename situasies teëkom. Om hierdie risiko's te minimaliseer en kennis binne die span te versprei, kan jy verskeie benaderings gebruik
Paar Devopsing
Dit is nie soos , dat die admins bier gedrink het, wagwoorde verander het en 'n analoog van paarprogrammering. Dié. twee ingenieurs gaan sit by een rekenaar, een sleutelbord en begin saam jou infrastruktuur opstel: 'n bediener opstel, 'n Ansible-rol skryf, ens. Dit klink lekker, maar dit het nie vir ons gewerk nie. Maar spesiale gevalle van hierdie praktyk het gewerk. 'n Nuwe werknemer het gekom, sy mentor neem 'n werklike taak saam met hom aan, werk en dra kennis oor.
Nog 'n spesiale geval is 'n voorvaloproep. Tydens 'n probleem kom 'n groep van die aan diens en die betrokkenes bymekaar, een leier word aangewys, wat sy skerm deel en die gedagtegang uitspreek. Ander deelnemers volg die leier se gedagtes, spioeneer op truuks vanaf die konsole, maak seker dat hulle nie 'n reël in die log gemis het nie, en leer nuwe dinge oor die stelsel. Hierdie benadering het meer dikwels gewerk as nie.
Kodeoorsig
Subjektief was dit meer effektief om kennis oor die infrastruktuur en hoe dit werk te versprei deur gebruik te maak van kodehersiening:
- Die infrastruktuur word beskryf deur kode in die bewaarplek.
- Veranderinge vind plaas in 'n aparte tak.
- Tydens 'n samesmeltingsversoek kan u die delta van veranderinge in die infrastruktuur sien.
Die hoogtepunt hier was dat die resensente een vir een gekies is, volgens 'n skedule, d.w.s. met 'n mate van waarskynlikheid sal jy in 'n nuwe stuk infrastruktuur klim.
kode styl
Met verloop van tyd het stryery tydens resensies begin verskyn, want... beoordelaars het hul eie styl gehad en die rotasie van beoordelaars het hulle met verskillende style gestapel: 2 spasies of 4, camelCase of snake_case. Dit was nie moontlik om dit dadelik te implementeer nie.
- Die eerste idee was om aan te beveel om linter te gebruik, almal is immers 'n ingenieur, almal is slim. Maar verskillende redakteurs, OS, is nie gerieflik nie
- Dit het ontwikkel in 'n bot wat vir elke problematiese commit te slap geskryf het en die linter-uitvoer aangeheg het. Maar in die meeste gevalle was daar belangriker dinge om te doen en die kode het onreggemaak gebly.
Groenboumeester
Die tyd gaan verby, en ons het tot die gevolgtrekking gekom dat verbintenisse wat sekere toetse nie slaag nie, nie in die meester toegelaat kan word nie. Voila! Ons het Green Build Master uitgevind, wat al lank in sagteware-ontwikkeling beoefen word:
- Ontwikkeling is aan die gang in 'n aparte tak.
- Toetse loop op hierdie draad.
- As die toetse misluk, sal die kode dit nie in die meester maak nie.
Dit was baie pynlik om hierdie besluit te neem, want... het baie omstredenheid veroorsaak, maar dit was die moeite werd, want. Resensies het versoeke vir samesmeltings begin ontvang sonder verskille in styl, en met verloop van tyd het die aantal probleemareas begin afneem.
IaC toets
Benewens stylkontrolering, kan jy ander dinge gebruik, byvoorbeeld om te kyk of jou infrastruktuur werklik kan ontplooi. Of maak seker dat veranderinge in infrastruktuur nie tot verlies aan geld sal lei nie. Hoekom is dit dalk nodig? Die vraag is kompleks en filosofies, dit is beter om met 'n storie te antwoord dat daar op een of ander manier 'n outo-skaaler op Powershell was wat nie die grensvoorwaardes nagegaan het nie => meer VM's is geskep as wat nodig is => die kliënt het meer geld spandeer as wat beplan is. Dit is nie baie aangenaam nie, maar dit sal heel moontlik wees om hierdie fout op vroeër stadiums te vang.
Mens kan vra, hoekom komplekse infrastruktuur selfs meer kompleks maak? Toetse vir infrastruktuur, net soos vir kode, gaan nie oor vereenvoudiging nie, maar om te weet hoe jou infrastruktuur moet werk.
IaC Toetspiramide
IaC Toetsing: Statiese Analise
As jy die hele infrastruktuur gelyktydig ontplooi en seker maak dat dit werk, kan jy vind dat dit baie tyd neem en baie tyd verg. Daarom moet die basis iets wees wat vinnig werk, daar is baie daarvan, en dit dek baie primitiewe plekke.
Bash is moeilik
Kom ons kyk na 'n onbenullige voorbeeld. kies alle lêers in die huidige gids en kopieer na 'n ander plek. Die eerste ding wat by jou opkom:
for i in * ; do
cp $i /some/path/$i.bak
doneWat as daar 'n spasie in die lêernaam is? Wel, ok, ons is slim, ons weet hoe om aanhalings te gebruik:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneWel gedaan? Geen! Wat as daar niks in die gids is nie, m.a.w. globbing sal nie werk nie.
find . -type f -exec mv -v {} dst/{}.bak ;Nou goed gedoen? Nee... vergeet wat in die lêernaam kan wees n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirStatiese analise gereedskap
Die probleem van die vorige stap kon vasgevang word toe ons die aanhalings vergeet het, hiervoor is daar baie middels in die natuur , oor die algemeen is daar baie van hulle, en heel waarskynlik kan jy 'n linter vir jou stapel onder jou IDE vind.
Taalvoorkeur
Tool
bash
Ruby
python
ansible
IaC-toetsing: Eenheidtoetse
Soos ons uit die vorige voorbeeld gesien het, is linters nie almagtig nie en kan dit nie al die probleemareas uitwys nie. Verder, in analogie met toetsing in sagteware-ontwikkeling, kan ons eenheidstoetse herroep. Wat dadelik by my opkom is , , , . Maar wat om te doen met ansible, sjef, soutstapel en ander soos hulle?
Heel aan die begin het ons gepraat oor SOLIED en dat ons infrastruktuur uit klein bakstene moet bestaan. Hulle tyd het aangebreek.
- Die infrastruktuur is verdeel in klein stene, byvoorbeeld Ansible rolle.
- Een of ander omgewing word ontplooi, of dit nou dokwerker of 'n VM is.
- Ons pas ons Ansible-rol toe op hierdie toetsomgewing.
- Ons kyk of alles werk soos ons verwag het (ons voer toetse uit).
- Ons besluit ok of nie ok.
IaC-toetsing: Eenheidtoetsinstrumente
Vraag, wat is toetse vir CFM? Jy kan eenvoudig die skrip laat loop, of jy kan klaargemaakte oplossings hiervoor gebruik:
CFM
Tool
Ansible
Chef
Chef
soutstapel
Voorbeeld vir testinfra, kontroleer dat gebruikers test1, test2 bestaan en is in 'n 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 om te kies? Die vraag is kompleks en dubbelsinnig, hier is 'n voorbeeld van veranderinge in projekte op github vir 2018-2019:
IaC-toetsraamwerke
Die vraag ontstaan: hoe om dit alles saam te voeg en dit te begin? Kan indien daar 'n voldoende aantal ingenieurs is. Of jy kan klaargemaakte oplossings neem, hoewel daar nie baie van hulle is nie:
CFM
Tool
Ansible
Chef
terraform
Voorbeeld van veranderinge in projekte op github vir 2018-2019:
Molekule vs. Toetskombuis
Aanvanklik het ons :
- Skep 'n VM in parallel.
- Pas Ansible rolle toe.
- Voer inspeksie uit.
Vir 25-35 rolle het dit 40-70 minute gewerk, wat lank was.
Die volgende stap was die oorgang na jenkins/docker/ansible/molekule. Idiologies is alles dieselfde
- Lint speelboeke.
- Rangskik die rolle.
- Begin houer
- Pas Ansible rolle toe.
- Begin testinfra.
- Gaan idempotensie na.
Lint vir 40 rolle en toetse vir 'n dosyn het ongeveer 15 minute begin neem.
Wat om te kies hang af van baie faktore, soos die stapel wat gebruik word, kundigheid in die span, ens. hier besluit elkeen self hoe om die Eenheidstoetsvraag af te sluit
IaC-toetsing: Integrasietoetse
Die volgende stap in die infrastruktuurtoetspiramide sal integrasietoetse wees. Hulle is soortgelyk aan eenheidstoetse:
- Die infrastruktuur word in klein stene verdeel, byvoorbeeld Ansible-rolle.
- Een of ander omgewing word ontplooi, of dit nou dokwerker of 'n VM is.
- Vir hierdie toetsomgewing geld n klop van Aanspreeklike rolle.
- Ons kyk of alles werk soos ons verwag het (ons voer toetse uit).
- Ons besluit ok of nie ok.
Rofweg gesproke gaan ons nie die werkverrigting van 'n individuele element van die stelsel na soos in eenheidstoetse nie, ons kyk hoe die bediener as 'n geheel opgestel is.
IaC-toetsing: eind-tot-einde-toetse
Aan die bopunt van die piramide word ons begroet deur End-to-End-toetse. Dié. Ons gaan nie die werkverrigting van 'n aparte bediener, 'n aparte skrif of 'n aparte steen van ons infrastruktuur na nie. Ons kyk of baie bedieners aan mekaar gekoppel is, ons infrastruktuur werk soos ons dit verwag. Ongelukkig het ek nog nooit klaargemaakte doosoplossings gesien nie, waarskynlik omdat... Die infrastruktuur is dikwels uniek en moeilik om te sjabloon en 'n raamwerk vir toetsing te skep. Gevolglik skep elkeen sy eie oplossings. Daar is 'n vraag, maar daar is geen antwoord nie. Daarom sal ek jou vertel wat daar is om ander te dwing om gedagtes te klink of my neus te vryf in die feit dat alles lank gelede voor ons uitgevind is.
'n Projek met 'n ryk geskiedenis. Dit word in groot organisasies gebruik en waarskynlik het elkeen van julle indirek paaie daarmee gekruis. Die toepassing ondersteun baie databasisse, integrasies, ens. Om te weet hoe die infrastruktuur kan lyk, is baie docker-compose-lêers, en om te weet watter toetse in watter omgewing uitgevoer moet word, is Jenkins.
Hierdie skema het nogal lank gewerk, tot binne die raamwerk ons het nie probeer om dit na Openshift oor te dra nie. Die houers bly dieselfde, maar die bekendstellingsomgewing het verander (hallo DRY weer).
Die navorsingsidee het verder gegaan, en in oopskuif het hulle iets soos APB (Ansible Playbook Bundle) gevind wat jou toelaat om kennis van hoe om infrastruktuur te ontplooi in 'n houer te pak. Dié. daar is 'n herhaalbare, toetsbare kennispunt oor hoe om die infrastruktuur te ontplooi.
Dit alles het goed geklink totdat ons 'n heterogene infrastruktuur raakgeloop het: ons het Windows nodig vir toetse. As gevolg hiervan is die kennis van wat, waar, hoe om te ontplooi en te toets, in jenkins.
Gevolgtrekking
Infrastruktuur soos Kode is
- Kode in die bewaarplek.
- Menslike interaksie.
- Infrastruktuurtoetsing.
skakels
- Droëloop 2019-04-24
- &
Bron: will.com