דב-אופס: זה לא כזה מפחיד

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

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

שום דבר אחר ב-DevOps הוא לא מפחיד.

הקונסול ריק? לפני פאניקה, בודקים region

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

זו לא רק אנקדוטה. region הוא בחירה טכנית אמיתית. הוא משפיע על latency מול המשתמשים, על availability ועל מגבלות של compliance. אם עובדים עם מידע של משתמשים באירופה וצריכים לעמוד ב-GDPR, למיקום הפיזי של הדאטה יש משמעות. אבל לפני שבונים אסטרטגיית multi-region, כדאי לדעת באיזה אזור הענן יצרתם את המשאב.

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

SSH: מפתח פרטי הוא לא קובץ שעוברים עליו הלאה

אחר כך ניב עוברת לחיבור SSH. יש public key שאפשר לשתף עם השרת, ויש private key שאינו אמור לצאת מהמכונה. כשמפתח פרטי נחשף, זו לא תקלה שמסדרים עם retry - צריך לייצר מפתחות חדשים ולעשות rotation.

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

היא נוגעת גם ב-known_hosts. בפעם הראשונה שמתחברים לשרת, SSH שומר את הזיהוי שלו. כשהוא משתנה, הודעת remote host identification has changed אמורה להדליק נורה: אולי ה-IP השתנה, ואולי אתם כבר לא מול אותו שרת. אפשר להסיר את הרשומה המתאימה ולהתחבר מחדש, אבל לא כדאי להפוך אזהרת אבטחה להרגל של yes אוטומטי.

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

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

היתרון הפרקטי הוא עקביות. Docker מאפשר לארוז את סביבת הריצה כך שהיא תיראה אותו דבר אצל המפתח, אצל איש DevOps, אצל הלקוח ובענן. זה מצמצם את הפער שמסתתר מאחורי “it works on my machine”. הוא לא הופך את כל הבעיות לבלתי אפשריות, אבל הוא מפסיק לתת לסביבה להיות תירוץ עמום.

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

Kubernetes לא הופך מוצר לרציני

Kubernetes הוא פלטפורמת open source לניהול אוטומטי של הרבה קונטיינרים. ההקבלה של ניב ישירה: הקונטיינרים הם המטען, ו-Kubernetes הוא הקברניט שמסדר ומנהל אותם. הוא עוסק ב-pods, היחידות הנפרסות הקטנות; ב-nodes שעליהם הם רצים; וב-cluster שמכיל את ה-nodes.

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

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

RTFM הוא חלק מעבודה משותפת

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

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

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

פרוד מינס פרוד.

פרודקשן לא צריך עוד buzzword

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

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

DevOps היא אחריות של הארגון

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

צוות DevOps, SRE, Platform או Developer Experience יכול להיקרא בהרבה שמות. התפקיד שלו הוא enablement - לאפשר לארגון לעבוד כך. מפתחים אינם צריכים להפוך לאנשי תשתיות במשרה מלאה, אבל הם כן צריכים להבין את החלק שלהם במסלול בין commit לפרודקשן.

DevOps זה מתודולוגיה.

השורה התחתונה

• לפני שמחפשים תקלה מסתורית בענן, בודקים region והגדרות בסיסיות.
• private key, הרשאות ו-known_hosts הם חלק מהאבטחה של סביבת הפיתוח, לא פרטי מערכת שאפשר להתעלם מהם.
• קונטיינרים נותנים עקביות; Kubernetes נותן ניהול בקנה מידה. לא כל מוצר צריך את שניהם באותה רמה.
• קריאת שגיאה ותיעוד לפני פתיחת ticket שומרת את הזמן של כל הצוות לבעיות שבאמת דורשות אותו.
• פחות רכיבים זזים בפרודקשן פירושם פחות דברים שיכולים להישבר.
• DevOps עובד כשהוא אחריות משותפת של הארגון, לא כשזורקים אותו לצוות אחד.