תיאור התשתית ב- Terraform לעתיד. אנטון בבנקו (2018)

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

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

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

לאחר שלוש שנים של ניהול אוסף של מודולי קהילה של Terraform עבור AWS ב-Github ותחזוקה ארוכת טווח של Terraform בייצור, אנטון בבנקו מוכן לחלוק את הניסיון שלו: איך לכתוב מודולי TF כך שזה לא יכאב בעתיד.

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

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

קישורים:

• terraform-community-modules + terraform-aws-modules
• antonbabenko/pre-commit-terraform - עיצוב אוטומטי של קוד ותיעוד
• antonbabenko/טרפין - מחולל מודולי Terraform (WIP)
• antonbabenko/modules.tf-lambda - מחולל קוד Terraform מתרשימים חזותיים (WIP)
• www.terraform-best-practices.com
• medium.com/@anton.babenko (פוסטים חדשים נמצאים באתר האישי שלי www.antonbabenko.com/)
• @antonbabenko - טוויטר, וחבורה של Slacks שונים

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

אני עובד על Terraform והייתי משתתף ותורם פעיל למספר רב של פרויקטים בקוד פתוח הקשורים ל- Terraform ואמזון מאז 2015.

מאז כתבתי מספיק קוד כדי לנסח אותו בצורה מעניינת. ואני אנסה לספר לכם על זה עכשיו.

אני אדבר על המורכבות והפרטים של עבודה עם Terraform. אבל זה לא באמת הנושא של HighLoad. ועכשיו תבינו למה.

עם הזמן, התחלתי לכתוב מודולים של Terraform. משתמשים כתבו שאלות, אני כתבתי אותן מחדש. אחר כך כתבתי כלי עזר שונים כדי לעצב את הקוד באמצעות הוק של pre-commit וכו'.

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

אני מאוקראינה. אני גר בנורבגיה שנים רבות.

כמו כן, מידע לדוח זה נאסף מאנשים שיודעים את שמי ומוצאים אותי ברשתות חברתיות. כמעט תמיד יש לי אותו כינוי.

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

כפי שציינתי, אני המתחזק הראשי של מודולי Terraform AWS, שהוא אחד המאגרים הגדולים ביותר ב-GitHub בו אנו מארחים מודולים למשימות הנפוצות ביותר: VPC, Autoscaling, RDS.

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

Terraform הופיע בשנת 2014 ככלי עזר שאיפשר לך לכתוב, לתכנן ולנהל תשתית כקוד. מושג המפתח כאן הוא "תשתית כקוד".

כל התיעוד, כפי שאמרתי, כתוב ב terraform.io. אני מקווה שרוב האנשים יודעים על האתר הזה וקראו את התיעוד. אם כן, אז אתה במקום הנכון.

כך נראה קובץ תצורה רגיל של Terraform, שבו אנו מגדירים תחילה כמה משתנים.

במקרה זה אנו מגדירים "aws_region".

לאחר מכן אנו מתארים אילו משאבים אנו רוצים ליצור.

אנו מפעילים כמה פקודות, במיוחד "terraform init" על מנת לטעון תלות וספקים.

ואנחנו מפעילים את הפקודה "terraform apply" על מנת לבדוק אם התצורה שצוינה תואמת את המשאבים שיצרנו. מכיוון שלא יצרנו דבר לפני כן, Terraform מבקש מאיתנו ליצור משאבים אלה.

אנו מאשרים זאת. כך אנו יוצרים דלי שנקרא ציפור ים.

יש גם כמה כלי עזר דומים. רבים מכם המשתמשים באמזון מכירים את AWS CloudFormation או Google Cloud Deployment Manager או Azure Resource Manager. לכל אחד מהם יש יישום משלו מסוג כלשהו לניהול משאבים בתוך כל אחד מספקי הענן הציבורי הללו. Terraform שימושי במיוחד מכיוון שהוא מאפשר לך לנהל למעלה מ-100 ספקים. (פרטים נוספים כאן)

המטרות שטראפורם רדף מההתחלה:

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

בשנת 2014, המילה "צפוי" נשמעה מאוד יוצאת דופן בהקשר הזה.

Terraform הוא כלי עזר אוניברסלי. אם יש לך ממשק API, אתה יכול לשלוט בהכל:

• אתה יכול להשתמש ביותר מ-120 ספקים כדי לנהל את כל מה שאתה רוצה.
• לדוגמה, אתה יכול להשתמש ב- Terraform כדי לתאר גישה למאגרי GitHub.
• אתה יכול אפילו ליצור ולסגור באגים ב-Jira.
• אתה יכול לנהל מדדי New Relic.
• אתה יכול אפילו ליצור קבצים בדרופבוקס אם אתה באמת רוצה.

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

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

והכל מעולה, יש לך קובץ שיוצר VPC.

אם אתה רוצה ליצור VPC, אז אתה מציין בערך 12 שורות אלה. תאר באיזה אזור אתה רוצה ליצור, באיזה cidr_block של כתובות IP להשתמש. זה הכל.

באופן טבעי, הפרויקט יגדל בהדרגה.

ואתה תוסיף שם המון דברים חדשים: משאבים, מקורות נתונים, תשתלב עם ספקים חדשים, פתאום תרצה להשתמש ב-Terraform כדי לנהל משתמשים בחשבון GitHub שלך וכו'. אולי תרצה להשתמש אחרת ספקי DNS, חוצים הכל. Terraform עושה את זה קל.

בואו נסתכל על הדוגמה הבאה.

אתה מוסיף בהדרגה internet_gateway כי אתה רוצה למשאבים מה-VPC שלך תהיה גישה לאינטרנט. זה רעיון טוב.

התוצאה היא main.tf זה:

זהו החלק העליון של main.tf.

זהו החלק התחתון של main.tf.

ואז אתה מוסיף רשת משנה. עד שתרצה להוסיף שערים של NAT, מסלולים, טבלאות ניתוב ועוד שלל רשתות משנה, לא יהיו לך 38 קווים, אלא בערך 200-300 קווים.

כלומר, קובץ main.tf שלך גדל בהדרגה. ולעתים קרובות אנשים שמים הכל בקובץ אחד. 10-20 Kb מופיע ב-main.tf. תארו לעצמכם ש-10-20 Kb הוא תוכן טקסט. והכל קשור להכל. זה הופך בהדרגה לקשה לעבוד איתו. 10-20 Kb הוא מקרה משתמש טוב, לפעמים יותר. ואנשים לא תמיד חושבים שזה רע.

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

• הקוד הולך וגדל.
• גם התלות בין המשאבים גוברת.

ויש לנו צורך גדול מאוד. אנחנו מבינים שאנחנו לא יכולים לחיות ככה יותר. הקוד שלנו הופך לעצום. 10-20 Kb זה, כמובן, לא מאוד עצום, אבל אנחנו מדברים רק על מחסנית הרשת, כלומר הוספת רק משאבי רשת. אנחנו לא מדברים על Application Load Balancer, Deployment ES Cluster, Kubernetes וכו', שבהם ניתן לשזור בקלות 100 Kb. אם תכתוב את כל זה, בקרוב מאוד תלמד ש- Terraform מספקת מודולים של Terraform.

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

אז אנחנו מנסים להבין איך נבצע אופטימיזציה של 10-20-30 Kb של הקוד שלנו. אנחנו מבינים בהדרגה שאנחנו צריכים להשתמש בכמה מודולים.

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

דוגמה למודול משאבים.

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

אנו מציינים איזו גרסה אנו רוצים להוריד.

אנחנו מעבירים שם שלל ויכוחים. זה הכל. זה כל מה שאנחנו צריכים לדעת כשאנחנו משתמשים במודול הזה.

אנשים רבים חושבים שאם הם משתמשים בגרסה העדכנית ביותר, הכל יהיה יציב. אבל לא. התשתית חייבת להיות מנוסחת בגרסה; עלינו לענות בבירור לאיזו גרסה נפרס רכיב זה או אחר.

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

המשתמש לא צריך לדעת איך זה נעשה בפנים.

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

בהמשך אראה כמה דוגמאות לכך.

מודול התשתית נקרא בדיוק באותו אופן.

המקור ממנו ניתן להוריד את התוכן מצוין.

חבורה של ערכים מועברים ומועברים למודול זה.

לאחר מכן, בתוך מודול זה, חבורה של מודולי משאבים נקראים ליצור VPC או Application Load Balancer, או ליצור קבוצת אבטחה או עבור אשכול Elastic Container Service.

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

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

בוא נסתכל על איך לכתוב את המודולים האלה בשלב הבא. לאחר מכן נראה איך להתקשר אליהם ואיך לעבוד עם הקוד.

Terraform Registry - https://registry.terraform.io/

טיפ מס' 0 הוא לא לכתוב מודולי משאבים. רוב המודולים האלה כבר נכתבו עבורך. כפי שאמרתי, הם קוד פתוח, הם לא מכילים שום היגיון עסקי שלך, אין להם ערכים מקודדים עבור כתובות IP, סיסמאות וכו'. המודול מאוד גמיש. וסביר להניח שזה כבר נכתב. ישנם מודולים רבים למשאבים מאמזון. בערך 650. ורובם באיכות טובה.

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

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

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

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

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

https://github.com/mbtproject/mbt

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

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

פתרון שני. אם יש לך הרבה תת-מודולים וכבר יש לך איזשהו צינור מבוסס, אז יש את פרויקט MBT, שמאפשר לך לאסוף חבילות רבות ושונות ממאגר מונו ולהעלות אותן ל-S3. זו דרך טובה מאוד. לפיכך, קובץ iam-user-1.0.0.zip ישקול רק 1 Kb, מכיוון שהקוד ליצירת המשאב הזה קטן מאוד. וזה יעבוד הרבה יותר מהר.

בואו נדבר על מה שלא ניתן להשתמש במודולים.

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

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

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

הרע הוא שאתה לא תמיד שולט מתי הספק הזה יושק, ראשית. ושנית, אתה לא שולט מה המשמעות של aws ec2, כלומר אנחנו מדברים עכשיו על לינוקס או ווינדוס. אז אתה לא יכול לכתוב משהו שיעבוד אותו הדבר במערכות הפעלה שונות או עבור מקרי משתמש שונים.

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

למעשה, כן, אין בזה שום דבר רע. אבל ממש בקרוב תבינו שהדבר המקומי-exec הזה לא קיים, למשל, ב- launch_configuration.

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

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

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

והמשאב הנכון ביותר עבור זה נקרא null_resource. Null_resource הוא משאב דמה שלעולם לא נוצר בפועל. זה לא נוגע בכלום, אין API, אין קנה מידה אוטומטי. אבל זה מאפשר לך לשלוט מתי להפעיל את הפקודה. במקרה זה, הפקודה מופעלת במהלך היצירה.

קשר http://bit.ly/common-traits-in-terraform-modules

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

אם אתה רוצה לכתוב משהו כדי שאנשים ישתמשו בו, אז אני ממליץ לעקוב אחר הסימנים האלה.

זהו:

• תיעוד ודוגמאות.
• פונקציונליות מלאה.
• ברירות מחדל סבירות.
• קוד נקי.
• בדיקות.

מבחנים הם מצב שונה כי הם די קשים לכתיבה. אני מאמין יותר בתיעוד ובדוגמאות.

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

זה החלק האפור של התיעוד. אולי עכשיו אתה חושב: "משהו לא ברור. לא משוכנע." אבל נראה בעוד שישה חודשים.

עכשיו בואו נדבר על איך לקרוא מודולים אלה.

אנו מבינים שהקוד שלנו גדל עם הזמן. אין לנו יותר קובץ אחד, יש לנו כבר 20 קבצים. כולם בתיקייה אחת. או אולי בחמש תיקיות. אולי אנחנו מתחילים איכשהו לפרק אותם לפי אזור, לפי כמה מרכיבים. אז אנחנו מבינים שעכשיו יש לנו כמה יסודות של סנכרון ותזמור. כלומר, עלינו להבין מה עלינו לעשות אם שינינו משאבי רשת, מה עלינו לעשות עם שאר המשאבים שלנו, כיצד לגרום לתלות אלו וכו'.

יש שני קצוות. הקיצוניות הראשונה היא הכל באחד. יש לנו קובץ מאסטר אחד. לעת עתה, זה היה השיטות המומלצות הרשמיות באתר Terraform.

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

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

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

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

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

למי יש את כל זה במקום אחד? אחד, שניים, שלושה אנשים, כלומר מישהו משתמש בזה.

ומי קורא לרכיב מסוים אחד, בלוק אחד או מודול תשתית אחד? חמישה עד שבעה אנשים. זה מגניב.

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

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

אני יכול להציע איזה פתרונות יש. אתה יכול להשתמש ב- Terraform כדי לעשות את הקסם, או שאתה יכול להשתמש ב-makefiles כדי להשתמש ב- Terraform. ותראה אם ​​משהו השתנה שם, אתה יכול להפעיל אותו כאן.

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

כמובן, אל תנסו את זה בבית. Terraform מעולם לא תוכנן להפעלה מ- Terraform.

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

https://github.com/gruntwork-io/terragrunt/

אם אתה צריך תזמור שיחות כשמשהו השתנה במקום אחד, אז יש Terragrunt.

Terragrunt הוא כלי שירות, תוסף ל- Terraform, המאפשר לך לתאם ולתזמר שיחות למודולי תשתית.

קובץ תצורה טיפוסי של Terraform נראה כך.

אתה מציין לאיזה מודול ספציפי אתה רוצה להתקשר.

אילו תלויות יש למודול?

ואיזה טיעונים מודול זה מקבל. זה כל מה שיש לדעת על Terragrunt.

התיעוד קיים, ויש 1 כוכבים ב-GitHub. אבל ברוב המקרים זה מה שאתה צריך לדעת. וזה קל מאוד ליישום בחברות שרק מתחילות לעבוד עם Terraform.

אז תזמור הוא Terragrunt. יש אפשרויות אחרות.

עכשיו בואו נדבר על איך לעבוד עם הקוד.

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

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

ותמך ביצירת משאבים חדשים באמצעות משאב הבלוק.

בפלט אנו תמיד מחזירים מזהה פלט בהתאם למה שהיה בשימוש.

הבעיה המאוד משמעותית השנייה ב- Terraform 0.11 היא עבודה עם רשימות.

הקושי הוא שאם יש לנו רשימה כזו של משתמשים.

וכאשר אנו יוצרים את המשתמשים האלה באמצעות משאב חסימה, אז הכל הולך כשורה. אנחנו עוברים על כל הרשימה, יוצרים קובץ לכל אחד. הכל בסדר. ואז, למשל, צריך להסיר מכאן את user3 שנמצא באמצע, ואז כל המשאבים שנוצרו אחריו ייווצרו מחדש כי האינדקס ישתנה.

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

זה הפתרון. זהו קוד שנכתב ב-Jsonnet. Jsonnet היא שפת תבנית מגוגל.

פקודה זו מאפשרת לך לקבל תבנית זו וכפלט היא מחזירה קובץ json שנעשה לפי התבנית שלך.

התבנית נראית כך.

Terraform מאפשר לך לעבוד גם עם HCL וגם עם Json באותו אופן, אז אם יש לך את היכולת ליצור Json, אז אתה יכול להחליק אותו לתוך Terraform. הקובץ עם הסיומת .tf.json יורד בהצלחה.

ואז אנחנו עובדים עם זה כרגיל: terraform init, terramorm apply. ואנחנו יוצרים שני משתמשים.

עכשיו אנחנו לא מפחדים אם מישהו יעזוב את הקבוצה. אנחנו פשוט נערוך את קובץ ה-json. ואסיה פאפקין עזבה, פטיה פיאטוצ'קין נשארה. Petya Pyatochkin לא תקבל מפתח חדש.

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

אבל מתעוררים מצבים כאשר אנו רוצים להרחיב את Terraform ולקרוא פקודה כלשהי לאחר שמשהו הושלם.

דרך ראשונה. אנו יוצרים פלט שבו אנו כותבים פקודה זו.

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

דרך שניה. זהו השימוש ב-null_resource בהתאם לשינויים בתשתית שלנו. אנחנו יכולים להתקשר לאותו local-exe ברגע שהמזהה של משאב כלשהו משתנה.

באופן טבעי, הכל חלק על הנייר, כי לאמזון, כמו לכל הספקים הציבוריים האחרים, יש חבורה של מקרים קצה משלה.

מקרה הקצה הנפוץ ביותר הוא שכאשר אתה פותח חשבון AWS, זה משנה באילו אזורים אתה משתמש; האם התכונה הזו מופעלת שם; אולי פתחת אותו אחרי דצמבר 2013; אולי אתה משתמש ברירת מחדל ב-VPC וכו'. ישנן הגבלות רבות. ואמזון פיזרה אותם לאורך התיעוד.

יש כמה דברים שאני ממליץ להימנע מהם.

כדי להתחיל, הימנע מכל הטיעונים הלא סודיים בתוך תוכנית Terraform או Terraform CLI. ניתן להכניס את כל זה לקובץ tfvars או למשתנה סביבה.

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

כמו כן, אל תשתמש בארגומנטים של יעד כדי לצמצם את ההיקף. בשביל זה הרבה יותר קל להשתמש במודולי תשתית קטנים.

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

Terraform ינסה להפעיל מחדש את רוב הבעיות הללו, אך כמעט לא תשיג דבר. Parallelism=1 הוא דבר חשוב לשימוש אם נתקלתם באיזה באג בתוך ה-API של AWS או בתוך ספק ה-Terraform. ואז אתה צריך לציין: parallelism=1 ולחכות עד ש- Terraform מסיים שיחה אחת, ואז השני, ואז השלישי. הוא ישיק אותם אחד אחד.

אנשים שואלים אותי לעתים קרובות, "מדוע אני חושב שמרחבי עבודה של Terraform הם רעים?" אני מאמין שהעיקרון של תשתית כקוד הוא לראות איזו תשתית נוצרה ועם אילו ערכים.

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

איך עובדים עם הקוד? למעשה, העבודה עם רשימות היא הכאב היחיד. וקחו את Terraform יותר בקלות. זה לא הדבר שיעשה לך הכל נהדר. אין צורך לדחוף לשם את כל מה שכתוב בתיעוד.

נושא הדו"ח נכתב "לעתיד". אני אדבר על זה בקצרה מאוד. לעתיד, זה אומר ש-0.12 ישוחרר בקרוב.

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

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

תודה על הדיווח! דיברת על תשתית כקוד וממש אמרת מילה אחת על בדיקות. האם יש צורך בבדיקות במודולים? של מי האחריות הזו? האם אני צריך לכתוב את זה בעצמי או שזו אחריות המודולים?

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

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

Terratest היא אחת הספריות המוזכרות בתדירות גבוהה המאפשרת לך לכתוב מבחני אינטגרציה עבור Terraform. זה אחד משירותי השירות. אני מעדיף את סוג ה-DSL, למשל, rspec.

אנטון, תודה על הדיווח! שמי הוא ולרי. הרשו לי לשאול שאלה פילוסופית קטנה. יש, בתנאי, אספקה, יש פריסה. ההקצאה יוצרת את התשתית שלי, בפריסה אנחנו ממלאים אותה במשהו שימושי, למשל, שרתים, אפליקציות וכו'. וזה בראש שלי ש-Terraform זה יותר להקצאה, ו-Ansible זה יותר לפריסה, כי Ansible זה גם לפיזי התשתית מאפשר לך להתקין nginx, Postgres. אבל במקביל, נראה כי Ansible מאפשרת הקצאה, למשל, של משאבי אמזון או גוגל. אבל Terraform גם מאפשר לך לפרוס תוכנות מסוימות באמצעות המודולים שלה. מנקודת המבט שלך, האם יש איזשהו גבול שעובר בין Terraform ל-Ansible, איפה ובמה עדיף להשתמש? או, למשל, אתה חושב ש-Ansible זה כבר זבל, כדאי לנסות להשתמש ב- Terraform לכל דבר?

שאלה טובה, ולרי. אני מאמין ש- Terraform לא השתנה מבחינת המטרה מאז 2014. הוא נוצר עבור תשתית ומת עבור תשתית. עדיין היה ויהיה לנו צורך בניהול תצורה Ansible. האתגר הוא שיש נתוני משתמש בתוך launch_configuration. ושם אתה מושך את Ansible וכו' זו ההבחנה הסטנדרטית שאני הכי אוהב.

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

שלום! תודה על הדיווח! שמי מישה, חברת RBS. אתה יכול להתקשר ל-Ansible באמצעות ספק בעת יצירת משאב. ל-Ansible יש גם נושא שנקרא מלאי דינמי. ואתה יכול קודם להתקשר לטרהפורם, ואז להתקשר לאנסיבל, שתיקח משאבים מהמדינה ותוציא את זה לפועל. מה עדיף?

אנשים משתמשים בשניהם בהצלחה שווה. נראה לי שמלאי דינמי ב-Ansible הוא דבר נוח, אם לא מדובר ב-autoscaling group. כי בקבוצת קנה המידה האוטומטי כבר יש לנו ערכת כלים משלנו, שנקראת launch_configuration. ב- launch_configuration אנו מתעדים את כל מה שצריך להפעיל כאשר אנו יוצרים משאב חדש. לכן, עם אמזון, השימוש במלאי דינמי וקריאת קובץ Terraform ts, לדעתי, הוא מוגזם. ואם אתה משתמש בכלים אחרים שבהם אין מושג של "קבוצת קנה מידה אוטומטי", למשל, אתה משתמש ב-DigitalOcean או בספק אחר שבו אין קבוצת קנה מידה אוטומטי, שם תצטרך למשוך ידנית את ה-API, למצוא כתובות IP, ליצור קובץ מלאי דינמי, ו-Ansible כבר תשוטט בו. כלומר, עבור אמזון יש launch_configuration, ולכל השאר יש מלאי דינמי.

מקור: www.habr.com