במאמר על Kubernetes דיברנו על תפקידו והשימושים שלו. היום נדגים מעשית איך ניתן להעלות את האפליקציה שלנו על Openshift. זו מערכת מבית Red Hat, שהיא מעטפת נוחה ל-Kubernetes, אך כל הקונספטים במאמר זה תקפים גם ל Kubernetes .
מבוא
מטרתנו היא לקחת את הפרויקט שלנו שמורכב מ-git repository אחד או יותר (ארכיטקטורת micro services) ולהרים אותו עם containers על גבי OpenShift. בדוגמא שלנו ניקח אפליקצית flask בסיסית מ-repo אחד ונעלה אותה על OpenShift.
מי שצריך רענון על docker מוזמן לקרוא כאן.
נשתמש בפרויקט דוגמא של IBM. ראשית, נבנה מהפרויקט docker image בשם MY_FLASK_APP שיהיה קיים על השרת שלנו לוקאלית. ניתן להשתמש גם ב-images שקיימים ב-repo (לדוגמא ב-DockerHub):
git clone https://github.com/IBM/deploy-python-openshift-tutorial.git cd deploy-python-openshift-tutorial docker build -t MY_FLASK_APP .
OpenShift CLI
יצרנו docker image של האפליקציה שלנו. כדי להעלות את הפרויקט שלנו על גבי OpenShift נשתמש ב oc (OpenShift cli). המקביל שלו ב-Kubernetes נקרא kubectl. בעזרת ה-cli נייצר אובייקטים ב -OpenShift שמייצגים את הפרויקט שלנו. האובייקטים נשמרים ומיוצגים כקבצי yml אותם ניתן גם בעצמנו ליצור ולערוך. לפני הרצת הפקודות נדרשת התחברות באמצעות הפקודה oc login. ההתקנה של oc נמצאת כאן.
OpenShift – Project
ראשית ,כל פרויקט או סביבה ב-OpenShift מוגדרים כ-project (עטיפה משוכללת לאובייקט של k8s שנקרא Namespace).נרצה בכל project להרים את כל האובייקטים שרלוונטיים אליו בלבד. כך נוכל להריץ באותו cluster כמה פרויקטים מבלי שיכירו אחד את השני.
נריץ את הפקודה שתיצור לנו project (ניתן גם ליצור בנוחות באמצעות ה OpenShift web console ):
oc new-project MYֹ_FLASK_PROJECT
העלאת האפליקציה
השלב הבא הוא העלאת האפליקציה, כלומר נריץ את הפקודה oc new-app , הפקודה יכולה לקבל נתיב לפרויקט לוקאלי, url ל-repository או כמו בדוגמא – שם ה-docker image שיצרנו מקודם הקיים לוקאלית על המכונה שלנו:
oc new-app MYֹ_FLASK_APP
לאחר מכן, ייווצרו לנו במערכת כמה אובייקטים, נתאר אותם מלמעלה למטה:
Pod – ייווצר לנו הפוד המכיל בתוכו את ה-container שנרצה להריץ (לעיתים יכיל מספר קונטיינרים עם רשת ואחסון משותפים). הפוד הוא instance זמני של האפליקציה שלנו כפי שמוגדר ב-deployment config.
Deployment Config – מגדיר איך האפליקציה שלנו תרוץ. לצורך כך הוא מגדיר כמה דברים. ביניהם, מספר הפודים שירוצו, תנאים להגדלת/הקטנת מספר הפודים, deployment strategy ועוד. ה-strategy יגדיר איך יתבצע עדכון האפליקציה (ואפשר להגדיר תנאים לקביעת סטטוס “זמינות מלאה” של האפליקציה). כלומר, איך ייווצר פוד, איזה docker image ירוץ בפוד, איזה פורטים ייחשפו ועוד.
ה-OpenShift תמיד יקפיד על ריצת הפודים כפי שמוגדר להם בקובץ yml של ה deployment config.
למשל, אם נמחק או קרס פוד, הוא אוטומטית ירים פוד חדש כך שתמיד ירוצו המספר הרצוי של פודים זהים הרצים במקביל. מספר זה נקרא מספר ה-replicas של ה-deployment ומוגדר בקובץ.
אם מספר ה-replicas ישתנה ב-deployment הוא יעדכן את מספר הפודים הרצים. הגדלת מספר ה-replicas נקרא scale up ואילו הקטנתם נקראת scale down, כשמשתמשים ב-Load balancer אפשר להעלות ולהוריד את מספר הרפליקות על פי ה-traffic של האפליקציה.
כך נחיל deployment config:
oc apply -f my_deployment_config.yml
OpenShift – Service
ניתן גם לקשר ל-deployment אובייקט שנקרא service. service מאפשר לנו לנהל את התקשורת לפודים של ה-deployment. ניתן לחשוף route ל-service. ה-route מגדיר את הכתובת הקבועה שאיתה המשתמשים שלנו יוכלו לפנות ל-service. למרות שפוד זו ישות זמנית ובתכיפות נוצרים פודים חדשים שמחליפים זה את זה, עדיין בכל רגע נתון ללקוחות שלנו תהיה כתובת אחת קבועה לאפליקציה שלנו.
נחשוף את ה-route בעזרת הפקודה הבאה, כאשר ה-port הפנימי של ה-container נלקח מה-Dockerfile (הפורט המצוין בפקודת ה-expose) וה-url החיצוני מתקבל כארגומנט לפקודה או נוצר דיפולטית:
oc expose svc ROUTE_NAME
לסיום, לאחר חשיפת ה-route לעולם החיצון, בשביל להיכנס לאפליקציה שלנו ניכנס לכתובת המורכבת בפורמט הבא:
<ROUTE_NAME >-<MY_FLASK_PROJECT>.<suffix>
ניגש לפרויקט שלנו ונראה את המסך הבא:
בהמשך נראה עוד יכולות ש-Kubernetes ו-OpenShift יכולים להציע לנו ונסביר מושגים מתקדמים יותר.