Testning av infrastruktur som kod med Pulumi. Del 2

Hej alla. Idag delar vi med oss av den avslutande delen av artikeln «Testning av infrastruktur som kod med hjälp av Pulumi», en översättning som är speciellt förberedd för studenter i kursen «DevOps metoder och verktyg».

Testning av distribution

Den stil av testning som diskuterades är en kraftfull metod, den gör det möjligt för oss att genomföra tests av vit låda för att kontrollera hur vår infrastruktur kod fungerar inuti. Men det begränsar något vad vi kan testa. Tester utförs baserat på en in-memory distributionsplan som Pulumi skapar innan själva distributionen, och därför kan själva distributionen inte testas. För sådana fall finns det ett integrations test ramverk i Pulumi. Och dessa två metoder fungerar utmärkt tillsammans!

Pulumi:s ramverk för integrationstestning är skrivet i Go, och det är med hjälp av detta vi testar större delen av vår interna kod. Om den tidigare diskuterade metoden för modulär testning mer liknade tests av vit låda, så är integrationstestning en svart låda. (Det finns också alternativ för noggrant intern testning.) Detta ramverk skapades för att ta ett komplett Pulumi-program och utföra olika livscykeloperationer för den, såsom att distribuera en ny stapel från grunden, uppdatera den med variationer och ta bort den, kanske flera gånger. Vi kör dem regelbundet (till exempel på natten) och som stresstester.

(Vi arbetar på att, så att liknande möjligheter för integrationstestning ska finnas i det inhemska SDK:t för språken. Du kan använda ramverket för integrationstestning i Go oavsett vilket språk din Pulumi-program är skriven på).

Genom att köra programmet med detta ramverk kan du kontrollera följande:

• Koden i ditt projekt är syntaktiskt korrekt och fungerar utan fel.
• Inställningar för stapel och hemligheter fungerar och tolkas korrekt.
• Ditt projekt kan framgångsrikt distribueras till den valda molnleverantören.
• Ditt projekt kan framgångsrikt uppdateras från det ursprungliga tillståndet till N andra tillstånd.
• Ditt projekt kan framgångsrikt förstöras och tas bort från din molnleverantör.

Som vi snart kommer att se, kan detta ramverk också användas för runtime-validering.

Enkel integreringstest

För att se detta i praktiken ska vi titta på repositoriet pulumi/examples, eftersom vårt team och Pulumi-gemenskapen använder det för att testa sina egna pull requests, commits och nattbyggnader.

Nedan följer ett förenklat test av vår exempel, som provisionerar en S3-bucket och några andra objekt:

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,
        },
    })
}

Det här testet går igenom den grundläggande livscykeln för att skapa, ändra och förstöra en stack för en mapp aws-js-s3-folder. Det tar cirka en minut att rapportera att testet passerade:

$ go test .
PASS
ok      ... 43.993s

Det finns många parametrar för att konfigurera beteendet hos dessa tester. En fullständig lista över alternativ se i strukturen ProgramTestOptions. Till exempel kan du konfigurera Jaeger-endpoint för spårning (Tracing), ange att du förväntar dig att testet ska misslyckas vid negativ testning (ExpectFailure), tillämpa en serie 'ändringar' på programmet för sekventiell övergång mellan tillstånd (EditDirs) och mycket mer. Låt oss titta på hur man använder dem för att kontrollera distributionen av en applikation.

Kontroll av resursers egenskaper

Integrationen som nämndes ovan säkerställer att vårt program "fungerar" — det kraschar inte. Men vad händer om vi vill kontrollera egenskaperna hos den resulterande stacken? Till exempel, att vissa typer av resurser skapades (eller inte skapades) och att de har vissa attribut.

Parameter ExtraRuntimeValidation för ProgramTestOptions låter oss titta på det tillstånd som Pulumi har registrerat efter distribution (post-deployment state), så att vi kan göra ytterligare kontroller. Det inkluderar en fullständig översikt över det resulterande stacktillståndet, inklusive konfiguration, exporterade utdata, alla resurser och deras egenskapsvärden, samt alla beroenden mellan resurser.

För att se ett grundläggande exempel på detta, låt oss verifiera att vårt program skapar en S3-bucket:

  integration.ProgramTest(t, &integration.ProgramTestOptions{
        // som innan...
        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, "Förväntade att hitta en enda AWS S3 Bucket")
        },
    })

Nu när vi kör go test kommer det inte bara att gå igenom en batteri av livscykeltester, utan även, efter en framgångsrik distribution av stacken, utföra ytterligare kontroller av det resulterande tillståndet.

Runtime-tester

Hittills har alla tester handlat om beteendet vid distribution och Pulumi-resursmodellen. Vad ska man göra om du vill kontrollera att din förberedda infrastruktur verkligen fungerar? Till exempel, att virtuella maskiner körs, att S3-bucket innehåller det vi förväntar oss och så vidare.

Du har kanske redan gissat hur man gör detta: alternativet ExtraRuntimeValidation för ProgramTestOptions — är en utmärkt möjlighet för detta. I det här skedet kör du ett godtyckligt Go-test med tillgång till det fulla tillståndet för dina resurser. Detta tillstånd inkluderar sådan information som IP-adresser för virtuella maskiner, URL:er och allt annat som behövs för verklig interaktion med de mottagna molnapplikationerna och infrastrukturen.

Till exempel exporterar vårt testprogram egenskapen webEndpoint av bucketen med namnet websiteUrl, som representerar den fulla URL:en där vi kan få åtkomst till den konfigurerade indexdokumentet. Även om vi kunde leta igenom tillståndsfilen för att hitta bucket och läsa den här egenskapen direkt, i många fall exporterar våra stackar användbara egenskaper som detta, som är bekväma att använda för verifiering:

integration.ProgramTest(t, &integration.ProgramTestOptions{
            // som innan ...
        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), "Hello, Pulumi!")
        },
    })

Precis som våra tidigare runtime-kontroller kommer denna kontroll att utföras omedelbart efter att stacken har lyfts, och allt detta som svar på ett enkelt anrop go test. Och det är bara toppen av isberget – alla testmöjligheter för Go är tillgängliga som du kan skriva i koden.

Kontinuerlig integration av infrastruktur

Det är bra att kunna köra tester på en bärbar dator när många förändringar görs i infrastrukturen, för att verifiera dem innan de skickas för kodgranskning. Men vi och många av våra kunder testar infrastrukturen i olika skeden av utvecklingslivscykeln:

• I varje öppen pull request för testning innan sammanslagning.
• Som svar på varje commit för att dubbelkolla att sammanslagningen har gjorts korrekt.
• Periodiskt, till exempel på natten eller veckovis för ytterligare testning.
• Som en del av prestandatestning eller stresstestning, som vanligtvis utförs under en längre period och kör tester parallellt och/eller distribuerar samma program flera gånger.

För var och en av dem stöder Pulumi integration med ditt favorit kontinuerliga integrationssystem. Vid kontinuerlig integration ger detta dig samma testtäcka för din infrastruktur som för din applikationsprogramvara.

Pulumi har stöd för vanliga CI-system. Här är några av dem:

• AWS Code Services
• Azure DevOps
• CircleCI
• GitHub Actions
• GitLab CI
• Google Cloud Build
• Travis

För mer information, se dokumentationen för Kontinuerlig leverans.

Efermeriska miljöer

En mycket kraftfull funktion som öppnas är möjligheten att distribuera efermeriska miljöer uteslutande för acceptanstestningsändamål. Konceptet projekt och stackar Pulumi är utformat för att enkelt distribuera och riva ner helt isolerade och oberoende miljöer, allt med några få enkla CLI-kommandon eller med hjälp av ett ramverk för integrationstestning.

Om du använder GitHub erbjuder Pulumi GitHub App, som hjälper dig att ansluta acceptanstestning till pull requests inom din CI-pipeline. Installera bara appen i ditt GitHub-förråd, och Pulumi i din CI så kommer information om infrastrukturförhandsgranskningar, uppdateringar och testresultat att läggas till i pull requests:

Genom att använda Pulumi för dina huvudacceptanstester får du nya automatiseringsmöjligheter som förbättrar teamets produktivitet och ger trygghet i kvaliteten på förändringarna.

Resultat

I den här artikeln har vi sett att när vi använder allmänna programmeringsspråk så blir många mjukvaruutvecklingsmetoder tillgängliga, vilket har varit användbart vid utvecklingen av våra applikationer. Dessa inkluderar modulär testning, integrationstestning och deras interaktion för att genomföra omfattande runtime-testning. Tester kan enkelt startas på begäran eller i ditt CI-system.

Pulumi – mjukvara med öppen källkod, den är gratis att använda och fungerar med dina favoritprogrammeringsspråk och moln – prova det idag!

→ Den första delen

Källa: habr.com