Toets infrastruktuur as kode met Pulumi. Deel 2

Hi almal. Vandag deel ons die laaste deel van die artikel met jou. "Toets infrastruktuur as kode met Pulumi", waarvan die vertaling spesifiek vir kursusstudente voorberei is "DevOps-praktyke en gereedskap".

Toets infrastruktuur as kode met Pulumi. Deel 2

Ontplooiingstoetsing

Hierdie styl van toetsing is 'n kragtige benadering en stel ons in staat om witbokstoetse uit te voer om die interne werking van ons infrastruktuurkode te toets. Dit beperk egter ietwat wat ons kan toets. Die toetse word uitgevoer op grond van die in-geheue-ontplooiingsplan wat deur Pulumi geskep is voor die werklike ontplooiing en daarom kan die ontplooiing self nie getoets word nie. Vir sulke gevalle het Pulumi 'n integrasietoetsraamwerk. En hierdie twee benaderings werk uitstekend saam!

Die Pulumi-integrasietoetsraamwerk is in Go geskryf, dit is hoe ons die meeste van ons interne kode toets. Terwyl die voorheen bespreekte eenheidstoetsbenadering meer soos witbokstoetsing was, is integrasietoetsing 'n swart boks. (Daar is ook opsies vir streng interne toetsing.) Hierdie raamwerk is geskep om 'n volledige Pulumi-program te neem en verskeie lewensiklusbewerkings daarop uit te voer, soos om 'n nuwe stapel van nuuts af te ontplooi, dit met variasies op te dateer en dit uit te vee, moontlik verskeie kere . Ons hardloop hulle gereeld (byvoorbeeld snags) en as strestoetse.

(Ons ons werk daaraan, sodat soortgelyke integrasietoetsvermoëns beskikbaar is in die inheemse SDK van tale. Jy kan die Go-integrasietoetsraamwerk gebruik ongeag die taal waarin jou Pulumi-program geskryf is).

Deur die program met hierdie raamwerk te laat loop, kan jy die volgende nagaan:

  • Jou projekkode is sintakties korrek en loop sonder foute.
  • Die stapel- en geheime-konfigurasie-instellings werk en word korrek geïnterpreteer.
  • Jou projek kan suksesvol in die wolkverskaffer van jou keuse ontplooi word.
  • Jou projek kan suksesvol opgegradeer word vanaf die aanvanklike toestand na N ander state.
  • Jou projek kan suksesvol vernietig en van jou wolkverskaffer verwyder word.

Soos ons binnekort sal sien, kan hierdie raamwerk ook gebruik word om runtime-validering uit te voer.

Eenvoudige integrasie toets

Om dit in aksie te sien, sal ons na die bewaarplek kyk pulumi/examples, aangesien ons span en die Pulumi-gemeenskap dit gebruik om ons eie trekversoeke, commits en nagtelike bouwerk te toets.

Hieronder is 'n vereenvoudigde toets van ons voorbeeld wat S3-emmer en 'n paar ander voorwerpe verskaf:

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

Hierdie toets gaan deur die basiese lewensiklus van die skep, wysiging en vernietiging van 'n stapel vir 'n vouer aws-js-s3-folder. Dit sal ongeveer 'n minuut neem om 'n geslaagde toets aan te meld:

$ go test .
PASS
ok      ... 43.993s

Daar is baie opsies om die gedrag van hierdie toetse aan te pas. Sien volledige lys opsies. in die struktuur ProgramTestOptions. Byvoorbeeld, jy kan Jaeger eindpunt instel om na te spoor (Tracing), dui aan dat jy verwag dat die toets sal misluk as die toets negatief is (ExpectFailure), pas 'n reeks "wysigings" op die program toe vir 'n opeenvolgende oorgang van toestande (EditDirs) en baie meer. Kom ons kyk hoe om dit te gebruik om jou toepassing-ontplooiing te toets.

Gaan hulpbroneienskappe na

Die integrasie wat hierbo bespreek is, verseker dat ons program "werk" - dit val nie ineen nie. Maar wat as ons die eienskappe van die resulterende stapel wil nagaan? Byvoorbeeld, dat sekere soorte hulpbronne voorsien (of nie) voorsien is nie en dat hulle sekere eienskappe het.

Parameter ExtraRuntimeValidation vir ProgramTestOptions laat ons toe om te kyk na die post-ontplooiing toestand wat deur Pulumi aangeteken is sodat ons bykomende kontrole kan doen. Dit sluit 'n volledige momentopname van die toestand van die resulterende stapel in, insluitend konfigurasie, uitgevoerde uitvoerwaardes, alle hulpbronne en hul eiendomswaardes, en alle afhanklikhede tussen hulpbronne.

Om 'n basiese voorbeeld hiervan te sien, kom ons kyk of ons program een ​​skep S3 Emmer:

  integration.ProgramTest(t, &integration.ProgramTestOptions{
        // as before...
        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, "Expected to find a single AWS S3 Bucket")
        },
    })

Nou, wanneer ons go-toets uitvoer, sal dit nie net deur 'n battery lewensiklustoetse gaan nie, maar ook, nadat die stapel suksesvol ontplooi is, sal dit 'n bykomende kontrole op die gevolglike toestand uitvoer.

Looptyd toetse

Tot dusver was alle toetse suiwer oor ontplooiingsgedrag en die Pulumi-hulpbronmodel. Wat as jy wil verifieer dat jou voorsiende infrastruktuur werklik werk? Byvoorbeeld, dat die virtuele masjien aan die gang is, die S3-emmer bevat wat ons verwag, ensovoorts.

Jy het dalk al geraai hoe om dit te doen: opsie ExtraRuntimeValidation vir ProgramTestOptions - dit is 'n wonderlike geleentheid hiervoor. Op hierdie stadium voer jy 'n pasgemaakte Go-toets uit met toegang tot die volle toestand van jou program se hulpbronne. Hierdie toestand sluit inligting in soos virtuele masjien-IP-adresse, URL's en alles wat nodig is om werklik met die gevolglike wolktoepassings en infrastruktuur te kommunikeer.

Byvoorbeeld, ons toetsprogram voer die eiendom uit webEndpoint emmer genoem websiteUrl, wat die volledige URL is waar ons die gekonfigureerde kan kry index document. Alhoewel ons in die staatslêer kon delf om te vind bucket en lees daardie eiendom direk, maar in baie gevalle voer ons stapels nuttige eienskappe soos hierdie uit wat ons gerieflik vind om te gebruik om na te gaan:

integration.ProgramTest(t, &integration.ProgramTestOptions{
            // as before ...
        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!")
        },
    })

Soos ons vorige looptydkontroles, sal hierdie kontrole onmiddellik uitgevoer word nadat die stapel verhoog is, alles in reaksie op 'n eenvoudige oproep go test. En dit is net die punt van die ysberg—elke Go-toetsfunksie wat jy in kode kan skryf, is beskikbaar.

Deurlopende infrastruktuurintegrasie

Dit is goed om toetse op 'n skootrekenaar te kan uitvoer wanneer baie infrastruktuurveranderinge aangebring word om dit te toets voordat dit vir kode-hersiening ingedien word. Maar ons en baie van ons kliënte toets infrastruktuur op verskeie stadiums van die ontwikkelingslewensiklus:

  • In elke oop trek versoek vir toetsing voor saamsmelt.
  • In reaksie op elke commit, om dubbel seker te maak dat die samesmelting korrek gedoen is.
  • Periodiek, soos snags of weekliks vir bykomende toetse.
  • As deel van prestasie- of strestoetsing, wat tipies oor 'n lang tydperk loop en toetse parallel loop en/of dieselfde program verskeie kere ontplooi.

Vir elk hiervan ondersteun Pulumi integrasie met jou gunsteling deurlopende integrasiestelsel. Met deurlopende integrasie gee dit jou dieselfde toetsdekking vir jou infrastruktuur as vir jou toepassingsagteware.

Pulumi het ondersteuning vir algemene CI-stelsels. Hier is 'n paar van hulle:

Vir meer gedetailleerde inligting, verwys asseblief na die dokumentasie vir deurlopende aflewering.

Efemere omgewings

'n Baie kragtige geleentheid wat oopmaak, is die vermoë om kortstondige omgewings uitsluitlik vir aanvaardingstoetsdoeleindes te ontplooi. Konsep projekte en stapels Pulumi is ontwerp om heeltemal geïsoleerde en onafhanklike omgewings maklik te ontplooi en af ​​te breek, alles in 'n paar eenvoudige CLI-opdragte of deur 'n integrasietoetsraamwerk te gebruik.

As jy GitHub gebruik, bied Pulumi GitHub-toepassing, wat jou sal help om aanvaardingstoetse te koppel om versoeke binne jou CI-pyplyn te trek. Installeer net die toepassing in die GitHub-bewaarplek, en Pulumi sal inligting oor infrastruktuurvoorskoue, opdaterings en toetsresultate by jou CI en poelversoeke voeg:

Toets infrastruktuur as kode met Pulumi. Deel 2

Wanneer jy Pulumi vir jou kernaanvaardingstoetse gebruik, kry jy nuwe outomatiseringsvermoëns wat spanproduktiwiteit sal verbeter en jou vertroue in die kwaliteit van jou veranderinge sal gee.

Totale

In hierdie artikel het ons gesien dat deur gebruik te maak van algemene programmeertale, baie sagteware-ontwikkelingstegnieke vir ons beskikbaar word wat nuttig was in die ontwikkeling van ons toepassings. Dit sluit in eenheidstoetsing, integrasietoetsing en hoe hulle saamwerk om uitgebreide looptydtoetse uit te voer. Toetse is maklik om op aanvraag of in jou CI-stelsel uit te voer.

Pulumi - oopbronsagteware, gratis om te gebruik en werk saam met jou gunsteling programmeertale en wolke - probeer dit vandag!

Eerste deel

Bron: will.com

Voeg 'n opmerking