🥇Infrastruktuuri testimine koodina Pulumi abil. Osa 2

Tere kõigile. Täna jagame teiega artikli viimast osa „Infrastruktuuri testimine koodina Pulumi abil“, mille tõlge on ette valmistatud spetsiaalselt kursuse tudengite jaoks «DevOps praktikad ja tööriistad».

Deployimise testimine

Käideldud testimisstiil on tõhus lähenemine, mis võimaldab meil teostada valge kasti testimist, et kontrollida meie infrastruktuurikoodi toimimist. Siiski piirab see veidi seda, mida saame kontrollida. Testid toimuvad Pulumi loodud in-memory deployimise plaani alusel enne tegelikku deployimist, mistõttu ei saa ise deployimist testida. Selliste juhtumite jaoks on Pulumis integreerimise testimise raamistiku süsteem. Need kaks lähenemist toimivad suurepäraselt koos!

Pulumi integreerimise testimise raamistiku on kirjutatud Go-s ja just selle abil testime suure osa meie sisekoodist. Kui varem käsitletud modulaarne testimine oli rohkem nagu valge kasti testimine, siis integreerimise testimine on must kasti testimine. (On ka võimalusi põhjalikuks sisetestimiseks.) See raamistik loodi selleks, et võtta terve Pulumi programm ja teostada selle suhtes erinevaid elutsükli toiminguid, nagu näiteks uue steigi deployimine nullist, selle uuendamine variatsioonidega ja eemaldamine, võimalikult mitu korda. Käitame neid regulaarselt (näiteks öösel) ja stressitestidena.

(Me töötame selle nimel, et sarnased integreerimise testimise võimalused oleksid olemas lähtekoodis. Saate kasutada Go integreerimise testimise raamistiku sõltumatult sellest, millises keeles on teie Pulumi programm kirjutatud).

Selle raamistiku abil programmi käivitades võite kontrollida järgmist:

Teie projekti kood on süntaktiliselt korrektne ja töötab vigadeta.
Steigi ja saladuste konfiguratsiooniseaded toimivad ja tõlgendatakse õigesti.
Teie projekt suudab edukalt deployida valitud pilveteenuse pakkuja juures.
Teie projekt suudab edukalt uuendada algsest olekust N teise olekuni.
Teie projekt saab edukalt hävitada ja eemaldada oma pilveteenuse pakkujast.

Nagu peagi näeme, saab seda raamistiku kasutada ka runtime valideerimiseks.

Lihtne integreerimistest

Et näha, kuidas see töötab, vaatame reposiitiumi pulumi/examples, kuna meie Pulumi meeskond ja kogukond kasutavad seda enda pull-requestide, commit'ide ja öiste ehituste testimiseks.

Allpool on meie näite lihtsustatud test, mis teeb S3 bucket'i ja mõnede teiste objektide varustamise:

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 aluslikku elutsüklit, kus luuakse, muudetakse ja hävitatakse stack kaustas aws-js-s3-folder. See võtab umbes minuti, et teavitada möödunud testist:

$ go test .
PASS
ok      ... 43.993s

On palju parameetreid, et kohandada nende testide käitumist. Täielik valik valikuid vaata struktuuris ProgramTestOptions. Näiteks saate seadistada Jaeger lõpp-punkti jälgimiseks (Tracing), märkida, et ootate testi ebaõnnestumist negatiivse testimise puhul (ExpectFailure), rakendada seeria "muudatusi" programmi jaoks järjestikuste olekute ülemineku jaoks (EditDirs) ja palju muud. Vaatame, kuidas neid kasutada rakenduse juurutamise kontrollimiseks.

Resursside omaduste kontrollimine

Ühendamine, millest räägiti, tagab, et meie programm "töötab" — see ei ebaõnnestu. Aga mis siis, kui soovime kontrollida saadud stack'i omadusi? Näiteks, et teatud tüüpi ressursid on (või ei ole) loodud ning et neil on teatud omadused.

Parameeter ExtraRuntimeValidation jaoks ProgramTestOptions laseb meil vaadata Pulumi jäädvustatud olekut pärast juurutamist (post-deployment state), et saaksime teha täiendavaid kontrollimisi. See hõlmab täielikku tulemuste stack'i oleku ülevaadet, sealhulgas konfiguratsiooni, eksporditud väljundväärtusi, kõiki ressursside ja nende omaduste väärtusi ning ressursi vahelisi sõltuvusi.

Et näha selle põhijoonist, kontrollime, et meie programm loob ühe S3 Bucket:

  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, "Ootame, et leiame ühe AWS S3 ämbri")
        },
    })

Nüüd, kui me käivitame go test, ei lähe see lihtsalt läbi testide, vaid pärast lahtiütlemise edukat sooritamist viib see läbi ka täiendava kontrolli lõpptulemuse kohta.

Runtime-testid

Kuni siiani olid kõik testid seotud ainult juurutamise käitumise ja Pulumi ressursimudeliga. Mis toimub, kui soovite kontrollida, et teie ettevalmistatud infrastruktuur tõesti töötab? Näiteks, et virtuaalne masin töötab, S3 ämbri sisu vastab meie ootustele jms.

Võite juba aimata, kuidas seda teha: valik ExtraRuntimeValidation jaoks ProgramTestOptions — on selle jaoks suurepärane võimalus. Selle etapi jooksul käitate oma programmi täiendava Go testi, millel on juurdepääs kõikide teie ressursside olekule. See olek sisaldab teavet, nagu virtuaalsete masinate IP-aadressid, URL-id ja kõik, mis on vajalik tõeliseks suhtlemiseks saadud pilve rakenduste ja infrastruktuuriga.

Näiteks meie testprogramm ekspordib omaduse webEndpoint ämber nimega websiteUrl, mis on täielik URL, mille kaudu me saame juurdepääsu seadistatud index document. Kuigi me võiksime uurida olekufaili, et leida bucket'i ja lugeda seda omadust otse, siis paljudel juhtudel ekspordivad meie stekid kasulikud omadused, näiteks see, mida on mugav kasutada kontrollimiseks:

integration.ProgramTest(t, &integration.ProgramTestOptions{
            \/\/ nagu enne ...
        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 eelnevad runtime-kontrollid, toimub see kontroll kohe pärast steki tõstmist ja kõik see reageerib lihtsale kutsungile go test. Ja see on vaid jäämäe tipp — kõik Go testimisvõimalused on saadaval, mida saate kodeerida.

Jätkuv infrastruktuuri integreerimine

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

Iga avatud puhvriküsimise jaoks testi enne ühinemist.
Iga commit'i vastusena, et kontrollida, et ühinemine toimus õigesti.
Perioodiliselt, näiteks öösiti või iganädalaselt täiendavate testide jaoks.
Kuna osa jõudlustestimisest või stressitestimisest, mis tavaliselt kestab pikema aja ja käivitab teste paralleelselt ja/või juurutab sama programmi mitu korda.

Igaühe jaoks toetab Pulumi integreerimist teie lemmik järjepideva integreerimise süsteemiga. Jätkuva integreerimisega saad sama testide katvuse oma infrastruktuurile, nagu ka rakendustarkvarale.

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

Rohkema teabe saamiseks vaadake dokumentatsiooni Continuous Delivery.

Efemeersed keskkonnad

Väga võimas võimalus, mis avatakse, on võime juurutada efemeerseid keskkondi eranditult vastuvõtutestimise eesmärkidel. Kontseptsioon projektidest ja virnadest Pulumi on kavandatud selliselt, et oleks lihtne juurutada ja hävitada täielikult isoleeritud ja sõltumatuid keskkondi, kõik vaid mõne lihtsa CLI-käsu või integreerimistestimise raamistiku abil.

Kui kasutate GitHubi, siis Pulumi pakub GitHubi rakendust, mis aitab teil ühenduda vastuvõtutestimisega puhvriküsimustes teie CI torujuhtmes. Paigaldage rakendus GitHubi hoidlas ja Pulumi teie CI-sse ning puhvriküsimustes lisatakse teavet infrastruktuuri eelvaate, uuenduste ja testimistulemuste kohta:

Pulumi kasutamisel teie põhivastuvõtutestide jaoks on teil uued automatiseerimisvõimalused, mis parandavad meeskonna tootlikkust ja annavad kindlustunde muudatuste kvaliteedi osas.

Kokkuvõte

Selles artiklis nägime, et üldotstarbeliste programmeerimiskeelte kasutamisel saavad meile kätte palju tarkvaraarenduse meetodeid, mis on olnud meie rakenduste arendamisel kasulikud. Need hõlmavad modulaarset testimist, integreerimistestimist ning nende koostööd ulatuslikuks runtime-testimiseks. Teste on lihtne käivitada nõudmisel või oma CI-süsteemis.

Pulumi — avatud lähtekoodiga tarkvara, mida on tasuta kasutada ja mis töötab teie lemmikprogrammide ja -pilvede abil — proovige seda täna!

→ Esimene osa

Allikas: habr.com