בניית pipeline מאובטח לעדכון קונפיגורציה עם Vault, Lambda ו-Kubernetes

הבעיה

אפליקציות בפלטפורמת העיבוד הביטוחי של Harel היו צריכות דרך מבוקרת לעדכן קונפיגורציה והגדרות חיות, בלי פריסה ידנית מלאה בכל פעם. מסלול העדכון חצה כמה גבולות תשתית בתהליך אחד: UI של האפליקציה, נתוני secret וקונפיגורציה ב-HashiCorp Vault, שלב עיבוד באמצעות AWS Lambda, קונפיגורציית האפליקציה ב-Kubernetes ConfigMap, ו-pipeline פריסה שהיה צריך לרוץ מחדש כדי שהשינוי יגיע בפועל לאפליקציה הרצה. האתגר לא היה אף אחד מהרכיבים לבדו. האתגר היה לגרום לתהליך המלא, שכבר היה מוגדר, לעבוד נכון מקצה לקצה.

הקשר

התהליך שהדשבורד היה צריך לממש, עדכון שמתחיל בממשק המשתמש ועובר דרך Vault, Lambda, ConfigMap והרצה מחדש של ה-pipeline, היה הדרישה המוגדרת שקיבלתי. הארכיטקטורה של התהליך הוגדרה מראש, ולא הייתה חלק מהתכנון העצמאי שלי. בניתי את דשבורד הקונפיגורציה ב-React וב-Node.js ואת התהליך שמאחוריו כחלק מהעבודה על מערכות העיבוד הביטוחי של Harel. שירות עצמי למנהלי מוצר על קונפיגורציה שמוחזקת ב-MongoDB היה עבודה נפרדת ב-Harel. הוא לא חלק מהתהליך הזה.

אילוצים

• העדכון היה צריך לעבור דרך Vault ל-secrets ולקונפיגורציה, דרך Lambda להרצה, דרך Kubernetes ConfigMap למצב הקונפיגורציה היעד, ודרך הרצה מחדש של ה-pipeline כדי להגיע לאפליקציה הרצה, בסדר הזה.
• הצורה הכוללת של התהליך הוגדרה מבחוץ. המטרה הייתה לספק אותו נכון, לא לתכנן אותו מחדש.

התפקיד שלי

בניתי מקצה לקצה את דשבורד הקונפיגורציה ב-React וב-Node.js ואת התהליך שמאחוריו: מה-UI, דרך טעינת ה-secret מ-Vault, שלב ה-Lambda, עדכון ה-ConfigMap והרצה מחדש של ה-pipeline. הצורה הכוללת של התהליך הייתה הדרישה המוגדרת שמימשתי, לא ארכיטקטורה שבחרתי באופן עצמאי.

ארכיטקטורה וגישה

1. משתמש מפעיל את דשבורד הקונפיגורציה ב-React/Node כדי לשנות הגדרת אפליקציה.
2. נתוני ה-secret או הקונפיגורציה הרלוונטיים נטענים דרך HashiCorp Vault.
3. פונקציית AWS Lambda מבצעת את שלב ההרצה הנדרש על הנתונים האלה.
4. ה-Kubernetes ConfigMap היעד מתעדכן בקונפיגורציה החדשה.
5. ה-pipeline רץ מחדש כדי שהקונפיגורציה המעודכנת תגיע לסביבת האפליקציה החיה.

החלטות מרכזיות

• לממש את סדר התהליך הנדרש בדיוק, מקצה לקצה. הרצף UI, Vault, Lambda, ConfigMap, הרצה מחדש של ה-pipeline היה דרישה נתונה ולא בחירה בין חלופות. מה שהפך את הפריסה לנכונה היה מימוש כל שלביו, בלי לקצר אף גבול.
• להתייחס להרצה מחדש של ה-pipeline כמנגנון הפריסה ולא כתיקון חי. העברת השינוי דרך הרצה מחדש של ה-pipeline הקיים, כנדרש, אמרה שהעדכון הגיע לאפליקציה דרך נתיב הפריסה הסטנדרטי של הפלטפורמה, ולא דרך עקיפה.
• להגביל את הדשבורד להפעלת התהליך ולא לבעלות עליו. תפקיד הדשבורד היה להפעיל באופן אמין את התהליך הנדרש, מ-Vault דרך Lambda ועד ConfigMap, מבלי לקחת על עצמו אחריות לתשתיות עצמן, כגון אחסון secrets או ניהול הגישה לאשכול Kubernetes.

שיקולים ופשרות

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

תוצאות ואימות

הדשבורד אפשר לעדכן באופן מאובטח את הקונפיגורציה של אפליקציות עיבוד ביטוחי הפועלות ב-Kubernetes, וסיפק באופן אמין את תהליך הקונפיגורציה הנדרש: UI, Vault, Lambda, ConfigMap והרצה מחדש של ה-pipeline.

מה למדתי

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