מלכודות Terraform

בואו נדגיש כמה מלכודות, כולל אלו הקשורות ללולאות, הצהרות וטכניקות פריסה, כמו גם בעיות כלליות יותר המשפיעות על Terraform באופן כללי:

• לפרמטרים ספירה ועבור_כל יש מגבלות;
• הגבלת אפס פריסות זמן השבתה;
• אפילו תוכנית טובה יכולה להיכשל;
• ל-refactoring יכולים להיות מלכודות;
• קוהרנטיות נדחית עולה בקנה אחד עם דחייה.

לפרמטרים ספירה ועבור_כל יש מגבלות

הדוגמאות בפרק זה עושות שימוש נרחב בפרמטר ה-count ובביטוי for_each בלולאות ובלוגיקה מותנית. הם מתפקדים היטב, אבל יש להם שתי מגבלות חשובות שאתה צריך להיות מודע אליהן.

• Count ו-for_each אינם יכולים להתייחס למשתני פלט כלשהם.
• לא ניתן להשתמש ב-count וב-for_each בתצורת מודול.

count ו-for_each אינם יכולים להתייחס למשתני פלט של משאבים

תאר לעצמך שאתה צריך לפרוס כמה שרתי EC2 ומשום מה אתה לא רוצה להשתמש ב-ASG. הקוד שלך יכול להיות כזה:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

בואו נסתכל עליהם אחד אחד.

מכיוון שפרמטר ה-count מוגדר לערך סטטי, קוד זה יעבוד ללא בעיות: כאשר אתה מפעיל את הפקודה apply, הוא יצור שלושה שרתי EC2. אבל מה אם תרצה לפרוס שרת אחד בכל אזור זמינות (AZ) באזור ה-AWS הנוכחי שלך? אתה יכול לגרום לקוד שלך לטעון רשימה של אזורים ממקור הנתונים aws_availability_zones ולאחר מכן לעבור דרך כל אחד מהם וליצור בו שרת EC2 באמצעות פרמטר הספירה וגישה לאינדקס מערך:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

קוד זה גם יעבוד מצוין, מכיוון שפרמטר הספירה יכול להפנות למקורות נתונים ללא בעיות. אבל מה קורה אם מספר השרתים שאתה צריך ליצור תלוי בפלט של משאב כלשהו? כדי להדגים זאת, הדרך הקלה ביותר היא להשתמש במשאב random_integer, שכפי שהשם מרמז, מחזיר מספר שלם אקראי:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

קוד זה יוצר מספר אקראי בין 1 ל-3. בוא נראה מה קורה אם ננסה להשתמש בפלט של משאב זה בפרמטר ה-count של המשאב aws_instance:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

אם תפעיל את תוכנית terraform בקוד זה, תקבל את השגיאה הבאה:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

Terraform דורש שספירה ועבור_כל יחושבו במהלך שלב התכנון, לפני יצירת או שינוי של משאבים כלשהם. המשמעות היא ש-count and for_each יכולים להתייחס למילולי, משתנים, מקורות נתונים ואפילו רשימות משאבים (כל עוד ניתן לקבוע את אורכם בזמן התזמון), אך לא למשתני פלט של משאבים מחושבים.

לא ניתן להשתמש ב-count וב-for_each בתצורת מודול

יום אחד אתה עלול להתפתות להוסיף פרמטר ספירה לתצורת המודול שלך:

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

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

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

למרבה הצער, נכון ל-Terraform 0.12.6, השימוש ב-count או for_each במשאב מודול אינו נתמך. על פי הערות השחרור של Terraform 0.12 (http://bit.ly/3257bv4), HashiCorp מתכננת להוסיף את היכולת הזו בעתיד, כך שתלוי מתי אתה קורא את הספר הזה, ייתכן שהוא כבר זמין. כדי לברר בוודאות, קרא את יומן השינויים של Terraform כאן.

מגבלות של אפס פריסות זמן השבתה

שימוש בבלוק create_before_destroy בשילוב עם ASG הוא פתרון מצוין ליצירת פריסות אפס זמן השבתה, למעט אזהרה אחת: כללי קנה מידה אוטומטי אינם נתמכים. או ליתר דיוק, זה מאפס את גודל ה-ASG בחזרה ל-min_size בכל פריסה, מה שיכול להיות בעיה אם היית משתמש בכללי קנה מידה אוטומטי כדי להגדיל את מספר השרתים הפועלים.

לדוגמה, מודול webserver-cluster מכיל זוג משאבי aws_autoscaling_schedule, אשר בשעה 9 בבוקר מגדיל את מספר השרתים באשכול משניים לעשרה. אם תפרוס, למשל, בשעה 11:9, ה-ASG החדש יאתחל עם שני שרתים בלבד ולא בעשרה ויישאר כך עד XNUMX בבוקר למחרת.

ניתן לעקוף מגבלה זו בכמה דרכים.

• שנה את פרמטר ההישנות ב-aws_autoscaling_schedule מ-0 9 * * * ("הפעל ב-9 בבוקר") למשהו כמו 0-59 9-17 * * * ("רוץ כל דקה מ-9 בבוקר עד 5 בערב"). אם ל-ASG כבר יש עשרה שרתים, הפעלה של כלל קנה המידה האוטומטי הזה שוב לא תשנה כלום, וזה מה שאנחנו רוצים. אבל אם ה-ASG נפרס רק לאחרונה, כלל זה יבטיח שתוך דקה מקסימום מספר השרתים שלו יגיע לעשרה. זו לא גישה אלגנטית לגמרי, וגם קפיצות גדולות מעשרה לשני שרתים ובחזרה עלולות לגרום לבעיות למשתמשים.
• צור סקריפט מותאם אישית המשתמש ב-API של AWS כדי לקבוע את מספר השרתים הפעילים ב-ASG, קרא לו באמצעות מקור נתונים חיצוני (ראה "מקור נתונים חיצוני" בעמוד 249), והגדר את הפרמטר wish_capacity של ה-ASG לערך המוחזר על ידי התסריט. בדרך זו, כל מופע ASG חדש יפעל תמיד באותה קיבולת כמו קוד Terraform הקיים ומקשה על התחזוקה.

כמובן, באופן אידיאלי תהיה ל- Terraform תמיכה מובנית לפריסות אפס זמן השבתה, אבל נכון למאי 2019, לצוות HashiCorp לא היו תוכניות להוסיף את הפונקציונליות הזו (פרטים - כאן).

ייתכן שהתוכנית הנכונה תיושם ללא הצלחה

לפעמים פקודת התוכנית מייצרת תוכנית פריסה נכונה לחלוטין, אך הפקודה החל מחזירה שגיאה. נסה, למשל, להוסיף את המשאב aws_iam_user באותו השם שבו השתמשת עבור משתמש IAM שיצרת קודם בפרק 2:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

כעת, אם תפעיל את פקודת התוכנית, Terraform תוציא תוכנית פריסה סבירה לכאורה:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

אם תפעיל את הפקודה applicer תקבל את השגיאה הבאה:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

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

נקודת המפתח היא שהפקודה של תוכנית terraform לוקחת בחשבון רק את המשאבים המצוינים בקובץ המצב של Terraform. אם משאבים נוצרים בדרך אחרת (למשל, ידנית על ידי לחיצה במסוף AWS), הם לא יגמרו בקובץ המצב ולכן Terraform לא ייקח אותם בחשבון בעת ​​ביצוע פקודת התוכנית. כתוצאה מכך, תוכנית שנראית נכונה במבט ראשון תתברר כלא מוצלחת.

יש ללמוד מכך שני לקחים.

• אם כבר התחלת לעבוד עם Terraform, אל תשתמש בשום דבר אחר. אם חלק מהתשתית שלך מנוהל באמצעות Terraform, לא תוכל עוד לשנות אותה באופן ידני. אחרת, אתה לא רק מסתכן בשגיאות מוזרות של Terraform, אלא אתה גם מבטל הרבה מהיתרונות של IaC מכיוון שהקוד כבר לא יהווה ייצוג מדויק של התשתית שלך.
• אם כבר יש לך תשתית כלשהי, השתמש בפקודה ייבוא. אם אתה מתחיל להשתמש ב- Terraform עם תשתית קיימת, תוכל להוסיף אותה לקובץ המצב באמצעות פקודת ייבוא ​​terraform. כך Terraform תדע איזו תשתית צריך לנהל. הפקודה ייבוא ​​לוקחת שני ארגומנטים. הראשון הוא כתובת המשאב בקובצי התצורה שלך. התחביר כאן זהה לקישורי משאבים: _. (כמו aws_iam_user.existing_user). הארגומנט השני הוא המזהה של המשאב שיש לייבא. נניח שמזהה המשאב aws_iam_user הוא שם המשתמש (לדוגמה, yevgeniy.brikman), ומזהה המשאב aws_instance הוא מזהה השרת EC2 (כמו i-190e22e5). כיצד לייבא משאב מצוין בדרך כלל בתיעוד בתחתית העמוד שלו.

  להלן פקודת ייבוא ​​המסנכרנת את המשאב aws_iam_user שהוספת לתצורת Terraform שלך יחד עם משתמש IAM בפרק 2 (החלפת שמך ב-yevgeniy.brikman, כמובן):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform יתקשר ל-AWS API כדי למצוא את משתמש IAM שלך וליצור שיוך קובץ מצב בינו לבין המשאב aws_iam_user.existing_user בתצורת Terraform שלך. מעתה, כאשר תפעיל את פקודת התוכנית, Terraform תדע שמשתמש IAM כבר קיים ולא ינסה ליצור אותו שוב.

  ראוי לציין שאם כבר יש לך הרבה משאבים שברצונך לייבא ל- Terraform, כתיבת הקוד ידנית ויבוא כל אחד בכל פעם יכול להיות טרחה. אז כדאי לבדוק כלי כמו Terraforming (http://terraforming.dtan4.net/), שיכול לייבא אוטומטית קוד ומצב מחשבון AWS שלך.

  לשחזור יכולות להיות מלכודות

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

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

  לדוגמה, למודול שרת האינטרנט-אשכול יש משתנה קלט cluster_name:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

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

  העובדה היא שמודול שרת-הרשת משתמש במשתנה cluster_name במספר משאבים, כולל פרמטר השם של שתי קבוצות אבטחה וה-ALB:

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

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

  סוג נוסף של עיבוד מחדש שאתה עשוי להתעניין בו הוא שינוי מזהה Terraform. ניקח את המשאב aws_security_group במודול שרת-הרשת כדוגמה:

  resource "aws_security_group" "instance" {
    # (...)
  }

  המזהה של משאב זה נקרא מופע. תארו לעצמכם שבמהלך ה-refactoring החלטתם לשנות אותו לשם cluster_instance מובן יותר (לדעתכם):

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  מה יקרה בסוף? נכון: שיבוש.

  Terraform משייך כל מזהה משאב למזהה ספק הענן. לדוגמה, iam_user משויך למזהה המשתמש של AWS IAM, ו-aws_instance משויך למזהה שרת AWS EC2. אם תשנה את מזהה המשאב (נניח מ-instance ל-cluster_instance, כפי שקורה ב-aws_security_group), ל-Terraform זה יופיע כאילו מחקת את המשאב הישן והוספת חדש. אם תחיל את השינויים האלה, Terraform תמחק את קבוצת האבטחה הישנה ותיצור קבוצה חדשה, בזמן שהשרתים שלך יתחילו לדחות כל תעבורת רשת.

  להלן ארבעה לקחי מפתח שכדאי לקחת מהדיון הזה.

  • השתמש תמיד בפקודת התוכנית. זה יכול לחשוף את כל החסרונות האלה. בדוק היטב את הפלט שלו ושם לב למצבים שבהם Terraform מתכננת למחוק משאבים שככל הנראה לא אמורים להימחק.
  • צור לפני שאתה מוחק. אם ברצונך להחליף משאב, חשוב היטב אם עליך ליצור תחליף לפני מחיקת המקור. אם התשובה היא כן, create_before_destroy יכול לעזור. ניתן להשיג את אותה תוצאה באופן ידני על ידי ביצוע שני שלבים: תחילה הוסף משאב חדש לתצורה והפעל את פקודת היישום, ולאחר מכן הסר את המשאב הישן מהתצורה והשתמש שוב בפקודה היישום.
  • שינוי המזהים מחייב שינוי מצב. אם ברצונך לשנות את המזהה המשויך למשאב (לדוגמה, לשנות את שם aws_security_group מ-instance ל-cluster_instance) מבלי למחוק את המשאב וליצור גרסה חדשה שלו, עליך לעדכן את קובץ המצב של Terraform בהתאם. לעולם אל תעשה זאת באופן ידני - השתמש בפקודה terraform state במקום זאת. בעת שינוי שמות של מזהים, עליך להפעיל את הפקודה terraform state mv, בעלת התחביר הבא:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE הוא ביטוי המתייחס למשאב בצורתו הנוכחית, ו-NEW_REFERENCE הוא המקום שבו אתה רוצה להעביר אותו. לדוגמה, בעת שינוי שם קבוצת aws_security_group ממופע ל-cluster_instance, עליך להפעיל את הפקודה הבאה:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    זה אומר ל- Terraform שהמצב שהיה משויך בעבר ל-aws_security_group.instance צריך להיות משויך כעת ל-aws_security_group.cluster_instance. אם לאחר שינוי שם והפעלת פקודה זו תוכנית terraform אינה מציגה שינויים, אז עשית הכל נכון.

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

  עקביות דחויה עולה בקנה אחד עם דחיה

  ממשקי API של ספקי ענן מסוימים, כגון AWS, הם אסינכרוניים ויש להם עקביות מושהית. אסינכרון פירושה שהממשק יכול להחזיר תגובה מיידית מבלי לחכות להשלמת הפעולה המבוקשת. עקביות מושהית פירושה ששינויים עשויים לקחת זמן להתפשט בכל המערכת; בזמן שזה קורה, התגובות שלך עשויות להיות לא עקביות ותלויות באיזה עותק מקור נתונים מגיב לקריאות ה-API שלך.

  תארו לעצמכם, למשל, שאתם מבצעים קריאת API ל-AWS ומבקשים ממנו ליצור שרת EC2. ה-API יחזיר תגובה "מוצלחת" (201 נוצר) כמעט באופן מיידי, מבלי לחכות ליצירת השרת עצמו. אם תנסה להתחבר אליו מיד, זה כמעט בוודאות ייכשל מכיוון שבשלב זה AWS עדיין מאתחל משאבים או לחילופין, השרת עדיין לא אתחול. יתרה מכך, אם תבצע שיחה נוספת כדי לקבל מידע על שרת זה, ייתכן שתקבל שגיאה (404 לא נמצא). העניין הוא שהמידע על שרת EC2 זה עדיין עשוי להיות מופץ ברחבי AWS לפני שהוא הופך זמין בכל מקום, תצטרך לחכות כמה שניות.

  בכל פעם שאתה משתמש ב-API אסינכרוני עם עקביות עצלה, עליך לנסות שוב את בקשתך מדי פעם עד שהפעולה תושלם ותתפשט במערכת. לרוע המזל, ה-AWS SDK אינו מספק כלים טובים לכך, ופרויקט Terraform סבל בעבר מהרבה באגים כמו 6813 (https://github.com/hashicorp/terraform/issues/6813):

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

  במילים אחרות, אתה יוצר משאב (כמו רשת משנה) ואז מנסה לקבל קצת מידע לגביו (כמו המזהה של רשת המשנה החדשה שנוצרה), ו- Terraform לא מוצא אותו. רוב הבאגים הללו (כולל 6813) תוקנו, אך הם עדיין צצים מעת לעת, במיוחד כאשר Terraform מוסיף תמיכה בסוג משאב חדש. זה מעצבן, אבל ברוב המקרים לא גורם נזק. כאשר אתה מפעיל את terraform app שוב, הכל אמור לעבוד, שכן בשלב זה המידע כבר יתפשט בכל המערכת.

  קטע זה מובא מתוך ספרו של יבגני בריקמן "Terraform: תשתית ברמת הקוד".

מקור: www.habr.com