Тэставанне інфраструктуры як код з дапамогай Pulumi. Частка 2

Ўсім прывітанне. Сёння дзелімся з вамі заключнай часткай артыкула "Тэставанне інфраструктуры як код з дапамогай Pulumi", пераклад якой падрыхтаваны спецыяльна для студэнтаў курса "DevOps практыкі і інструменты".

Тэставанне інфраструктуры як код з дапамогай Pulumi. Частка 2

Тэставанне разгортвання

Разгледжаны стыль тэставання - гэта магутны падыход, ён дазваляе нам праводзіць тэставанне белай скрыні для праверкі вантроб працы нашага інфраструктурнага кода. Аднак ён крыху абмяжоўвае тое, што мы можам праверыць. Тэсты выконваюцца на аснове in-memory плана разгортвання, створанага Pulumi перад непасрэдным разгортваннем і таму само разгортванне не пратэставаць. Для такіх выпадкаў у Pulumi ёсць фрэймворк інтэграцыйных тэстаў. І гэтыя два падыходы выдатна працуюць разам!

Фрэймворк інтэграцыйнага тэсціравання Pulumi напісаны на Go, і менавіта з яго дапамогай мы тэстуем большую частку нашага ўнутранага кода. Калі разгледжаны раней падыход модульнага тэсціравання быў больш падобны на тэсціраванне белай скрыні, то інтэграцыйнае тэсціраванне — гэта чорная скрыня. (Ёсць таксама варыянты ўважлівага ўнутранага тэставання.) Гэты фрэймворк быў створаны для таго, каб узяць поўную Pulumi-праграму і выканаць для яе розныя аперацыі жыццёвага цыклу, такія як разгортванне новага стэка з нуля, яго абнаўленне з варыяцыямі і выдаленне, магчыма некалькі разоў. Мы запускаем іх рэгулярна (напрыклад, уначы) і ў якасці стрэс-тэстаў.

(Мы працуем над тым, Каб аналагічныя магчымасці інтэграцыйнага тэсціравання былі ў роднай SDK моў. Вы можаце выкарыстоўваць фрэймворк інтэграцыйнага тэсціравання Go незалежна ад мовы, на якім напісана ваша Pulumi-праграма).

Запусціўшы праграму з дапамогай гэтага фрэймворка вы можаце праверыць наступнае:

  • Код вашага праекту сінтаксічна правільны і працуе без памылак.
  • Налады канфігурацыі стэка і сакрэтаў працуюць і інтэрпрэтуюцца правільна.
  • Ваш праект можа быць паспяхова разгорнуты ў абраным вамі хмарным правайдэры.
  • Ваш праект можа быць паспяхова абноўлены з пачатковага стану да N іншых станаў.
  • Ваш праект можа быць паспяхова знішчаны і выдалены з вашага хмарнага правайдэра.

Як мы хутка ўбачым, гэты фрэймворк можна выкарыстоўваць таксама для выканання runtime-валідацыі.

Просты інтэграцыйны тэст

Каб убачыць гэта ў дзеянні, мы паглядзім на рэпазітар pulumi/examples, так як наша каманда і супольнасць Pulumi, выкарыстоўвае яго для тэсціравання ўласных пул рэквестаў, коммітаў і начных зборак.

Ніжэй прыведзены спрошчаны тэст нашага прыкладу, які робіць прасоўванне S3 bucket і некаторых іншых аб'ектаў:

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

Гэты тэст праходзіць праз базавы жыццёвы цыкл стварэння, змены і знішчэнні стэка для тэчкі aws-js-s3-folder. Ён зойме каля хвіліны, каб паведаміць аб пройдзеным тэсце:

$ go test .
PASS
ok      ... 43.993s

Ёсць шмат параметраў для наладкі паводзін гэтых тэстаў. Поўны спіс опцый гл. у структуры ProgramTestOptions. Напрыклад, вы можаце наладзіць Jaeger endpoint для трасіроўкі (Tracing), пазначыць, што чакаеце падзення тэсту пры негатыўным тэсціраванні (ExpectFailure), прымяніць серыю “правак” да праграмы для паслядоўнага пераходу станаў (EditDirs) і многае іншае. Давайце паглядзім, як выкарыстоўваць іх для праверкі разгортвання прыкладання.

Праверка ўласцівасцей рэсурсаў

Інтэграцыя, пра якую казалі вышэй, гарантуе, што нашая праграма «працуе» — яна не падае. Але што, калі мы жадаем, праверыць уласцівасці атрыманага стэка? Напрыклад, што пэўныя віды рэсурсаў былі (ці не былі) падрыхтаваны і што яны маюць пэўныя атрыбуты.

Параметр ExtraRuntimeValidation для ProgramTestOptions дазваляе нам паглядзець на стан, зафіксаваны Pulumi пасля разгортвання (post-deployment state), каб мы маглі зрабіць дадатковыя праверкі. Сюды ўваходзіць поўны здымак стану выніковага стэка, уключаючы канфігурацыю, экспартаваныя выходныя значэнні, усе рэсурсы і значэнні іх уласцівасцяў, а таксама ўсе залежнасці паміж рэсурсамі.

Каб убачыць базавы прыклад гэтага, давайце праверым, што наша праграма стварае адзін S3 вядро:

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

Цяпер, калі мы запусцім go test, ён не толькі пройдзе праз батарэю тэстаў жыццёвага цыклу, але таксама, пасля паспяховага разгортвання стэка, выканае дадатковую праверку выніковага стану.

Runtime-тэсты

Да гэтага часу ўсе тэсты былі выключна аб паводзінах пры разгортванні і аб мадэлі рэсурсаў Pulumi. Што рабіць, калі вы хочаце праверыць, што ваша падрыхтаваная інфраструктура сапраўды працуе? Напрыклад, што віртуальная машына працуе, S3 bucket змяшчае тое, што мы чакаем, і гэтак далей.

Вы, магчыма, ужо здагадаліся, як гэта зрабіць: опцыя ExtraRuntimeValidation для ProgramTestOptions - Гэта выдатная магчымасць для гэтага. На гэтым этапе вы запускаеце адвольны тэст Go з доступам да поўнага стану рэсурсаў вашай праграмы. Гэты стан уключае ў сябе такую ​​інфармацыю, як IP-адрасы віртуальных машын, URL-адрасы і ўсё, што неабходна для рэальнага ўзаемадзеяння з атрыманымі хмарнымі прыкладаннямі і інфраструктурай.

Напрыклад, наша тэставая праграма экспартуе ўласцівасць webEndpoint bucket'а пад назвай websiteUrl, якое ўяўляе сабой поўны URL-адрас, па якім мы можам атрымаць настроены index document. Хоць мы маглі б пакапацца ў файле стану, каб знайсці bucket і прачытаць гэтую ўласцівасць напрамую, але ў многіх выпадках нашы стэкі экспартуюць карысныя ўласцівасці, такія як гэта, якія нам зручна выкарыстоўваць для праверкі:

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

Як і нашы папярэднія runtime-праверкі, гэтая праверка будзе выконвацца адразу пасля ўзняцця стэка, і ўсё гэта ў адказ на просты выклік go test. І гэта толькі вяршыня айсберга – даступныя ўсе тэставыя магчымасці Go, якія вы можаце напісаць у кодзе.

Бесперапынная інтэграцыя інфраструктуры

Добра мець магчымасць запускаць тэсты на ноўтбуку, калі робіцца шмат змен у інфраструктуры, для іх праверкі перад адпраўкай на раўчу кода. Але мы і многія нашы кліенты тэсціруем інфраструктуру на розных этапах жыццёвага цыкла распрацоўкі:

  • У кожным адкрытым пул рэквест для тэсту перад зліццём.
  • У адказ на кожны коміт, каб пераправерыць, што зліццё было выканана правільна.
  • Перыядычна, напрыклад, ноччу ці штотыдзень для дадатковага тэсціравання.
  • У рамках тэставання прадукцыйнасці ці стрэс-тэставанні, якія звычайна выконваюцца на працягу працяглага перыяду часу і запускаюць тэсты раўналежна і/ці разгортваюць адну і тую ж праграму некалькі разоў.

Для кожнага з іх Pulumi падтрымлівае інтэграцыю з вашай каханай сістэмай бесперапыннай інтэграцыі. Пры бесперапыннай інтэграцыі гэта дае вам такое ж пакрыццё тэстамі для вашай інфраструктуры, як і для прыкладнога праграмнага забеспячэння.

У Pulumi ёсць падтрымка распаўсюджаных CI-сістэм. Вось некаторыя з іх:

Для атрымання больш падрабязнай інфармацыі звернецеся да дакументацыі па бесперапынная пастаўка.

Эфемерныя асяроддзі

Вельмі магутная магчымасць, якая адкрываецца - гэта магчымасць разгортваць эфемерныя асяроддзі выключна для мэт прыёмачнага тэставання. Канцэпцыя праектаў і стэкаў Pulumi распрацавана такім чынам, каб лёгка разгортваць і зносіць цалкам ізаляваныя і незалежныя асяроддзі, усё ў некалькі простых каманд CLI або з дапамогай фрэймворка інтэграцыйнага тэсціравання.

Калі вы карыстаецеся GitHub, то Pulumi прапануе GitHub App, Якое дапаможа вам падлучыць прыёмачнае тэсціраванне да пул рэквестам ўнутры вашага CI-пайплайну. Проста ўсталюеце прыкладанне ў рэпазітар GitHub, а Pulumi у ваш CI і ў пул рэквесты будзе дадавацца інфармацыя аб прэв'ю інфраструктуры, абнаўленнях і выніках тэсціравання:

Тэставанне інфраструктуры як код з дапамогай Pulumi. Частка 2

Пры выкарыстанні Pulumi для вашых асноўных прыёмачных тэстаў, у вас з'явяцца новыя магчымасці аўтаматызацыі, якія палепшаць прадукцыйнасць каманды і нададуць упэўненасць у якасці змен.

Вынік

У гэтым артыкуле мы ўбачылі, што пры выкарыстанні моў праграмавання агульнага прызначэння нам становяцца даступнымі шматлікія метады распрацоўкі праграмнага забеспячэння, якія былі карысныя пры распрацоўцы нашых прыкладанняў. Яны ўключаюць у сябе модульнае тэсціраванне, інтэграцыйнае тэсціраванне, а таксама іх узаемадзеянне для правядзення шырокага runtime-тэставанні. Тэсты лёгка запускаць па патрабаванні ці ў вашай CI-сістэме.

Пулумі - Праграмнае забеспячэнне з адкрытым зыходным кодам, яно бясплатна для выкарыстання і працуе з вашымі любімымі мовамі праграмавання і аблокамі - паспрабуйце яго сёння!

Першая частка

Крыніца: habr.com

Дадаць каментар