ტესტირების ინფრასტრუქტურა, როგორც კოდი Pulumi-ით. Ნაწილი 2

Სალამი ყველას. დღეს გაგიზიარებთ სტატიის ბოლო ნაწილს. "ინფრასტრუქტურის ტესტირება, როგორც კოდი Pulumi-ით", რომლის თარგმანიც სპეციალურად კურსის სტუდენტებისთვის მომზადდა "DevOps პრაქტიკა და ინსტრუმენტები".

განლაგების ტესტირება

ტესტირების ეს სტილი მძლავრი მიდგომაა და საშუალებას გვაძლევს შევასრულოთ თეთრი ყუთის ტესტირება ჩვენი ინფრასტრუქტურის კოდის შიდა მუშაობის შესამოწმებლად. თუმცა, ეს გარკვეულწილად ზღუდავს იმას, რისი ტესტირებაც შეგვიძლია. ტესტები ტარდება მეხსიერებაში განლაგების გეგმის საფუძველზე, რომელიც შექმნილია Pulumi-ს მიერ რეალურ განლაგებამდე და, შესაბამისად, თავად განლაგების ტესტირება შეუძლებელია. ასეთი შემთხვევებისთვის პულუმს აქვს ინტეგრაციის ტესტის ჩარჩო. და ეს ორი მიდგომა მშვენივრად მუშაობს ერთად!

Pulumi ინტეგრაციის ტესტირების ჩარჩო დაწერილია Go-ში, ასე ვამოწმებთ ჩვენი შიდა კოდის უმეტეს ნაწილს. მიუხედავად იმისა, რომ ადრე განხილული ერთეულის ტესტირების მიდგომა უფრო ჰგავს თეთრი ყუთის ტესტირებას, ინტეგრაციის ტესტირება შავი ყუთია. (ასევე არსებობს მკაცრი შიდა ტესტირების ვარიანტები.) ეს ჩარჩო შეიქმნა იმისათვის, რომ მიიღოს სრული Pulumi პროგრამა და განახორციელოს მასზე სიცოცხლის ციკლის სხვადასხვა ოპერაციები, როგორიცაა ახალი სტეკის განლაგება ნულიდან, მისი განახლება ვარიაციებით და წაშლა, შესაძლოა, რამდენჯერმე. . ჩვენ მათ რეგულარულად ვატარებთ (მაგალითად, ღამით) და სტრეს ტესტების სახით.

(ჩვენ ჩვენ მასზე ვმუშაობთ, ასე რომ ინტეგრაციის ტესტირების მსგავსი შესაძლებლობები ხელმისაწვდომია ენების მშობლიურ SDK-ში. შეგიძლიათ გამოიყენოთ Go ინტეგრაციის ტესტირების ჩარჩო, მიუხედავად იმისა, თუ რა ენაზეა დაწერილი თქვენი Pulumi პროგრამა).

ამ ჩარჩოს გამოყენებით პროგრამის გაშვებით შეგიძლიათ შეამოწმოთ შემდეგი:

• თქვენი პროექტის კოდი სინტაქსურად სწორია და მუშაობს შეცდომების გარეშე.
• სტეკის და საიდუმლოების კონფიგურაციის პარამეტრები მუშაობს და სწორად არის ინტერპრეტირებული.
• თქვენი პროექტი შეიძლება წარმატებით განთავსდეს თქვენს მიერ არჩეულ ღრუბლოვან პროვაიდერში.
• თქვენი პროექტი შეიძლება წარმატებით განახლდეს საწყისი მდგომარეობიდან N სხვა შტატში.
• თქვენი პროექტი შეიძლება წარმატებით განადგურდეს და წაიშალოს თქვენი ღრუბლოვანი პროვაიდერიდან.

როგორც მალე დავინახავთ, ეს ჩარჩო ასევე შეიძლება გამოყენებულ იქნას გაშვების დროის ვალიდაციის შესასრულებლად.

მარტივი ინტეგრაციის ტესტი

ამის გასაგებად, ჩვენ გადავხედავთ საცავს pulumi/examples, რადგან ჩვენი გუნდი და პულუმის საზოგადოება იყენებს მას ჩვენი საკუთარი მოთხოვნის, ვალდებულებების და ღამის აშენებების შესამოწმებლად.

ქვემოთ მოცემულია ჩვენი გამარტივებული ტესტი მაგალითი, რომელიც უზრუნველყოფს 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-ის ბოლო წერტილი კვალზე (Tracing), მიუთითეთ, რომ თქვენ ელოდებით, რომ ტესტი ჩავარდება, თუ ტესტირება უარყოფითია (ExpectFailure), გამოიყენეთ პროგრამაში "რედაქტირების" სერია მდგომარეობების თანმიმდევრული გადასვლისთვის (EditDirs) და უფრო მეტი. ვნახოთ, როგორ გამოვიყენოთ ისინი თქვენი აპლიკაციის განლაგების შესამოწმებლად.

რესურსის თვისებების შემოწმება

ზემოთ განხილული ინტეგრაცია უზრუნველყოფს ჩვენი პროგრამის "მუშაობას" - ის არ იშლება. მაგრამ რა მოხდება, თუ გვსურს შევამოწმოთ მიღებული სტეკის თვისებები? მაგალითად, რომ გარკვეული ტიპის რესურსები უზრუნველყოფილია (ან არა) და რომ მათ აქვთ გარკვეული ატრიბუტები.

პარამეტრის ExtraRuntimeValidation ამისთვის ProgramTestOptions საშუალებას გვაძლევს გადავხედოთ პულუმის მიერ დაფიქსირებულ განლაგების შემდგომ მდგომარეობას, რათა შევძლოთ დამატებითი შემოწმებები. ეს მოიცავს შედეგად მიღებული სტეკის მდგომარეობის სრულ სურათს, მათ შორის კონფიგურაციას, ექსპორტირებულ გამომავალ მნიშვნელობებს, ყველა რესურსს და მათ თვისებებს და რესურსებს შორის დამოკიდებულებებს.

ამის საბაზისო მაგალითის სანახავად, მოდით შევამოწმოთ, რომ ჩვენი პროგრამა ქმნის ერთს S3 Bucket:

  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-ს, ის არა მხოლოდ გაივლის სასიცოცხლო ციკლის ტესტების ბატარეას, არამედ, სტეკის წარმატებით განლაგების შემდეგ, ის შეასრულებს დამატებით შემოწმებას მიღებულ მდგომარეობაზე.

გაშვების ტესტები

ჯერჯერობით, ყველა ტესტი ეხებოდა განლაგების ქცევას და პულუმის რესურსის მოდელს. რა მოხდება, თუ გსურთ გადაამოწმოთ, რომ თქვენი მოწოდებული ინფრასტრუქტურა რეალურად მუშაობს? მაგალითად, რომ ვირტუალური მანქანა მუშაობს, S3 bucket შეიცავს იმას, რასაც ველით და ა.შ.

თქვენ შეიძლება უკვე მიხვდით, როგორ გააკეთოთ ეს: ვარიანტი ExtraRuntimeValidation ამისთვის ProgramTestOptions -ეს ამის დიდი შესაძლებლობაა. ამ ეტაპზე, თქვენ აწარმოებთ პერსონალურ Go ტესტს თქვენი პროგრამის რესურსების სრულ მდგომარეობაზე წვდომით. ეს მდგომარეობა მოიცავს ინფორმაციას, როგორიცაა ვირტუალური აპარატის IP მისამართები, URL-ები და ყველაფერი, რაც საჭიროა რეალურად ურთიერთქმედებისთვის მიღებულ ღრუბლოვან აპლიკაციებთან და ინფრასტრუქტურასთან.

მაგალითად, ჩვენი სატესტო პროგრამა ახდენს ქონების ექსპორტს webEndpoint ვედრო დარეკა 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!")
        },
    })

ისევე როგორც ჩვენი წინა გაშვების შემოწმებები, ეს შემოწმება შესრულდება სტეკის აწევისთანავე, ეს ყველაფერი მარტივი ზარის საპასუხოდ. go test. და ეს მხოლოდ აისბერგის მწვერვალია - ხელმისაწვდომია Go ტესტის ყველა ფუნქცია, რომელიც შეგიძლიათ კოდით დაწეროთ.

უწყვეტი ინფრასტრუქტურის ინტეგრაცია

კარგია, რომ შეგეძლოს ლეპტოპზე ტესტების გაშვება, როდესაც მრავალი ინფრასტრუქტურული ცვლილება ხდება მათი შესამოწმებლად, კოდის განსახილველად გაგზავნამდე. მაგრამ ჩვენ და ბევრი ჩვენი კლიენტი ვამოწმებთ ინფრასტრუქტურას განვითარების სასიცოცხლო ციკლის სხვადასხვა ეტაპზე:

• შერწყმამდე ტესტირების მოთხოვნაზე გაყვანის ყველა ღია მოთხოვნაში.
• ყოველი ჩადენის საპასუხოდ, ორჯერ შეამოწმეთ, რომ შერწყმა სწორად შესრულდა.
• პერიოდულად, მაგალითად ღამით ან ყოველკვირეულად დამატებითი ტესტირებისთვის.
• როგორც შესრულების ან სტრეს ტესტირების ნაწილი, რომელიც, როგორც წესი, გადის ხანგრძლივ პერიოდში და ატარებს ტესტებს პარალელურად და/ან ახორციელებს ერთსა და იმავე პროგრამას რამდენჯერმე.

თითოეული მათგანისთვის, პულუმი მხარს უჭერს ინტეგრაციას თქვენს საყვარელ უწყვეტი ინტეგრაციის სისტემასთან. უწყვეტი ინტეგრაციით, ეს გაძლევთ იგივე ტესტის დაფარვას თქვენი ინფრასტრუქტურისთვის, როგორც თქვენი აპლიკაციის პროგრამული უზრუნველყოფისთვის.

პულუმს აქვს საერთო CI სისტემების მხარდაჭერა. აქ არის რამდენიმე მათგანი:

• AWS კოდის სერვისები
• Azure DevOps
• წრეCI
• GitHub მოქმედებები
• GitLab CI
• Google Cloud Build
• Travis

უფრო დეტალური ინფორმაციისთვის, გთხოვთ, ეწვიოთ დოკუმენტაციას უწყვეტი მიწოდების.

ეფემერული გარემო

ძალიან ძლიერი შესაძლებლობა, რომელიც იხსნება, არის ეფემერული გარემოს განლაგების შესაძლებლობა მხოლოდ მისაღები ტესტირების მიზნებისთვის. Შინაარსი პროექტები და სტეკები Pulumi შექმნილია იმისათვის, რომ ადვილად განათავსოს და გაანადგუროს სრულიად იზოლირებული და დამოუკიდებელი გარემო, ეს ყველაფერი რამდენიმე მარტივი CLI ბრძანებით ან ინტეგრაციის ტესტირების ჩარჩოს გამოყენებით.

თუ იყენებთ GitHub-ს, მაშინ Pulumi გთავაზობთ GitHub აპლიკაცია, რომელიც დაგეხმარებათ დააკავშიროთ მიღების ტესტირება თქვენი CI მილსადენში მოთხოვნების გასაგზავნად. უბრალოდ დააინსტალირეთ აპლიკაცია GitHub-ის საცავში და Pulumi დაამატებს ინფორმაციას ინფრასტრუქტურის გადახედვის, განახლებების და ტესტირების შედეგების შესახებ თქვენს CI და აუზის მოთხოვნებს:

როდესაც იყენებთ Pulumi-ს თქვენი ძირითადი მისაღები ტესტებისთვის, თქვენ მიიღებთ ავტომატიზაციის ახალ შესაძლებლობებს, რაც გააუმჯობესებს გუნდის პროდუქტიულობას და მოგცემთ ნდობას თქვენი ცვლილებების ხარისხში.

სულ

ამ სტატიაში ჩვენ დავინახეთ, რომ ზოგადი დანიშნულების პროგრამირების ენების გამოყენებით, ჩვენთვის ხელმისაწვდომი გახდა პროგრამული უზრუნველყოფის განვითარების მრავალი ტექნიკა, რომლებიც სასარგებლო იყო ჩვენი აპლიკაციების შემუშავებაში. ისინი მოიცავს ერთეულის ტესტირებას, ინტეგრაციის ტესტირებას და თუ როგორ მუშაობენ ისინი ერთად ვრცელი გაშვების ტესტირების შესასრულებლად. ტესტები მარტივია მოთხოვნით ან თქვენს CI სისტემაში.

პულუმი - ღია კოდის პროგრამული უზრუნველყოფა, უფასო გამოსაყენებლად და მუშაობს თქვენს საყვარელ პროგრამირების ენებთან და ღრუბლებთან - სცადე დღეს!

→ პირველი ნაწილი

წყარო: www.habr.com