ຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມໃນ OpenShift, ສ່ວນ 2: ການສ້າງລະບົບຕ່ອງໂສ້

ສະບາຍດີທຸກຄົນ! ນີ້ແມ່ນຂໍ້ຄວາມທີສອງໃນຊຸດຂອງພວກເຮົາທີ່ພວກເຮົາສະແດງວິທີການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກເວັບທີ່ທັນສະໄຫມໃນ Red Hat OpenShift.

ໃນບົດຂຽນທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ສໍາຜັດກັບຄວາມສາມາດຂອງຕົວສ້າງ S2I (ແຫຼ່ງໄປຫາຮູບພາບ) ໃຫມ່, ເຊິ່ງຖືກອອກແບບມາສໍາລັບການກໍ່ສ້າງແລະນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກເວັບທີ່ທັນສະໄຫມໃນເວທີ OpenShift. ຫຼັງຈາກນັ້ນ, ພວກເຮົາມີຄວາມສົນໃຈໃນຫົວຂໍ້ຂອງການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຢ່າງໄວວາ, ແລະໃນມື້ນີ້ພວກເຮົາຈະເບິ່ງວິທີການນໍາໃຊ້ຮູບພາບ S2I ເປັນຮູບພາບ builder "ບໍລິສຸດ" ແລະສົມທົບກັບອົງປະກອບ OpenShift ທີ່ກ່ຽວຂ້ອງ.

ສະອາດຮູບພາບ builder

ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວມາໃນພາກທີ XNUMX, ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ທັນສະໄຫມສ່ວນໃຫຍ່ມີອັນທີ່ເອີ້ນວ່າຂັ້ນຕອນການກໍ່ສ້າງ, ເຊິ່ງປົກກະຕິດໍາເນີນການເຊັ່ນ: ການຖ່າຍທອດລະຫັດ, ການເຊື່ອມໂຍງໄຟລ໌ຫຼາຍ, ແລະ minification. ໄຟລ໌ທີ່ໄດ້ຮັບຜົນມາຈາກການປະຕິບັດງານເຫຼົ່ານີ້ - ແລະນີ້ແມ່ນ HTML, JavaScript ແລະ CSS ຄົງທີ່ - ຖືກເກັບໄວ້ໃນໂຟນເດີຜົນຜະລິດ. ສະຖານທີ່ຂອງໂຟນເດີ້ນີ້ປົກກະຕິແລ້ວແມ່ນຂຶ້ນກັບສິ່ງທີ່ເຄື່ອງມືສ້າງກໍາລັງຖືກນໍາໃຊ້, ແລະສໍາລັບ React ນີ້ຈະເປັນໂຟນເດີ ./build (ພວກເຮົາຈະກັບຄືນໄປບ່ອນນີ້ໃນລາຍລະອຽດເພີ່ມເຕີມຂ້າງລຸ່ມນີ້).

ທີ່ມາ-to-Image (S2I)

ໃນບົດຂຽນນີ້, ພວກເຮົາບໍ່ໄດ້ເວົ້າເຖິງຫົວຂໍ້ "S2I ແມ່ນຫຍັງແລະວິທີການໃຊ້ມັນ" (ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້. ທີ່ນີ້), ແຕ່ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈະແຈ້ງກ່ຽວກັບສອງຂັ້ນຕອນໃນຂະບວນການນີ້ເພື່ອເຂົ້າໃຈສິ່ງທີ່ຮູບພາບຂອງ Web App Builder ເຮັດ.

ໄລຍະການປະກອບ

ໄລຍະການປະກອບແມ່ນຄ້າຍຄືກັນຫຼາຍກັບສິ່ງທີ່ເກີດຂື້ນໃນເວລາທີ່ທ່ານດໍາເນີນການສ້າງ docker ແລະສິ້ນສຸດດ້ວຍຮູບພາບ Docker ໃຫມ່. ຕາມນັ້ນແລ້ວ, ຂັ້ນຕອນນີ້ເກີດຂຶ້ນເມື່ອເລີ່ມຕົ້ນການກໍ່ສ້າງໃນເວທີ OpenShift.

ໃນກໍລະນີຂອງຮູບພາບ Web App Builder, ມັນຮັບຜິດຊອບໃນການຕິດຕັ້ງການເພິ່ງພາອາໄສຂອງແອັບພລິເຄຊັນຂອງທ່ານແລະດໍາເນີນການກໍ່ສ້າງ. ປະກອບສະຄິບ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຮູບພາບ builder ໃຊ້ npm run build build, ແຕ່ນີ້ສາມາດ overridden ຜ່ານຕົວແປສະພາບແວດລ້ອມ NPM_BUILD.

ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວກ່ອນຫນ້ານີ້, ສະຖານທີ່ຂອງຄໍາຮ້ອງສະຫມັກສໍາເລັດຮູບ, ກໍ່ສ້າງແລ້ວແມ່ນຂຶ້ນກັບເຄື່ອງມືທີ່ທ່ານໃຊ້. ຕົວຢ່າງ, ໃນກໍລະນີຂອງ React ນີ້ຈະເປັນໂຟນເດີ ./build, ແລະສໍາລັບແອັບພລິເຄຊັນ Angular ມັນຈະເປັນໂຟນເດີ project_name/dist. ແລະ, ດັ່ງທີ່ສະແດງຢູ່ໃນຂໍ້ຄວາມທີ່ຜ່ານມາ, ສະຖານທີ່ຂອງໄດເລກະທໍລີຜົນຜະລິດ, ເຊິ່ງຖືກກໍານົດເພື່ອສ້າງເປັນຄ່າເລີ່ມຕົ້ນ, ສາມາດຖືກລົບລ້າງຜ່ານຕົວແປສະພາບແວດລ້ອມ OUTPUT_DIR. ດີ, ເນື່ອງຈາກວ່າສະຖານທີ່ຂອງໂຟເດີຜົນຜະລິດແຕກຕ່າງຈາກກອບກັບກອບ, ທ່ານພຽງແຕ່ຄັດລອກຜົນຜະລິດທີ່ສ້າງຂຶ້ນໃສ່ໂຟນເດີມາດຕະຖານໃນຮູບພາບ, ຄື /opt/apt-root/output. ນີ້ແມ່ນສິ່ງສໍາຄັນສໍາລັບການເຂົ້າໃຈສ່ວນທີ່ເຫຼືອຂອງບົດຄວາມນີ້, ແຕ່ສໍາລັບຕອນນີ້ໃຫ້ພວກເຮົາເບິ່ງຢ່າງໄວວາໃນຂັ້ນຕອນຕໍ່ໄປ - ໄລຍະການແລ່ນ.

ໄລຍະແລ່ນ

ຂັ້ນຕອນນີ້ເກີດຂື້ນໃນເວລາທີ່ການໂທຫາ docker ດໍາເນີນການຢູ່ໃນຮູບພາບໃຫມ່ທີ່ສ້າງຂຶ້ນໃນລະຫວ່າງຂັ້ນຕອນການປະກອບ. ສິ່ງດຽວກັນເກີດຂຶ້ນເມື່ອນຳໃຊ້ໃນເວທີ OpenShift. ຄ່າເລີ່ມຕົ້ນ ແລ່ນສະຄຣິບ ການນໍາໃຊ້ ໂມດູນໃຫ້ບໍລິການ ເພື່ອຮັບໃຊ້ເນື້ອຫາທີ່ສະຖິດຢູ່ໃນໄດເລກະທໍລີຜົນຜະລິດມາດຕະຖານຂ້າງເທິງ.

ວິທີການນີ້ແມ່ນດີສໍາລັບການນໍາໃຊ້ຢ່າງວ່ອງໄວ, ແຕ່ໂດຍທົ່ວໄປແລ້ວມັນບໍ່ໄດ້ແນະນໍາໃຫ້ໃຫ້ບໍລິການເນື້ອໃນຄົງທີ່ດ້ວຍວິທີນີ້. ດີ, ເພາະວ່າໃນຄວາມເປັນຈິງພວກເຮົາພຽງແຕ່ໃຫ້ບໍລິການເນື້ອຫາຄົງທີ່, ພວກເຮົາບໍ່ຕ້ອງການ Node.js ຕິດຕັ້ງຢູ່ໃນຮູບພາບຂອງພວກເຮົາ - ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ຈະພຽງພໍ.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ໃນເວລາທີ່ປະກອບພວກເຮົາຕ້ອງການສິ່ງຫນຶ່ງ, ໃນເວລາທີ່ປະຕິບັດພວກເຮົາຕ້ອງການສິ່ງອື່ນ. ໃນກໍລະນີດັ່ງກ່າວນີ້, ການກໍ່ສ້າງລະບົບຕ່ອງໂສ້ມາຢູ່ໃນສະດວກ.

ການສ້າງຕ່ອງໂສ້

ນີ້ແມ່ນສິ່ງທີ່ພວກເຂົາຂຽນກ່ຽວກັບ ການສ້າງຕ່ອງໂສ້ ໃນເອກະສານ OpenShift:

"ສອງສະພາແຫ່ງສາມາດເຊື່ອມໂຍງເຂົ້າກັນໄດ້, ໂດຍຫນຶ່ງສ້າງຫນ່ວຍງານທີ່ລວບລວມແລະອີກຫນ່ວຍຫນຶ່ງເປັນເຈົ້າພາບໃນຮູບພາບແຍກຕ່າງຫາກທີ່ຖືກນໍາໃຊ້ເພື່ອດໍາເນີນການຫນ່ວຍງານນັ້ນ."

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ພວກເຮົາສາມາດນໍາໃຊ້ຮູບພາບ Web App Builder ເພື່ອດໍາເນີນການສ້າງຂອງພວກເຮົາ, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ຮູບພາບເຊີຟເວີເວັບ, NGINX ດຽວກັນ, ເພື່ອຮັບໃຊ້ເນື້ອຫາຂອງພວກເຮົາ.

ດັ່ງນັ້ນ, ພວກເຮົາສາມາດນໍາໃຊ້ຮູບພາບ Web App Builder ເປັນຕົວສ້າງ "ບໍລິສຸດ" ແລະໃນເວລາດຽວກັນມີຮູບພາບ runtime ຂະຫນາດນ້ອຍ.

ຕອນນີ້ໃຫ້ເບິ່ງເລື່ອງນີ້ດ້ວຍຕົວຢ່າງສະເພາະ.

ສໍາລັບການຝຶກອົບຮົມພວກເຮົາຈະນໍາໃຊ້ ຄໍາຮ້ອງສະຫມັກ 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 tagged 10.x on ສູນກາງ Docker.

ອັນທີສີ່ແມ່ນຮູບພາບ NGINX (ຮຸ່ນ 1.12) ທີ່ມີແທັກຫຼ້າສຸດ ສູນກາງ Docker.

ຕອນນີ້ໃຫ້ເບິ່ງສອງຮູບທໍາອິດ. ພວກເຂົາທັງສອງຫວ່າງເປົ່າໃນຕອນເລີ່ມຕົ້ນແລະຖືກສ້າງຂື້ນພຽງແຕ່ໃນໄລຍະການກໍ່ສ້າງ. ຮູບພາບທໍາອິດ, react-web-app-builder, ຈະເປັນຜົນມາຈາກຂັ້ນຕອນການປະກອບທີ່ຈະສົມທົບຮູບພາບ web-app-builder-runtime ແລະລະຫັດແຫຼ່ງຂອງພວກເຮົາ. ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາໄດ້ເພີ່ມ "-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 repository, ແລະສະຖານທີ່, ref ແລະ context folder ຖືກກໍານົດໂດຍພາລາມິເຕີທີ່ພວກເຮົາໄດ້ເຫັນແລ້ວຂ້າງເທິງ.

ເສັ້ນທີ່ຕິດສະຫຼາກ 3 ແມ່ນສິ່ງທີ່ພວກເຮົາເຫັນແລ້ວໃນພາກພາລາມິເຕີ. ມັນເພີ່ມຕົວແປສະພາບແວດລ້ອມ OUTPUT_DIR, ເຊິ່ງໃນຕົວຢ່າງຂອງພວກເຮົາແມ່ນສ້າງ.
ເສັ້ນປ້າຍຊື່ 4 ບອກວ່າໃຫ້ໃຊ້ຮູບພາບ web-app-builder-runtime, ເຊິ່ງພວກເຮົາໄດ້ເຫັນແລ້ວໃນພາກ ImageStream.

Line labeled 5 ເວົ້າວ່າພວກເຮົາຕ້ອງການໃຊ້ incremental build ຖ້າຮູບພາບ S2I ສະຫນັບສະຫນູນມັນ, ແລະຮູບພາບ Web App Builder ເຮັດ. ໃນການເປີດຕົວຄັ້ງທໍາອິດ, ຫຼັງຈາກສໍາເລັດຂັ້ນຕອນການປະກອບ, ຮູບພາບຈະບັນທຶກໂຟນເດີ node_modules ເຂົ້າໄປໃນແຟ້ມຈັດເກັບ. ຫຼັງຈາກນັ້ນ, ໃນການດໍາເນີນການຕໍ່ໄປ, ຮູບພາບພຽງແຕ່ຈະ unzip ໂຟນເດີນີ້ເພື່ອຫຼຸດຜ່ອນເວລາການກໍ່ສ້າງ.

ແລະສຸດທ້າຍ, ເສັ້ນທີ່ຕິດສະຫຼາກ 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 ແມ່ນພາກສ່ວນຂອງ triggers ທີ່ຈະກະຕຸ້ນການສ້າງນີ້ທຸກຄັ້ງທີ່ 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

ຄໍາສັ່ງທໍາອິດໃນຮູບຫນ້າຈໍຂ້າງເທິງນີ້ແມ່ນວິທີການວິສະວະກໍາໂດຍເຈດຕະນາເພື່ອຊອກຫາແມ່ແບບ./openshiftio/application.yaml.

ຄໍາສັ່ງທີສອງພຽງແຕ່ສ້າງຄໍາຮ້ອງສະຫມັກໃຫມ່ໂດຍອີງໃສ່ແມ່ແບບນີ້.

ຫຼັງຈາກຄໍາສັ່ງເຫຼົ່ານີ້ເຮັດວຽກ, ພວກເຮົາຈະເຫັນວ່າພວກເຮົາມີສອງສະພາແຫ່ງ:

ແລະກັບຄືນໄປຫາຫນ້າຈໍພາບລວມ, ພວກເຮົາຈະເຫັນ pod ເປີດຕົວ:

ຄລິກທີ່ລິ້ງນັ້ນແລ້ວພວກເຮົາຈະຖືກພາໄປທີ່ແອັບຂອງພວກເຮົາ, ເຊິ່ງເປັນໜ້າແອັບ React ເລີ່ມຕົ້ນ:

ເສີມປີ 1

ສໍາລັບ lovers Angular ພວກເຮົາຍັງມີ ຄໍາຮ້ອງສະຫມັກຕົວຢ່າງ.

ຮູບແບບຢູ່ທີ່ນີ້ແມ່ນຄືກັນ, ຍົກເວັ້ນຕົວແປ OUTPUT_DIR.

ເສີມປີ 2

ໃນບົດຄວາມນີ້ພວກເຮົາໄດ້ໃຊ້ NGINX ເປັນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌, ແຕ່ມັນຂ້ອນຂ້າງງ່າຍທີ່ຈະທົດແທນມັນດ້ວຍ Apache, ພຽງແຕ່ປ່ຽນແມ່ແບບໃນໄຟລ໌. ຮູບພາບ NGINX ສຸດ ຮູບພາບ Apache.

ສະຫລຸບ

ໃນສ່ວນທໍາອິດຂອງຊຸດນີ້, ພວກເຮົາໄດ້ສະແດງວິທີການນໍາໃຊ້ເວັບທີ່ທັນສະໄຫມຢ່າງໄວວາໃນເວທີ OpenShift. ມື້ນີ້ພວກເຮົາໄດ້ເບິ່ງສິ່ງທີ່ຮູບພາບຂອງ Web App ເຮັດແລະວິທີການທີ່ມັນສາມາດຖືກລວມເຂົ້າກັບເຄື່ອງແມ່ຂ່າຍເວັບທີ່ບໍລິສຸດເຊັ່ນ NGINX ໂດຍໃຊ້ລະບົບຕ່ອງໂສ້ການກໍ່ສ້າງເພື່ອສ້າງຄໍາຮ້ອງສະຫມັກທີ່ພ້ອມທີ່ຈະຜະລິດຫຼາຍຂຶ້ນ. ໃນບົດຄວາມຕໍ່ໄປແລະສຸດທ້າຍໃນຊຸດນີ້, ພວກເຮົາຈະສະແດງວິທີການດໍາເນີນການເຄື່ອງແມ່ຂ່າຍການພັດທະນາສໍາລັບແອັບພລິເຄຊັນຂອງທ່ານໃນ OpenShift ແລະຮັບປະກັນການ synchronization ຂອງໄຟລ໌ທ້ອງຖິ່ນແລະຫ່າງໄກສອກຫຼີກ.

ເນື້ອໃນຂອງບົດຄວາມຊຸດນີ້

• ສ່ວນທີ 1: ວິທີການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ທັນສະໄຫມໃນພຽງແຕ່ສອງສາມຂັ້ນຕອນ;
• ສ່ວນທີ 2: ວິທີການນໍາໃຊ້ຮູບພາບ S2I ໃຫມ່ກັບຮູບພາບເຄື່ອງແມ່ຂ່າຍ HTTP ທີ່ມີຢູ່ແລ້ວ, ເຊັ່ນ NGINX, ນໍາໃຊ້ສະພາແຫ່ງ OpenShift ທີ່ກ່ຽວຂ້ອງສໍາລັບການປະຕິບັດການຜະລິດ;
• ສ່ວນທີ 3: ວິທີການແລ່ນເຊີບເວີພັດທະນາສໍາລັບແອັບພລິເຄຊັນຂອງທ່ານໃນເວທີ OpenShift ແລະ synchronize ມັນກັບລະບົບໄຟລ໌ທ້ອງຖິ່ນ.

ຊັບພະຍາກອນເພີ່ມເຕີມ

• e-book ຟຣີ ນຳໃຊ້ກັບ OpenShift.
• ຂໍ້ມູນກ່ຽວກັບ OpenShift ແລະ Kubernetes.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com