הגדרה ואוטומציה של DigitalOcean Droplets לפרודקשן

אוטומציה של DigitalOcean Droplets: מה נשבר בהפעלה ידנית

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

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

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

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

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

מה נותנת האוטומציה: פריסות יציבות וחזרה לאחור מהירה

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

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

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

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

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

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

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

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

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

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

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

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

1. אודיט תשתית. אוספים תמונה מצבית: מלאי של Droplets, תגיות ותפקידים, מה הוגדר ידנית ואיפה הקונפיגורציות התפצלו בין צמתים, איך בנויים תמונות מצב, גיבויים וכללי גישה. בתוצר — מפת סיכונים ורשימת צווארי בקבוק עם עדיפויות.
2. סכמת סביבת היעד. מפרידים בין קונטור פרודקשן לקונטור בדיקות, מתארים סגמנטציית רשת, תפקידי צמתים, מקומות אחסון של סודות ומצב. בנפרד מתאמים מה מעבירים לתיאור דקלרטיבי ומה במודע נשאר ידני.
3. הכנת תבניות. בונים דימוי בסיסי עם תלויות ותרחיש אתחול ראשוני: שרת חדש מוקם מהתיאור ומקבל מיד את התפקידים הדרושים, ולא מוגדר "מהזיכרון".
4. הגדרת סביבות. פורסים קונטורים לפי תיאור אחד, מחברים ניטור, איסוף לוגים, התראות, רוטציית תמונות מצב ובדיקת גיבויים.
5. בדיקה. מריצים תרחישים: יצירה מחדש של צומת מאפס, חזרה לאחור של ריליס, שחזור מגיבוי, הדמיית כשל אזור. מודדים זמן של כל אחד — אלה הנורמות העתידיות למשמרת תורנות.
6. מסירה לתמיכה. מוסרים הרשאות גישה, נהלי תורנות והוראות לאירועים טיפוסיים, ומכשירים את צוות הלקוח. בשבועות הראשונים מלווים ומתקנים לפי מצב התפעול בשטח.

מה נשאר אצל הלקוח: סכמות, מדיניות, נהלים

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

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

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

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

מצב התחלתי

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

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

מה שינינו

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

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

מה השתנה

זמן השחזור הצטמצם מ-40–60 דקות ל-5–7: הצומת נוצר מחדש מהדימוי, הקונפיג מיושם לבד, התעבורה חוזרת אחרי מעבר בדיקות. פעולות ידניות בשחרור שינויים פחתו פי שלושה — במקום תיקונים בשלוש מכונות משתנה קובץ אחד במאגר.

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

במה שונה קונפיגורציה מנוהלת מהגדרה ידנית?

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

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

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

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

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

ספקות טכניים ותשובות מהנדסים

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

אפשר לעשות הטמעה מדורגת?

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

יש לנו סקריפטים ידניים — צריך לכתוב הכול מחדש?

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

מה קורה אחרי מסירת הפרויקט?

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

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

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

לפני ההערכה נבהיר:

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

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