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

შუადღე მშვიდობისა მეგობრებო. კურსით ახალი ნაკადის დაწყების მოლოდინში "DevOps პრაქტიკა და ინსტრუმენტები" ჩვენ გაგიზიარებთ ახალ თარგმანს. წადი.

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

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

რატომ შეამოწმეთ ინფრასტრუქტურა?

სანამ დეტალებს შევეხებით, ღირს კითხვა: "რატომ ატესტოთ ინფრასტრუქტურა საერთოდ?" ამის მრავალი მიზეზი არსებობს და აქ არის რამდენიმე მათგანი:

• ინდივიდუალური ფუნქციების ან თქვენი პროგრამის ლოგიკის ფრაგმენტების ტესტირება
• ამოწმებს ინფრასტრუქტურის სასურველ მდგომარეობას გარკვეული შეზღუდვებისგან.
• გავრცელებული შეცდომების გამოვლენა, როგორიცაა შენახვის თაიგულის დაშიფვრის ნაკლებობა ან დაუცველი, ღია წვდომა ინტერნეტიდან ვირტუალურ მანქანებზე.
• ინფრასტრუქტურის უზრუნველყოფის განხორციელების შემოწმება.
• თქვენი „დაპროგრამებული“ ინფრასტრუქტურის შიგნით გაშვებული აპლიკაციის ლოგიკის გაშვების ტესტის შესრულება, რათა შეამოწმოს ფუნქციონირება უზრუნველყოფის შემდეგ.
• როგორც ვხედავთ, ინფრასტრუქტურის ტესტირების ვარიანტების ფართო სპექტრია. Polumi-ს აქვს ამ სპექტრის ყველა წერტილში ტესტირების მექანიზმები. დავიწყოთ და ვნახოთ, როგორ მუშაობს.

ერთეულის ტესტირება

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

(ამ სტატიაში, მიუხედავად იმისა, რომ მრავალენოვანი და მრავალღრუბელია, ჩვენ ვიყენებთ JavaScript-ს და Mocha-ს და ფოკუსირებას ვაკეთებთ AWS-ზე. შეგიძლიათ გამოიყენოთ Python unittest, გადადით ტესტის ჩარჩოში, ან ნებისმიერი სხვა ტესტის ჩარჩო, რომელიც მოგწონთ. და, რა თქმა უნდა, პულუმი მშვენივრად მუშაობს Azure-თან, Google Cloud-თან, Kubernetes-თან.)

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

• შემთხვევებს აქვთ ტეგი Name.
• ინსტანციებმა არ უნდა გამოიყენონ შიდა სკრიპტი userData - უნდა გამოვიყენოთ AMI (სურათი).
• არ უნდა იყოს SSH დაუცველი ინტერნეტში.

ეს მაგალითი ეფუძნება ჩემი მაგალითი aws-js-webserver:

index.js:

"use strict";
 
let aws = require("@pulumi/aws");
 
let group = new aws.ec2.SecurityGroup("web-secgrp", {
    ingress: [
        { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
        { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
    ],
});
 
let userData =
`#!/bin/bash
echo "Hello, World!" > index.html
nohup python -m SimpleHTTPServer 80 &`;
 
let server = new aws.ec2.Instance("web-server-www", {
    instanceType: "t2.micro",
    securityGroups: [ group.name ], // reference the group object above
    ami: "ami-c55673a0"             // AMI for us-east-2 (Ohio),
    userData: userData              // start a simple web server
});
 
exports.group = group;
exports.server = server;
exports.publicIp = server.publicIp;
exports.publicHostName = server.publicDns;

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

წერითი ტესტები

ჩვენი ტესტების ზოგადი სტრუქტურა ჰგავს ჩვეულებრივ მოკას ტესტებს:

ec2tests.js

test.js:
let assert = require("assert");
let mocha = require("mocha");
let pulumi = require("@pulumi/pulumi");
let infra = require("./index");
 
describe("Infrastructure", function() {
    let server = infra.server;
    describe("#server", function() {
        // TODO(check 1): Должен быть тэг Name.
        // TODO(check 2): Не должно быть inline-скрипта userData.
    });
    let group = infra.group;
    describe("#group", function() {
        // TODO(check 3): Не должно быть SSH, открытого в Интернет.
    });
});

ახლა მოდით დავწეროთ ჩვენი პირველი ტესტი: დარწმუნდით, რომ ინსტანციებს აქვთ ტეგი Name. ამის შესამოწმებლად ჩვენ უბრალოდ ვიღებთ EC2 ინსტანციის ობიექტს და ვამოწმებთ შესაბამის თვისებას tags:

 // check 1: Должен быть тэг Name.
        it("must have a name tag", function(done) {
            pulumi.all([server.urn, server.tags]).apply(([urn, tags]) => {
                if (!tags || !tags["Name"]) {
                    done(new Error(`Missing a name tag on server ${urn}`));
                } else {
                    done();
                }
            });
        });

როგორც ჩანს, ჩვეულებრივი ტესტია, მაგრამ რამდენიმე მახასიათებლით, რომელიც აღსანიშნავია:

• იმის გამო, რომ ჩვენ ვკითხულობთ რესურსის მდგომარეობას განთავსებამდე, ჩვენი ტესტები ყოველთვის ტარდება „გეგმის“ (ან „გადახედვის“) რეჟიმში. ამრიგად, არსებობს მრავალი თვისება, რომელთა მნიშვნელობები უბრალოდ არ იქნება მოძიებული ან არ იქნება განსაზღვრული. ეს მოიცავს ყველა გამომავალ თვისებას, რომელიც გამოითვლება თქვენი ღრუბლოვანი პროვაიდერის მიერ. ეს ნორმალურია ჩვენი ტესტებისთვის - ჩვენ ვამოწმებთ მხოლოდ შეყვანის მონაცემებს. ამ საკითხს მოგვიანებით დავუბრუნდებით, როდესაც საქმე ეხება ინტეგრაციის ტესტებს.
• ვინაიდან პულუმის რესურსის ყველა თვისება გამომავალია და ბევრი მათგანი ასინქრონულად ფასდება, ჩვენ უნდა გამოვიყენოთ განაცხადის მეთოდი მნიშვნელობებზე წვდომისთვის. ეს ძალიან ჰგავს დაპირებებს და ფუნქციონირებას then .
• ვინაიდან ჩვენ ვიყენებთ რამდენიმე თვისებას, რათა გამოვიყენოთ რესურსის URN შეცდომის შეტყობინებაში, ჩვენ უნდა გამოვიყენოთ ფუნქცია pulumi.allმათი შერწყმა.
• დაბოლოს, რადგან ეს მნიშვნელობები გამოითვლება ასინქრონულად, ჩვენ უნდა გამოვიყენოთ Mocha-ს ჩაშენებული ასინქრონული გამოძახების ფუნქცია. done ან დაპირების დაბრუნება.

მას შემდეგ რაც ყველაფერს დავაყენებთ, ჩვენ გვექნება წვდომა შეყვანებზე, როგორც მარტივი JavaScript მნიშვნელობებზე. საკუთრება tags არის რუკა (ასოციაციური მასივი), ამიტომ ჩვენ უბრალოდ დავრწმუნდებით, რომ ის (1) არ არის მცდარი და (2) არის გასაღები Name. ეს ძალიან მარტივია და ახლა ჩვენ შეგვიძლია გამოვცადოთ ყველაფერი!

ახლა დავწეროთ ჩვენი მეორე შემოწმება. ეს კიდევ უფრო მარტივია:

 // check 2: Не должно быть inline-скрипта userData.
        it("must not use userData (use an AMI instead)", function(done) {
            pulumi.all([server.urn, server.userData]).apply(([urn, userData]) => {
                if (userData) {
                    done(new Error(`Illegal use of userData on server ${urn}`));
                } else {
                    done();
                }
            });
        });

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

    // check 3: Не должно быть SSH, открытого в Интернет.
        it("must not open port 22 (SSH) to the Internet", function(done) {
            pulumi.all([ group.urn, group.ingress ]).apply(([ urn, ingress ]) => {
                if (ingress.find(rule =>
                        rule.fromPort == 22 && rule.cidrBlocks.find(block =>
                            block === "0.0.0.0/0"))) {
                    done(new Error(`Illegal SSH port 22 open to the Internet (CIDR 0.0.0.0/0) on group ${urn}`));
                } else {
                    done();
                }
            });
        });

Სულ ეს არის. ახლა მოდით ჩავატაროთ ტესტები!

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

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

ამ პრობლემის გადასაჭრელად, ჩვენ უბრალოდ უნდა დავაკონკრეტოთ შემდეგი:

• პროექტის სახელი, რომელიც შეიცავს გარემოს ცვლადში PULUMI_NODEJS_PROJECT (ან, ზოგადად, PULUMI__PROJECT для других языков).
  დატის სახელი, რომელიც მითითებულია გარემოს ცვლადში PULUMI_NODEJS_STACK (ან, ზოგადად, PULUMI__ STACK).
  თქვენი სტეკის კონფიგურაციის ცვლადები. მათი მიღება შესაძლებელია გარემოს ცვლადის გამოყენებით PULUMI_CONFIG და მათი ფორმატი არის JSON რუკა გასაღები/მნიშვნელობის წყვილებით.

  პროგრამა გამოსცემს გაფრთხილებებს, რომლებიც მიუთითებს იმაზე, რომ CLI/ძრავთან კავშირი არ არის ხელმისაწვდომი შესრულების დროს. ეს მნიშვნელოვანია, რადგან თქვენი პროგრამა რეალურად არ განათავსებს არაფერს და შეიძლება გასაკვირი იყოს, თუ ეს არ არის ის, რის გაკეთებასაც აპირებდით! იმისათვის, რომ პულუმს უთხრათ, რომ ეს არის ზუსტად ის, რაც გჭირდებათ, შეგიძლიათ დააინსტალიროთ PULUMI_TEST_MODE в true.

  წარმოიდგინეთ, რომ ჩვენ გვჭირდება პროექტის სახელის მითითება my-ws, სტეკის სახელი devდა AWS რეგიონი us-west-2. მოჩას ტესტების გაშვების ბრძანების ხაზი ასე გამოიყურება:

  $ PULUMI_TEST_MODE=true 
      PULUMI_NODEJS_STACK="my-ws" 
      PULUMI_NODEJS_PROJECT="dev" 
      PULUMI_CONFIG='{ "aws:region": "us-west-2" }' 
      mocha tests.js

  ამის გაკეთება, როგორც მოსალოდნელი იყო, გვაჩვენებს, რომ სამი ჩავარდნილი ტესტი გვაქვს!

  Infrastructure
      #server
        1) must have a name tag
   	 2) must not use userData (use an AMI instead)
      #group
        3) must not open port 22 (SSH) to the Internet
  
    0 passing (17ms)
    3 failing
   
   1) Infrastructure
         #server
           must have a name tag:
       Error: Missing a name tag on server
          urn:pulumi:my-ws::my-dev::aws:ec2/instance:Instance::web-server-www
  
   2) Infrastructure
         #server
           must not use userData (use an AMI instead):
       Error: Illegal use of userData on server
          urn:pulumi:my-ws::my-dev::aws:ec2/instance:Instance::web-server-www
  
   3) Infrastructure
         #group
           must not open port 22 (SSH) to the Internet:
       Error: Illegal SSH port 22 open to the Internet (CIDR 0.0.0.0/0) on group

  მოდით გავასწოროთ ჩვენი პროგრამა:

  "use strict";
   
  let aws = require("@pulumi/aws");
   
  let group = new aws.ec2.SecurityGroup("web-secgrp", {
      ingress: [
          { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
      ],
  });
   
  let server = new aws.ec2.Instance("web-server-www", {
      tags: { "Name": "web-server-www" },
      instanceType: "t2.micro",
      securityGroups: [ group.name ], // reference the group object above
      ami: "ami-c55673a0"             // AMI for us-east-2 (Ohio),
  });
   
  exports.group = group;
  exports.server = server;
  exports.publicIp = server.publicIp;
  exports.publicHostName = server.publicDns;
  

  და შემდეგ კვლავ გაიარეთ ტესტები:

  Infrastructure
      #server
        ✓ must have a name tag
        ✓ must not use userData (use an AMI instead)
      #group
        ✓ must not open port 22 (SSH) to the Internet
   
   
   3 passing (16ms)

  ყველაფერმა კარგად ჩაიარა... რა! ✓✓✓

  დღეისთვის სულ ესაა, მაგრამ განლაგების ტესტირებაზე ვისაუბრებთ თარგმანის მეორე ნაწილში 😉

წყარო: www.habr.com