הגדרת Docker Compose עבור סביבות בדיקה וייצור

Docker Compose בייצור: היכן התצורה נשברת

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

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

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

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

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

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

מה נותנת הפרדת הגדרות הסביבות

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

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

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

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

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

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

דרכים לארגון סביבות: השוואת אפשרויות

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

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

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

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

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

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

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

ארטיפקטים למסירה: קבצים, סכמות, נהלים

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

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

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

מקרה בוחן: איך שתי סביבות הפסיקו להיות שונות בהגדרות

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

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

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

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

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

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

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

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

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

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

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

סודות, כרכים ומיגרציות: שאלות טכניות נפוצות

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

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

האם אפשר לחזור לאחור מהדורה?

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

איך מופרדות הסביבות?

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

מי מקבל גישה לסודות?

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

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

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

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

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