אני מצטער, OpenShift, לא הערכנו אותך מספיק ולקחנו אותך כמובן מאליו

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

בדרך כלל אנחנו מתחילים עם התזה ש-Kubernetes זה רק Kubernetes, ו-OpenShift היא כבר פלטפורמת Kubernetes, כמו Microsoft AKS או Amazon EKS. לכל אחת מהפלטפורמות הללו יש יתרונות משלה, המתמקדים בקהל יעד מסוים. ואחרי זה, השיחה כבר זורמת להשוואה בין החוזקות והחולשות של פלטפורמות ספציפיות.

באופן כללי, חשבנו לכתוב את הפוסט הזה עם פלט כמו "תשמע, זה לא משנה איפה אתה מריץ את הקוד, ב-OpenShift או ב-AKS, ב-EKS, בכמה Kubernetes מותאמים אישית, כן בכל Kubernetes. (בואו נקרא לזה בקיצור KUK) "זה ממש פשוט, גם שם וגם שם."

לאחר מכן תכננו לקחת את ה-"Hello World" הפשוט ביותר ולהראות מה משותף ומהם ההבדלים בין ה-CMC ל-Red Hat OpenShift Container Platform (להלן, OCP או פשוט OpenShift).

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

באופן כללי, הגיע הזמן לחזרה בתשובה אקטיבית, ועכשיו נשווה צעד אחר צעד את הפעלת ה"Hello World" שלנו ב-KUK וב-OpenShift, ונעשה זאת בצורה אובייקטיבית ככל האפשר (טוב, אולי לפעמים נראה אישיות יחס לנושא). אם אתה מעוניין בדעה סובייקטיבית גרידא בנושא זה, אז אתה יכול לקרוא אותה כאן (EN). ובפוסט הזה ניצמד לעובדות ורק לעובדות.

אשכולות

אז, "שלום עולם" שלנו צריך אשכולות. בואו פשוט נגיד "לא" לכל ענן ציבורי, כדי לא לשלם עבור שרתים, רישום, רשתות, העברת נתונים וכו'. בהתאם לכך, אנו בוחרים אשכול צמת אחד פשוט על מיניקוב (עבור KUK) ו מיכלים מוכנים לקוד (עבור אשכול OpenShift). שתי האפשרויות הללו ממש קלות להתקנה, אך דורשות די הרבה משאבים במחשב הנייד שלך.

הרכבה על KUK-e

אז בואו נלך.

שלב 1 - בניית תמונת המכולות שלנו

בואו נתחיל בפריסה של "Hello World" שלנו ל-minikube. זה ידרוש:

1. 1. הותקן Docker.
2. 2. התקנת Git.
3. 3. מותקן Maven (למעשה, הפרויקט הזה משתמש ב-mvnw בינארי, אז אתה יכול להסתדר בלעדיו).
4. 4. למעשה, המקור עצמו, כלומר. שיבוט מאגר github.com/gcolman/quarkus-hello-world.git

הצעד הראשון הוא ליצור פרויקט של Quarkus. אל תפחד אם מעולם לא השתמשת ב-Quarkus.io - זה קל. אתה פשוט בוחר את הרכיבים שבהם אתה רוצה להשתמש בפרויקט (RestEasy, Hibernate, Amazon SQS, Camel וכו'), ואז Quarkus עצמו, ללא כל השתתפותך, מגדיר את הארכיטיפ של maven ומעלה הכל על github. כלומר, ממש לחיצה אחת של העכבר - וסיימת. זו הסיבה שאנחנו אוהבים את קווארקוס.

הדרך הקלה ביותר לבנות את "Hello World" שלנו לתמונה עם מיכל היא להשתמש בהרחבות quarkus-maven עבור Docker, שיעשו את כל העבודה הדרושה. עם כניסתו של Quarkus, זה הפך להיות ממש קל ופשוט: הוסף את התוסף Container-image-docker ותוכל ליצור תמונות עם פקודות maven.

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

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

./mvnw -X clean package -Dquarkus.container-image.build=true

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

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

לאחר הפעלת מופע ה-container, כל שנותר הוא לבדוק עם פקודת curl שהשירות שלנו פועל:

אז הכל עובד וזה היה ממש קל ופשוט.

שלב 2 - שלח את המיכל שלנו למאגר תמונות המכולה

לעת עתה, התמונה שיצרנו מאוחסנת באופן מקומי באחסון המכולה המקומי שלנו. אם אנחנו רוצים להשתמש בתמונה הזו בסביבת ה-KUK שלנו, אז אנחנו צריכים לשים אותה במאגר אחר. ל-Kubernetes אין את התכונות הללו, אז נשתמש ב-docerhub. כי ראשית, זה בחינם, ושנית, (כמעט) כולם עושים את זה.

זה גם מאוד פשוט, ויש צורך רק בחשבון dockerhub כאן.

אז, אנו מתקינים dockerhub ושולחים לשם את התמונה שלנו.

שלב 3 - התחל Kubernetes

ישנן דרכים רבות להרכיב תצורת kubernetes כדי להפעיל את "Hello World" שלנו, אבל נשתמש בפשוטה שבהן, כי אנחנו אנשים כאלה...

ראשית, אנו מתחילים את אשכול המיניקוב:

minikube start

שלב 4 - פריסת תמונת המיכל שלנו

כעת עלינו להמיר את הקוד ותמונת המכולה שלנו לתצורת kubernetes. במילים אחרות, אנחנו צריכים תרמיל והגדרת פריסה המצביעים על תמונת המכולה שלנו ב-docerhub. אחת הדרכים הקלות ביותר לעשות זאת היא להפעיל את פקודת create deployment המצביעה על התמונה שלנו:

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

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

שלב 5 - גישה פתוחה לשירות שלנו

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

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

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

נתעכב לרגע על אפשרות ה"-type" של פקודת החשיפה.

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

למשל, כתיבה type=LoadBalancer, אנו מאתחלים אוטומטית את מאזן העומס הציבורי בענן כדי להתחבר לאשכול Kubernetes שלנו. זה, כמובן, נהדר, אבל אתה צריך להבין שתצורה כזו תהיה קשורה באופן הדוק לענן ציבורי ספציפי ויהיה קשה יותר להעביר אותה בין מופעי Kubernetes בסביבות שונות.

בדוגמה שלנו type=NodePort, כלומר, הקריאה לשירות שלנו עוברת לפי כתובת ה-IP של הצומת ומספר היציאה. אפשרות זו מאפשרת לא להשתמש בעננים ציבוריים, אך דורשת מספר שלבים נוספים. ראשית, אתה צריך מאזן עומסים משלך, אז אנו נפרוס את מאזן העומס NGINX באשכול שלנו.

שלב 6 - הגדר מאזן עומסים

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

minikube addons enable ingress

כעת, עם פקודה אחת בלבד, ניצור בקר כניסה של Nginx שיעבוד בתוך אשכול המיניקובים שלנו:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

שלב 7 - הגדר את הכניסה

כעת עלינו להגדיר את בקר הכניסה של Nginx לקבל בקשות שלום-קווארקוס.

ולבסוף, עלינו ליישם את התצורה הזו.

kubectl apply -f ingress.yml

מכיוון שאנו עושים את כל זה במחשב שלנו, אנו פשוט מוסיפים את כתובת ה-IP של הצומת שלנו לקובץ /etc/hosts כדי להפנות בקשות http ל-minikube שלנו למאזן העומס של NGINX.

192.168.99.100 hello-quarkus.info

זהו, עכשיו שירות ה-minikube שלנו זמין מבחוץ דרך בקר הכניסה של Nginx.

ובכן, זה היה קל, נכון? או לא כל כך?

הפעל על OpenShift (מכולות מוכנות לקוד)

ועכשיו בואו נראה איך הכל נעשה בפלטפורמת Red Hat OpenShift Container Platform (OCP).

כמו במקרה של minikube, אנו בוחרים סכימה עם אשכול OpenShift בעל צומת יחיד בצורה של Code Ready Containers (CRC). פעם זה נקרא minishift והתבסס על פרויקט OpenShift Origin, אבל עכשיו זה CRC ובנוי על פלטפורמת OpenShift Container של Red Hat.

הנה, סליחה, אנחנו לא יכולים שלא לומר: "OpenShift זה נהדר!"

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

בואו נעבור על התהליך ונראה מה עלינו לעשות.

אז בדוגמה של minikube, התחלנו עם Docker... רגע, אנחנו לא צריכים את Docker מותקן על המחשב יותר.

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

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

שלב 1 - הפעלת אשכול OpenShift שלך

אנו משתמשים בקונטיינרים מוכנים לקוד מ-Red Hat, שהוא בעצם אותו Minikube, אבל רק עם אשכול Openshift מלא עם צומת יחיד.

crc start

שלב 2 - בנה ופריסה של האפליקציה לאשכול OpenShift

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

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

אנו נשתמש בתהליך Source 2 Image (S2I) של OpenShift, שיש לו מספר דרכים שונות לקחת את המקור שלנו (קוד או קבצים בינאריים) ולהפוך אותו לתמונה מכוללת שפועלת על אשכול OpenShift.

בשביל זה אנחנו צריכים שני דברים:

• קוד המקור שלנו במאגר git
• Builder-image, שעל בסיסו תתבצע ההרכבה.

יש הרבה תמונות כאלה, שמתוחזקות הן על ידי Red Hat והן על ידי הקהילה, ואנו נשתמש בתמונת OpenJDK, ובכן, מכיוון שאני בונה יישום Java.

אתה יכול להריץ בניית S2I הן מהמסוף הגרפי של OpenShift Developer והן משורת הפקודה. אנו נשתמש בפקודה new-app, ונגיד לה היכן להשיג את תמונת הבונה ואת קוד המקור שלנו.

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

זהו, האפליקציה שלנו נוצרה. בכך, תהליך S2I עשה את הדברים הבאים:

• יצר שירות build-pod לכל מיני דברים שקשורים לבניית האפליקציה.
• יצר תצורת OpenShift Build.
• הורדתי את תמונת ה-Builder לרישום OpenShift docker הפנימי.
• שיבוט את "Hello World" למאגר מקומי.
• ראיתי שיש שם מייבן פום וכך ערכתי את האפליקציה עם מייבן.
• יצר תמונת קונטיינר חדשה המכילה את אפליקציית Java המהידור והכנס את התמונה הזו לרישום הקונטיינר הפנימי.
• יצר פריסת Kubernetes עם מפרטים עבור פוד, שירות וכו'.
• הושקה תמונת פריסה של מיכל.
• הוסר שירות build-pod.

יש הרבה ברשימה הזו, אבל העיקר שהבנייה כולה מתרחשת אך ורק בתוך OpenShift, הרישום הפנימי של Docker נמצא בתוך OpenShift, ותהליך הבנייה יוצר את כל רכיבי Kubernetes ומריץ אותם על האשכול.

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

ועכשיו בואו נסתכל על היומנים של תרמיל ה-Builder: ראשית, שם תוכלו לראות כיצד Maven עושה את העבודה שלה ומוריד תלות כדי לבנות את אפליקציית ה-Java שלנו.

לאחר השלמת ה-maven build, מתחילים לבנות את תמונת המכולה, ואז התמונה הבנויה הזו נשלחת למאגר הפנימי.

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

oc get service

זה הכל. ויש רק צוות אחד. כל שעלינו לעשות הוא לחשוף את השירות הזה לגישה מבחוץ.

שלב 3 - הפוך את השירות לחשוף לגישה מבחוץ

כמו במקרה של KUK, בפלטפורמת OpenShift, "Hello World" שלנו זקוק גם לנתב כדי להפנות תעבורה חיצונית לשירות בתוך האשכול. ב-OpenShift זה מקל מאוד. ראשית, רכיב הניתוב HAProxy מותקן באשכול כברירת מחדל (ניתן לשנות אותו לאותו NGINX). שנית, ישנם משאבים מיוחדים וניתנים להגדרה הנקראים Routes, שמזכירים אובייקטים של Ingress ב-Kubernetes הישנים והטובים (למעשה, המסלולים של OpenShift השפיעו מאוד על העיצוב של אובייקטי Ingress, שכעת ניתן להשתמש בהם ב-OpenShift), אבל בשביל ה"שלום שלנו" עולם", וכמעט בכל שאר המקרים, המסלול הסטנדרטי מספיק לנו ללא תצורה נוספת.

כדי ליצור FQDN ניתן לניתוב עבור "Hello World" (כן, ל- OpenShiift יש DNS משלה לניתוב לפי שמות שירותים), אנו פשוט חושפים את השירות שלנו:

oc expose service quarkus-hello-world

אם אתה מסתכל על המסלול החדש שנוצר, תוכל למצוא שם את ה-FQDN ומידע ניתוב אחר:

oc get route

ולבסוף, אנו ניגשים לשירות שלנו מהדפדפן:

אבל עכשיו זה היה ממש קל!

אנחנו אוהבים את Kubernetes וכל מה שהטכנולוגיה הזו מאפשרת לכם לעשות, ואנחנו גם אוהבים פשטות וקלילות. Kubernetes תוכנן להפוך מיכלים מבוזרים וניתנים להרחבה לקלים להפליא לתפעול, אבל הפשטות שלו כבר לא מספיקה כדי להביא יישומים לייצור היום. כאן נכנסת לתמונה OpenShift, עומדת בקצב הזמן ומציעה Kubernetes הממוקדות במפתחים. מאמצים רבים הושקעו כדי להתאים את פלטפורמת OpenShift במיוחד עבור המפתח, כולל יצירת כלים כגון S2I, ODI, Developer Portal, OpenShift Operator Framework, שילוב IDE, קטלוגים למפתחים, אינטגרציה של Helm, ניטור ועוד רבים אחרים.

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

מקור: www.habr.com