🥇Infrastruktuuri testimine koodina Pulumi abil. Osa 2

Tere kõigile. Täna jagame teiega artikli lõpposa „Infrastruktuuri testimine koodi kaudu Pulumi abil“, mille tõlke valmistamiseks on see spetsiaalselt mõeldud kursuse üliõpilastele „DevOps praktikas ja tööriistades“.

Deployimise testimine

Käsitletud testimisstiil on tugev lähenemine, mis võimaldab meil teostada valge kasti testimist meie infrastruktuuri koodi sisemiste tööde kontrollimiseks. Kuid see piirab veidi seda, mida me saame kontrollida. Testid viiakse läbi in-memory deployimisplaani põhjal, mille Pulumi loob enne tegelikku paigaldamist, seetõttu ei saa me paigaldust ennast testida. Selliste juhtumite jaoks on Pulumi-s integratsioonitestide raamistik. Ja need kaks lähenemist toimivad koos suurepäraselt!

Pulumi integreerimise testimise raamistik on kirjutatud Go-s ja just selle abil testime suurt osa meie sisemisest koodist. Kui eelnevalt arutatud moodulitestimise lähenemine oli rohkem sarnane valge kasti testimisele, siis integreerimistestimine on must kast. (On ka võimalusi põhjalikuks sisemiseks testimiseks.) See raamistik loodi selleks, et võtta täis Pulumi programm ja teostada selle kohta erinevaid elutsükli operatsioone, nagu uue virna juurutamine nullist, selle uuendamine variatsioonidega ja kustutamine, võib-olla mitu korda. Käivitame neid regulaarselt (näiteks öösiti) ja pingetestide osana.

(Me töötame selle nimel, et sarnased integreerimistestimise võimalused oleksid kohalike SDK-de keeltes. Saate Go integreerimistestimise raamistikku kasutada sõltumata keelt, milles teie Pulumi programm on kirjutatud).

Programmi käivitamisel selle raamistikuga saate kontrollida järgmist:

Teie projekti kood on süntaktiliselt korrektne ja töötab vigadeta.
Stacki ja saladuste konfigureerimise seaded töötavad ning tõlgendatakse õigesti.
Teie projekt saab edukalt juurutatud valitud pilveteenusesse.
Teie projekt saab edukalt uuendatud algsest olekust N muusse olekusse.
Teie projekt saab edukalt hävitatud ja kustutatud teie pilveteenuse pakkujalt.

Nagu me varsti näeme, saab seda raamistikku kasutada ka runtime'i valideerimiseks.

Lihtne integreerimistest

Et seda tegevuses näha, vaatame repositooriumi pulumi/examples, kuna meie meeskond ja Pulumi kogukond kasutavad seda oma pull-requestide, kommitite ja öiste kogumiste testimiseks.

Allpool on toodud lihtsustatud test meie näitest, mis loob S3 bucket'i ja mõned teised objektid.:

example_test.go:

package test
 
import (
    "os"
    "path"
    "testing"
 
    "github.com/pulumi/pulumi/pkg/testing/integration"
)
 
func TestExamples(t *testing.T) {
    awsRegion := os.Getenv("AWS_REGION")
    if awsRegion == "" {
        awsRegion = "us-west-1"
    }
    cwd, _ := os.Getwd()
    integration.ProgramTest(t, &integration.ProgramTestOptions{
        Quick:       true,
        SkipRefresh: true,
        Dir:         path.Join(cwd, "..", "..", "aws-js-s3-folder"),
        Config: map[string]string{
            "aws:region": awsRegion,
        },
    })
}

See test läbib põhijärkude loomise, muutmise ja hävitamise tsüklit kausta jaoks aws-js-s3-folder. See võtab aega umbes minuti, et teavitada läbitud testist:

$ go test .
PASS
ok      ... 43.993s

Testide käitumise kohandamiseks on palju valikuid. Täielik loetelu valikutest vaata siit. struktuuris ProgramTestOptions. Näiteks võid seadistada Jaegeri lõpp-punkti jälgimise jaoks (Jälgimine), märkida, et ootad testi ebaõnnestumist negatiivse testimise korral (OotaEbaõnnestumist), rakendada programmi “muudatusi” süsteemide järkjärguliseks üleminekuks (MuudaKaasid) ja palju muud. Vaatame, kuidas neid kasutada rakenduse juurutamise kontrollimiseks.

Ressursside omaduste kontrollimine

Ülaltoodud integreerimine tagab, et meie programm „töötab“ — see ei ebaõnnestu. Aga kui me soovime kontrollida saadud stack'i omadusi? Näiteks, et teatud tüüpi ressursse on (või ei ole) ette valmistatud ja et neil on teatud atribuudid.

Parameeter ExtraRuntimeValidation kuna ProgramTestOptions võimaldab meil vaadata Pulumi registreeritud seisundit pärast juurutamist (post-deployment state), et saaksime teha täiendavaid kontrolle. Siia kuulub täielik tulemuse steki seisundi jäljend, sealhulgas konfiguratsioon, eksporditavad väljundväärtused, kõik ressursid ja nende omaduste väärtused, samuti kõik ressursivahelised sõltuvused.

Et näha selle põhinäidet, vaatame, et meie programm loob ühe S3 ämbri:

  integration.ProgramTest(t, &integration.ProgramTestOptions{
        // nagu enne...
        ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
            var foundBuckets int
            for _, res := range stack.Deployment.Resources {
                if res.Type == "aws:s3/bucket:Bucket" {
                    foundBuckets++
                }
            }
            assert.Equal(t, 1, foundBuckets, "Oodata, et leida üksik AWS S3 ämbri")
        },
    })

Nüüd, kui käivitame go test, siis see mitte ainult ei läbi elu tsükli testide seeriat, vaid ka pärast steki eduka juurutamise tulemuse kontrollimise täiendava kontrolli.

Runtime-testid

Kuni praeguseni on kõik testid käsitlenud ainult käivitamisprotsesside ja Pulumi ressursimudelite käitumist. Kuidas aga kontrollida, kas teie seadistatud infrastruktuur tõepoolest töötab? Näiteks kas virtuaalmasin töötab, S3 ämber sisaldab seda, mida ootame, jne.

Võisite juba arvata, kuidas seda teha: variant ExtraRuntimeValidation kuna ProgramTestOptions — on selleks suurepärane võimalus. Sellisel hetkel käitate juhuslikku Go testi, millel on juurdepääs teie programmi täielikule ressursiseisundile. See seisund sisaldab teavet, nagu virtuaalmasinate IP-aadressid, URL-id ja kõik, mis on vajalik reaalseteks interaktsioonideks saamiskeskkondade ja infrastruktuuriga.

Näiteks ekspordib meie testprogrammmis omadus webEndpoint ämber nimega websiteUrl, mis esindab täielikku URL-i, mille kaudu saame ligipääsu seadistatud index document. Kuigi me võiksime seisundifailis süüvida ja lugeda seda omadust otse, ekspordivad paljudel juhtudel meie stekid kasulikke omadusi, nagu see, mida on mugav kasutada kontrollimiseks: baketi ja lugeda seda omadust otse, kuid paljudel juhtudel ekspordivad meie stekid kasulikke omadusi, nagu see, mida me saame mugavalt kasutada kontrollimiseks:

integration.ProgramTest(t, &integration.ProgramTestOptions{
            // nagu varem ...
        ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
            url := "http://" + stack.Outputs["websiteUrl"].(string)
            resp, err := http.Get(url)
            if !assert.NoError(t, err) {
                return
            }
            if !assert.Equal(t, 200, resp.StatusCode) {
                return
            }
            defer resp.Body.Close()
            body, err := ioutil.ReadAll(resp.Body)
            if !assert.NoError(t, err) {
                return
            }
            assert.Contains(t, string(body), "Tere, Pulumi!")
        },
    })

Nagu meie varasemad runtime-kontrollid, viiakse see kontroll läbi kohe pärast steigi käivitamist ja kõik see on lihtsa kutse vastus. go test. Ja see on alles jäämäe tipp — kõik Go testimise võimalused on saadaval ja neid saab kirjutada koodis.

Täitmise pidev integreerimine

Hea on võimalus käivitada teste sülearvutis, kui tehakse palju muudatusi infrastuktuuris, et neid enne koodile ülevaatamiseks saatmist kontrollida. Kuid meie ja paljud meie kliendid testivad infrastruktuuri erinevates arenduse elutsükli etappides:

Igas avatud pulli taotluses testi enne sulandumist.
Kasutaja iga commiti puhul, et üle kontrollida, et sulandumine toimus õigesti.
Perioodiliselt, näiteks öösel või nädalas lisatestimiseks.
Jõudlustestide või stressitestide raames, mida tavaliselt tehakse pika aja jooksul ja mis käivitavad teste paralleelselt ja / või kasutavad sama programmi mitu korda.

Igaühe jaoks toetab Pulumi integreerimist teie lemmik pideva integreerimise süsteemiga. Pideva integreerimise korral annab see teile sama katvuse testidega teie infrastruktuuri jaoks, nagu ka rakendustarkvara jaoks.

Pulumi toetab levinud CI-süsteeme. Siin on mõned neist:

Lisainformatsiooni saamiseks pöörduge dokumentatsiooni poole Jätkuv kohaletoimetamine.

Efemeraalsed keskkonnad

Väga võimas võimalus, mis avaneb, on efemeersete keskkondade juurutamine ainult aktsepteerimistestide eesmärkidel. Kontseptsioon projektidest ja stekidest Pulumi on loodud selleks, et hõlpsasti juurutada ja likvideerida täiesti isoleeritud ja sõltumatuid keskkondi, kõik mõne lihtsa CLI käsu või integratsioonitestimise raamistikuga.

Kui kasutate GitHubi, siis Pulumi pakub GitHubi rakendust, mis aitab teil siduda aktsepteerimistestid teie CI-pipeline'i pull-request'idega. Lihtsalt installige rakendus GitHubi repositooriumis ja Pulumi teie CI-s, ning pull-request'idele lisatakse teavet infrastruktuuri eelvaate, värskenduste ja testimistulemustega:

Pulumi kasutamine teie põhieksamite jaoks avab uued automatiseerimise võimalused, mis parandavad meeskonna tootlikkust ja annavad kindlustunde muudatuste kvaliteedis.

Kokkuvõte

Käesolevas artiklis nägime, et üldotstarbeliste programmeerimiskeelte kasutamine avab meile palju tarkvaraarenduse meetodeid, mis on meie rakenduste arendamisel kasulikud. Nende hulka kuuluvad moodulitestimine, integreerimistestimine ning nende koostoime ulatuslikuks runtime-testeerimiseks. teste on lihtne käivitada nõudmise korral või teie CI-süsteemis.

Pulumi — avatud lähtekoodiga tarkvara, mis on tasuta, et kasutada ja töötab teie lemmikprogrammeeringute ja pilvedega — katseta seda täna!

→ Esimene osa

Allikas: habr.com