יישומים מודרניים ב-OpenShift, חלק 2: בנייה משורשרת

שלום לכולם! זהו הפוסט השני בסדרה שלנו בו אנו מראים כיצד לפרוס יישומי אינטרנט מודרניים ב-Red Hat OpenShift.

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

תמונת בנאי נקייה

כפי שהזכרנו בחלק XNUMX, לרוב יישומי האינטרנט המודרניים יש מה שנקרא שלב בנייה, אשר בדרך כלל מבצע פעולות כמו תעתוק קוד, שרשור קבצים מרובים והקטנה. הקבצים המתקבלים כתוצאה מפעולות אלו - וזהו HTML סטטי, JavaScript ו-CSS - מאוחסנים בתיקיית הפלט. המיקום של תיקיה זו תלוי בדרך כלל באילו כלי בנייה משתמשים, ועבור React זו תהיה תיקיית ./build (נחזור לכך בפירוט רב יותר בהמשך).

מקור לתמונה (S2I)

בפוסט זה איננו נוגעים בנושא "מהו S2I וכיצד להשתמש בו" (תוכלו לקרוא עוד על זה כאן), אבל חשוב שיהיה ברור לגבי שני השלבים בתהליך זה כדי להבין מה עושה תמונה של Web App Builder.

שלב ההרכבה

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

במקרה של תמונת Web App Builder, הוא אחראי על התקנת התלות של האפליקציה שלך והפעלת ה-build. להרכיב סקריפט. כברירת מחדל, תמונת הבונה משתמשת במבנה npm run build, אך ניתן לעקוף זאת באמצעות משתנה הסביבה NPM_BUILD.

כפי שאמרנו קודם לכן, המיקום של היישום המוגמר, שנבנה כבר, תלוי באילו כלים אתה משתמש. לדוגמה, במקרה של React זו תהיה התיקיה ./build, ועבור יישומי Angular זו תהיה התיקיה project_name/dist. וכפי שכבר הוצג בפוסט הקודם, ניתן לעקוף את המיקום של ספריית הפלט, המוגדרת לבנייה כברירת מחדל, דרך משתנה הסביבה OUTPUT_DIR. ובכן, מכיוון שהמיקום של תיקיית הפלט שונה ממסגרת למסגרת, אתה פשוט מעתיק את הפלט שנוצר לתיקיה הרגילה בתמונה, כלומר /opt/apt-root/output. זה חשוב להבנת המשך המאמר הזה, אבל לעת עתה בואו נסתכל במהירות על השלב הבא - שלב הריצה.

שלב הריצה

שלב זה מתרחש כאשר מתבצעת קריאה ל-docer run על התמונה החדשה שנוצרה במהלך שלב ההרכבה. אותו דבר קורה בעת פריסה בפלטפורמת OpenShift. בְּרִירַת מֶחדָל להפעיל סקריפט использует מודול שירות לשרת תוכן סטטי הממוקם בספריית הפלט הסטנדרטית לעיל.

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

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

בונה משורשר

על זה הם כותבים בונים משורשרים בתיעוד של OpenShift:

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

במילים אחרות, אנו יכולים להשתמש בתמונת Web App Builder כדי להפעיל את ה-build שלנו, ולאחר מכן להשתמש בתמונת שרת האינטרנט, אותה NGINX, כדי לשרת את התוכן שלנו.

לפיכך, אנו יכולים להשתמש בתמונת Web App Builder כבונה "טהורה" ובמקביל לקבל תמונת זמן ריצה קטנה.

עכשיו בואו נסתכל על זה עם דוגמה ספציפית.

להדרכה נשתמש יישום פשוט של React, נוצר באמצעות כלי שורת הפקודה create-react-app.

זה יעזור לנו לחבר הכל ביחד קובץ תבנית OpenShift.

בואו נסתכל על הקובץ הזה ביתר פירוט, ונתחיל בסעיף הפרמטרים.

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: The source URL for the application
    displayName: Source URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: The branch name for the application
    displayName: Source Branch
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: The location within the source repo of the application
    displayName: Source Directory
    value: .
    required: true
  - name: OUTPUT_DIR
    description: The location of the compiled static files from your web apps builder
    displayName: Output Directory
    value: build
    required: false

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

עכשיו בואו נסתכל על קטע ImageStreams.

- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-builder  // 1 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-runtime  // 2 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: web-app-builder-runtime // 3
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: nginx-image-runtime // 4
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: 'centos/nginx-112-centos7:latest'

תסתכל על התמונה השלישית והרביעית. שתיהן מוגדרות כתמונות Docker, וניתן לראות בבירור מאיפה הן מגיעות.

התמונה השלישית היא web-app-builder והיא מגיעה מ-nodeshift/ubi8-s2i-web-app מתויג 10.x ב- רכזת דוקר.

הרביעית היא תמונת NGINX (גרסה 1.12) עם התג האחרון רכזת דוקר.

עכשיו בואו נסתכל על שתי התמונות הראשונות. שניהם ריקים בהתחלה ונוצרים רק בשלב הבנייה. התמונה הראשונה, react-web-app-builder, תהיה תוצאה של שלב הרכבה שישלב את תמונת ה-web-app-builder-runtime וקוד המקור שלנו. לכן הוספנו "-בונה" לשם התמונה הזו.

התמונה השנייה - react-web-app-runtime - תהיה תוצאה של שילוב של nginx-image-runtime וכמה קבצים מתמונת react-web-app-builder. תמונה זו תשמש גם במהלך הפריסה ותכיל רק את שרת האינטרנט ו-HTML סטטי, JavaScript, CSS של האפליקציה שלנו.

מְבוּלבָּל? עכשיו בואו נסתכל על תצורות הבנייה וזה יהפוך קצת יותר ברור.

לתבנית שלנו יש שתי תצורות בנייה. הנה הראשון, והוא די סטנדרטי:

  apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-builder
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-builder:latest // 1
    source:   // 2 
      git:
        uri: ${SOURCE_REPOSITORY_URL}
        ref: ${SOURCE_REPOSITORY_REF}
      contextDir: ${SOURCE_REPOSITORY_DIR}
      type: Git
    strategy:
      sourceStrategy:
        env:
          - name: OUTPUT_DIR // 3 
            value: ${OUTPUT_DIR}
        from:
          kind: ImageStreamTag
          name: web-app-builder-runtime:latest // 4
        incremental: true // 5
      type: Source
    triggers: // 6
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - imageChange: {}
      type: ImageChange

כפי שאתה יכול לראות, השורה עם תווית 1 אומרת שהתוצאה של הבנייה הזו תמוקם באותה תמונת react-web-app-builder שראינו קצת קודם בקטע ImageStreams.

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

השורה שכותרתה 3 היא מה שכבר ראינו בסעיף הפרמטרים. הוא מוסיף את משתנה הסביבה OUTPUT_DIR, שבדוגמה שלנו הוא build.
השורה שכותרתה 4 אומרת להשתמש בתמונת ה-web-app-builder-runtime, אותה ראינו כבר בקטע ImageStream.

שורה שכותרתה 5 אומרת שאנחנו רוצים להשתמש ב-build מצטבר אם תמונת S2I תומכת בזה, ותמונת Web App Builder כן. בהשקה הראשונה, לאחר השלמת שלב ההרכבה, התמונה תשמור את תיקיית node_modules לקובץ ארכיון. לאחר מכן, בריצות עוקבות, התמונה פשוט תפתח את התיקייה הזו כדי להפחית את זמן הבנייה.

ולבסוף, השורה שכותרתה 6 היא רק כמה טריגרים כדי לגרום לבנייה לפעול באופן אוטומטי, ללא התערבות ידנית, כאשר משהו משתנה.

בסך הכל מדובר בתצורת בנייה די סטנדרטית.

עכשיו בואו נסתכל על תצורת הבנייה השנייה. זה מאוד דומה לראשון, אבל יש הבדל אחד חשוב.

apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-runtime
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-runtime:latest // 1
    source: // 2
      type: Image
      images:                              
        - from:
            kind: ImageStreamTag
            name: react-web-app-builder:latest // 3
          paths:
            - sourcePath: /opt/app-root/output/.  // 4
              destinationDir: .  // 5
             
    strategy: // 6
      sourceStrategy:
        from:
          kind: ImageStreamTag
          name: nginx-image-runtime:latest
        incremental: true
      type: Source
    triggers:
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - type: ImageChange
      imageChange: {}
    - type: ImageChange
      imageChange:
        from:
          kind: ImageStreamTag
          name: react-web-app-builder:latest // 7

אז תצורת הבנייה השנייה היא react-web-app-runtime, והיא מתחילה די סטנדרטית.

השורה שכותרתה 1 אינה חדשה - היא פשוט אומרת שתוצאת הבנייה מוכנסת לתמונת ריact-web-app-runtime.

השורה שכותרתה 2, כמו בתצורה הקודמת, מציינת מאיפה להשיג את קוד המקור. אבל שימו לב שכאן אנחנו אומרים שזה נלקח מהתמונה. יתרה מכך, מהתמונה שיצרנו זה עתה - מ-react-web-app-builder (מסומן בשורה שכותרתה 3). הקבצים שאנו רוצים להשתמש בהם נמצאים בתוך התמונה ומיקומם שם מוגדר בשורה שכותרתה 4, במקרה שלנו זה /opt/app-root/output/. אם אתה זוכר, כאן מאוחסנים הקבצים שנוצרו על סמך תוצאות בניית האפליקציה שלנו.

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

קטע האסטרטגיה - קו שכותרתו 6 - דומה גם לתצורת הבנייה הראשונה. רק שהפעם אנחנו הולכים להשתמש ב-nginx-image-runtime, שכבר ראינו בקטע ImageStream.

לבסוף, השורה שכותרתה 7 היא קטע של טריגרים שיפעיל את המבנה הזה בכל פעם שתמונת React-Web-App-Builder משתנה.

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

פריסת יישומים

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

אנו יכולים להשתמש בכלי הלקוח OpenShift שנקרא oc כדי לפרוס את התבנית שלנו:

$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f

$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app

הפקודה הראשונה בצילום המסך למעלה היא דרך הנדסית במכוון למצוא תבנית./openshiftio/application.yaml.

הפקודה השנייה פשוט יוצרת יישום חדש המבוסס על תבנית זו.

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

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

לחץ על הקישור ונועבר לאפליקציה שלנו, שהיא דף אפליקציית React המוגדר כברירת מחדל:

מוסף 1

לאוהבי Angular יש לנו גם יישום לדוגמה.

הדפוס כאן זהה, למעט המשתנה OUTPUT_DIR.

מוסף 2

במאמר זה השתמשנו ב-NGINX כשרת אינטרנט, אבל די קל להחליף אותו ב-Apache, פשוט שנה את התבנית בקובץ תמונת NGINX על תמונת אפאצ'י.

מסקנה

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

תוכן סדרת מאמרים זו

• חלק 1: כיצד לפרוס יישומי אינטרנט מודרניים בכמה שלבים בלבד;
• חלק 2: כיצד להשתמש בתמונת S2I חדשה עם תמונת שרת HTTP קיימת, כגון NGINX, באמצעות מכלולי OpenShift משויכים לפריסת ייצור;
• חלק 3: כיצד להפעיל שרת פיתוח עבור האפליקציה שלך בפלטפורמת OpenShift ולסנכרן אותו עם מערכת הקבצים המקומית.

משאבים נוספים

• ספר אלקטרוני בחינם פריסה ל-OpenShift.
• מידע על OpenShift ו-Kubernetes.

מקור: www.habr.com