עבר מ-Terraform ל-CloudFormation - והתחרט

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

השוואת ניסיון עם Terraform ו-CloudFormation

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

Terraform נורא

תוכנת בטא

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

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

תכיר את הרגל... זה כדור

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

Terraform נהדר

התאוששות ממצבים לא שלמים

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

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

שינויים ברורים יותר במצב המסמך

"בסדר, מאזן עומסים, אתה משתנה. אבל איך?"

-מהנדס מודאג, מוכן ללחוץ על כפתור ה"קבל".

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

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

גמישות

כתוב תוכנה לאחור.

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

מודולים ב-git

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

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

פעולות כקוד

"בוא נכתוב את זה ובסדר."

-מהנדס 3 שנים לפני המצאת האופניים של Terraform.

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

קוד כקוד

יש גם את התשתית שעליה זה עובד.

תשתית כקוד

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

פעולות כקוד

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

AWS הוא לא היחיד: אתה כנראה משתמש בספקים אחרים. SignalFx, PagerDuty או Github. אולי יש לך שרת Jenkins פנימי עבור CI/CD או לוח מחוונים פנימי של Grafana לניטור. Infra as Code נבחר מסיבות שונות, וכל אחת מהן חשובה באותה מידה לכל מה שקשור לתוכנה.

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

• Я: לעזאזל, זה הרבה מחוות לעשות אובר-clock של מיקרו-שירות אחד. אני אצטרך להשתמש בזבל הזה כדי ליצור חשבון AWS (הלכנו ל-2 חשבונות ב- שירות מיקרו), אחר כך זה להגדרת התראות, זה עבור מאגר קודים, וזה עבור רשימת דוא"ל, ואז זה...
• עוֹפֶרֶת: בוא נכתוב את זה ובסדר.
• Я: בסדר, אבל התסריט עצמו ישתנה. נצטרך דרך לבדוק שכל הגיזמו המובנים האלה של אמזון מעודכנים.
• עוֹפֶרֶת: נשמע טוב. ואנחנו נכתוב תסריט בשביל זה.
• Я: גדול! והסקריפט כנראה עדיין יצטרך להגדיר פרמטרים. האם הוא יקבל אותם?
• עוֹפֶרֶת: תן לו לקחת לאן שהוא הולך!
• Я: התהליך עשוי להשתנות והתאימות לאחור תאבד. יידרש סוג של בקרת גרסאות סמנטית.
• עוֹפֶרֶת: רעיון מצוין!
• Я: ניתן לשנות כלים באופן ידני, בתוך ממשק המשתמש. נצטרך דרך לבדוק ולתקן את זה.

… 3 שנים מאוחר יותר:

• עוֹפֶרֶת: וקיבלנו terraform.

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

CloudFormation למבדה לעומת מודולי git terraform

lambda היא הפתרון של CloudFormation לבעיית ההיגיון המותאם אישית. עם למבדה אתה יכול ליצור פקודות מאקרו או משאב משתמש. גישה זו מציגה מורכבויות נוספות שאינן קיימות בגרסאות הסמנטיות של Terraform של מודולי git. עבורי, הבעיה הדחופה ביותר הייתה ניהול ההרשאות עבור כל ה-Lambdas של המשתמשים הללו (ואלה עשרות חשבונות AWS). בעיה חשובה נוספת הייתה בעיית "מה בא קודם, התרנגולת או הביצה?": היא הייתה קשורה לקוד הלמבדה. פונקציה זו עצמה היא תשתית וקוד, והיא עצמה זקוקה לניטור ועדכונים. המסמר האחרון בארון הקבורה היה הקושי לעדכן סמנטי את שינויי קוד הלמבדה; היינו צריכים גם לוודא שפעולות המחסנית ללא פקודה ישירה לא ישתנו בין ריצות.

אני זוכר שפעם רציתי ליצור פריסה קנרית לסביבת Elastic Beanstalk עם מאזן עומסים קלאסי. הדבר הקל ביותר לעשות יהיה לבצע פריסה שנייה עבור ה-EB ליד סביבת הייצור, לקחת את זה צעד קדימה: שילוב של קבוצת הפריסה הקנרית בקנה מידה אוטומטי עם הפריסה LB לתוך סביבת הייצור. ומאז Terraform משתמש ASG beantalk כמסקנה, זה ידרוש 4 שורות קוד נוספות ב- Terraform. כששאלתי אם יש פתרון דומה ב-CloudFormation, הם הצביעו לי על מאגר git שלם עם צינור פריסה והכל, הכל למען משהו ש-4 שורות גרועות של קוד Terraform יכולות לעשות.

הוא מזהה סחיפה טוב יותר

ודא שהמציאות תואמת את הציפיות.

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

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

CDK והעתיד של CloudFormation

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

כדי שטראפורם לא יאכזב

זוהי "תשתית כקוד", ולא "כטקסט".

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

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

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

איך לא ניתן לתעד את הקוד?

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

כיצד נוכל לפרוס שירותים שפעם היו פונקציית main() אחת גדולה?

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

האם החברה שלך לא משתמשת בספריות?

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

אתה לא משתמש ב-PEP8 או ב-gofmt?

לרוב השפות יש ערכת עיצוב סטנדרטית ומקובלת. ב-Python זה PEP8. בגו - גופמט. ל- Terraform יש משלו: terraform fmt. תהנה מזה בשביל הבריאות שלך!

האם תשתמש ב-React מבלי לדעת JavaScript?

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

האם אתה מקודד עם יחידות או הזרקת תלות?

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

האם הספריות שלך עושות עשרה דברים טוב או דבר אחד נהדר?

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

איך מבצעים שינויים בספריות ללא תאימות לאחור?

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

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

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

אתה לא כותב מבחנים?

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

Terraform ומיקרו-שירותים

החיים והמוות של חברות מיקרו-שירותים תלויים במהירות, בחדשנות ובשיבוש של ערימות עבודה חדשות של מיקרו-שירותים.

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

מקור: www.habr.com