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

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

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

וידאו:

אני בן 40, אני ב-IT כבר 20 שנה. אני עובד עבור Ixtens כבר 12 שנים. אנו עוסקים בפיתוח מונע-מסחר אלקטרוני. ואני מתרגל שיטות DevOps כבר 5 שנים.

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

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

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

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

הגיעו מפתחים והתחילו לייצר קוד תשתית.

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

Terraform הוא פרויקט קוד פתוח מבית HashiCorp. ולמי שבכלל לא יודע מה זה, השקופיות הבאות.

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

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

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

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

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

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

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

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

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

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

Terraform מאפשר לך ליצור דבר כזה כמו מודול, כלומר, לתאר את אותו הדבר בתיקייה כלשהי.

ולדוגמא, בבדיקה, קראו למודול הזה וקבלו את אותו הדבר כאילו הפעלנו את Terraform application במודול עצמו. לבדיקה יהיה הקוד הזה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איפה אני יכול להשיג את הנתונים? קובץ JSON. Terraform מאפשר לכתוב תשתית לא רק ב-hcl (שפת התצורה של HashiCorp), אלא גם ב-JSON.

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

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

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

לא תמיד ניתן להשתמש בקובץ מצב מרוחק. לדוגמה, יצרת VPC ביד. והקוד של Terraform שיוצר את ה-VPC יוצר VPCs כל כך שונים שזה ייקח הרבה מאוד זמן ואתה תצטרך להתאים אחד לשני, כדי שתוכל להשתמש בטריק הבא.

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

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

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

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

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

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

מקביל זה דבר מאוד מגניב, השתמש בו.

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

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

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

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

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

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

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

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

תוכנית היא דבר די יקר. זה לוקח זמן כי Terraform הולך לאמזון ושואל, "האם המופע הזה עדיין קיים? האם לקנה מידה אוטומטי הזה יש בדיוק אותם פרמטרים?" וכדי לזרז את זה, אפשר להשתמש בפרמטר כמו refresh=false. המשמעות היא ש- Terraform יוריד מצב מ- S3. והיא תאמין שהמדינה תתאים בדיוק למה שיש באמזון.

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

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

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

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

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

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

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

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

הדבר הבא שאני רוצה לדבר עליו הוא Automate Terraform application.

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

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

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

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

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

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

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

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

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

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

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

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

בואו נסכם:

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

• תשתית בלתי ניתנת לשינוי. משלוח AMI על לוח הזמנים.
• מבנה עבור route53 כאשר יש לך הרבה ערכים ואתה רוצה שהם יהיו בסדר עקבי.
• נלחם במגבלות שיעורי API. זה כאשר אמזון אומרת, "זהו זה, אני לא יכול לקבל עוד בקשות, אנא המתן." ומחצית מהמשרד מחכה עד שיוכל להשיק את התשתית שלו.
• זיהוי מופעים. אמזון הוא אירוע לא זול וספוטים מאפשרים לכם לחסוך לא מעט. ושם אתה יכול לספר על זה דיווח שלם.
• תפקידי אבטחה ו-IAM.
• בחיפוש אחר משאבים אבודים, כאשר יש לך מקרים של מקור לא ידוע באמזון, הם אוכלים כסף. גם אם מקרים עולים 100-150 דולר לחודש, זה יותר מ-1 דולר לשנה. מציאת משאבים כאלה היא עסק רווחי.
• ומופעים שמורים.

זה הכל בשבילי. Terraform הוא מאוד מגניב, אתה משתמש בו. תודה!

שאלות

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

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

האם אתה משתמש בקוד פתוח או בארגון?

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

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

הזמן היה מוגבל. נקודה טובה.

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

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

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

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

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

שמעת משהו על jsonnet?

לא.

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

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

רק תסתכל. תודה!

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

אלו דברים מאוד שונים. אתה יכול ליצור משאבים ב-Ansible, ו-Puppet יכול ליצור משאבים באמזון. אבל Terraform ישר מושחזת.

יש לך רק אמזון?

זה לא שיש לנו רק אמזון. יש לנו כמעט רק אמזון. אבל התכונה העיקרית היא ש-Terraform זוכר. ב-Ansible, אם אתה אומר: "תן לי 5 מקרים", אז זה יעלה, ואז אתה אומר: "ועכשיו אני צריך 3." וטרהפורם יגיד: "בסדר, אני אהרוג 2", ואנסיבל יגיד: "בסדר, הנה 3 בשבילך." סך הכל 8.

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

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

השאלה היא זו. אתה משתמש ב-Remote backend, אתה משתמש ב-S 3. למה אתה לא משתמש ב-backend הרשמי?

רשמי?

Terraform Cloud.

מתי הוא הופיע?

לפני 4 חודשים.

אם זה היה מופיע לפני 4 שנים, אז כנראה שהייתי עונה על השאלה שלך.

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

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

דיברת על פתיתי שלג, למה לא השתמשת בענף? למה זה לא הסתדר ככה?

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

אז זה לא עובד?

זה לא עובד בכלל.

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

שלום! שמי יורה! תודה על הדיווח! שאלה לגבי מודולים. אתה אומר שאתה משתמש במודולים. כיצד פותרים את הבעיה אם בוצעו שינויים במודול אחד שאינם תואמים לשינוי של אדם אחר? האם אתה איכשהו עורך גרסאות של המודולים או מנסה להביא wunderwaffle כדי לענות על שתי דרישות?

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

כלומר, זה עדיין לא נפתר?

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

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

מידע משתמש.

כלומר, אתה פשוט יורק את הקובץ ואיכשהו מבצע אותו?

User-data הוא הערה, כלומר כשאנחנו עושים שיבוט של התמונה, Daemon עולה שם, ומנסה להבין מי הוא קורא את ההערה שהוא מאזן עומסים.

כלומר, האם מדובר בסוג של תהליך נפרד שנמסר?

אנחנו לא המצאנו את זה. אנחנו משתמשים בו.

שלום! יש לי רק שאלה לגבי User - Data. אמרת שיש שם בעיות, שמישהו עלול לשלוח משהו למקום הלא נכון. האם יש דרך כלשהי לאחסן נתוני משתמש באותו Git, כך שתמיד יהיה ברור למה מתייחס User-data?

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

מסתבר שהפתרון היחיד הוא לבדוק?

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

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

אפילו לא התחלתי.

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

כלומר, האם עלי לכתוב כאן (שקף: Production/environment/settings.tf): domain = משתנה, domain vpcnetwork, משתנה vpcnetwork ו-stvars – האם אני יכול לקבל את אותו הדבר?

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

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

האם אפשר להחזיק הכל במקום אחד?

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

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

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

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

למרבה הצער, כן.

שלום! שמי סטארקוב סטניסלב. דוֹאַר. ru Group. איך פותרים את הבעיה של יצירת תגית על..., איך מעבירים אותו פנימה? לפי הבנתי, דרך User - נתונים לציון שם המארח, להגדיר Puppet on? והחלק השני של השאלה. איך פותרים את הבעיה הזו ב-SG, כלומר כשיוצרים SG, מאות מופעים מאותו סוג, מה השם הנכון עבורם?

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

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

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

כאשר SG יוצר מאות מופעים, האם צריך להבחין ביניהם איכשהו?

לא, אל תעשה. בכל מופע יש סוכן שמדווח שיש לי בעיה. אם סוכן מדווח, אז הסוכן יודע עליו ולכל הפחות כתובת ה-IP שלו קיימת. אתה כבר יכול לברוח. שנית, אנו משתמשים ב-Consul for Discovery, במקום שבו Kubernetes לא נמצא. וקונסול מראה גם את כתובת ה-IP של המופע.

כלומר, האם אתה מתמקד ספציפית ב-IP, ולא בשם המארח?

אי אפשר לנווט לפי שם מארח, כלומר יש הרבה כאלה. ישנם מזהי מופעים - AE וכו'. אתה יכול למצוא אותו איפשהו, אתה יכול לזרוק אותו לחיפוש.

שלום! הבנתי ש- Terraform הוא דבר טוב, מותאם לעננים.

לא רק.

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

Ansible הוא קצת על משהו אחר. כלומר, Ansible כבר עובד כאשר המופע התחיל. ו- Terraform עובד לפני שהמופע מתחיל. מעבר ל-Bare Metal - לא.

לא עכשיו, אבל עסקים יבואו ויגידו: "קדימה."

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

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

Terraform מאפשר לך ליצור משימות Front-End, להגדיר את PagerDuty, מסמך נתונים וכו'. יש לזה הרבה זנבות. הוא יכול לשלוט כמעט בכל העולם.

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

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

אם יש שגיאה, האם אתה חוזר לאחור? ניסית לעשות את זה?

לא, זו החלטה של ​​אדם ברגע שהוא רואה בעיה.

מקור: www.habr.com