โปรโฮสต์ > บล็อก > การบริหาร > แอปพลิเคชันสมัยใหม่บน OpenShift ตอนที่ 2: การสร้างแบบเชื่อมโยง

แอปพลิเคชันสมัยใหม่บน OpenShift ตอนที่ 2: การสร้างแบบเชื่อมโยง

สวัสดีทุกคน! นี่เป็นโพสต์ที่สองในชุดของเรา ซึ่งเราจะแสดงวิธีการปรับใช้เว็บแอปพลิเคชันสมัยใหม่บน Red Hat OpenShift

แอปพลิเคชันสมัยใหม่บน OpenShift ตอนที่ 2: การสร้างแบบเชื่อมโยง

ในโพสต์ที่แล้ว เราได้กล่าวถึงความสามารถของอิมเมจตัวสร้าง S2I (จากต้นทางถึงรูปภาพ) ใหม่เล็กน้อย ซึ่งได้รับการออกแบบมาสำหรับการสร้างและปรับใช้แอปพลิเคชันเว็บสมัยใหม่บนแพลตฟอร์ม OpenShift จากนั้นเราสนใจหัวข้อการปรับใช้แอปพลิเคชันอย่างรวดเร็ว และวันนี้เราจะมาดูวิธีใช้อิมเมจ S2I เป็นอิมเมจตัวสร้างที่ "บริสุทธิ์" และรวมเข้ากับแอสเซมบลี OpenShift ที่เกี่ยวข้อง

อิมเมจตัวสร้างที่สะอาดตา

ดังที่เราได้กล่าวไว้ในตอนที่ XNUMX เว็บแอปพลิเคชันสมัยใหม่ส่วนใหญ่มีสิ่งที่เรียกว่าขั้นตอนการสร้าง ซึ่งโดยทั่วไปจะดำเนินการต่างๆ เช่น การแปลงรหัส การต่อไฟล์หลายไฟล์ และการย่อขนาด ไฟล์ที่ได้รับจากการดำเนินการเหล่านี้ - และนี่คือ HTML, JavaScript และ CSS แบบคงที่ - จะถูกเก็บไว้ในโฟลเดอร์เอาต์พุต ตำแหน่งของโฟลเดอร์นี้มักจะขึ้นอยู่กับเครื่องมือสร้างที่กำลังใช้งานอยู่ และสำหรับ React นี่จะเป็นโฟลเดอร์ ./build (เราจะกลับมาดูรายละเอียดเพิ่มเติมด้านล่าง)

แหล่งที่มาถึงรูปภาพ (S2I)

ในโพสต์นี้ เราไม่ได้พูดถึงหัวข้อ “S2I คืออะไรและใช้งานอย่างไร” (คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ ที่นี่) แต่สิ่งสำคัญคือต้องมีความชัดเจนเกี่ยวกับสองขั้นตอนในกระบวนการนี้เพื่อทำความเข้าใจว่าอิมเมจ Web App Builder ทำหน้าที่อะไร

ขั้นตอนการประกอบ

ขั้นตอนการประกอบจะคล้ายกันมากโดยธรรมชาติกับสิ่งที่เกิดขึ้นเมื่อคุณรัน docker build และจบลงด้วยอิมเมจ Docker ใหม่ ดังนั้น ขั้นตอนนี้จึงเกิดขึ้นเมื่อเริ่มต้นบิลด์บนแพลตฟอร์ม OpenShift

ในกรณีของอิมเมจ Web App Builder จะต้องรับผิดชอบในการติดตั้งการขึ้นต่อกันของแอปพลิเคชันของคุณและรันบิลด์ ประกอบสคริปต์. ตามค่าเริ่มต้น อิมเมจตัวสร้างจะใช้โครงสร้างการรันการรัน npm แต่สามารถแทนที่ได้ผ่านตัวแปรสภาพแวดล้อม NPM_BUILD

ดังที่เราได้กล่าวไว้ก่อนหน้านี้ ตำแหน่งของแอปพลิเคชันที่สร้างเสร็จแล้วนั้นขึ้นอยู่กับเครื่องมือที่คุณใช้ ตัวอย่างเช่น ในกรณีของ React นี่จะเป็นโฟลเดอร์ ./build และสำหรับแอปพลิเคชัน Angular จะเป็นโฟลเดอร์ project_name/dist และดังที่แสดงไว้แล้วในโพสต์ที่แล้ว ตำแหน่งของไดเร็กทอรีเอาต์พุตซึ่งถูกกำหนดให้สร้างเป็นค่าเริ่มต้น สามารถแทนที่ได้ผ่านตัวแปรสภาพแวดล้อม OUTPUT_DIR เนื่องจากตำแหน่งของโฟลเดอร์เอาต์พุตนั้นแตกต่างกันไปในแต่ละเฟรมเวิร์ก คุณเพียงแค่คัดลอกเอาต์พุตที่สร้างขึ้นไปยังโฟลเดอร์มาตรฐานในรูปภาพ นั่นคือ /opt/apt-root/output นี่เป็นสิ่งสำคัญสำหรับการทำความเข้าใจส่วนที่เหลือของบทความนี้ แต่สำหรับตอนนี้ เรามาดูขั้นตอนต่อไปอย่างรวดเร็ว - ระยะดำเนินการ

ระยะการวิ่ง

ขั้นตอนนี้เกิดขึ้นเมื่อทำการเรียกใช้นักเทียบท่าบนอิมเมจใหม่ที่สร้างขึ้นในระหว่างขั้นตอนการประกอบ สิ่งเดียวกันนี้จะเกิดขึ้นเมื่อใช้งานบนแพลตฟอร์ม OpenShift ค่าเริ่มต้น เรียกใช้สคริปต์ ใช้ ให้บริการโมดูล เพื่อแสดงเนื้อหาคงที่ที่อยู่ในไดเร็กทอรีเอาต์พุตมาตรฐานข้างต้น

วิธีการนี้ดีสำหรับการปรับใช้แอปพลิเคชันอย่างรวดเร็ว แต่โดยทั่วไปแล้วไม่แนะนำให้แสดงเนื้อหาคงที่ด้วยวิธีนี้ เนื่องจากในความเป็นจริง เราให้บริการเฉพาะเนื้อหาคงที่ เราจึงไม่จำเป็นต้องติดตั้ง Node.js ภายในอิมเมจของเรา เว็บเซิร์ฟเวอร์ก็เพียงพอแล้ว

กล่าวอีกนัยหนึ่ง เมื่อประกอบเราจำเป็นต้องมีสิ่งหนึ่ง เมื่อดำเนินการ เราจำเป็นต้องมีอีกสิ่งหนึ่ง ในสถานการณ์เช่นนี้ chained builds จะมีประโยชน์

งานสร้างที่ถูกล่ามโซ่

นี่คือสิ่งที่พวกเขาเขียนเกี่ยวกับ งานสร้างที่ถูกล่ามโซ่ ในเอกสาร OpenShift:

“แอสเซมบลีสองชุดสามารถเชื่อมโยงเข้าด้วยกัน โดยชุดหนึ่งสร้างเอนทิตีที่คอมไพล์แล้ว และอีกชุดหนึ่งโฮสต์เอนทิตีนั้นในอิมเมจแยกต่างหากที่ใช้ในการรันเอนทิตีนั้น”

กล่าวอีกนัยหนึ่ง เราสามารถใช้อิมเมจ Web App Builder เพื่อรันบิลด์ของเรา จากนั้นใช้อิมเมจของเว็บเซิร์ฟเวอร์ ซึ่งเป็น 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 จะเป็นผลมาจากขั้นตอนการประกอบที่จะรวมอิมเมจรันไทม์ของตัวสร้างเว็บแอปและซอร์สโค้ดของเรา นั่นคือเหตุผลที่เราเพิ่ม "-builder" ให้กับชื่อของรูปภาพนี้

รูปภาพที่สอง - 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 และตำแหน่ง โฟลเดอร์อ้างอิง และบริบทจะถูกกำหนดโดยพารามิเตอร์ที่เราเห็นข้างต้น

บรรทัดที่มีป้ายกำกับ 3 คือสิ่งที่เราเห็นแล้วในส่วนพารามิเตอร์ โดยจะเพิ่มตัวแปรสภาพแวดล้อม OUTPUT_DIR ซึ่งในตัวอย่างของเราคือ build
บรรทัดที่ระบุว่า 4 บอกว่าให้ใช้อิมเมจ web-app-builder-runtime ซึ่งเราเห็นแล้วในส่วน ImageStream

บรรทัดที่ระบุว่า 5 บอกว่าเราต้องการใช้บิลด์ส่วนเพิ่มหากอิมเมจ 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 ไม่มีอะไรใหม่ - เพียงบอกว่าผลลัพธ์ของบิลด์ถูกใส่ลงในอิมเมจ react-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 เปลี่ยนแปลง

มิฉะนั้น เทมเพลตนี้จะมีการกำหนดค่าการปรับใช้ที่ค่อนข้างเป็นมาตรฐาน รวมถึงสิ่งที่เกี่ยวข้องกับบริการและเส้นทาง แต่เราจะไม่ลงรายละเอียดมากเกินไป โปรดทราบว่าอิมเมจที่จะปรับใช้คืออิมเมจ react-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

คำสั่งแรกในภาพหน้าจอด้านบนเป็นวิธีการทางวิศวกรรมอย่างจงใจในการค้นหา template./openshiftio/application.yaml

คำสั่งที่สองเพียงสร้างแอปพลิเคชันใหม่โดยใช้เทมเพลตนี้

หลังจากที่คำสั่งเหล่านี้ทำงาน เราจะเห็นว่าเรามีแอสเซมบลีสองชุด:

แอปพลิเคชันสมัยใหม่บน OpenShift ตอนที่ 2: การสร้างแบบเชื่อมโยง

และกลับมาที่หน้าจอภาพรวม เราจะเห็นพ็อดที่เปิดตัว:

แอปพลิเคชันสมัยใหม่บน OpenShift ตอนที่ 2: การสร้างแบบเชื่อมโยง

คลิกที่ลิงก์แล้วเราจะไปที่แอปของเรา ซึ่งเป็นหน้าแอป React เริ่มต้น:

แอปพลิเคชันสมัยใหม่บน OpenShift ตอนที่ 2: การสร้างแบบเชื่อมโยง

อาหารเสริม 1

สำหรับคนรักแองกูลาร์เราก็มี แอปพลิเคชันตัวอย่าง.

รูปแบบที่นี่เหมือนกัน ยกเว้นตัวแปร OUTPUT_DIR

อาหารเสริม 2

ในบทความนี้ เราใช้ NGINX เป็นเว็บเซิร์ฟเวอร์ แต่การแทนที่ด้วย Apache นั้นค่อนข้างง่าย เพียงเปลี่ยนเทมเพลตในไฟล์ รูปภาพ NGINX บน ภาพอาปาเช่.

ข้อสรุป

ในส่วนแรกของซีรีส์นี้ เราได้แสดงวิธีปรับใช้เว็บแอปพลิเคชันสมัยใหม่บนแพลตฟอร์ม OpenShift อย่างรวดเร็ว วันนี้เรามาดูกันว่าอิมเมจของ Web App ทำอะไรได้บ้าง และสามารถรวมเข้ากับเว็บเซิร์ฟเวอร์ล้วนๆ เช่น NGINX ได้อย่างไร โดยใช้บิลด์แบบลูกโซ่เพื่อสร้างบิลด์แอปพลิเคชันที่พร้อมสำหรับการผลิตมากขึ้น ในบทความถัดไปและบทความสุดท้ายของชุดนี้ เราจะแสดงวิธีเรียกใช้เซิร์ฟเวอร์การพัฒนาสำหรับแอปพลิเคชันของคุณบน OpenShift และรับประกันการซิงโครไนซ์ไฟล์ในเครื่องและระยะไกล

เนื้อหาของบทความชุดนี้

  • ส่วนหนึ่งของ 1: วิธีปรับใช้เว็บแอปพลิเคชันสมัยใหม่เพียงไม่กี่ขั้นตอน;
  • ส่วนที่ 2: วิธีใช้อิมเมจ S2I ใหม่กับอิมเมจเซิร์ฟเวอร์ HTTP ที่มีอยู่ เช่น NGINX โดยใช้แอสเซมบลี OpenShift ที่เกี่ยวข้องสำหรับการปรับใช้จริง
  • ส่วนที่ 3: วิธีรันเซิร์ฟเวอร์การพัฒนาสำหรับแอปพลิเคชันของคุณบนแพลตฟอร์ม OpenShift และซิงโครไนซ์กับระบบไฟล์ในเครื่อง

แหล่งข้อมูลเพิ่มเติม

ที่มา: will.com

เพิ่มความคิดเห็น