אוטומציה של שרתי VK Cloud: Terraform, cloud-init ו-High-IOPS

הגדרת VK Cloud Servers: היכן שעבודה ידנית נכשלת

הגדרת שרתים בענן דרך קונסולת הווב נראית מהירה, כל עוד יש סביבה אחת בלבד. עד הסביבה השלישית מופיעים פערים: במכונת הבדיקה פתוח פורט שאינו קיים בפרודקשן, גרסת ספריית המערכת שונה, וכלל חומת האש קיים רק בלשונית של מישהו בדפדפן. לא ניתן עוד לשחזר סביבה כזו מאפס — אפשר лишь «בערך להיזכר» מה נעשה בידיים.

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

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

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

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

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

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

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

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

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

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

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

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

שלבי ההטמעה: מהאודיט ועד העברה לתמיכה

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

1. אודיט תשתית. ספירת מלאי: אילו שרתים באמת פועלים, אילו כרכים ורשתות מחוברים אליהם, מי ובאילו מפתחות ניגש, והיכן התצורה בפועל מתפצלת מהתיעוד. בלי צעד זה תיאור המשאבים פשוט מעביר את השגיאות לקוד.
2. תכנון סכימת הסביבות. מגדירים את מספר המערכים, בידוד הרשתות, אילו עומסים דורשים דיסקים בדרגת High-IOPS ואילו מסתפקים בסטנדרטיים. הסכימה נק�עת לפני כתיבת המניפסטים.
3. תיאור המשאבים. שרתים, רשתות, מאזני עומסים וכרכים מתוארים באופן דקלרטיבי ב-Terraform, וההגדרה הראשונית של המערכת — דרך cloud-init. המצב נשמר במאגר עם גישה מוגבלת, והמודולים משמשים מחדש בין הסביבות.
4. הגדרת תפקידים והרשאות. חשבונות נפרדים לאוטומציה ולאנשים, הרשאות לפי עקרון המינימום ההכרחי, מפתחות מונפקים עבור תפקיד ספציפי. תיקונים ידניים בקונסולה נחסמים — אחרת היישום הבא יבטל אותם.
5. בדיקת התצורה. העתק של המערך נפרס מאפס, נמחק ונבנה מחדש, ותוכנית השינויים נבדקת מול התשתית הקיימת. כך נבדקת יכולת השחזור והיעדר תלויות נסתרות.
6. העברה לתחזוקה. הצוות מקבל תיעוד, נוהל שינויים וסכימת חזרה ברורה; הרחבה, סבב מפתחות ועדכונים מבוצעים לפי הוראות ללא מעורבות מחברי הסכימה.

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

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

• תיאור התשתית — קבצים דקלרטיביים של VK Cloud Servers: רשת, תת-רשתות, דיסקים, קבוצות אבטחה, מאזן עומסים. המצב נשמר מרחוק עם נעילה, כדי ששני יישומים בו-זמניים לא יתפצלו.
• סכימות סביבות — מה שונה בין הסביבות, היכן נדרסים הפרמטרים, וכיצד להקים העתק של מערך הייצור לבדיקת שינויים.
• מדיניות גישה — תפקידים למהנדסים ולחשבונות שירות, עקרון ההרשאות המינימליות, סדר הנפקה וביטול של מפתחות וגישות לקונסולה.
• נוהל גיבוי — לוח זמנים לצילומי דיסקים, עומק השמירה, בדיקת שחזור בסביבה נפרדת, וסדר החזרה לנקודה הקודמת.
• תבניות הגדרה ראשונית — תרחישי cloud-init: חשבונות, עגינת דיסקים, התקנת סוכנים, כדי שמכונה חדשה תיכנס לפעולה ללא צעדים ידניים.
• תיעוד תחזוקה — הוראות למשמרת התורנות: מה משמעות אות הניטור, כיצד להרחיב דיסק, כיצד לחזור לריליס קודם, ולאן להסתכל קודם כול.

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

מקרה בוחן: העברנו סביבות ידניות לסכימה ניתנת לשחזור

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

העברנו את תיאור התשתית לתצורות דקלרטיביות: הרשת, דיסקים בדרגת High-IOPS עבור בסיסי הנתונים וההגדרה הראשונית של הצמתים הפכו לחלק מהקוד. VK Cloud סיפקה ממשק תכנותי שתצורות פונות אליו ישירות — לחיצה ידנית בפאנל הפסיקה להיות שלב בפריסה.

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

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

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

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

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

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

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

שאלות טכניות נפוצות לפני תחילת העבודה

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

כיצד בנוי הגיבוי והאם נבדק השחזור?

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

האם אפשר להעביר תמונות משלכם וכרכים לא-סטנדרטיים?

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

מה יקרה אם הספק ישנה את ממשקי הניהול?

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

מה כולל התחזוקה של התשתית לאחר ההטמעה?

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

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

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

מה כדאי לציין בבקשה:

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

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

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