במאמר הקודם הסברנו איך איש ה-DevOps שותף לתהליכי הפיתוח בחברה. היום נמשיך בהצגת ה DevOps Role וחשיבותו לכל ארגון. המאמר הראשון התמקד בעיקר בתחום ה-CI, בחלק זה נעסוק יותר בתחום ה-CD.
הטמעה
כאשר יש לנו רכיב מתפקד ובדוק, הגיע הזמן להטמיע אותו. שלב זה השתנה מאוד עם השנים. במאמר זה אתייחס רק לגישת הקונטיינרים בצורה מעמיקה. שיטות ישנות יותר כוללות הטמעה בשרתים פיזיים או וירטואלים. שיטות חדשות יותר כוללות טכנולוגיות כמו Serverless לדוגמא (אולי ארחיב עליה בהזדמנות אחרת). אז לענייננו, אחלק קטע זה לשני חלקים: העטיפה שלרוב קורית בשלב ה-CI ועדכון לשרתים שאמור לקרות בשלב ה-CD.
עטיפה
את הקוד הבדוק נהפוך ל-Docker Image בעזרת Dockerfile וכלי שיהפוך את סט הפקודות הזה ל-image כמו-Docker/Kaniko או-Buildah. בשלב זה ישנו מחקר מתמיד במטרה להגיע ל-image שידרוש כמה שפחות משאבים כיוון שיכול להיות שניצור ממנו המון instances. אסטרטגיה לדוגמא להשגת מטרה זאת הינה Multi-Stage Build. לפעמים נכניס images של אפליקציות צד שלישי מבחוץ ואז יתווספו לשלב זה סריקות אבטחה.
העלאה
בחלק זה נרצה לשמור במקום מרוכז את כל ה-images שיצרנו לפני ולהטמיע בסביבה שלנו. כדי לעשות זאת יש להרים Image Registry כגון Docker Hub או Hurbor או Artifactory או Openshift CPR. אל ה-Image Registry יש להעלות את התמונה שבנינו (על איש ה-DevOps לתחזק ולהבין את הארכיטקטורה של הכלי שנבחר כדי לקנפג אותו בצורה יעילה).
לאחר שהעלינו את ה-Image, נכנס הכלי שינהל את חיי הקונטיינר: משלב היצירה דרך בדיקות חיות וזמינות ועד להורדה והעלאה על פי פקודה. במקרה של שרת יחיד נוכל להסתפק ב-Docker (בשביל POC לדוגמא). במקרה של כמה שרתים נעבור לאורקיסטרטור, כמו kubernetes או docker swarm (במאמר זה אתייחס ל-k8s). ככל שיש צורך בתשתית גדולה יותר כך נדרש כוח אדם גדול יותר. בחלק הזה נכנס הגדרת ה-Infrastructure – בעידן של היום יש צורך לדאוג לתשתית מודולרית, יציבה ונוחה לניהול שתאדיר את יכולות האפליקציה שיושבת עליה. בנוסף, היא נדרשת לספק לה את המשאבים הדרושים ולא מעבר לכך.
ישנם המון אובייקטים הבנויים מעל יחידת הבניין הבסיסית (pod) של האורקסטרטור (Kubernetes) . לכל אחד מסוגי האובייקטים באורקיסטרטור use case משלו. בגישה החדשה Infrastructure as Code, נכתוב קובץ קונפיגורציה (בדרך כלל Yaml או Json) שיגדיר את התשתית שלנו. נעלה את הקבצים ל-scm ונדאג לכך שהתשתית תותאם אליו כך ששינוי בקונפיגורציה שיעלה לSCM יגרום לשינוי של התשתית בפועל. כלים כמו Flux ו-Argo Cd עושים חלק זה בצורה אוטומטית. על חלק זה מבחינת האפליקציה שולט תהליך ה-CD שבכל כלי CI/CD נראה קצת אחרת. המטרה דומה, להטמיע את הקוד כל פעם שגרסא נעטפה בהצלחה.
ניטור וטיפול בלוגים
האפליקציה באוויר ויש משתמשים אבל דברים מתחילים לא לעבוד. מתגלים באגים קטנים ורוחביים שלא כוסו על ידי הבדיקות ושרתים מפסיקים לעבוד, איך נתמודד עם זה?
- ניטור לכל מה שקשור לתשתית עם סטאק ניטור שאוסף את הנתונים, מאנדקס אותם ומציג. לדוגמא, Prometheus ו-Grafana. כתלות בדרישת החברה האחריות על ה-Dashboards יכולה להיות של אנשי ה-DevOps. איש ה-DevOps צריך להבין מה קורה עם התשתית בכל רגע נתון. הניטור מספק את הכלי להשגת מטרה זאת ודרכו ניתן לראות תוצאות של scenarios תשתיתיים. לדוגמא, במקומות רבים בונים תרחישים של עומס כדי להבין מה מצב העמידות של התשתית והאפליקציה. תרחישים אלו הינם הבדיקות הארוכות עליהן דברתי בחלק של בדיקות והן ההצדקה לקיום סביבת staging בין היתר. באמצעותן ובעזרת כלי ניטור איש ה-DevOps יוכל להסיק מה הבעיה ומה הרכיב הבעייתי.
- טיפול בלוגים לכל מה שקשור לאפליקציה עצמה. שימוש ב-ELK או Splunk כדי לאסוף את הלוגים מכל הרכיבים וליצור trace שיעזור לנו לטפל גם בבאגים רוחביים שנוגעים בכמה רכיבים. בכדי שכל זה יצליח על אנשי הדוופס להכווין את המפתחים לעבוד לפי סטנדרט לוגים אחיד כמו OpenTracing בכל שפה כך שיהיה קל למצוא את הבעיה ולטפל בה במהירות ובמקצועיות.
משוב
אחרי כל גרסא חדשה מומלץ לקבל משוב מהלקוחות כדי להפיק לקחים. לפעמים גם זה בתחום האחריות של אנשי ה-DevOps – להנגיש את המידע הזה לאנליסטים או ל-data engineers כך שהם יוכלו לעבוד איתו ולהסיק מסקנות מהצד האפליקטיבי. מהצד התשתיתי ישנו גם משוב והוא כולל בין היתר סוגיות כגון עלות התשתית, האם ניתן לצמצם עלות זאת, האם הארכיטקטורה התשתיתית עמדה בציפיות ואם לא מה המסקנות. בתחום זה אין כלי שנחשב סטנדרט כי זה מאוד תלוי מקרה. בחלק זה יש שימוש בכלים כמו well architected של aws בכדי להסיק מסקנות בנושא שיפורים בארכיטקטורה. מפה חוזרים לתכנון (!Agile).
בחלק זה המשכתי והסברתי על תפקיד איש ה-DevOps בחברה אך זה לא הכל. בחלק השלישי אסביר על התחום האנושי (soft skills) והצורך בבניית אוטומציות וכלים פנימיים בחברה שמפתחי ה-DevOps דואגים לפתח למען הפרודוקטיביות הכללית של החברה.