Infrastruktuurin testaus koodina Pulumin kanssa. Osa 2

Hei kaikki. Tänään jaamme kanssasi artikkelin viimeisen osan. "Infrastruktuurin testaus koodina Pulumin kanssa", jonka käännös on tehty erityisesti kurssin opiskelijoille "DevOps-käytännöt ja -työkalut".

Infrastruktuurin testaus koodina Pulumin kanssa. Osa 2

Käyttöönoton testaus

Tämä testaustyyli on tehokas lähestymistapa ja antaa meille mahdollisuuden suorittaa valkoisen laatikon testausta infrastruktuurikoodimme sisäisen toiminnan testaamiseksi. Se kuitenkin rajoittaa jonkin verran sitä, mitä voimme testata. Testit perustuvat Pulumin ennen varsinaista käyttöönottoa luomaan muistin sisäiseen käyttöönottosuunnitelmaan, joten itse käyttöönottoa ei voida testata. Tällaisia ​​tapauksia varten Pulumilla on integraatiotestikehys. Ja nämä kaksi lähestymistapaa toimivat loistavasti yhdessä!

Pulumi-integraatiotestauskehys on kirjoitettu Go-kielellä, jolla testaamme suurimman osan sisäisestä koodistamme. Aiemmin käsitelty yksikkötestaustapa oli enemmän kuin valkoisen laatikon testausta, mutta integraatiotestaus on musta laatikko. (On myös vaihtoehtoja tiukkaan sisäiseen testaukseen.) Tämä kehys luotiin ottamaan täydellinen Pulumi-ohjelma ja suorittamaan sille erilaisia ​​elinkaaren toimenpiteitä, kuten uuden pinon käyttöönotto alusta alkaen, sen päivittäminen muunnelmilla ja poistaminen, mahdollisesti useita kertoja . Teemme niitä säännöllisesti (esimerkiksi yöllä) ja stressitesteinä.

(Me työskentelemme sen parissa, jotta samanlaiset integroinnin testausominaisuudet ovat saatavilla kielten alkuperäisessä SDK:ssa. Voit käyttää Go-integraatiotestauskehystä riippumatta siitä, millä kielellä Pulumi-ohjelmasi on kirjoitettu).

Suorittamalla ohjelman tämän kehyksen avulla voit tarkistaa seuraavat asiat:

  • Projektisi koodi on syntaktisesti oikea ja toimii ilman virheitä.
  • Pinon ja salaisuuksien kokoonpanoasetukset toimivat ja ne tulkitaan oikein.
  • Projektisi voidaan ottaa onnistuneesti käyttöön valitsemassasi pilvipalveluntarjoajassa.
  • Projektisi voidaan päivittää onnistuneesti alkuperäisestä tilasta N muuhun tilaan.
  • Projektisi voidaan tuhota ja poistaa pilvipalveluntarjoajaltasi onnistuneesti.

Kuten pian näemme, tätä kehystä voidaan käyttää myös suorituksenaikaisen validoinnin suorittamiseen.

Yksinkertainen integraatiotesti

Nähdäksemme tämän toiminnassa tarkastelemme arkistoa pulumi/examples, sillä tiimimme ja Pulumi-yhteisö testaavat sen avulla omia vetopyyntöjämme, sitoumuksiamme ja öisiä koontiversioita.

Alla on yksinkertaistettu testimme esimerkki, joka tarjoaa S3-ämpäri ja joitain muita objekteja:

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

Tämä testi käy läpi kansion pinon luomisen, muokkaamisen ja tuhoamisen peruselinkaarin aws-js-s3-folder. Läpäisevän testin ilmoittaminen kestää noin minuutin:

$ go test .
PASS
ok      ... 43.993s

On monia vaihtoehtoja näiden testien käyttäytymisen mukauttamiseen. Katso täydellinen luettelo vaihtoehdoista. rakenteessa ProgramTestOptions. Voit esimerkiksi määrittää Jaeger-päätepisteen jäljittämään (Tracing), osoita, että odotat testin epäonnistuvan, jos testi on negatiivinen (ExpectFailure), käytä sarjan "muokkauksia" ohjelmaan tilojen peräkkäistä siirtymistä varten (EditDirs) ja paljon enemmän. Katsotaanpa, kuinka voit käyttää niitä sovelluksesi käyttöönoton testaamiseen.

Resurssien ominaisuuksien tarkistus

Yllä käsitelty integrointi varmistaa, että ohjelmamme "toimii" – se ei kaatu. Mutta entä jos haluamme tarkistaa tuloksena olevan pinon ominaisuudet? Esimerkiksi, että tietyntyyppisiä resursseja on (tai ei ole) varattu ja että niillä on tietyt attribuutit.

Parametri ExtraRuntimeValidation varten ProgramTestOptions antaa meille mahdollisuuden tarkastella Pulumin tallentamaa käyttöönoton jälkeistä tilaa, jotta voimme tehdä lisätarkastuksia. Tämä sisältää täydellisen tilannekuvan tuloksena olevan pinon tilasta, mukaan lukien kokoonpanon, viedyt tulostearvot, kaikki resurssit ja niiden ominaisuusarvot sekä kaikki resurssien väliset riippuvuudet.

Nähdäksesi perusesimerkin tästä, tarkistamme, että ohjelmamme luo sellaisen S3 Kauha:

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

Nyt, kun suoritamme go-testin, se ei vain käy läpi useita elinkaaritestejä, vaan myös sen jälkeen, kun pino on otettu käyttöön, se suorittaa lisätarkistuksen tuloksena olevalle tilalle.

Ajonaikaiset testit

Tähän mennessä kaikki testit ovat koskeneet vain käyttöönottokäyttäytymistä ja Pulumi-resurssimallia. Entä jos haluat varmistaa, että tarjoamasi infrastruktuuri todella toimii? Esimerkiksi, että virtuaalikone on käynnissä, S3-ämpäri sisältää sen, mitä odotamme, ja niin edelleen.

Olet ehkä jo arvannut kuinka tämä tehdään: vaihtoehto ExtraRuntimeValidation varten ProgramTestOptions – Tämä on loistava tilaisuus tähän. Tässä vaiheessa suoritat mukautetun Go-testin, jolla pääset käyttämään ohjelmasi resurssien koko tilaa. Tämä tila sisältää tietoja, kuten virtuaalikoneen IP-osoitteita, URL-osoitteita ja kaiken, mitä tarvitaan todelliseen vuorovaikutukseen tuloksena olevien pilvisovellusten ja -infrastruktuurin kanssa.

Esimerkiksi testiohjelmamme vie kiinteistön webEndpoint ämpäri kutsuttiin websiteUrl, joka on täydellinen URL-osoite, josta saamme asetukset index document. Vaikka voisimme kaivaa valtion tiedostoon löytääksemme bucket ja lue tämä ominaisuus suoraan, mutta monissa tapauksissa pinomme vievät hyödyllisiä ominaisuuksia, kuten tämä, joita meidän mielestämme on kätevä käyttää tarkastamiseen:

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

Kuten aiemmat ajonaikaiset tarkistukset, tämä tarkistus suoritetaan heti pinon nostamisen jälkeen, kaikki vastauksena yksinkertaiseen kutsuun go test. Ja se on vain jäävuoren huippu – jokainen Go-testiominaisuus, jonka voit kirjoittaa koodiin, on käytettävissä.

Jatkuva infrastruktuurin integrointi

On hyvä, että testejä voidaan suorittaa kannettavalla tietokoneella, kun infrastruktuuriin tehdään paljon muutoksia, jotta niitä testataan ennen kuin ne lähetetään koodin tarkasteluun. Mutta me ja monet asiakkaamme testaamme infrastruktuuria kehityksen elinkaaren eri vaiheissa:

  • Jokaisessa avoimessa testauspyynnössä ennen yhdistämistä.
  • Vastauksena jokaiseen sitoumukseen tarkista, että yhdistäminen on tehty oikein.
  • Määräajoin, kuten yöllä tai viikoittain lisätestejä varten.
  • Osana suorituskyky- tai stressitestausta, joka tyypillisesti kestää pitkän ajanjakson ja suorittaa testejä rinnakkain ja/tai ottaa saman ohjelman käyttöön useita kertoja.

Jokaisessa näistä Pulumi tukee integrointia suosikki jatkuvaan integrointijärjestelmääsi. Jatkuvan integroinnin ansiosta saat infrastruktuurillesi saman testikattavuuden kuin sovellusohjelmistollesi.

Pulumilla on tuki yleisille CI-järjestelmille. Tässä muutama niistä:

Katso tarkemmat tiedot asiakirjoista Jatkuva Toimitus.

Efemeraaliset ympäristöt

Erittäin tehokas mahdollisuus, joka avautuu, on mahdollisuus ottaa käyttöön lyhytaikaisia ​​ympäristöjä vain hyväksymistestausta varten. Konsepti projekteja ja pinoja Pulumi on suunniteltu ottamaan helposti käyttöön ja purkamaan täysin eristettyjä ja itsenäisiä ympäristöjä, kaikki muutamalla yksinkertaisella CLI-komennolla tai integraatiotestauskehyksen avulla.

Jos käytät GitHubia, Pulumi tarjoaa GitHub-sovellus, joka auttaa sinua yhdistämään hyväksymistestauksen hakemaan pyyntöjä CI-putkistosi sisällä. Asenna vain sovellus GitHub-tietovarastoon, ja Pulumi lisää tietoa infrastruktuurin esikatseluista, päivityksistä ja testaustuloksista CI- ja poolipyyntöihisi:

Infrastruktuurin testaus koodina Pulumin kanssa. Osa 2

Kun käytät Pulumia ydinhyväksyntätesteissäsi, saat uusia automaatioominaisuuksia, jotka parantavat tiimin tuottavuutta ja antavat sinulle luottamusta muutostesi laatuun.

Koko

Tässä artikkelissa olemme nähneet, että yleiskäyttöisiä ohjelmointikieliä käyttämällä saamme saatavillemme monia ohjelmistokehitystekniikoita, joista on ollut hyötyä sovelluksiemme kehittämisessä. Ne sisältävät yksikkötestauksen, integraatiotestauksen ja sen, kuinka ne toimivat yhdessä laajan ajonaikaisen testauksen suorittamiseksi. Testit on helppo suorittaa pyynnöstä tai CI-järjestelmässäsi.

Pulumi - avoimen lähdekoodin ohjelmisto, vapaasti käytettävä ja toimii suosikkiohjelmointikielesi ja pilvipalveluiden kanssa - kokeile tänään!

Ensimmäinen osa

Lähde: will.com

Lisää kommentti