Yrityksemme on perustamassa SRE-tiimiä. Tulin koko tarinaan kehityksen puolelta. Prosessin aikana sain ajatuksia ja oivalluksia, jotka haluan jakaa muiden kehittäjien kanssa. Tässä reflektioartikkelissa puhun siitä, mitä tapahtuu, miten se tapahtuu ja kuinka jokainen voi jatkaa elämäänsä sen kanssa.
Jatkoa sisäisessä tilaisuudessamme pidettyjen puheiden perusteella kirjoitetulle artikkelisarjalle :
2. Infrastruktuuri koodina. (Sinä olet täällä)
3. Typescript-sopimusten luominen C#-malleja käyttäen. (Käynnissä...)
4. Johdatus Raft-konsensusalgoritmiin. (Käynnissä...)
...
Päätimme perustaa SRE-tiimin toteuttamaan ideoita . He rekrytoivat ohjelmoijia omien kehittäjiensä joukosta ja lähettivät heidät harjoittelemaan useiden kuukausien ajan.
Joukkueella oli seuraavat harjoitustehtävät:
- Kuvaile infrastruktuuriamme, joka on enimmäkseen Microsoft Azuressa koodin muodossa (Terraform ja kaikki ympärillä).
- Opeta kehittäjiä työskentelemään infrastruktuurin kanssa.
- Valmista kehittäjät tehtäviin.
Esittelemme käsitteen infrastruktuuri koodina
Tavallisessa maailmanmallissa (klassinen hallinto) tieto infrastruktuurista sijaitsee kahdessa paikassa:
- Tai tiedon muodossa asiantuntijoiden päässä.
- Tai nämä tiedot ovat joissakin kirjoituskoneissa, joista osa on asiantuntijoiden tiedossa. Mutta se ei ole tosiasia, että ulkopuolinen (jos koko tiimimme yhtäkkiä kuolee) voi selvittää, mikä toimii ja miten se toimii. Koneessa voi olla paljon tietoa: lisävarusteita, työtöitä, peloteltua (katso. ) -levy ja vain loputon luettelo siitä, mitä voi tapahtua. On vaikea ymmärtää, mitä todella tapahtuu.
Molemmissa tapauksissa huomaamme olevamme riippuvaisia:
- tai henkilöltä, joka on kuolevainen, altis sairaus, rakastuminen, mielialan vaihtelut ja yksinkertaisesti banaalit irtisanomiset;
- tai fyysisesti toimivasta koneesta, joka myös putoaa, varastetaan ja tuottaa yllätyksiä ja haittoja.
On sanomattakin selvää, että ihannetapauksessa kaikki pitäisi kääntää ihmisen luettavaksi, ylläpidettäväksi, hyvin kirjoitetuksi koodiksi.
Infrastruktuuri koodina (Incfastructure as Code - IaC) on siis kuvaus koko olemassa olevasta infrastruktuurista koodin muodossa sekä siihen liittyvät työkalut sen kanssa työskentelyyn ja todellisen infrastruktuurin toteuttamiseen siitä.
Miksi kääntää kaikki koodiksi?Ihmiset eivät ole koneita. He eivät voi muistaa kaikkea. Ihmisen ja koneen reaktio on erilainen. Kaikki automatisoitu on mahdollisesti nopeampaa kuin mikään ihmisen tekemä. Tärkeintä on yksi ainoa totuuden lähde.
Mistä uudet SRE-insinöörit tulevat?Joten päätimme palkata uusia SRE-insinöörejä, mutta mistä niitä saa? Kirja oikeilla vastauksilla () kertoo meille: kehittäjiltä. Loppujen lopuksi ne toimivat koodin kanssa ja saavutat ihanteellisen tilan.
Etsimme heitä paljon pitkään yrityksemme ulkopuolelta henkilöstömarkkinoilta. Mutta meidän on myönnettävä, että emme löytäneet ketään, joka vastaisi pyyntöihimme. Minun piti etsiä omien ihmisten joukosta.
Ongelmat Infrastruktuuri koodina
Katsotaanpa nyt esimerkkejä siitä, kuinka infrastruktuuri voidaan koodata koodiksi. Koodi on hyvin kirjoitettu, laadukas, kommenteilla ja sisennyksillä.
Esimerkkikoodi Terraformalta.
Esimerkkikoodi Ansiblesta.
Hyvät herrat, jos se olisikin niin yksinkertaista! Olemme todellisessa maailmassa, ja se on aina valmis yllättämään sinut, tuomaan sinulle yllätyksiä ja ongelmia. Täälläkään ei pärjää ilman niitä.
1. Ensimmäinen ongelma on, että useimmissa tapauksissa IaC on jonkinlainen dsl.
Ja DSL puolestaan on rakenteen kuvaus. Tarkemmin sanottuna, mitä sinulla pitäisi olla: Json, Yaml, joidenkin suurten yritysten muutokset, jotka keksivät oman dsl:n (HCL:tä käytetään terraformissa).
Ongelmana on, että se ei välttämättä sisällä sellaisia tuttuja asioita kuin:
- muuttujat;
- ehdot;
- jossain ei ole kommentteja, esimerkiksi Jsonissa, oletuksena niitä ei tarjota;
- toiminnot;
- enkä edes puhu sellaisista korkean tason asioista kuin luokat, perinnöllisyys ja kaikki se.
2. Toinen ongelma tällaisessa koodissa on, että useimmiten se on heterogeeninen ympäristö. Yleensä istut ja työskentelet C#:lla, ts. yhdellä kielellä, yhdellä pinolla, yhdellä ekosysteemillä. Ja täällä on valtava valikoima tekniikoita.
Se on hyvin todellinen tilanne, kun bash with python käynnistää jonkin prosessin, johon Json lisätään. Analysoit sen, sitten jokin muu generaattori tuottaa vielä 30 tiedostoa. Kaikkea tätä varten Azure Key Vaultilta saadaan syötemuuttujat, jotka on vedetty yhteen Go-kielellä kirjoitetun drone.io-laajennuksen avulla, ja nämä muuttujat kulkevat yamlin kautta, joka on luotu jsonnet-mallimoottorista generoinnin tuloksena. On melko vaikeaa saada tarkasti kuvattua koodia, kun sinulla on niin monipuolinen ympäristö.
Perinteinen kehitys yhden tehtävän puitteissa tulee yhdellä kielellä. Täällä työskentelemme useiden kielten kanssa.
3. Kolmas ongelma on viritys. Olemme tottuneet viileisiin editoreihin (Ms Visual Studio, Jetbrains Rider), jotka tekevät kaiken puolestamme. Ja vaikka olisimme tyhmiä, he sanovat, että olemme väärässä. Vaikuttaa normaalilta ja luonnolliselta.
Mutta jossain lähellä on VSCode, jossa on joitain laajennuksia, jotka on jotenkin asennettu, tuettu tai ei tueta. Uusia versioita julkaistiin, eikä niitä tuettu. Banaalista siirtymisestä funktion toteuttamiseen (vaikka se on olemassa) tulee monimutkainen ja ei-triviaali ongelma. Yksinkertainen muuttujan uudelleennimeäminen on toisto tusinan tiedoston projektissa. Olet onnekas, jos hän sijoittaa tarvitsemasi. Tietysti siellä täällä on taustavaloa, on automaattinen täydennys, jossain on muotoilu (vaikka se ei toiminut minulle terraformissa Windowsissa).
Tätä kirjoitettaessa ei ole vielä julkaistu tukemaan versiota 0.12, vaikka se on julkaistu 3 kuukautta.
On aika unohtaa...
- Virheenkorjaus.
- Refaktorointityökalu.
- Automaattinen täydennys.
- Virheiden havaitseminen käännöksen aikana.
Se on hauskaa, mutta tämä myös lisää kehitysaikaa ja lisää väistämättä tapahtuvien virheiden määrää.
Pahinta on, että meidän ei tarvitse ajatella, kuinka suunnitella, järjestää tiedostot kansioihin, hajottaa, tehdä koodista ylläpidettävä, luettava ja niin edelleen, vaan sitä, kuinka voin kirjoittaa tämän komennon oikein, koska kirjoitin sen jotenkin väärin. .
Aloittelijana yrität oppia terraformeja, eikä IDE auta sinua ollenkaan. Kun asiakirjoja on, mene sisään ja katso. Mutta jos olisit kirjoittamassa uutta ohjelmointikieltä, IDE kertoisi sinulle, että tällainen tyyppi on olemassa, mutta sellaista ei ole. Ainakin int- tai merkkijonotasolla. Tästä on usein hyötyä.
Entä testit?
Kysyt: "Entä testit, herrat ohjelmoijat?" Vakavat kaverit testaavat kaiken tuotannossa, ja se on vaikeaa. Tässä on esimerkki sivuston terraform-moduulin yksikkötestistä .
Heillä on hyvät dokumentit. Olen aina pitänyt Microsoftista sen lähestymistavasta dokumentointiin ja koulutukseen. Mutta sinun ei tarvitse olla Bob-setä ymmärtääksesi, että tämä ei ole täydellinen koodi. Huomaa oikealla oleva vahvistus.
Yksikkötestin ongelma on, että sinä ja minä voimme tarkistaa Json-lähdön oikeellisuuden. Heitin 5 parametria ja sain Json-jalkaliinan, jossa oli 2000 riviä. Voin analysoida mitä täällä tapahtuu, vahvistaa testitulokset...
Jsonin jäsentäminen Gossa on vaikeaa. Ja sinun on kirjoitettava Go-kielellä, koska terraform in Go on hyvä käytäntö testata kielellä, jolla kirjoitat. Itse koodin organisointi on erittäin heikko. Samalla tämä on paras kirjasto testaukseen.
Microsoft itse kirjoittaa moduulinsa ja testaa niitä tällä tavalla. Tietenkin se on avoin lähdekoodi. Kaikki mistä puhun, voit tulla korjaamaan. Voin istua alas ja korjata kaiken viikossa, avata lähdekoodin VS-koodilaajennuksia, terraformeja, tehdä liitännäisen ratsastajalle. Ehkä kirjoittaa pari analysaattoria, lisätä linteriä, lisätä kirjasto testausta varten. Voin tehdä kaikkea. Mutta sitä minun ei pitäisi tehdä.
Parhaat käytännöt Infrastruktuuri koodina
Siirrytään eteenpäin. Jos IaC:ssä ei ole testejä, IDE ja viritys ovat huonoja, niin ainakin parhaita käytäntöjä pitäisi olla. Kävin juuri Google Analyticsissa ja vertasin kahta hakukyselyä: Terraformin parhaat käytännöt ja c# parhaat käytännöt.
Mitä me näemme? Häikäilemättömät tilastot eivät ole meidän eduksemme. Materiaalin määrä on sama. C#-kehityksessä olemme yksinkertaisesti täynnä materiaaleja, meillä on superparhaat käytännöt, on asiantuntijoiden kirjoittamia kirjoja ja myös kirjoja, jotka on kirjoitettu muiden asiantuntijoiden kirjoista, jotka arvostelevat näitä kirjoja. Meri virallista dokumentaatiota, artikkeleita, koulutuskursseja ja nyt myös avoimen lähdekoodin kehitystä.
Mitä tulee IaC-pyyntöön: tässä yrität kerätä tietoa vähän kerrallaan highload- tai HashiConf-raporteista, virallisesta dokumentaatiosta ja lukuisista Githubin ongelmista. Miten näitä moduuleja jaetaan yleisesti, mitä niille tehdään? Tämä näyttää olevan todellinen ongelma... Hyvät herrat, on yhteisö, jossa jokaiseen kysymykseen annetaan 10 kommenttia Githubissa. Mutta se ei ole aivan.
Valitettavasti tällä hetkellä asiantuntijoita on vasta alkamassa ilmaantua. Niitä on toistaiseksi liian vähän. Ja yhteisö itse hengaa alkeellisella tasolla.
Mihin tämä kaikki menee ja mitä tehdä
Voit pudottaa kaiken ja palata C#:aan, ratsastajan maailmaan. Mutta ei. Miksi edes vaivaudut tekemään tätä, jos et löydä ratkaisua? Esitän alla subjektiiviset johtopäätökseni. Voit väittää kanssani kommenteissa, se on mielenkiintoista.
Henkilökohtaisesti lyön vetoa muutamasta asiasta:
- Kehitys tällä alueella tapahtuu erittäin nopeasti. Tässä on DevOps-pyyntöjen aikataulu.
Aihe voi olla hype, mutta jo se tosiasia, että pallo kasvaa, antaa toivoa.Jos jokin kasvaa niin nopeasti, niin varmasti ilmestyy älykkäitä ihmisiä, jotka kertovat sinulle, mitä tehdä ja mitä ei. Suosion kasvu johtaa siihen, että ehkä joku ehtii vihdoin lisätä jsonnet for vscode -laajennuksen, jonka avulla voit siirtyä toiminnon toteuttamiseen sen sijaan, että etsit sitä näppäinyhdistelmällä ctrl+shift+f. Kun asiat kehittyvät, materiaalia tulee lisää. Googlen julkaisema kirja SRE:stä on erinomainen esimerkki tästä.
- Perinteisessä kehityksessä on kehitetty tekniikoita ja käytäntöjä, joita voimme menestyksekkäästi soveltaa täällä. Kyllä, testauksessa on vivahteita ja heterogeeninen ympäristö, riittämätön työkalu, mutta käytäntöjä on kertynyt valtava määrä, joista voi olla hyötyä ja apua.
Triviaali esimerkki: yhteistyö pariohjelmoinnin kautta. Sen selvittäminen auttaa paljon. Kun lähellä on naapuri, joka myös yrittää ymmärtää jotain, ymmärrätte yhdessä paremmin.
Refaktoroinnin tekemisen ymmärtäminen auttaa sen toteuttamisessa myös tällaisessa tilanteessa. Eli kaikkea ei voi muuttaa kerralla, vaan muuta nimeämistä, sitten sijaintia, niin voit korostaa jonkin osan, oh, mutta täällä ei ole tarpeeksi kommentteja.
Johtopäätös
Huolimatta siitä, että päättelyni saattaa tuntua pessimistiseltä, katson tulevaisuuteen toiveikkaana ja toivon vilpittömästi, että kaikki järjestyy meidän (ja sinun) puolesta.
Artikkelin toista osaa valmistellaan seuraavaksi. Siinä kerron kuinka yritimme käyttää ketteriä kehityskäytäntöjä parantaaksemme oppimisprosessiamme ja työskennelläksemme infrastruktuurin kanssa.
Lähde: will.com