Consul KV כמקור תצורה יחיד: מה נשבר
כל עוד הגדרות השירות חיות בשלושה מקומות — באימג', במשתני סביבה על המארח ובעריכות שנעשו ידנית במהלך חקירת תקלה — מקור האמת הופך למי שנכנס לשרת אחרון. יצרנו מחדש את הקונטיינר לאחר עדכון, והשירות עלה עם מגבלת חיבורים אחרת או כתובת תלות אחרת.
בסביבת בדיקות זה לא משוחזר: אי-ההתאמה צצה לאחר כמה שעות תחת עומס אמיתי, כשהסיבה כבר אבדה בין השינויים.
סוג התקלות השני — חוסר סנכרון של הגדרות בין סביבות. פרמטר תוקן בסביבת הבדיקות ולא הועבר לסביבת הייצור: הבדיקות ירוקות, אבל בפרודקשן יש זמן המתנה אחר ומכסה אחרת לבקשות חיצוניות.
מסוכן יותר כשערכים שמהם תלויים ניתוב או גישה לאחסון מתפצלים: חלק מהשירותים פונים בשקט למסד נתונים זר, וזה נראה כשגיאות קריאה אקראיות, לא כבעיית תצורה.
השלישי — אין לא היסטוריה ולא עקביות בהחלה. אי אפשר לענות מי ומתי שינה ערך, ולכן מבצעים חזרה לאחור מהזיכרון. גם העדכון אינו אטומי: חלק מהעותקים קראו מחדש את התצורה, חלק ממשיכות לעבוד עם הישנה, ובאותו אשכול חיות במקביל שתי גרסאות הגדרות. האבחון נתקע בשאלה לאיזה צומת הגיעה הבקשה.
מקור תצורה יחיד סוגר את שלוש הסיבות בבת אחת: תצורה מרכזית של שירותים נשמרת ב-Consul KV, השינויים מקבלים ניהול גרסאות ומשויכים במפורש לסביבה, וההחלה הופכת לניהולית. נסביר איך זה בנוי ואילו מלכודות מחכות בהטמעה לא זהירה.
מה נותנת תצורה מרכזית של שירותים
כשההגדרות נמצאות בקבצים על כל מכונה, כל שינוי הופך לסבב על פני כל השרתים: חלק מהצמתים קיבלו את הערך החדש, חלק ממשיכים לעבוד עם הישן, ואי-ההתאמה צצה רק בתקלה. ניהול תצורה מרכזי מסיר את סוג המשימות הזה: הערך חי במקום אחד, והשירותים מנויים על קידומת המפתחות שלהם. אחסון התצורה כאן הוא HashiCorp Consul.
זמן ההפצה של שינויים מתקצר בזכות מינוי על מפתח: השירות קורא מחדש את ההגדרה בלי הפעלה מחדש ובלי בנייה מחדש של האימג'. תיקון פרמטר מבוצע בנפרד מהפצת הקוד — הערך משתנה באחסון, והאפליקציה קולטת אותו בתוך שנייה. בפועל זה הופך שעות של תיאומים ופריסה לפעולה אחת ניתנת לבדיקה.
הפחתת מספר התקלות נובעת לא מעצם כתיבת הערך, אלא מהרשאות גישה ומניהול גרסאות. הרשאות ניתנות לפי קידומות: השירות קורא ומשנה רק את המפתחות שלו, ולכן טעות בשירות אחד לא דורסת הגדרות של אחרים.
תצורה אחידה לסביבות נבנית על סט מפתחות זהה — סביבות הבדיקה נבדלות בערכים, לא במבנה, ואי-ההתאמה בין הסביבות נעלמת.
זמן ההתאוששות נקבע לפי מהירות החזרה לאחור. כל שינוי במפתח נרשם עם מספר גרסה, ולכן חזרה לערך הקודם היא פעולה אחת במקום חיפוש התיקון בהיסטוריית הקבצים. חלק התקלות שקשורות לחוסר סנכרון הגדרות שואף לאפס, וחקירת אירוע מתחילה ביומן השינויים, לא בבדיקה ידנית של מכונות.
דרכים לאחסון תצורה: השוואת גישות
אפשר להחזיק הגדרות בשלושה מקומות, והבחירה ביניהם קובעת כמה זמן עובר מהתיקון ועד ההחלה ומה קורה בעת חזרה לאחור. מדובר בקבצים במאגר הקוד לצד הקוד, בקבצים ישירות על השרתים, ובאחסון מנוהל של מפתחות וערכים. לכל אחד יש סוג תקלות משלו, והגישות מחליפות זו את זו בצורה גרועה.
מאגר קוד נותן היסטוריית תיקונים וסקירה, אבל ההגדרה מגיעה לשירות רק יחד עם פריסה. קבצים על השרתים עובדים כל עוד יש מכונות בודדות, והופכים לאי-התאמה בתצורות כשהפארק גדל. אחסון מפתחות וערכים מעביר שינויים בלי בנייה מחדש, אבל דורש סביבה נפרדת, הפרדת הרשאות וגיבויים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הגדרות במאגר הקוד | התצורה משתנה יחד עם הגרסה, צריך היסטוריה וסקירה | תיקון דורש בנייה מחדש ופריסה; סודות נשארים בהיסטוריה |
| קבצים על השרתים | מעט מכונות, הפרמטרים סטטיים | אי-התאמה בין צמתים, אין ניהול גרסאות, תיקונים ידניים |
| משתני סביבה | הפרמטרים משויכים לסביבת ההרצה | אין היסטוריה, עצי הגדרות גדולים אינם קריאים, תלויים בזמן ריצה |
| אחסון מפתחות וערכים | יש הרבה הגדרות, הן משתנות לעיתים קרובות ובצוותים שונים | דרושים סביבה משלו, הרשאות, ביקורת, גיבויים והגנת סודות |
בפועל זה לעיתים רחוקות "או-או": פרמטרים סטטיים נשארים לצד הקוד, משתני סביבה משייכים את השירות לסביבה, וערכים שמשתנים לעיתים קרובות עוברים לאחסון. בהמשך נסביר איך בנויה העבודה עם Consul KV ומה נותנת העברה כזו.
שלבי הטמעה: מביקורת תצורות ועד מסירה
הטמעת Consul KV מתחילה לא בהתקנה, אלא בביקורת תצורות: כל עוד לא רואים אילו פרמטרים היכן מוגדרים ומי משנה אותם, כל עץ מפתחות ייצא שרירותי ובעוד חודש יתפזר. לכן העבודה מתנהלת בשלבים עוקבים, וכל שלב נסגר בארטיפקט שאתם מקבלים יחד איתנו.
- מיפוי מלאי. אוספים משתני סביבה, קובצי הגדרות, סקריפטים לפריסה וערכים שמוטבעים ישירות בקוד — עם שיוך לסביבות הבדיקה.
- ביקורת תצורות. מחלקים את הפרמטרים לסודות, פרמטרים כלל-שירותיים ופרמטרים יישומיים, מסמנים כפילויות, אי-התאמות בין סביבות וכל מה שמתוקן ידנית.
- תכנון סכימת עץ המפתחות. קובעים היררכיה של "סביבה → שירות → רכיב", כללי שמות וסדר ירושת ערכים.
- העברת הגדרות. מניחים את הערכים לפי הסכימה המתוכננת, כשהמקור הקודם נשאר פעיל עד לאימות נכונות.
- הגדרת גישה. נותנים לשירותים ולמהנדסים הרשאות נפרדות לקריאה ולכתיבה, כך שתיקון פרמטרים בפרודקשן יהיה פעולה מודעת.
- בדיקה. מריצים את סביבת הבדיקה, משווים התנהגות שירותים לפני ואחרי, ומתרגלים חזרה להגדרות הקודמות.
- מסירה. מוסרים תיאור של עץ המפתחות, נוהל שינויים והדרכה למשמרת התורנות.
עץ מפתחות, מדיניות גישה ונוהל שינויים
אחרי הגדרת Consul KV בפרויקט נשארת לא קבוצת מפתחות, אלא מערכת עובדת: לפיה מהנדס חדש מקים סביבה בלי שיחות עם המחבר, והתורן מבין מה ואיפה לשנות. אנחנו מוסרים ומתחזקים ארטיפקטים כאלה.
- עץ מפתחות — סכימת מרחבי שמות, מוסכמת שמות כמו
שירות/סביבה/פרמטרוכלל: מה חי בשורש המשותף ומה מוחלף בסביבת הבדיקה. - מדיניות גישה — תפקידים המשויכים לקידומות: קריאה לשירותים, כתיבה רק לצינור האספקה, סביבה נפרדת לסודות.
- תבניות תצורה — תבניות מוכנות לשירותים טיפוסיים, כך שרכיב חדש ייקח פרמטרים לפי דוגמה, לא בהעתקת בלוק של אחר.
- נוהל שינויים — מי יוזם תיקון, אילו ערכים דורשים מאשר שני, ואילו התורן משנה בעצמו.
- סדר חזרה לאחור — ניהול גרסאות של ערכים והוראה כיצד להחזיר סט פרמטרים קודם באופן נקודתי, בלי הפעלה מחדש של כל הסביבה.
- הוראות לתורן — תרחישים לתקלות טיפוסיות: פרמטר לא הוחל, השירות לא רואה ענף, הגישה נדחתה על ידי מדיניות.
- ביקורת תיקונים — יומן פניות ל-KV והתראות על קידומות קריטיות, כדי ששינוי לא יעבור בלי שיבחינו בו.
הארטיפקטים נמצאים לצד הקוד ומתעדכנים יחד איתו — העץ, המדיניות והתבניות לא מתפצלים מהמציאות אחרי הגרסה הבאה.
מקרה בוחן: ביטול חוסר סנכרון תצורות בין סביבות
מה היה לפני
שלוש סביבות — פיתוח, טרום-פרודקשן ופרודקשן — וכעשרה שירותים, שלכל אחד קבצי הגדרות משלו, שפוזרו על השרתים ידנית. תיקון של פרמטר אחד לקח ערב שלם: להתחבר לכל מכונה, לשנות, להפעיל מחדש, לבדוק.
אי-ההתאמות בין הסביבות גרמו לתקלות: בסביבת טרום-פרודקשן תצורה אחת, בפרודקשן אחרת, והסיבה צצה רק אחרי הפריסה.
מה שינינו
רכזנו את הפרמטרים באחסון יחיד Consul KV — נקודת אמת אחת לכל הסביבות. קובצי ההגדרות נבנים ממנו בעת הפעלת השירות, וההבדלים בין הסביבות מתוארים במפורש: מפתחות משותפים עוברים בירושה, ומפתחות ייחודיים מוחלפים ברמת הסביבה. כל שינוי עובר בדיקה ונכנס להיסטוריית גרסאות — רואים מי, מתי ומה שינה, ויש לאן לחזור.
מה קרה אחרי
תיקון פרמטר לוקח דקות במקום ערב שלם: מפתח אחד משתנה, ושאר השירותים קולטים אותו בעצמם. ברבעון שלפני המעבר יותר ממחצית התקלות בפריסה נבעו מאי-התאמה בהגדרות — כעת תקלות כאלה נעלמו, כי אי-ההתאמה נראית לפני ההפצה, לא בסביבת הייצור.
זמן ההשבתה בשינויים מתוכננים הצטמצם משעות להפעלה מחדש של שירות אחד, והחזרה לגרסת ההגדרות הקודמת היא צעד אחד.
במה Consul KV שונה מתצורה במאגר קוד?
אלה שני סוגים שונים של אחסון, לא אפשרויות חלופיות. תצורה במאגר קוד היא ארטיפקט בלתי משתנה: הערך עובר סקירה ומגיע לסביבה יחד עם הגרסה. Consul KV הוא אחסון חי של ערכי זמן ריצה: האפליקציה קוראת פרמטר בעת ההפעלה או מנויה על שינויים באמצעות תשאול ארוך של הסוכן.
מכאן ההבדל במהירות ההחלה. תיקון במאגר קוד הוא קומיט, בדיקה, בנייה ופריסה; עבור סף אחד מדובר בדקות ולעיתים יותר. כתיבה ל-KV מגיעה למנויים בשברירי שנייה, בלי בנייה מחדש והפעלה מחדש של השירות, ולכן תיקון חירום של מגבלה או כתובת שירות נעשה תוך כדי תנועה.
ניהול הגרסאות בנוי אחרת. מאגר קוד נותן היסטוריה מלאה, שיוך למחבר וחזרה לאחור בפקודה אחת. ב-KV יש אינדקס שינוי וכתיבה עם השוואת ערך, שמגנה מפני תיקונים במקביל, אבל אין היסטוריית ערכים — אותה מתחזקים ידנית: תמונות מצב, שכפול מפתחות או ייצוא למאגר קוד בכל כתיבה.
גישה וסודות הם ההבדל הבולט ביותר. במאגר קוד ההרשאות ניתנות על ידי מערכת ניהול הגרסאות, אבל סיסמה שנכנסה להיסטוריה נשארת שם לנצח. ב-KV מגבילים גישה באמצעות מדיניות ACL לפי קידומות: השירות מקבל טוקן לקריאה בלבד של ענף המפתחות שלו.
עם זאת, הערכים ב-KV נמצאים בטקסט גלוי — לסיסמאות ולמפתחות מחזיקים אחסון סודות נפרד, וב-KV שומרים פרמטרים והפניות אליהם.
הבחירה כאן היא לא "או", אלא "גם": הגדרות בלתי משתנות חיות במאגר קוד, והמשתנות — ב-KV.
שאלות טכניות על אחסון תצורה
אחסון הפרמטרים הוא נקודת כשל משותפת: אם השירות לא מקבל את ההגדרות שלו בעת ההפעלה, הוא לא עולה. להלן תשובות לשאלות שמהנדסים שואלים לרוב לפני העברת פרויקט ל-Consul KV מבית HashiCorp: מהן תלויים סכימת הקידומות, ההרשאות וסדר הפריסה.
מה יקרה אם האחסון לא יהיה זמין?
הסוכן מחזיק עותק מקומי של המפתחות הנדרשים ומוסר אותו לשירות גם כשהאשכול אינו זמין, וכמה צמתים באזורים שונים שורדים אובדן של חלק מהם. הפעלה קרה בלי עותק כזה היא תרחיש הכשל היחיד, ולכן הסוכן נמצא לצד האפליקציה, והפרמטרים לא נשלפים ברשת בכל הפעלה.
איך להפריד גישה לפרמטרים?
ההרשאות ניתנות לפי קידומת מפתחות: השירות קורא רק את הענפים שלו, והכתיבה נשארת בידי בעל הענף. הטוקנים משויכים לתפקיד ובעלי תוקף, והשינויים נכנסים ליומן — רואים מי ומתי שינה ערך. אין צורך ב"טוקן-על" משותף במשתני סביבה.
איך לחזור משינוי לא מוצלח?
תיקונים עוברים דרך מאגר קוד ובדיקות אוטומטיות, והאחסון מקבל מצב שכבר תואם — החזרה לאחור מסתכמת בהחזרת הגרסה הקודמת של הקובץ. תמונות מצב מחזירות את כל סט המפתחות בבת אחת, אם התיקון נגע בכמה שירותים.
מה המגבלות של הגישה?
אחסון KV לא מחליף מסד נתונים: נפחים גדולים, קבצים בינאריים וכתיבה תכופה אינם מתאימים לו. עקביות בין מפתחות מספקת האפליקציה, ולכן פרמטרים קשורים אנחנו מחזיקים במפתח אחד. סודות נשארים באחסון נפרד, וב-KV נמצאת הפניה אליהם.
ספקות נוספים — לגבי תאימות וסדר המיגרציה של פרויקט עובד — נפרט בהמשך.נדון במשימה: ננתח את סכימת התצורה שלכם
כדי שהערכת ההטמעה תהיה עניינית ותוכנית העבודה ברת ביצוע, אנחנו צריכים את סכימת התצורה שלכם: מאיפה השירותים מקבלים היום פרמטרים ואיך שינויים מגיעים לסביבת העבודה. להלן רשימה של מה שמספיק לתאר במילים או לשלוח כקבצים וסכמות: מתאימות גם תצוגות, צילומי מסך והערות קצרות.
- מקורות התצורה הנוכחיים: קבצים על השרתים, משתני סביבה, תבניות, סקריפטים עצמיים — ומה מזה כבר הועבר לאחסון משותף.
- רשימת השירותים והסביבות להעברה ל-Consul KV, עם סימון אילו פרמטרים משותפים ואילו ייחודיים לסביבת הבדיקה.
- איך שינויים מועברים כעת: מי מבצע אותם, כמה זמן לוקח המסלול עד סביבת העבודה ואיפה נוצרות לרוב אי-התאמות בין סביבות הבדיקה.
- עבודה עם סודות: היכן נמצאים סיסמאות ומפתחות, מי שיש לו גישה אליהם, והאם נדרש חיבור בין Consul KV לאחסון סודות נפרד.
- מדיניות גישה: אילו שירותים וצוותים קוראים או משנים ערכים, והאם נדרש יומן שינויים עם ציון מחבר התיקון.
- תרחיש חזרה לאחור: איך אתם מחזירים את התצורה הקודמת, תוך כמה זמן ומה קורה אז לשירותים פעילים.
- מגבלות תפעול: חלונות שינויים, דרישות לזמינות גבוהה של האשכול וקשרים בין אתרים.
תארו את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית עבודה: שלבים, הרכב השינויים ומה יידרש מכם בכל צעד.