Testiranje infrastrukture kot kode s Pulumijem. 2. del

Pozdravljeni vsi skupaj. Danes z vami delimo zadnji del članka. "Testiranje infrastrukture kot kode s Pulumijem", katerega prevod je bil pripravljen posebej za tečajnike "Prakse in orodja DevOps".

Testiranje infrastrukture kot kode s Pulumijem. 2. del

Testiranje uvajanja

Ta način testiranja je zmogljiv pristop in nam omogoča, da izvedemo testiranje bele škatle, da preizkusimo notranje delovanje naše infrastrukturne kode. Vendar pa nekoliko omejuje, kaj lahko testiramo. Preizkusi se izvajajo na podlagi načrta uvedbe v pomnilniku, ki ga je ustvaril Pulumi pred dejansko uvedbo, zato same uvedbe ni mogoče preizkusiti. Za takšne primere ima Pulumi ogrodje za integracijski test. In ta dva pristopa odlično delujeta skupaj!

Ogrodje za testiranje integracije Pulumi je napisano v Go, tako testiramo večino naše interne kode. Medtem ko je bil prej obravnavani pristop testiranja enot bolj podoben testiranju bele škatle, je testiranje integracije črna škatla. (Obstajajo tudi možnosti za strogo interno testiranje.) To ogrodje je bilo ustvarjeno za prevzem celotnega programa Pulumi in izvajanje različnih operacij življenjskega cikla na njem, kot je uvajanje novega sklada iz nič, njegovo posodabljanje z različicami in brisanje, po možnosti večkrat . Izvajamo jih redno (na primer ponoči) in kot stresne teste.

(Mi delamo na tem, tako da so podobne zmožnosti testiranja integracije na voljo v izvirnem SDK jezikov. Ogrodje za testiranje integracije Go lahko uporabite ne glede na jezik, v katerem je napisan vaš program Pulumi).

Z zagonom programa z uporabo tega okvira lahko preverite naslednje:

  • Koda vašega projekta je sintaktično pravilna in deluje brez napak.
  • Konfiguracijske nastavitve sklada in skrivnosti delujejo in se pravilno razlagajo.
  • Vaš projekt je mogoče uspešno namestiti v ponudniku oblaka po vaši izbiri.
  • Vaš projekt je mogoče uspešno nadgraditi iz začetnega stanja v N drugih stanj.
  • Vaš projekt je mogoče uspešno uničiti in odstraniti od vašega ponudnika oblaka.

Kot bomo kmalu videli, je to ogrodje mogoče uporabiti tudi za izvajanje validacije med izvajanjem.

Preprost integracijski test

Da bi videli to v akciji, si bomo ogledali skladišče pulumi/examples, saj ga naša ekipa in skupnost Pulumi uporabljata za preizkušanje lastnih zahtev za vleko, zaveze in nočne gradnje.

Spodaj je poenostavljen naš test primer, ki ponuja vedro S3 in nekatere druge predmete:

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

Ta preizkus gre skozi osnovni življenjski cikel ustvarjanja, spreminjanja in uničenja sklada za mapo aws-js-s3-folder. Poročilo o opravljenem testu bo trajalo približno minuto:

$ go test .
PASS
ok      ... 43.993s

Obstaja veliko možnosti za prilagajanje delovanja teh testov. Oglejte si celoten seznam možnosti. v strukturi ProgramTestOptions. Končno točko Jaeger lahko na primer konfigurirate za sledenje (Tracing), pomeni, da pričakujete, da bo test neuspešen, če je test negativen (ExpectFailure), uporabite niz "urejanja" programa za zaporedni prehod stanj (EditDirs) in veliko več. Poglejmo, kako jih uporabiti za preizkušanje uvajanja vaše aplikacije.

Preverjanje lastnosti vira

Zgoraj obravnavana integracija zagotavlja, da naš program "deluje" - ne zruši se. Kaj pa, če želimo preveriti lastnosti nastalega sklada? Na primer, da so (ali niso) omogočene določene vrste virov in da imajo določene atribute.

Parameter ExtraRuntimeValidation za ProgramTestOptions nam omogoča vpogled v stanje po uvedbi, ki ga je zabeležil Pulumi, da lahko opravimo dodatna preverjanja. To vključuje celoten posnetek stanja nastalega sklada, vključno s konfiguracijo, izvoženimi izhodnimi vrednostmi, vsemi viri in njihovimi vrednostmi lastnosti ter vsemi odvisnostmi med viri.

Če si želite ogledati osnovni primer tega, preverimo, ali ga naš program ustvari S3 žlica:

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

Zdaj, ko zaženemo go test, ne bo šel samo skozi niz testov življenjskega cikla, ampak bo po uspešni umestitvi sklada izvedel tudi dodatno preverjanje nastalega stanja.

Preizkusi izvajanja

Doslej so bili vsi testi namenjeni izključno vedenju pri uvajanju in modelu virov Pulumi. Kaj pa, če želite preveriti, ali vaša predvidena infrastruktura dejansko deluje? Na primer, da virtualni stroj deluje, vedro S3 vsebuje tisto, kar pričakujemo, in tako naprej.

Morda ste že uganili, kako to storiti: možnost ExtraRuntimeValidation za ProgramTestOptions - to je odlična priložnost za to. Na tej točki zaženete preizkus Go po meri z dostopom do celotnega stanja virov vašega programa. To stanje vključuje informacije, kot so naslovi IP navideznega stroja, URL-ji in vse, kar je potrebno za dejansko interakcijo z nastalimi aplikacijami in infrastrukturo v oblaku.

Na primer, naš testni program izvozi lastnost webEndpoint klicano vedro websiteUrl, ki je celoten URL, kjer lahko dobimo konfigurirano index document. Čeprav bi lahko brskali po državni datoteki, da bi našli bucket in neposredno prebere to lastnost, vendar v mnogih primerih naši skladi izvozijo uporabne lastnosti, kot je ta, ki se nam zdijo primerne za uporabo za preverjanje:

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

Tako kot naša prejšnja izvajalna preverjanja bo tudi to preverjanje izvedeno takoj po dvigu sklada, vse kot odgovor na preprost klic go test. In to je le vrh ledene gore – na voljo je vsaka preskusna funkcija Go, ki jo lahko zapišete v kodo.

Neprekinjena integracija infrastrukture

Dobro je, da lahko izvajate teste na prenosnem računalniku, ko se izvede veliko sprememb infrastrukture, da jih preizkusite, preden jih pošljete v pregled kode. Toda mi in številne naše stranke testiramo infrastrukturo na različnih stopnjah življenjskega cikla razvoja:

  • V vsaki odprti vlečni zahtevi za testiranje pred združevanjem.
  • Kot odgovor na vsako objavo, da dvakrat preverite, ali je bila združitev izvedena pravilno.
  • Občasno, na primer ponoči ali tedensko za dodatno testiranje.
  • Kot del testiranja zmogljivosti ali stresnega testiranja, ki se običajno izvaja v daljšem časovnem obdobju in vzporedno izvaja teste in/ali večkrat uvaja isti program.

Za vsako od teh Pulumi podpira integracijo z vašim najljubšim sistemom neprekinjene integracije. Z neprekinjeno integracijo vam to zagotavlja enako testno pokritost za vašo infrastrukturo kot za vašo aplikacijsko programsko opremo.

Pulumi ima podporo za običajne sisteme CI. Tukaj je nekaj izmed njih:

Za podrobnejše informacije si oglejte dokumentacijo za Nenehna dostava.

Efemerna okolja

Zelo močna priložnost, ki se odpre, je zmožnost uvajanja efemernih okolij izključno za namene testiranja sprejemljivosti. Koncept projekti in skladi Pulumi je zasnovan za preprosto uvajanje in rušenje popolnoma izoliranih in neodvisnih okolij, vse v nekaj preprostih ukazih CLI ali z uporabo okvira za testiranje integracije.

Če uporabljate GitHub, potem ponuja Pulumi Aplikacija GitHub, ki vam bo pomagal povezati testiranje sprejemljivosti z zahtevami za vleko v vašem cevovodu CI. Preprosto namestite aplikacijo v repozitorij GitHub in Pulumi bo vašim zahtevam CI in bazena dodal informacije o predogledih infrastrukture, posodobitvah in rezultatih testiranja:

Testiranje infrastrukture kot kode s Pulumijem. 2. del

Ko boste Pulumi uporabljali za svoje osnovne teste sprejemljivosti, boste pridobili nove zmožnosti avtomatizacije, ki bodo izboljšale produktivnost ekipe in vam dale zaupanje v kakovost vaših sprememb.

Skupaj

V tem članku smo videli, da nam z uporabo splošnih programskih jezikov postanejo na voljo številne tehnike razvoja programske opreme, ki so bile uporabne pri razvoju naših aplikacij. Vključujejo testiranje enot, testiranje integracije in kako sodelujejo pri izvajanju obsežnega testiranja med izvajanjem. Teste je enostavno izvesti na zahtevo ali v vašem sistemu CI.

Pulumi - odprtokodna programska oprema, brezplačna za uporabo in deluje z vašimi najljubšimi programskimi jeziki in oblaki - poskusite danes!

Prvi del

Vir: www.habr.com

Dodaj komentar