תשתית כקוד (IaC) עם AWS CloudFormation — אוטומציה של AWS

AWS CloudFormation: איפה הגדרה ידנית של הענן נשברת

הגדרה ידנית של הענן נשברת לא בהרצה הראשונה, אלא בשינוי השלישי-רביעי. מהנדס מוסיף כלל ל-security group, מרים instance, מוסיף תגיות — וחוזר על זה ב-dev, stage ו-prod מהזיכרון.

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

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

Infrastructure as Code מסירה את זה ברמת המודל: תיאור הסביבה חי בתבניות, שינויים עוברים בדיקה ונכנסים למערכת בקרת גרסאות, ולא ל-console. אוטומציה של AWS דרך CloudFormation הופכת כל סביבה לתוצאה של יישום אותו תיאור — מרשתות ומאזני עומס ועד הרשאות גישה. יכולת השחזור של הסביבות מפסיקה להיות תלויה במי בדיוק בנה את הסביבה ובאיזה סדר לחץ על כפתורים.

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

מה משתנה אחרי המעבר לתבניות תשתית

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

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

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

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

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

דרכים לתיאור תשתית: השוואת גישות

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

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

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

סדר היישום: מביקורת ועד מסירת נהלים

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

1. ביקורת תשתית. עוברים על חשבונות ואזורים, מתעדים משאבים בפועל, קשרים ביניהם ושינויים שנעשו ידנית שלא דרך התיאורים. בסוף — רשימת מלאי ופירוט אי-ההתאמות עם התיעוד.

2. תרשים תלויות. מחלקים את המשאבים ל-stacks: רשת, מחשוב, מאגרים, הרשאות. קובעים את סדר היצירה ואת מה שאסור לשנות בלי השבתה — זה מגדיר את גבולות התבניות של CloudFormation.

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

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

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

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

ערכת תבניות, תרשימים ונהלי מסירה

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

• תבניות סביבה — תיאורי CloudFormation לפיתוח, בדיקה ופרודקשן. נבדלות בפרמטרים, ולא בעותקים של קוד: שינוי במקום אחד לא מתפצל לשלוש גרסאות.
• תרשימי תלויות — סדר יצירה ומחיקה של משאבים, stacks מקוננים, העברת ערכים ביניהם. לפי התרשים רואים מה ישפיע על שינוי של משאב מסוים.
• מדיניות גישה — תפקידים לפריסה ולאפליקציות, גבולות הרשאות, הפרדה בין שינויים ידניים לשינויים דרך תבנית.
• נוהל שינויים — branch, בנייה, בדיקה על ידי מהנדס שני, אישור לסביבת הפרודקשן, סדר חזרה לגרסה קודמת.
• תיעוד — ייעוד הפרמטרים, ערכי פלט, הוראות פריסה מאפס, מגבלות ידועות ופתרונות עוקפים.
• הגנות מפני הרס מקרי — איסור מחיקת stack, מדיניות לעדכון משאבים קריטיים, השוואה קבועה בין המצב בפועל לתיאור.
• קטלוג קטעים לשימוש חוזר — בלוקים טיפוסיים של רשת, אחסון והרשאות, שמחוברים לשירותים חדשים במקום להעתיק אותם.

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

מקרה בוחן: איך התקצר זמן הפריסה של הסביבה

סביבת קבלה וקדם-פרודקשן נבנתה ידנית לפי הוראות: רשתות, מאזן עומסים, בסיסי נתונים, הרשאות גישה. פריסה מלאה ארכה 6–8 שעות עבודה של שני מהנדסים, ואי-התאמות בין סביבות צפו כבר בבדיקות — חלק מהשינויים הוחזרו לאחור בתיקונים הפוכים ישירות ב-console.

תיארנו את התשתית באופן דקלרטיבי בתבניות Amazon Web Services CloudFormation: stack נפרד לכל סביבה, פרמטרים משותפים הוצאו לשכבה נפרדת, שינויים עוברים סקירה לפני יישום. החזרה לאחור הפסיקה להיות פעולה ידנית — חזרה ל-stack הקודם אורכת צעד אחד.

לפני ואחרי

פריסת הסביבה מאפס התקצרה מ-6–8 שעות ל-20–25 דקות, ומפעיל אותה מהנדס אחד, בלי לחכות לאחרים. שיעור הכשלים בפריסה ירד בערך פי שלושה: הסביבה משוחזרת אחת לאחת, מפני שהשינויים מגיעים מהתיאור ולא מתיקונים ידניים. זמן השחזור לאחר כשל תצורה ירד מכמה שעות ל-10–15 דקות — הסביבה פשוט נבנית מחדש.

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

במה AWS CloudFormation שונה מתרחישים ידניים?

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

אפשר ליישם בחלקים?

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

איך לעקוב אחרי שינויים ידניים?

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

איך לחלק הרשאות גישה?

תפקידים מקושרים ל-stacks ולסביבות. לפרודקשן שינויים נכנסים רק דרך pipeline עם סקירה; למפתחים — סביבת בדיקה וקריאת מצב הפרודקשן.

מה עם חזרה לאחור של שינויים?

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

נדון במשימה ונחזור עם תוכנית יישום

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

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

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

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

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