OpenShift၊ အပိုင်း 2- ကွင်းဆက်တည်ဆောက်မှုများ

အားလုံးမင်္ဂလာပါ! ဤသည်မှာ Red Hat OpenShift တွင် ခေတ်မီဝဘ်အက်ပလီကေးရှင်းများကို မည်သို့အသုံးချရမည်ကို ပြသသည့် ကျွန်ုပ်တို့၏စီးရီးရှိ ဒုတိယပို့စ်ဖြစ်သည်။

ယခင်ပို့စ်တွင်၊ OpenShift ပလပ်ဖောင်းပေါ်တွင် ခေတ်မီဝဘ်အက်ပလီကေးရှင်းများတည်ဆောက်ခြင်းနှင့် အသုံးချခြင်းအတွက် ဒီဇိုင်းထုတ်ထားသည့် S2I (source-to-image) တည်ဆောက်သူရုပ်ပုံ၏စွမ်းရည်များကို ကျွန်ုပ်တို့ အနည်းငယ် ထိတွေ့မိပါသည်။ ထို့နောက် ကျွန်ုပ်တို့သည် အက်ပလီကေးရှင်းတစ်ခုအား လျင်မြန်စွာအသုံးချခြင်းဆိုင်ရာ ခေါင်းစဉ်ကို စိတ်ဝင်စားခဲ့ကြပြီး ယနေ့တွင် S2I ရုပ်ပုံအား "စင်ကြယ်သော" တည်ဆောက်သူရုပ်ပုံအဖြစ် မည်သို့အသုံးပြုရမည်ကို လေ့လာပြီး ၎င်းကို သက်ဆိုင်ရာ OpenShift စည်းဝေးပွဲများနှင့် ပေါင်းစပ်မည်ဖြစ်သည်။

သန့်ရှင်းသောတည်ဆောက်သူပုံ

အပိုင်း XNUMX တွင်ဖော်ပြထားသည့်အတိုင်း၊ ခေတ်မီဝဘ်အပလီကေးရှင်းအများစုတွင် ကုဒ်အစားထိုးခြင်း၊ ဖိုင်အများအပြားပေါင်းစပ်ခြင်းနှင့် အသေးစိပ်ပြုလုပ်ခြင်းကဲ့သို့သော လုပ်ဆောင်ချက်များကို ပုံမှန်အားဖြင့် လုပ်ဆောင်သည့် တည်ဆောက်မှုအဆင့်ဟုခေါ်သည်။ ဤလုပ်ဆောင်မှုများကြောင့် ရရှိသောဖိုင်များ - ၎င်းသည် တည်ငြိမ်သော HTML၊ JavaScript နှင့် CSS ဖြစ်သည် - အထွက်ဖိုင်တွဲတွင် သိမ်းဆည်းထားသည်။ ဤဖိုင်တွဲ၏တည်နေရာသည် အများအားဖြင့် မည်သည့်တည်ဆောက်ကိရိယာများကို အသုံးပြုနေသည်ပေါ်တွင်မူတည်ပြီး React အတွက် ၎င်းသည် ./build ဖိုင်တွဲဖြစ်လိမ့်မည် (ကျွန်ုပ်တို့သည် ဤအရာအား အောက်တွင် ပိုမိုအသေးစိတ်ဖြင့် ပြန်လည်ဖော်ပြပါမည်)။

အရင်းအမြစ်မှပုံရိပ် (S2I)

ဤပို့စ်တွင် ကျွန်ုပ်တို့သည် "S2I ဆိုသည်မှာ ဘာလဲ၊ ၎င်းကို အသုံးပြုနည်း" ဟူသော ခေါင်းစဉ်နှင့် မသက်ဆိုင်ပါ (ဤအကြောင်းကို ဆက်လက်ဖတ်ရှုနိုင်ပါသည်။ ဒီမှာ) သို့သော် Web App Builder ရုပ်ပုံ မည်သို့လုပ်ဆောင်သည်ကို နားလည်ရန် ဤလုပ်ငန်းစဉ်တွင် အဆင့်နှစ်ဆင့်အကြောင်း ရှင်းလင်းရန် အရေးကြီးပါသည်။

စည်းဝေးပွဲအဆင့်

တပ်ဆင်မှုအဆင့်သည် သင် docker တည်ဆောက်ပြီး Docker ပုံအသစ်ဖြင့် အဆုံးသတ်သည့်အခါ ဖြစ်ပျက်ပုံနှင့် အလွန်ဆင်တူပါသည်။ ထို့ကြောင့်၊ OpenShift ပလပ်ဖောင်းပေါ်တွင်တည်ဆောက်မှုစတင်သောအခါဤအဆင့်သည်ဖြစ်ပေါ်သည်။

Web App Builder ပုံတစ်ခုအတွက်၊ သင့်အပလီကေးရှင်း၏ မှီခိုမှုကို ထည့်သွင်းပြီး တည်ဆောက်မှုကို လုပ်ဆောင်ရန် တာဝန်ရှိသည်။ script ကိုစုဝေး. မူရင်းအားဖြင့်၊ တည်ဆောက်သူရုပ်ပုံသည် npm လည်ပတ်တည်ဆောက်တည်ဆောက်မှုကို အသုံးပြုသည်၊ သို့သော် ၎င်းကို NPM_BUILD ပတ်၀န်းကျင် ကိန်းရှင်မှတစ်ဆင့် လွှမ်းမိုးနိုင်သည်။

စောစောကပြောခဲ့သလိုပဲ၊ တည်ဆောက်ပြီးသား အပလီကေးရှင်းရဲ့ တည်နေရာဟာ သင်အသုံးပြုတဲ့ ကိရိယာတွေအပေါ် မူတည်ပါတယ်။ ဥပမာအားဖြင့်၊ React တွင် ၎င်းသည် ./build ဖိုင်တွဲဖြစ်မည်ဖြစ်ပြီး Angular အပလီကေးရှင်းများအတွက် ၎င်းသည် project_name/dist ဖိုင်တွဲဖြစ်လိမ့်မည်။ ယခင်ပို့စ်တွင်ပြထားပြီးဖြစ်သည့်အတိုင်း၊ ပုံသေဖြင့်တည်ဆောက်ရန်သတ်မှတ်ထားသည့် output directory ၏တည်နေရာကို OUTPUT_DIR ပတ်၀န်းကျင် variable မှတဆင့်လွှမ်းမိုးနိုင်သည်။ ကောင်းပြီ၊ output folder ၏တည်နေရာသည် framework တစ်ခုမှ framework တစ်ခုနှင့်တစ်ခုမတူသောကြောင့်၊ သင်သည် image ရှိ standard folder သို့ထုတ်လုပ်လိုက်သော output ဖြစ်သည့် /opt/apt-root/output ကိုကူးယူပါ။ ဤဆောင်းပါး၏ကျန်ရှိနေသေးသည်ကိုနားလည်ရန်အရေးကြီးသည်၊ သို့သော်ယခုအတွက်နောက်ထပ်အဆင့် - အပြေးအဆင့်ကိုအမြန်ကြည့်ရှုကြပါစို့။

run အဆင့်

စည်းဝေးပွဲအဆင့်အတွင်း ဖန်တီးထားသော ပုံအသစ်တွင် docker run သို့ ခေါ်ဆိုမှုပြုလုပ်သည့်အခါ ဤအဆင့်သည် ဖြစ်ပေါ်သည်။ OpenShift ပလပ်ဖောင်းပေါ်တွင် ဖြန့်ကျက်သည့်အခါ အလားတူဖြစ်တတ်ပါသည်။ ပုံသေ script ကို run ပါ။ အသုံးပြုမှု ဝန်ဆောင်မှု module အထက်ဖော်ပြပါ စံထုတ်ပေးမှုလမ်းညွှန်တွင်ရှိသော တည်ငြိမ်သောအကြောင်းအရာကို လုပ်ဆောင်ရန်။

ဤနည်းလမ်းသည် အပလီကေးရှင်းများကို လျင်မြန်စွာ အသုံးချခြင်းအတွက် ကောင်းမွန်သော်လည်း၊ ဤနည်းဖြင့် တည်ငြိမ်သော အကြောင်းအရာကို လုပ်ဆောင်ရန် ယေဘုယျအားဖြင့် အကြံပြုထားခြင်း မရှိပါ။ ကောင်းပြီ၊ လက်တွေ့တွင် ကျွန်ုပ်တို့သည် တည်ငြိမ်သောအကြောင်းအရာကိုသာ ဆောင်ရွက်ပေးသောကြောင့်၊ ကျွန်ုပ်တို့၏ရုပ်ပုံအတွင်းတွင် Node.js ထည့်သွင်းရန် မလိုအပ်ပါ - ဝဘ်ဆာဗာသည် လုံလောက်မည်ဖြစ်သည်။

တစ်နည်းဆိုရသော် ကျွန်ုပ်တို့သည် တစ်စုံတစ်ခုအား စုစည်းသောအခါ၊ အကောင်အထည်ဖော်သောအခါတွင် အခြားတစ်ခုကို လိုအပ်သည်။ ဤအခြေအနေတွင်၊ သံကြိုးဖြင့်တည်ဆောက်မှုများသည်အဆင်ပြေသည်။

သံကြိုးများဖြင့် တည်ဆောက်သည်။

ဒါက သူတို့ရေးတဲ့အကြောင်းပါ။ သံကြိုးများဖြင့် တည်ဆောက်သည်။ OpenShift စာရွက်စာတမ်းတွင်-

"တစ်ခုသည် compiled entity ကိုဖန်တီးခြင်းနှင့် အခြားတစ်ခုသည် ထိုentity ကို run ရန်အသုံးပြုသော သီးခြားပုံတစ်ခုတွင် ထိုentity ကို hosting လုပ်ခြင်းဖြင့် စည်းဝေးပွဲနှစ်ခုကို အတူတကွချိတ်ဆက်နိုင်သည်။"

တစ်နည်းဆိုရသော်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏တည်ဆောက်မှုကိုလုပ်ဆောင်ရန် Web App Builder ပုံကို အသုံးပြုနိုင်ပြီး၊ ထို့နောက် ကျွန်ုပ်တို့၏အကြောင်းအရာကို ဆောင်ရွက်ပေးရန်အတွက် ဝဘ်ဆာဗာပုံဖြစ်သည့် NGINX ကို အသုံးပြုနိုင်သည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Web App Builder ရုပ်ပုံကို "စင်ကြယ်သော" တည်ဆောက်သူအဖြစ် အသုံးပြုနိုင်ပြီး တစ်ချိန်တည်းတွင် အသေးစား runtime ပုံတစ်ခုရှိသည်။

အခု ဒါကို အတိအကျ ဥပမာတစ်ခုနဲ့ ကြည့်ရအောင်။

လေ့ကျင့်မှုအတွက် အသုံးပြုပါမည်။ ရိုးရှင်းသော React အက်ပလီကေးရှင်းcreate-react-app command line tool ကို အသုံးပြု၍ ဖန်တီးထားသည်။

အဲဒါက ငါတို့အားလုံးကို ပေါင်းစည်းဖို့ ကူညီပေးလိမ့်မယ်။ 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

သင်တွေ့မြင်ရသည့်အတိုင်း၊ ဤတည်ဆောက်မှု၏ရလဒ်ကို ImageStreams ကဏ္ဍတွင် အနည်းငယ်စောသော ကျွန်ုပ်တို့တွေ့ခဲ့သည့် react-web-app-builder ပုံတွင် သင်မြင်ရသည့်အတိုင်း အညွှန်း 1 ပါသောစာကြောင်းက ဖော်ပြသည်။

2 လို့ တံဆိပ်တပ်ထားတဲ့ စာကြောင်းက ကုဒ်ကို ဘယ်ကရမယ်ဆိုတာ ပြောပြတယ်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ၎င်းသည် git repository ဖြစ်ပြီး၊ တည်နေရာ၊ ref နှင့် context folder သည် အထက်တွင်တွေ့မြင်ပြီးသား parameters များဖြင့် ဆုံးဖြတ်ပါသည်။

3 ဟု တံဆိပ်တပ်ထားသော စာကြောင်းသည် ကန့်သတ်ချက်များ ကဏ္ဍတွင် ကျွန်ုပ်တို့ မြင်ပြီးသားဖြစ်သည်။ ၎င်းသည် ကျွန်ုပ်တို့၏နမူနာတွင် တည်ဆောက်ထားသည့် OUTPUT_DIR ပတ်၀န်းကျင် variable ကို ပေါင်းထည့်သည်။
ImageStream ကဏ္ဍတွင် ကျွန်ုပ်တို့မြင်ထားပြီးဖြစ်သည့် web-app-builder-runtime ပုံကို 4 ဟု တံဆိပ်တပ်ထားသည့် စာကြောင်းက ဆိုသည်။

S5I ရုပ်ပုံသည် ၎င်းကို ပံ့ပိုးပေးမည်ဆိုပါက ကျွန်ုပ်တို့သည် တိုးမြင့်တည်ဆောက်မှုတစ်ခုကို အသုံးပြုလိုကြောင်း နှင့် Web App Builder ပုံတွင် တံဆိပ်တပ်ထားသော စာကြောင်း 2 က ဆိုသည်။ ပထမဦးစွာစတင်ချိန်တွင်၊ စုဝေးမှုအဆင့်ပြီးသွားသောအခါ၊ ပုံသည် node_modules ဖိုဒါကို archive file တစ်ခုအဖြစ်သိမ်းဆည်းမည်ဖြစ်သည်။ ထို့နောက်၊ နောက်ဆက်တွဲလုပ်ဆောင်မှုများတွင်၊ ပုံသည် တည်ဆောက်ချိန်ကိုလျှော့ချရန် ဤဖိုင်တွဲကို ဇစ်ဖွင့်လိုက်ပါမည်။

နောက်ဆုံးအနေနှင့်၊ 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 ဟုအမည်တပ်ထားသော လိုင်းသည် ပထမတည်ဆောက်ပုံဖွဲ့စည်းပုံနှင့် ဆင်တူသည်။ ယခုတစ်ကြိမ်သာ ကျွန်ုပ်တို့သည် ImageStream ကဏ္ဍတွင် တွေ့ထားပြီးဖြစ်သည့် nginx-image-runtime ကို အသုံးပြုပါမည်။

နောက်ဆုံးတွင်၊ 7 ဟုအမည်တပ်ထားသောစာကြောင်းသည် react-web-app-builder ပုံပြောင်းတိုင်း ဤတည်ဆောက်မှုကို အသက်သွင်းမည့် အစပျိုးကဏ္ဍတစ်ခုဖြစ်သည်။

မဟုတ်ပါက၊ ဤပုံစံပလိတ်တွင် စံနမူနာပြဖွဲ့စည်းမှုပုံစံအပြင် ဝန်ဆောင်မှုများနှင့် လမ်းကြောင်းများနှင့် သက်ဆိုင်သည့်အရာများပါရှိသည်၊ သို့သော် ကျွန်ုပ်တို့သည် ထိုအသေးစိတ်အချက်အလက်များကို လွန်လွန်ကဲကဲ လုပ်ဆောင်မည်မဟုတ်ပါ။ အသုံးပြုမည့်ပုံသည် react-web-app-runtime ပုံဖြစ်ကြောင်း ကျေးဇူးပြု၍ သတိပြုပါ။

လျှောက်လွှာဖြန့်ကျက်ခြင်း။

ဒါကြောင့် အခု နမူနာပုံစံကို ကြည့်ပြီး အက်ပလီကေးရှင်းကို ဘယ်လိုအသုံးချရမလဲဆိုတာ ကြည့်ကြရအောင်။

ကျွန်ုပ်တို့၏ template ကိုအသုံးပြုရန် oc ဟုခေါ်သော OpenShift client tool ကိုသုံးနိုင်သည်-

$ 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။

ဒုတိယ command သည် ဤ template ကို အခြေခံ၍ အပလီကေးရှင်းအသစ်တစ်ခုကို ဖန်တီးသည်။

ဤအမိန့်များအလုပ်လုပ်ပြီးနောက်၊ ကျွန်ုပ်တို့တွင်စည်းဝေးပွဲနှစ်ခုရှိသည်ကိုကျွန်ုပ်တို့တွေ့လိမ့်မည်။

ခြုံငုံသုံးသပ်ချက် ဖန်သားပြင်သို့ ပြန်သွားသောအခါ၊ လွှင့်တင်ထားသော ပေါ့ဒ်ကို ကျွန်ုပ်တို့ တွေ့ရလိမ့်မည်-

လင့်ခ်ကို နှိပ်လိုက်ပါ၊ ကျွန်ုပ်တို့သည် မူရင်း React App စာမျက်နှာဖြစ်သည့် ကျွန်ုပ်တို့၏အက်ပ်သို့ ခေါ်ဆောင်သွားပါမည်။

ဖြည့်စွက် 1

Angular ချစ်သူများအတွက်ကျွန်ုပ်တို့လည်းရှိသည်။ ဥပမာလျှောက်လွှာ.

OUTPUT_DIR ကိန်းရှင်မှလွဲ၍ ဤနေရာတွင် ပုံစံသည် အတူတူပင်ဖြစ်ပါသည်။

ဖြည့်စွက် 2

ဤဆောင်းပါးတွင် ကျွန်ုပ်တို့သည် NGINX ကို ဝဘ်ဆာဗာအဖြစ် အသုံးပြုခဲ့သည်၊ သို့သော် ၎င်းကို Apache ဖြင့် အစားထိုးရန် အလွန်လွယ်ကူသည်၊ ဖိုင်ရှိ နမူနာပုံစံကို ပြောင်းလိုက်ရုံပင်။ NGINX ပုံ အပေါ် Apache ပုံ.

ကောက်ချက်

ဤစီးရီး၏ပထမပိုင်း၌၊ ကျွန်ုပ်တို့သည် OpenShift ပလပ်ဖောင်းပေါ်တွင် ခေတ်မီဝဘ်အက်ပ်လီကေးရှင်းများကို မည်သို့လျင်မြန်စွာအသုံးချရမည်ကို ပြသခဲ့သည်။ ယနေ့တွင် Web App ပုံတစ်ခုလုပ်ဆောင်ပုံနှင့် ၎င်းကို NGINX ကဲ့သို့ သန့်စင်သောဝဘ်ဆာဗာတစ်ခုနှင့် ပေါင်းစပ်ထုတ်လုပ်နိုင်စေရန် သံကြိုးတည်ဆောက်မှုများကို အသုံးပြု၍ ပိုမိုထုတ်လုပ်ရန်အဆင်သင့်ရှိသော application build တစ်ခုကို ဖန်တီးရန်အတွက် ယနေ့ ကျွန်ုပ်တို့ ကြည့်ရှုခဲ့ကြသည်။ ဤစီးရီး၏ နောက်နှင့် နောက်ဆုံးဆောင်းပါးတွင် OpenShift တွင် သင့်အက်ပ်လီကေးရှင်းအတွက် ဖွံ့ဖြိုးတိုးတက်မှုဆာဗာကို မည်သို့လုပ်ဆောင်ရမည်ကို ပြသမည်ဖြစ်ပြီး ဒေသတွင်းနှင့် အဝေးထိန်းဖိုင်များကို တစ်ပြိုင်တည်းလုပ်ဆောင်ကြောင်း သေချာစေမည်ဖြစ်သည်။

ဤဆောင်းပါးတွဲ၏ အကြောင်းအရာများ

• အပိုင်း 1: အဆင့်အနည်းငယ်မျှဖြင့် ခေတ်မီဝဘ်အက်ပ်လီကေးရှင်းများကို မည်သို့အသုံးပြုရမည်နည်း။;
• အပိုင်း 2- ထုတ်လုပ်မှု ဖြန့်ကျက်မှုအတွက် ဆက်စပ် OpenShift စည်းဝေးပွဲများကို အသုံးပြု၍ လက်ရှိ HTTP ဆာဗာပုံဖြစ်သည့် NGINX ကဲ့သို့ S2I ရုပ်ပုံအသစ်ကို အသုံးပြုနည်း။
• အပိုင်း 3- OpenShift ပလပ်ဖောင်းပေါ်တွင် သင့်အပလီကေးရှင်းအတွက် ဖွံ့ဖြိုးတိုးတက်မှုဆာဗာကို မည်သို့လည်ပတ်ပြီး ၎င်းကို ဒေသတွင်း ဖိုင်စနစ်နှင့် တစ်ပြိုင်တည်းလုပ်ဆောင်ရမည်နည်း။

ထပ်လောင်းအရင်းအမြစ်များ

• အခမဲ့ e-book OpenShift သို့ အသုံးချနေပါသည်။.
• သတင်းအချက်အလက်အပေါ် OpenShift နှင့် Kubernetes.

source: www.habr.com