בדוק תשתית כקוד עם Pulumi. חלק 1

צהריים טובים חברים. לקראת תחילת זרימה חדשה בקצב "שיטות וכלים של DevOps" אנו משתפים אתכם בתרגום חדש. ללכת.

שימוש ב-Pulumi ושפות תכנות למטרות כלליות לקוד תשתית (Infrastructure as Code) מספק יתרונות רבים: זמינות של מיומנויות וידע, ביטול ה-boilerplate בקוד באמצעות הפשטה, כלים המוכרים לצוות שלך, כגון IDEs ו-linters. כל כלי הנדסת התוכנה הללו לא רק הופכים אותנו ליותר פרודוקטיביים, אלא גם משפרים את איכות הקוד שלנו. לכן, זה אך טבעי שהשימוש בשפות תכנות למטרות כלליות יאפשר לנו להציג פרקטיקה חשובה נוספת של פיתוח תוכנה - בדיקות.

במאמר זה, נראה כיצד Pulumi עוזרת לנו לבדוק את התשתית שלנו כקוד.

למה לבדוק תשתית?

לפני שנכנס לפרטים, כדאי לשאול את השאלה: "למה בכלל לבדוק תשתית?" יש לכך סיבות רבות והנה כמה מהן:

• בדיקת יחידות של פונקציות בודדות או קטעים מהלוגיקה של התוכנית שלך
• מאמת את המצב הרצוי של התשתית מול אילוצים מסוימים.
• זיהוי שגיאות נפוצות, כגון חוסר הצפנה של דלי אחסון או גישה לא מוגנת, פתוחה מהאינטרנט למכונות וירטואליות.
• בדיקת יישום אספקת תשתית.
• ביצוע בדיקת זמן ריצה של לוגיקה של אפליקציה הפועלת בתוך התשתית ה"מתוכנתת" שלך כדי לבדוק פונקציונליות לאחר הקצאה.
• כפי שאנו יכולים לראות, יש מגוון רחב של אפשרויות לבדיקת תשתית. ל-Polumi יש מנגנונים לבדיקה בכל נקודה בספקטרום הזה. בואו נתחיל ונראה איך זה עובד.

בדיקת יחידה

תוכניות Pulumi כתובות בשפות תכנות למטרות כלליות כמו JavaScript, Python, TypeScript או Go. לכן, מלוא כוחן של שפות אלו, לרבות הכלים והספריות שלהן, לרבות מסגרות בדיקה, עומד לרשותן. Pulumi הוא רב ענן, מה שאומר שניתן להשתמש בו לבדיקות מכל ספק ענן.

(במאמר זה, למרות היותו רב לשוני ורב ענן, אנו משתמשים ב-JavaScript וב-Mocha ומתמקדים ב-AWS. אתה יכול להשתמש ב-Python unittest, Go test framework, או כל מסגרת בדיקה אחרת שתרצו. וכמובן, Pulumi עובד מצוין עם 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;

זוהי תוכנית Pulumi הבסיסית: היא פשוט מקצה קבוצת אבטחה 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();
                }
            });
        });

זה נראה כמו מבחן רגיל, אבל עם כמה תכונות שכדאי לציין:

• מכיוון שאנו מבצעים שאילתות על מצבו של משאב לפני הפריסה, הבדיקות שלנו מופעלות תמיד במצב "תוכנית" (או "תצוגה מקדימה"). לפיכך, ישנם נכסים רבים שהערכים שלהם פשוט לא יאוחזרו או לא יוגדרו. זה כולל את כל מאפייני הפלט שחושבו על ידי ספק הענן שלך. זה נורמלי עבור הבדיקות שלנו - אנחנו בודקים רק את נתוני הקלט. לסוגיה זו נחזור בהמשך, בכל הנוגע למבחני אינטגרציה.
• מכיוון שכל מאפייני המשאבים של Pulumi הם פלטים, ורבים מהם מוערכים באופן אסינכרוני, עלינו להשתמש בשיטת היישום כדי לגשת לערכים. זה מאוד דומה להבטחות ולא פונקציה 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 שכדאי לשים אליה לב.
בדרך כלל, כדי להפעיל תוכניות של Pulumi, נעשה שימוש ב-pulimi CLI (ממשק קו פקודה), שמגדיר את זמן הריצה של השפה, שולט בהשקה של מנוע ה-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