שלום לכולם בבלוג הזה! זהו הפוסט השלישי בסדרה בו אנו מראים כיצד לפרוס יישומי אינטרנט מודרניים ב-Red Hat OpenShift.
בשני הפוסטים הקודמים, הראינו כיצד לפרוס יישומי אינטרנט מודרניים בכמה שלבים בלבד וכיצד להשתמש בתמונת S2I חדשה יחד עם תמונת שרת HTTP מדף, כגון NGINX, תוך שימוש ב-builds משורשרים כדי לתזמן פריסות ייצור. .
היום נראה כיצד להפעיל שרת פיתוח עבור האפליקציה שלכם בפלטפורמת OpenShift ולסנכרן אותו עם מערכת הקבצים המקומית, וכן נדבר על מה זה OpenShift Pipelines וכיצד ניתן להשתמש בהם כחלופה למכלולים מקושרים.
OpenShift כסביבת פיתוח
זרימת עבודה לפיתוח
כפי שכבר נאמר ב , תהליך הפיתוח האופייני ליישומי אינטרנט מודרניים הוא פשוט סוג של "שרת פיתוח" שעוקב אחר שינויים בקבצים מקומיים. כאשר הם מתרחשים, בניית האפליקציה מופעלת ואז היא מתעדכנת לדפדפן.
ברוב המסגרות המודרניות, "שרת פיתוח" כזה מובנה בכלי שורת הפקודה המתאימים.
דוגמה מקומית
ראשית, בואו נראה איך זה עובד בעת הפעלת יישומים באופן מקומי. ניקח את היישום כדוגמה ממאמרים קודמים, אם כי כמעט אותם מושגי זרימת עבודה חלים בכל המסגרות המודרניות האחרות.
לכן, כדי להפעיל את "שרת הפיתוח" בדוגמה שלנו ב-React, נזין את הפקודה הבאה:
$ npm run start
ואז בחלון הטרמינל נראה משהו כזה:
והאפליקציה שלנו תיפתח בדפדפן ברירת המחדל:
כעת, אם נבצע שינויים בקובץ, האפליקציה אמורה להתעדכן בדפדפן.
בסדר, הכל ברור עם פיתוח במצב מקומי, אבל איך להשיג את אותו הדבר ב-OpenShift?
שרת פיתוח ב-OpenShift
אם אתה זוכר, ב , הסתכלנו על מה שנקרא שלב הריצה של תמונת S2I וראינו כי כברירת מחדל, מודול השרת אחראי על שירות אפליקציית האינטרנט שלנו.
עם זאת, אם תסתכל מקרוב מהדוגמה הזו, הוא מכיל את משתנה הסביבה $NPM_RUN, המאפשר לך לבצע את הפקודה שלך.
לדוגמה, אנו יכולים להשתמש במודול ה-nodeshift כדי לפרוס את האפליקציה שלנו:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
הערה: הדוגמה לעיל מקוצרת כדי להמחיש את הרעיון הכללי.
כאן הוספנו לפריסה שלנו את משתנה הסביבה NPM_RUN, שאומר לזמן הריצה להפעיל את פקודת yarn start, שמתחילה את שרת הפיתוח React בתוך הפוד OpenShift שלנו.
אם תסתכל ביומן של תרמיל פועל, הוא ייראה בערך כך:
כמובן שכל זה לא יהיה כלום עד שנוכל לסנכרן את הקוד המקומי עם הקוד, שגם הוא מנוטר לשינויים, אבל חי על שרת מרוחק.
סנכרון מרחוק וקוד מקומי
למרבה המזל, הסטת צומת יכולה לעזור בקלות בסנכרון, ואתה יכול להשתמש בפקודת השעון כדי לעקוב אחר שינויים.
אז לאחר שהרצנו את הפקודה לפריסת שרת הפיתוח עבור האפליקציה שלנו, נוכל להשתמש בבטחה בפקודה הבאה:
$ npx nodeshift watch
כתוצאה מכך, יתבצע חיבור לפוד הריצה שיצרנו קצת קודם, יופעל סנכרון הקבצים המקומיים שלנו עם האשכול המרוחק, והקבצים במערכת המקומית שלנו יתחילו להיות במעקב אחר שינויים.
לכן, אם נעדכן כעת את קובץ src/App.js, המערכת תגיב לשינויים הללו, תעתיק אותם לאשכול המרוחק ותפעיל את שרת הפיתוח, שלאחר מכן יעדכן את האפליקציה שלנו בדפדפן.
כדי להשלים את התמונה, בואו נראה איך כל הפקודות האלה נראות:
$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000
$ npx nodeshift watch --strictSSL=false
הפקודה watch היא הפשטה על הפקודה oc rsync, אתה יכול ללמוד עוד על איך זה עובד .
זו הייתה דוגמה ל-React, אבל ניתן להשתמש באותה שיטה בדיוק עם מסגרות אחרות, פשוט הגדר את משתנה הסביבה NPM_RUN לפי הצורך.
צינורות עם הילוך פתוח
בשלב הבא נדבר על כלי כמו OpenShift Pipelines וכיצד ניתן להשתמש בו כחלופה לבנייה משורשרת.
מהם OpenShift Pipelines
OpenShift Pipelines היא מערכת אינטגרציה ואספקה מתמשכת CI/CD מקורית בענן המיועדת לארגון צינורות באמצעות Tekton. Tekton היא מסגרת CI/CD גמישה בקוד פתוח של Kubernetes, המאפשרת לך להפוך את הפריסה לאוטומטית בפלטפורמות שונות (Kubernetes, ללא שרתים, מכונות וירטואליות וכו') על ידי הפשטה מהשכבה הבסיסית.
הבנת מאמר זה דורשת ידע מסוים ב-Pipelines, לכן אנו ממליצים בחום לקרוא תחילה .
הגדרת סביבת העבודה שלך
כדי לשחק עם הדוגמאות במאמר זה, תחילה עליך להכין את סביבת העבודה שלך:
- התקן והגדר אשכול OpenShift 4. הדוגמאות שלנו משתמשות ב-CodeReady Containers (CRD) לשם כך, שניתן למצוא עבורן הוראות התקנה .
- לאחר שהאשכול מוכן, עליך להתקין עליו Pipeline Operator. אל תפחד, זה קל, הוראות התקנה .
- הורד (tkn) .
- הפעל את כלי שורת הפקודה create-react-app כדי ליצור אפליקציה שתפרוס לאחר מכן (זהו יישום פשוט ).
- (אופציונלי) שכפל את המאגר כדי להפעיל את היישום לדוגמה באופן מקומי עם npm install ולאחר מכן npm start.
למאגר היישומים תהיה גם תיקיית k8s, שתכיל את Kubernetes/OpenShift YAMLs המשמשים לפריסת האפליקציה. יהיו משימות, ClusterTasks, משאבים וצינורות שניצור בזה .
בואו נתחיל
הצעד הראשון עבור הדוגמה שלנו הוא יצירת פרויקט חדש באשכול OpenShift. בואו נקרא לפרויקט הזה webapp-pipeline וניצור אותו עם הפקודה הבאה:
$ oc new-project webapp-pipeline
שם הפרויקט הזה יופיע בקוד בהמשך, אז אם תחליט לקרוא לו משהו אחר, אל תשכח לערוך את הקוד לדוגמה בהתאם. החל מנקודה זו, לא נלך מלמעלה למטה, אלא מלמטה למעלה: כלומר, קודם כל ניצור את כל מרכיבי המסוע, ורק אחר כך את המסוע עצמו.
אז קודם כל...
משימות
בואו ניצור כמה משימות, שיעזרו לפרוס את האפליקציה בתוך הצינור שלנו. המשימה הראשונה - application_manifests_task - אחראית על החלת ה-YAML של משאבי Kubernetes האלו (שירות, פריסה ומסלול) שנמצאים בתיקיית k8s של האפליקציה שלנו. המשימה השנייה - update_deployment_task - אחראית על עדכון תמונה שכבר נפרסה לזו שנוצרה על ידי הצינור שלנו.
אל תדאג אם זה עדיין לא מאוד ברור. למעשה, משימות אלה הן משהו כמו כלי עזר, ואנו נבחן אותן בפירוט רב יותר מעט מאוחר יותר. לעת עתה, בואו פשוט ניצור אותם:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml
לאחר מכן, באמצעות פקודת tkn CLI, נבדוק שהמשימות נוצרו:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
הערה: אלו הן משימות מקומיות עבור הפרויקט הנוכחי שלך.
משימות אשכול
משימות אשכול זהות בעצם למשימות פשוטות. כלומר, מדובר באוסף רב פעמי של שלבים המשולבים בצורה כזו או אחרת בעת הפעלת משימה ספציפית. ההבדל הוא שמשימת אשכול זמינה בכל מקום בתוך האשכול. כדי לראות את רשימת משימות האשכול שנוצרות אוטומטית בעת הוספת Pipeline Operator, נשתמש שוב בפקודה tkn CLI:
$ tkn clustertask ls
NAME AGE
buildah 1 day ago
buildah-v0-10-0 1 day ago
jib-maven 1 day ago
kn 1 day ago
maven 1 day ago
openshift-client 1 day ago
openshift-client-v0-10-0 1 day ago
s2i 1 day ago
s2i-go 1 day ago
s2i-go-v0-10-0 1 day ago
s2i-java-11 1 day ago
s2i-java-11-v0-10-0 1 day ago
s2i-java-8 1 day ago
s2i-java-8-v0-10-0 1 day ago
s2i-nodejs 1 day ago
s2i-nodejs-v0-10-0 1 day ago
s2i-perl 1 day ago
s2i-perl-v0-10-0 1 day ago
s2i-php 1 day ago
s2i-php-v0-10-0 1 day ago
s2i-python-3 1 day ago
s2i-python-3-v0-10-0 1 day ago
s2i-ruby 1 day ago
s2i-ruby-v0-10-0 1 day ago
s2i-v0-10-0 1 day ago
עכשיו בואו ניצור שתי משימות אשכול. הראשון יפיק את תמונת S2I ותשלח אותה לרישום OpenShift הפנימי; השני הוא לבנות את התמונה שלנו על בסיס NGINX, באמצעות האפליקציה שכבר בנינו כתוכן.
צור ושלח את התמונה
בעת יצירת המשימה הראשונה, נחזור על מה שכבר עשינו במאמר הקודם על הרכבות מקושרות. נזכיר שהשתמשנו בתמונת S2I (ubi8-s2i-web-app) כדי "לבנות" את האפליקציה שלנו, ובסופו של דבר קיבלנו תמונה מאוחסנת ברישום הפנימי של OpenShift. כעת נשתמש בתמונת אפליקציית האינטרנט של S2I כדי ליצור DockerFile עבור האפליקציה שלנו ולאחר מכן נשתמש ב-Buildah כדי לבצע את הבנייה בפועל ולדחוף את התמונה המתקבלת לרישום הפנימי של OpenShift, מכיוון שזה בדיוק מה ש-OpenShift עושה כאשר אתה פורס את היישומים שלך באמצעות NodeShift .
איך ידענו את כל זה, אתם שואלים? מ , פשוט העתקנו אותו ושינינו אותו לעצמנו.
אז, עכשיו בואו ניצור את משימת אשכול s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
לא ננתח זאת בפירוט, אלא נתמקד רק בפרמטר OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
כברירת מחדל, פרמטר זה שווה ל-build, וזה המקום שבו React מכניס את התוכן המורכב. מסגרות אחרות משתמשות בנתיבים שונים, למשל, ב- Ember it is dist. הפלט של משימת האשכול הראשונה שלנו תהיה תמונה המכילה את HTML, JavaScript ו-CSS שאספנו.
בנה תמונה המבוססת על NGINX
באשר למשימת האשכול השנייה שלנו, היא אמורה לבנות עבורנו תמונה מבוססת NGINX, תוך שימוש בתוכן האפליקציה שכבר בנינו. בעיקרו של דבר, זה החלק של הסעיף הקודם שבו הסתכלנו על מבנים משורשרים.
לשם כך, אנו - בדיוק כמו למעלה - ניצור משימת אשכול webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
אם תסתכל על הקוד של משימות האשכולות האלה, אתה יכול לראות שהוא לא מציין את מאגר Git איתו אנחנו עובדים או את שמות התמונות שאנחנו יוצרים. אנו מציינים רק מה בדיוק אנו מעבירים ל-Git, או תמונה מסוימת שבה התמונה הסופית צריכה להיות פלט. זו הסיבה שניתן לעשות שימוש חוזר במשימות האשכולות הללו בעת עבודה עם יישומים אחרים.
והנה אנו עוברים בחן לנקודה הבאה...
Ресурсы
לכן, מכיוון שכפי שאמרנו זה עתה, משימות אשכול צריכות להיות כלליות ככל האפשר, עלינו ליצור משאבים שישמשו כקלט (מאגר Git) וכפלט (התמונות הסופיות). המשאב הראשון שאנחנו צריכים הוא Git, היכן שהאפליקציה שלנו שוכנת, משהו כמו זה:
# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: web-application-repo
spec:
type: git
params:
- name: url
value: https://github.com/nodeshift-starters/react-pipeline-example
- name: revision
value: master
כאן PipelineResource הוא מסוג git. מפתח ה-url בקטע params מצביע על מאגר ספציפי ומציין את ענף המאסטר (זה אופציונלי, אבל אנחנו כותבים את זה לשלמות).
כעת עלינו ליצור משאב עבור התמונה שבו יישמרו התוצאות של משימת s2i-web-app, זה נעשה כך:
# This resource is the result of running "npm run build", the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: built-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest
כאן ה-PipelineResource הוא מסוג image, והערך של הפרמטר url מצביע על רישום התמונות הפנימי של OpenShift, במיוחד זה שנמצא במרחב השמות של webapp-pipeline. אל תשכח לשנות הגדרה זו אם אתה משתמש במרחב שמות אחר.
ולבסוף, המשאב האחרון שאנו צריכים יהיה גם מסוג image וזו תהיה תמונת NGINX הסופית שתשמש לאחר מכן במהלך הפריסה:
# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: runtime-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest
שוב, שים לב שהמשאב הזה מאחסן את התמונה ברישום OpenShift הפנימי במרחב השמות של webapp-pipeline.
כדי ליצור את כל המשאבים הללו בבת אחת, אנו משתמשים בפקודה create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
אתה יכול לוודא שהמשאבים נוצרו כך:
$ tkn resource ls
צינור מסוע
עכשיו כשיש לנו את כל הרכיבים הדרושים, בואו נרכיב מהם צינור על ידי יצירתו בפקודה הבאה:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
אבל לפני שנפעיל את הפקודה הזו, בואו נסתכל על הרכיבים האלה. הראשון הוא השם:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
ואז בסעיף המפרט אנו רואים אינדיקציה למשאבים שיצרנו קודם לכן:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
לאחר מכן אנו יוצרים את המשימות שהצינור שלנו צריך להשלים. קודם כל, עליו לבצע את משימת s2i-web-app שכבר יצרנו:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
משימה זו לוקחת פרמטרים של קלט (משאב gir) ופלט (משאב אינטרנט-יישום-תמונה מובנה). אנחנו גם מעבירים לו פרמטר מיוחד כדי שהוא לא יאמת את TLS מכיוון שאנו משתמשים בתעודות בחתימה עצמית:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
המשימה הבאה כמעט זהה, רק שכאן משימת האשכול של webapp-build-runtime שכבר יצרנו נקראת:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
כמו במשימה הקודמת, אנחנו מעבירים משאב, אבל עכשיו זה מובנה-web-application-image (הפלט של המשימה הקודמת שלנו). וכפלט אנחנו שוב מגדירים את התמונה. מכיוון שמשימה זו חייבת להתבצע לאחר הקודמת, אנו מוסיפים את השדה runAfter:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
שתי המשימות הבאות אחראיות על השימוש בקבצי השירות, המסלול והפריסה של YAML שנמצאים בספריית k8s של אפליקציית האינטרנט שלנו, וגם על עדכון הפריסה הזו בעת יצירת תמונות חדשות. הגדרנו את שתי משימות האשכול הללו בתחילת המאמר.
הפעלת המסוע
אז, כל חלקי הצינור שלנו נוצרים, ואנחנו נריץ אותו עם הפקודה הבאה:
$ tkn pipeline start build-and-deploy-react
בשלב זה, שורת הפקודה משמשת באופן אינטראקטיבי ועליך לבחור את המשאבים המתאימים בתגובה לכל אחת מהבקשות שלה: עבור משאב git, בחר web-application-repo, ולאחר מכן עבור משאב התמונה הראשון, מובנה-web-application -image, ולבסוף, עבור משאב תמונה שני – runtime-web-application-image:
? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr
כעת נבדוק את מצב הצינור באמצעות הפקודה הבאה:
$ tkn pipeline logs -f
לאחר שהצינור התחיל והאפליקציה נפרסה, נוכל לבקש את המסלול שפורסם באמצעות הפקודה הבאה:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
להדמיה טובה יותר, אתה יכול להציג את הצינור שלנו במצב מפתחים של קונסולת האינטרנט בקטע צינורות, כפי שמוצג באיור. 1.
איור.1. סקירה של צינורות פועלים.
לחיצה על צינור פועל מציגה פרטים נוספים, כפי שמוצג באיור 2.
אורז. 2. מידע נוסף על הצינור.
לאחר מידע נוסף, תוכל לראות יישומים פועלים בתצוגה טופולוגיה, כפי שמוצג באיור 3.
איור 3. פוד הושק.
לחיצה על העיגול בפינה הימנית העליונה של הסמל פותחת את האפליקציה שלנו, כפי שמוצג באיור 4.
אורז. 4. הפעלת אפליקציית React.
מסקנה
אז, הראינו כיצד להפעיל שרת פיתוח עבור האפליקציה שלך ב-OpenShift ולסנכרן אותו עם מערכת הקבצים המקומית. בדקנו גם כיצד לדמות תבנית בנייה משורשרת באמצעות OpenShift Pipelines. ניתן למצוא את כל הקודים לדוגמה מהמאמר הזה .
משאבים נוספים (EN)
- ספר אלקטרוני בחינם
- נוסף על באתר Red Hat
הודעות על סמינרים מקוונים קרובים
אנו מתחילים סדרה של סמינרים מקוונים של יום שישי על חוויה מקורית בשימוש ב-Red Hat OpenShift Container Platform ו-Kubernetes:
מקור: www.habr.com
