កម្មវិធីទំនើបនៅលើ OpenShift ផ្នែកទី 2៖ ការបង្កើតជាច្រវ៉ាក់

សួស្តី​អ្នក​ទាំងអស់គ្នា! នេះគឺជាការប្រកាសទីពីរនៅក្នុងស៊េរីរបស់យើងដែលយើងបង្ហាញពីរបៀបដាក់ពង្រាយកម្មវិធីបណ្ដាញទំនើបនៅលើ Red Hat OpenShift ។

នៅក្នុងការប្រកាសមុន យើងបានប៉ះបន្តិចលើសមត្ថភាពនៃរូបភាពអ្នកបង្កើត S2I (ប្រភពទៅរូបភាព) ដែលត្រូវបានរចនាឡើងសម្រាប់ការកសាង និងដាក់ពង្រាយកម្មវិធីបណ្ដាញទំនើបនៅលើវេទិកា OpenShift ។ បន្ទាប់មកយើងចាប់អារម្មណ៍លើប្រធានបទនៃការដាក់ពង្រាយកម្មវិធីយ៉ាងរហ័ស ហើយថ្ងៃនេះយើងនឹងពិនិត្យមើលរបៀបប្រើរូបភាព S2I ជារូបភាពអ្នកបង្កើត "សុទ្ធ" ហើយបញ្ចូលវាជាមួយការផ្គុំ OpenShift ដែលពាក់ព័ន្ធ។

រូបភាពអ្នកសាងសង់ស្អាត

ដូចដែលយើងបានលើកឡើងនៅក្នុងផ្នែកទី XNUMX កម្មវិធីបណ្ដាញទំនើបភាគច្រើនមានដំណាក់កាលដែលហៅថា build ដែលជាធម្មតាដំណើរការដូចជាការចម្លងកូដ ការភ្ជាប់ឯកសារច្រើន និងការបង្រួមតូច។ ឯកសារដែលទទួលបានជាលទ្ធផលនៃប្រតិបត្តិការទាំងនេះ ហើយនេះគឺជា HTML ឋិតិវន្ត JavaScript និង CSS ត្រូវបានរក្សាទុកក្នុងថតលទ្ធផល។ ទីតាំងរបស់ Folder នេះជាធម្មតាអាស្រ័យលើអ្វីដែល build tool កំពុងត្រូវបានប្រើប្រាស់ ហើយសម្រាប់ React នេះនឹងក្លាយជា folder ./build (យើងនឹងត្រលប់មកវាវិញនៅក្នុងព័ត៌មានលម្អិតខាងក្រោម)។

ប្រភព-ទៅរូបភាព (S2I)

នៅក្នុងការប្រកាសនេះ យើងមិននិយាយអំពីប្រធានបទ "អ្វីជា S2I និងរបៀបប្រើវា" (អ្នកអាចអានបន្ថែមអំពីរឿងនេះ។ នៅទីនេះ) ប៉ុន្តែវាជារឿងសំខាន់ដែលត្រូវដឹងច្បាស់អំពីជំហានពីរក្នុងដំណើរការនេះ ដើម្បីយល់ពីអ្វីដែលរូបភាព Web App Builder ធ្វើ។

ដំណាក់កាលនៃការជួបប្រជុំគ្នា។

ដំណាក់កាលដំឡើងគឺស្រដៀងគ្នាទៅនឹងអ្វីដែលកើតឡើងនៅពេលអ្នកដំណើរការ docker build និងបញ្ចប់ដោយរូបភាព Docker ថ្មី។ ដូច្នោះហើយ ដំណាក់កាលនេះកើតឡើងនៅពេលចាប់ផ្តើមបង្កើតនៅលើវេទិកា OpenShift ។

ក្នុងករណីរូបភាព Web App Builder វាទទួលខុសត្រូវក្នុងការដំឡើងភាពអាស្រ័យនៃកម្មវិធីរបស់អ្នក និងដំណើរការ build។ ប្រមូលផ្តុំស្គ្រីប. តាមលំនាំដើម រូបភាពអ្នកសាងសង់ប្រើ npm ដំណើរការសាងសង់ ប៉ុន្តែវាអាចត្រូវបានបដិសេធតាមរយៈអថេរបរិស្ថាន NPM_BUILD ។

ដូចដែលយើងបាននិយាយមុននេះ ទីតាំងនៃកម្មវិធីដែលបានបញ្ចប់ និងបានសាងសង់រួចហើយ អាស្រ័យលើឧបករណ៍អ្វីដែលអ្នកប្រើ។ ឧទាហរណ៍ ក្នុងករណី React វានឹងជា ./build folder ហើយសម្រាប់កម្មវិធី Angular វានឹងក្លាយជាថត project_name/dist ។ ហើយដូចដែលបានបង្ហាញរួចមកហើយនៅក្នុងការប្រកាសមុន ទីតាំងនៃថតលទ្ធផល ដែលត្រូវបានកំណត់ដើម្បីបង្កើតតាមលំនាំដើម អាចត្រូវបានបដិសេធតាមរយៈអថេរបរិស្ថាន OUTPUT_DIR ។ ជាការប្រសើរណាស់ ចាប់តាំងពីទីតាំងនៃថតលទ្ធផលខុសគ្នាពីក្របខ័ណ្ឌមួយទៅក្របខ័ណ្ឌ អ្នកគ្រាន់តែចម្លងលទ្ធផលដែលបានបង្កើតទៅថតឯកសារស្តង់ដារក្នុងរូបភាព ពោលគឺ /opt/apt-root/output ។ នេះមានសារៈសំខាន់សម្រាប់ការយល់ដឹងពីអត្ថបទនេះ ប៉ុន្តែសម្រាប់ពេលនេះ ចូរយើងក្រឡេកមើលដំណាក់កាលបន្ទាប់យ៉ាងរហ័ស - ដំណាក់កាលរត់។

ដំណាក់កាលដំណើរការ

ដំណាក់កាលនេះកើតឡើងនៅពេលដែលការហៅទៅកាន់ docker run ត្រូវបានធ្វើឡើងនៅលើរូបភាពថ្មីដែលបានបង្កើតកំឡុងពេលជួបប្រជុំគ្នា។ ដូចគ្នានេះដែរកើតឡើងនៅពេលដាក់ពង្រាយនៅលើវេទិកា OpenShift ។ លំនាំដើម ដំណើរការស្គ្រីប ការប្រើប្រាស់ បម្រើម៉ូឌុល ដើម្បីបម្រើមាតិកាឋិតិវន្តដែលមានទីតាំងនៅក្នុងថតលទ្ធផលស្តង់ដារខាងលើ។

វិធីសាស្រ្តនេះគឺល្អសម្រាប់ការដាក់ពង្រាយកម្មវិធីយ៉ាងឆាប់រហ័ស ប៉ុន្តែជាទូទៅវាមិនត្រូវបានគេណែនាំឱ្យបម្រើមាតិកាឋិតិវន្តតាមវិធីនេះទេ។ ជាការប្រសើរណាស់ ដោយសារការពិតយើងបម្រើតែមាតិកាឋិតិវន្ត យើងមិនត្រូវការ Node.js ដែលបានដំឡើងនៅខាងក្នុងរូបភាពរបស់យើងទេ - ម៉ាស៊ីនមេគេហទំព័រនឹងគ្រប់គ្រាន់។

ម្យ៉ាង​ទៀត ពេល​ដំឡើង​យើង​ត្រូវ​ការ​របស់​មួយ ពេល​ប្រតិបត្តិ យើង​ត្រូវ​ការ​របស់​មួយ​ទៀត។ ក្នុង​ស្ថានភាព​នេះ ការ​សាង​សង់​ដែល​ជាប់​ជា​ច្រវាក់​មក​ជា​ប្រយោជន៍។

សំណង់ជាប់ច្រវ៉ាក់

នេះគឺជាអ្វីដែលពួកគេសរសេរអំពី សំណង់ជាប់ច្រវ៉ាក់ នៅក្នុងឯកសារ OpenShift៖

"ការជួបប្រជុំគ្នាពីរអាចត្រូវបានភ្ជាប់ជាមួយគ្នាដោយមួយបង្កើតអង្គភាពចងក្រង និងមួយទៀតបង្ហោះអង្គភាពនោះនៅក្នុងរូបភាពដាច់ដោយឡែកដែលត្រូវបានប្រើដើម្បីដំណើរការអង្គភាពនោះ។"

ម្យ៉ាងវិញទៀត យើងអាចប្រើរូបភាព Web App Builder ដើម្បីដំណើរការការបង្កើតរបស់យើង ហើយបន្ទាប់មកប្រើរូបភាពម៉ាស៊ីនមេគេហទំព័រ NGINX ដូចគ្នា ដើម្បីបម្រើមាតិការបស់យើង។

ដូច្នេះ យើងអាចប្រើរូបភាព Web App Builder ជាអ្នកបង្កើត "សុទ្ធ" ហើយក្នុងពេលតែមួយមានរូបភាពពេលដំណើរការតូចមួយ។

ឥឡូវនេះសូមក្រឡេកមើលរឿងនេះជាមួយនឹងឧទាហរណ៍ជាក់លាក់មួយ។

សម្រាប់ការបណ្តុះបណ្តាលយើងនឹងប្រើ កម្មវិធីប្រតិកម្មសាមញ្ញបង្កើតដោយប្រើឧបករណ៍បង្កើត-react-app command line។

វានឹងជួយយើងដាក់អ្វីគ្រប់យ៉ាងរួមគ្នា ឯកសារគំរូ 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 នៅលើ មជ្ឈមណ្ឌល 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 ហើយទីតាំង ref និងថតបរិបទត្រូវបានកំណត់ដោយប៉ារ៉ាម៉ែត្រដែលយើងបានឃើញខាងលើរួចហើយ។

បន្ទាត់ដែលមានស្លាកលេខ 3 គឺជាអ្វីដែលយើងបានឃើញរួចហើយនៅក្នុងផ្នែកប៉ារ៉ាម៉ែត្រ។ វាបន្ថែមអថេរបរិស្ថាន OUTPUT_DIR ដែលក្នុងឧទាហរណ៍របស់យើងត្រូវបានសាងសង់។
បន្ទាត់ដែលមានស្លាកលេខ 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

ពាក្យបញ្ជាដំបូងនៅក្នុងរូបថតអេក្រង់ខាងលើគឺជាវិធីវិស្វកម្មដោយចេតនាដើម្បីស្វែងរកគំរូ./openshiftio/application.yaml។

ពាក្យបញ្ជាទីពីរគ្រាន់តែបង្កើតកម្មវិធីថ្មីដោយផ្អែកលើគំរូនេះ។

បន្ទាប់ពីពាក្យបញ្ជាទាំងនេះដំណើរការ យើងនឹងឃើញថាយើងមានសភាពីរ៖

ហើយត្រលប់ទៅអេក្រង់ទិដ្ឋភាពទូទៅ យើងនឹងឃើញផតដែលបានបើកដំណើរការ៖

ចុចលើតំណភ្ជាប់នោះ យើងនឹងនាំទៅកាន់កម្មវិធីរបស់យើង ដែលជាទំព័រកម្មវិធី React លំនាំដើម៖

បន្ថែមឆ្នាំ ២០២០

សម្រាប់អ្នកស្រលាញ់ Angular យើងក៏មានផងដែរ។ កម្មវិធីឧទាហរណ៍.

លំនាំនៅទីនេះគឺដូចគ្នា លើកលែងតែអថេរ OUTPUT_DIR ។

បន្ថែមឆ្នាំ ២០២០

នៅក្នុងអត្ថបទនេះ យើងបានប្រើ NGINX ជា web server ប៉ុន្តែវាងាយស្រួលណាស់ក្នុងការជំនួសវាដោយ Apache ដោយគ្រាន់តែប្តូរ template ក្នុងឯកសារ រូបថតរបស់ NGINX នៅលើ រូបភាព Apache.

សេចក្តីសន្និដ្ឋាន

នៅក្នុងផ្នែកដំបូងនៃស៊េរីនេះ យើងបានបង្ហាញពីរបៀបដាក់ឱ្យប្រើប្រាស់កម្មវិធីបណ្តាញទំនើបយ៉ាងឆាប់រហ័សនៅលើវេទិកា OpenShift ។ ថ្ងៃនេះយើងបានពិនិត្យមើលអ្វីដែលរូបភាពកម្មវិធីគេហទំព័រធ្វើ និងរបៀបដែលវាអាចត្រូវបានផ្សំជាមួយម៉ាស៊ីនមេគេហទំព័រសុទ្ធដូចជា NGINX ដោយប្រើការស្ថាបនាជាច្រវ៉ាក់ ដើម្បីបង្កើតកម្មវិធីដែលត្រៀមរួចជាស្រេចក្នុងការផលិតកាន់តែច្រើន។ នៅក្នុងអត្ថបទបន្ទាប់ និងចុងក្រោយនៅក្នុងស៊េរីនេះ យើងនឹងបង្ហាញពីរបៀបដំណើរការម៉ាស៊ីនមេអភិវឌ្ឍន៍សម្រាប់កម្មវិធីរបស់អ្នកនៅលើ OpenShift និងធានាឱ្យមានការធ្វើសមកាលកម្មនៃឯកសារក្នុងស្រុក និងពីចម្ងាយ។

ខ្លឹមសារនៃស៊េរីនៃអត្ថបទនេះ។

• ផ្នែកទី 1៖ របៀបដាក់ពង្រាយកម្មវិធីបណ្ដាញទំនើបដោយគ្រាន់តែពីរបីជំហានប៉ុណ្ណោះ។;
• ផ្នែកទី 2៖ របៀបប្រើរូបភាព S2I ថ្មីជាមួយរូបភាពម៉ាស៊ីនមេ HTTP ដែលមានស្រាប់ ដូចជា NGINX ដោយប្រើការភ្ជាប់ OpenShift ដែលពាក់ព័ន្ធសម្រាប់ការដាក់ពង្រាយផលិតកម្ម។
• ផ្នែកទី 3៖ របៀបដំណើរការម៉ាស៊ីនមេអភិវឌ្ឍន៍សម្រាប់កម្មវិធីរបស់អ្នកនៅលើវេទិកា OpenShift ហើយធ្វើសមកាលកម្មវាជាមួយប្រព័ន្ធឯកសារមូលដ្ឋាន។

ធនធានបន្ថែម

• សៀវភៅអេឡិចត្រូនិចឥតគិតថ្លៃ ការដាក់ពង្រាយទៅ OpenShift.
• ព័ត៌មាននៅលើ OpenShift និង Kubernetes.

ប្រភព: www.habr.com