OpenShift-ലെ ആധുനിക ആപ്ലിക്കേഷനുകൾ, ഭാഗം 2: ചങ്ങലയുള്ള ബിൽഡുകൾ

എല്ലാവർക്കും ഹായ്! Red Hat OpenShift-ൽ ആധുനിക വെബ് ആപ്ലിക്കേഷനുകൾ എങ്ങനെ വിന്യസിക്കാമെന്ന് കാണിക്കുന്ന ഞങ്ങളുടെ പരമ്പരയിലെ രണ്ടാമത്തെ പോസ്റ്റാണിത്.

മുമ്പത്തെ പോസ്റ്റിൽ, ഓപ്പൺഷിഫ്റ്റ് പ്ലാറ്റ്‌ഫോമിൽ ആധുനിക വെബ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനും വിന്യസിക്കുന്നതിനുമായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന പുതിയ S2I (സോഴ്‌സ്-ടു-ഇമേജ്) ബിൽഡർ ഇമേജിന്റെ കഴിവുകളെ ഞങ്ങൾ ചെറുതായി സ്പർശിച്ചു. ഒരു ആപ്ലിക്കേഷൻ വേഗത്തിൽ വിന്യസിക്കുക എന്ന വിഷയത്തിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ടായിരുന്നു, ഇന്ന് ഞങ്ങൾ ഒരു S2I ഇമേജ് ഒരു "പ്യുവർ" ബിൽഡർ ഇമേജായി എങ്ങനെ ഉപയോഗിക്കാമെന്നും അനുബന്ധ ഓപ്പൺഷിഫ്റ്റ് അസംബ്ലികളുമായി സംയോജിപ്പിക്കാമെന്നും നോക്കും.

ക്ലീൻ ബിൽഡർ ചിത്രം

ഞങ്ങൾ ഭാഗം XNUMX-ൽ സൂചിപ്പിച്ചതുപോലെ, മിക്ക ആധുനിക വെബ് ആപ്ലിക്കേഷനുകൾക്കും ബിൽഡ് സ്റ്റേജ് എന്ന് വിളിക്കപ്പെടുന്നവയുണ്ട്, ഇത് സാധാരണയായി കോഡ് ട്രാൻസ്‌പൈലേഷൻ, മൾട്ടിപ്പിൾ ഫയൽ കോൺകറ്റനേഷൻ, മിനിഫിക്കേഷൻ തുടങ്ങിയ പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു. ഈ പ്രവർത്തനങ്ങളുടെ ഫലമായി ലഭിച്ച ഫയലുകൾ - ഇത് സ്റ്റാറ്റിക് HTML, JavaScript, CSS എന്നിവയാണ് - ഔട്ട്പുട്ട് ഫോൾഡറിൽ സംഭരിച്ചിരിക്കുന്നു. ഈ ഫോൾഡറിന്റെ സ്ഥാനം സാധാരണയായി ഏത് ബിൽഡ് ടൂളുകളാണ് ഉപയോഗിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, പ്രതികരണത്തിനായി ഇത് ./build ഫോൾഡറായിരിക്കും (ഞങ്ങൾ ഇതിലേക്ക് കൂടുതൽ വിശദമായി ചുവടെ വരാം).

ഉറവിടം-ചിത്രം (S2I)

ഈ പോസ്റ്റിൽ "എന്താണ് S2I, അത് എങ്ങനെ ഉപയോഗിക്കാം" എന്ന വിഷയത്തിൽ ഞങ്ങൾ സ്പർശിക്കുന്നില്ല (നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം ഇവിടെ), എന്നാൽ ഒരു വെബ് ആപ്പ് ബിൽഡർ ചിത്രം എന്താണ് ചെയ്യുന്നതെന്ന് മനസിലാക്കാൻ ഈ പ്രക്രിയയിലെ രണ്ട് ഘട്ടങ്ങളെക്കുറിച്ച് വ്യക്തമായിരിക്കേണ്ടത് പ്രധാനമാണ്.

അസംബ്ലി ഘട്ടം

നിങ്ങൾ ഡോക്കർ ബിൽഡ് പ്രവർത്തിപ്പിച്ച് ഒരു പുതിയ ഡോക്കർ ഇമേജിൽ അവസാനിക്കുമ്പോൾ സംഭവിക്കുന്ന കാര്യങ്ങളുമായി അസംബ്ലി ഘട്ടം സ്വഭാവത്തിൽ വളരെ സാമ്യമുള്ളതാണ്. അതനുസരിച്ച്, OpenShift പ്ലാറ്റ്ഫോമിൽ ഒരു ബിൽഡ് ആരംഭിക്കുമ്പോൾ ഈ ഘട്ടം സംഭവിക്കുന്നു.

ഒരു വെബ് ആപ്പ് ബിൽഡർ ഇമേജിന്റെ കാര്യത്തിൽ, നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഡിപൻഡൻസികൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനും ബിൽഡ് പ്രവർത്തിപ്പിക്കുന്നതിനും ഇത് ഉത്തരവാദിയാണ്. സ്ക്രിപ്റ്റ് കൂട്ടിച്ചേർക്കുക. സ്ഥിരസ്ഥിതിയായി, ബിൽഡർ ഇമേജ് npm റൺ ബിൽഡ് കൺസ്ട്രക്‌റ്റ് ഉപയോഗിക്കുന്നു, എന്നാൽ ഇത് NPM_BUILD എൻവയോൺമെന്റ് വേരിയബിളിലൂടെ അസാധുവാക്കാം.

ഞങ്ങൾ നേരത്തെ പറഞ്ഞതുപോലെ, പൂർത്തിയായതും ഇതിനകം നിർമ്മിച്ചതുമായ ആപ്ലിക്കേഷന്റെ സ്ഥാനം നിങ്ങൾ ഉപയോഗിക്കുന്ന ടൂളുകളെ ആശ്രയിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, React-ന്റെ കാര്യത്തിൽ ഇത് ./build ഫോൾഡറും കോണീയ ആപ്ലിക്കേഷനുകൾക്ക് ഇത് project_name/dist ഫോൾഡറും ആയിരിക്കും. കൂടാതെ, മുമ്പത്തെ പോസ്റ്റിൽ കാണിച്ചിരിക്കുന്നതുപോലെ, സ്ഥിരസ്ഥിതിയായി നിർമ്മിക്കാൻ സജ്ജമാക്കിയിരിക്കുന്ന ഔട്ട്പുട്ട് ഡയറക്ടറിയുടെ സ്ഥാനം, OUTPUT_DIR എൻവയോൺമെന്റ് വേരിയബിളിലൂടെ അസാധുവാക്കാവുന്നതാണ്. ശരി, ഔട്ട്‌പുട്ട് ഫോൾഡറിന്റെ സ്ഥാനം ചട്ടക്കൂടിൽ നിന്ന് ചട്ടക്കൂടിലേക്ക് വ്യത്യാസപ്പെട്ടിരിക്കുന്നതിനാൽ, നിങ്ങൾ ജനറേറ്റുചെയ്‌ത ഔട്ട്‌പുട്ട് ഇമേജിലെ സ്റ്റാൻഡേർഡ് ഫോൾഡറിലേക്ക് പകർത്തുക, അതായത് /opt/apt-root/output. ഈ ലേഖനത്തിന്റെ ബാക്കി ഭാഗങ്ങൾ മനസ്സിലാക്കുന്നതിന് ഇത് പ്രധാനമാണ്, എന്നാൽ ഇപ്പോൾ നമുക്ക് അടുത്ത ഘട്ടം വേഗത്തിൽ നോക്കാം - റൺ ഘട്ടം.

റൺ ഘട്ടം

അസംബ്ലി ഘട്ടത്തിൽ സൃഷ്ടിച്ച പുതിയ ഇമേജിൽ ഡോക്കർ റണ്ണിലേക്കുള്ള ഒരു കോൾ ചെയ്യുമ്പോൾ ഈ ഘട്ടം സംഭവിക്കുന്നു. OpenShift പ്ലാറ്റ്‌ഫോമിൽ വിന്യസിക്കുമ്പോഴും ഇതുതന്നെ സംഭവിക്കുന്നു. സ്ഥിരസ്ഥിതി സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുക ഉപയോഗിക്കുന്നു സെർവ് മൊഡ്യൂൾ മുകളിലുള്ള സ്റ്റാൻഡേർഡ് ഔട്ട്‌പുട്ട് ഡയറക്ടറിയിൽ സ്ഥിതി ചെയ്യുന്ന സ്റ്റാറ്റിക് ഉള്ളടക്കം നൽകുന്നതിന്.

ആപ്ലിക്കേഷനുകൾ വേഗത്തിൽ വിന്യസിക്കാൻ ഈ രീതി നല്ലതാണ്, എന്നാൽ സ്റ്റാറ്റിക് ഉള്ളടക്കം ഈ രീതിയിൽ നൽകാൻ പൊതുവെ ശുപാർശ ചെയ്യുന്നില്ല. ശരി, വാസ്തവത്തിൽ ഞങ്ങൾ സ്റ്റാറ്റിക് ഉള്ളടക്കം മാത്രമേ നൽകുന്നുള്ളൂ എന്നതിനാൽ, ഞങ്ങളുടെ ചിത്രത്തിനുള്ളിൽ Node.js ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതില്ല - ഒരു വെബ് സെർവർ മതിയാകും.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, അസംബ്ലി ചെയ്യുമ്പോൾ നമുക്ക് ഒരു കാര്യം ആവശ്യമാണ്, എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ മറ്റൊന്ന് ആവശ്യമാണ്. ഈ സാഹചര്യത്തിൽ, ചങ്ങലയുള്ള ബിൽഡുകൾ ഉപയോഗപ്രദമാണ്.

ചങ്ങലയിട്ട പണികൾ

ഇതാണ് അവർ എഴുതുന്നത് ചങ്ങലയിൽ കെട്ടിയുണ്ടാക്കുന്നു OpenShift ഡോക്യുമെന്റേഷനിൽ:

"രണ്ട് അസംബ്ലികൾ ഒരുമിച്ച് ബന്ധിപ്പിക്കാൻ കഴിയും, ഒന്ന് കംപൈൽ ചെയ്ത എന്റിറ്റി സൃഷ്ടിക്കുന്നു, മറ്റൊന്ന് ആ എന്റിറ്റി പ്രവർത്തിപ്പിക്കാൻ ഉപയോഗിക്കുന്ന ഒരു പ്രത്യേക ഇമേജിൽ ആ എന്റിറ്റിയെ ഹോസ്റ്റുചെയ്യുന്നു."

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഞങ്ങളുടെ ബിൽഡ് പ്രവർത്തിപ്പിക്കുന്നതിന് ഞങ്ങൾക്ക് വെബ് ആപ്പ് ബിൽഡർ ഇമേജ് ഉപയോഗിക്കാം, തുടർന്ന് ഞങ്ങളുടെ ഉള്ളടക്കം നൽകുന്നതിന് വെബ് സെർവർ ഇമേജ്, അതേ NGINX ഉപയോഗിക്കാം.

അതിനാൽ, നമുക്ക് വെബ് ആപ്പ് ബിൽഡർ ഇമേജ് ഒരു "ശുദ്ധമായ" ബിൽഡറായി ഉപയോഗിക്കാനും അതേ സമയം ഒരു ചെറിയ റൺടൈം ഇമേജ് ഉണ്ടായിരിക്കാനും കഴിയും.

ഇനി ഇത് ഒരു പ്രത്യേക ഉദാഹരണത്തിലൂടെ നോക്കാം.

പരിശീലനത്തിനായി ഞങ്ങൾ ഉപയോഗിക്കും ലളിതമായ പ്രതികരണ ആപ്ലിക്കേഷൻ, 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 പാരാമീറ്റർ ശ്രദ്ധിക്കുന്നത് മൂല്യവത്താണ്. ഞങ്ങളുടെ ഉദാഹരണത്തിലെ റിയാക്റ്റ് ആപ്ലിക്കേഷന്, വിഷമിക്കേണ്ട കാര്യമില്ല, കാരണം റിയാക്റ്റ് ഔട്ട്‌പുട്ട് ഫോൾഡറായി ഡിഫോൾട്ട് മൂല്യം ഉപയോഗിക്കുന്നു, എന്നാൽ ആംഗുലറിന്റെയോ മറ്റെന്തെങ്കിലുമോ കാര്യത്തിൽ, ഈ പരാമീറ്റർ ആവശ്യാനുസരണം മാറ്റേണ്ടതുണ്ട്.

ഇപ്പോൾ നമുക്ക് ഇമേജ് സ്ട്രീംസ് വിഭാഗം നോക്കാം.

- 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'

മൂന്നാമത്തെയും നാലാമത്തെയും ചിത്രങ്ങൾ നോക്കൂ. അവ രണ്ടും ഡോക്കർ ഇമേജുകളായി നിർവചിച്ചിരിക്കുന്നു, അവ എവിടെ നിന്നാണ് വരുന്നതെന്ന് നിങ്ങൾക്ക് വ്യക്തമായി കാണാൻ കഴിയും.

മൂന്നാമത്തെ ചിത്രം 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

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഈ ബിൽഡിന്റെ ഫലം ഇമേജ് സ്ട്രീംസ് വിഭാഗത്തിൽ ഞങ്ങൾ അൽപ്പം മുമ്പ് കണ്ട അതേ react-web-app-builder ഇമേജിൽ സ്ഥാപിക്കുമെന്ന് ലേബൽ 1 ഉള്ള വരി പറയുന്നു.

2 എന്ന് ലേബൽ ചെയ്‌തിരിക്കുന്ന വരി നിങ്ങളോട് കോഡ് എവിടെ നിന്ന് ലഭിക്കുമെന്ന് പറയുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, ഇതൊരു ജിറ്റ് റിപ്പോസിറ്ററിയാണ്, കൂടാതെ ലൊക്കേഷൻ, റെഫർ, കോൺടെക്സ്റ്റ് ഫോൾഡർ എന്നിവ ഞങ്ങൾ ഇതിനകം മുകളിൽ കണ്ട പാരാമീറ്ററുകൾ അനുസരിച്ചാണ് നിർണ്ണയിക്കുന്നത്.

പാരാമീറ്ററുകൾ വിഭാഗത്തിൽ ഞങ്ങൾ ഇതിനകം കണ്ടതാണ് 3 എന്ന് ലേബൽ ചെയ്തിരിക്കുന്ന വരി. ഇത് OUTPUT_DIR എൻവയോൺമെന്റ് വേരിയബിൾ ചേർക്കുന്നു, അത് ഞങ്ങളുടെ ഉദാഹരണത്തിൽ ബിൽഡ് ആണ്.
ഇമേജ് സ്ട്രീം വിഭാഗത്തിൽ ഞങ്ങൾ ഇതിനകം കണ്ട വെബ്-ആപ്പ്-ബിൽഡർ-റൺടൈം ഇമേജ് ഉപയോഗിക്കാൻ 4 എന്ന് ലേബൽ ചെയ്തിരിക്കുന്ന വരി പറയുന്നു.

S5I ഇമേജ് പിന്തുണയ്ക്കുകയും വെബ് ആപ്പ് ബിൽഡർ ഇമേജ് പിന്തുണയ്ക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, ഒരു ഇൻക്രിമെന്റൽ ബിൽഡ് ഉപയോഗിക്കണമെന്ന് 2 ലേബൽ ചെയ്തിരിക്കുന്ന ലൈൻ പറയുന്നു. ആദ്യ ലോഞ്ചിൽ, അസംബ്ലി ഘട്ടം പൂർത്തിയായ ശേഷം, ചിത്രം 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

അതിനാൽ രണ്ടാമത്തെ ബിൽഡ് കോൺഫിഗറേഷൻ റിയാക്റ്റ്-വെബ്-ആപ്പ്-റൺടൈം ആണ്, ഇത് വളരെ സ്റ്റാൻഡേർഡ് ആയി ആരംഭിക്കുന്നു.

1 എന്ന് ലേബൽ ചെയ്‌തിരിക്കുന്ന ലൈൻ പുതിയ കാര്യമല്ല - ബിൽഡ് റിസൾട്ട് റിയാക്റ്റ്-വെബ്-ആപ്പ്-റൺടൈം ഇമേജിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്നു എന്ന് ഇത് പറയുന്നു.

മുമ്പത്തെ കോൺഫിഗറേഷനിലെന്നപോലെ 2 എന്ന് ലേബൽ ചെയ്തിരിക്കുന്ന വരി, സോഴ്സ് കോഡ് എവിടെ നിന്ന് ലഭിക്കുമെന്ന് സൂചിപ്പിക്കുന്നു. എന്നാൽ ഇവിടെ നമ്മൾ പറയുന്നത് ചിത്രത്തിൽ നിന്ന് എടുത്തതാണെന്ന് ശ്രദ്ധിക്കുക. മാത്രമല്ല, ഞങ്ങൾ ഇപ്പോൾ സൃഷ്ടിച്ച ഇമേജിൽ നിന്ന് - react-web-app-builder-ൽ നിന്ന് (3 എന്ന വരിയിൽ സൂചിപ്പിച്ചിരിക്കുന്നു). ഞങ്ങൾ ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്ന ഫയലുകൾ ചിത്രത്തിനുള്ളിലാണ്, അവയുടെ സ്ഥാനം 4 എന്ന വരിയിൽ സജ്ജീകരിച്ചിരിക്കുന്നു, ഞങ്ങളുടെ കാര്യത്തിൽ അത് /opt/app-root/output/ ആണ്. നിങ്ങൾ ഓർക്കുന്നുവെങ്കിൽ, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ നിർമ്മിക്കുന്നതിന്റെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി സൃഷ്ടിച്ച ഫയലുകൾ ഇവിടെയാണ് സംഭരിക്കുന്നത്.

ലേബൽ 5 ഉള്ള പദത്തിൽ പറഞ്ഞിരിക്കുന്ന ഡെസ്റ്റിനേഷൻ ഫോൾഡർ കേവലം നിലവിലെ ഡയറക്‌ടറിയാണ് (ഇതെല്ലാം ഓപ്പൺഷിഫ്റ്റ് എന്ന മാന്ത്രിക വസ്‌തുവിനുള്ളിലാണ് പ്രവർത്തിക്കുന്നത്, നിങ്ങളുടെ പ്രാദേശിക കമ്പ്യൂട്ടറിലല്ല).

സ്ട്രാറ്റജി വിഭാഗം - 6 എന്ന് ലേബൽ ചെയ്‌തിരിക്കുന്ന വരി - ആദ്യ ബിൽഡ് കോൺഫിഗറേഷന് സമാനമാണ്. ഈ സമയം മാത്രം ഞങ്ങൾ ഇമേജ് സ്ട്രീം വിഭാഗത്തിൽ ഇതിനകം കണ്ട nginx-image-runtime ഉപയോഗിക്കാൻ പോകുന്നു.

അവസാനമായി, 7 എന്ന് ലേബൽ ചെയ്തിരിക്കുന്ന ലൈൻ ട്രിഗറുകളുടെ ഒരു വിഭാഗമാണ്, അത് react-web-app-builder ഇമേജ് മാറുമ്പോഴെല്ലാം ഈ ബിൽഡ് സജീവമാക്കും.

അല്ലെങ്കിൽ, ഈ ടെംപ്ലേറ്റിൽ നല്ല സ്റ്റാൻഡേർഡ് ഡിപ്ലോയ്‌മെന്റ് കോൺഫിഗറേഷനും സേവനങ്ങളുമായും റൂട്ടുകളുമായും ബന്ധപ്പെട്ട കാര്യങ്ങളും അടങ്ങിയിരിക്കുന്നു, എന്നാൽ ഞങ്ങൾ അത്രയും വിശദാംശങ്ങളിലേക്ക് കടക്കില്ല. വിന്യസിക്കപ്പെടുന്ന ചിത്രം റിയാക്റ്റ്-വെബ്-ആപ്പ്-റൺടൈം ചിത്രമാണെന്ന് ദയവായി ശ്രദ്ധിക്കുക.

ആപ്ലിക്കേഷൻ വിന്യാസം

ഇപ്പോൾ നമ്മൾ ടെംപ്ലേറ്റ് പരിശോധിച്ചു, ഒരു ആപ്ലിക്കേഷൻ വിന്യസിക്കാൻ അത് എങ്ങനെ ഉപയോഗിക്കാമെന്ന് നോക്കാം.

ഞങ്ങളുടെ ടെംപ്ലേറ്റ് വിന്യസിക്കാൻ oc എന്ന് വിളിക്കുന്ന OpenShift ക്ലയന്റ് ടൂൾ ഉപയോഗിക്കാം:

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

രണ്ടാമത്തെ കമാൻഡ് ഈ ടെംപ്ലേറ്റിനെ അടിസ്ഥാനമാക്കി ഒരു പുതിയ ആപ്ലിക്കേഷൻ സൃഷ്ടിക്കുന്നു.

ഈ കമാൻഡുകൾ പ്രവർത്തിച്ചതിനുശേഷം, നമുക്ക് രണ്ട് അസംബ്ലികൾ ഉണ്ടെന്ന് കാണാം:

അവലോകന സ്ക്രീനിലേക്ക് മടങ്ങുമ്പോൾ, ലോഞ്ച് ചെയ്ത പോഡ് ഞങ്ങൾ കാണും:

ലിങ്കിൽ ക്ലിക്ക് ചെയ്യുക, ഞങ്ങൾ ഞങ്ങളുടെ ആപ്പിലേക്ക് കൊണ്ടുപോകും, ​​അത് ഡിഫോൾട്ട് റിയാക്റ്റ് ആപ്പ് പേജ് ആണ്:

സപ്ലിമെന്റ് 1

കോണീയ പ്രേമികൾക്കായി ഞങ്ങളുമുണ്ട് ഉദാഹരണ ആപ്ലിക്കേഷൻ.

OUTPUT_DIR വേരിയബിൾ ഒഴികെയുള്ള പാറ്റേൺ ഇവിടെ സമാനമാണ്.

സപ്ലിമെന്റ് 2

ഈ ലേഖനത്തിൽ ഞങ്ങൾ NGINX ഒരു വെബ് സെർവറായി ഉപയോഗിച്ചു, പക്ഷേ അത് അപ്പാച്ചെ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നത് വളരെ എളുപ്പമാണ്, ഫയലിലെ ടെംപ്ലേറ്റ് മാറ്റുക NGINX ചിത്രം ഓൺ അപ്പാച്ചെ ചിത്രം.

തീരുമാനം

ഈ പരമ്പരയുടെ ആദ്യ ഭാഗത്തിൽ, OpenShift പ്ലാറ്റ്‌ഫോമിൽ ആധുനിക വെബ് ആപ്ലിക്കേഷനുകൾ എങ്ങനെ വേഗത്തിൽ വിന്യസിക്കാമെന്ന് ഞങ്ങൾ കാണിച്ചുതന്നു. ഒരു വെബ് ആപ്പ് ഇമേജ് എന്താണ് ചെയ്യുന്നതെന്നും കൂടുതൽ പ്രൊഡക്ഷൻ-റെഡി ആപ്ലിക്കേഷൻ ബിൽഡ് സൃഷ്‌ടിക്കുന്നതിന് ചെയിൻഡ് ബിൽഡുകൾ ഉപയോഗിച്ച് NGINX പോലുള്ള ഒരു ശുദ്ധമായ വെബ് സെർവറുമായി അത് എങ്ങനെ സംയോജിപ്പിക്കാമെന്നും ഇന്ന് ഞങ്ങൾ പരിശോധിച്ചു. ഈ പരമ്പരയിലെ അടുത്തതും അവസാനവുമായ ലേഖനത്തിൽ, OpenShift-ൽ നിങ്ങളുടെ ആപ്ലിക്കേഷനായി ഒരു ഡെവലപ്‌മെന്റ് സെർവർ എങ്ങനെ പ്രവർത്തിപ്പിക്കാമെന്നും ലോക്കൽ, റിമോട്ട് ഫയലുകളുടെ സമന്വയം ഉറപ്പാക്കുന്നത് എങ്ങനെയെന്നും ഞങ്ങൾ കാണിക്കും.

ഈ ലേഖന പരമ്പരയുടെ ഉള്ളടക്കം

• ഭാഗം XX: ഏതാനും ഘട്ടങ്ങളിലൂടെ ആധുനിക വെബ് ആപ്ലിക്കേഷനുകൾ എങ്ങനെ വിന്യസിക്കാം;
• ഭാഗം 2: പ്രൊഡക്ഷൻ വിന്യാസത്തിനായി അനുബന്ധ ഓപ്പൺഷിഫ്റ്റ് അസംബ്ലികൾ ഉപയോഗിച്ച് NGINX പോലുള്ള നിലവിലുള്ള HTTP സെർവർ ഇമേജിനൊപ്പം ഒരു പുതിയ S2I ഇമേജ് എങ്ങനെ ഉപയോഗിക്കാം;
• ഭാഗം 3: ഓപ്പൺഷിഫ്റ്റ് പ്ലാറ്റ്‌ഫോമിൽ നിങ്ങളുടെ ആപ്ലിക്കേഷനായി ഒരു ഡെവലപ്‌മെന്റ് സെർവർ എങ്ങനെ പ്രവർത്തിപ്പിക്കുകയും പ്രാദേശിക ഫയൽ സിസ്റ്റവുമായി സമന്വയിപ്പിക്കുകയും ചെയ്യാം.

അധിക വിഭവങ്ങൾ

• സൗജന്യ ഇ-ബുക്ക് OpenShift-ലേക്ക് വിന്യസിക്കുന്നു.
• സംബന്ധിച്ച വിവരങ്ങൾ ഓപ്പൺഷിഫ്റ്റും കുബർനെറ്റസും.

അവലംബം: www.habr.com