ProHoster > Blogs > Administrācija > MÅ«sdienÄ«gas lietojumprogrammas OpenShift, 2. daļa: ķēdes veidojumi

MÅ«sdienÄ«gas lietojumprogrammas OpenShift, 2. daļa: ķēdes veidojumi

Sveiki visiem! Šis ir otrais ieraksts mūsu sērijā, kurā mēs parādām, kā izvietot modernas tīmekļa lietojumprogrammas Red Hat OpenShift.

MÅ«sdienÄ«gas lietojumprogrammas OpenShift, 2. daļa: ķēdes veidojumi

IepriekŔējā ierakstā mēs nedaudz pieskārāmies jaunā S2I (source-to-image) veidotāja attēla iespējām, kas paredzēts modernu tÄ«mekļa lietojumprogrammu veidoÅ”anai un izvietoÅ”anai OpenShift platformā. Tad mÅ«s interesēja tēma par lietojumprogrammas ātru izvietoÅ”anu, un Å”odien mēs apskatÄ«sim, kā izmantot S2I attēlu kā ā€œtÄ«ruā€ veidotāja attēlu un apvienot to ar saistÄ«tajiem OpenShift komplektiem.

Tīrs celtnieka attēls

Kā jau minējām XNUMX. daļā, lielākajai daļai mÅ«sdienu tÄ«mekļa lietojumprogrammu ir tā sauktā veidoÅ”anas stadija, kas parasti veic tādas darbÄ«bas kā koda transpilācija, vairāku failu savienoÅ”ana un samazināŔana. Å o darbÄ«bu rezultātā iegÅ«tie faili - un tas ir statisks HTML, JavaScript un CSS - tiek saglabāti izvades mapē. Å Ä«s mapes atraÅ”anās vieta parasti ir atkarÄ«ga no tā, kādi veidoÅ”anas rÄ«ki tiek izmantoti, un React tā bÅ«s mape ./build (sÄ«kāk par to atgriezÄ«simies tālāk).

No avota uz attēlu (S2I)

Å ajā ierakstā mēs nepieskaramies tēmai ā€œkas ir S2I un kā to lietotā€ (par to varat lasÄ«t vairāk Å”eit), taču ir svarÄ«gi skaidri saprast abas Ŕī procesa darbÄ«bas, lai saprastu, ko dara Web App Builder attēls.

Montāžas posms

Montāžas fāze pēc bÅ«tÄ«bas ir ļoti lÄ«dzÄ«ga tam, kas notiek, palaižot Docker build un beidzot ar jaunu Docker attēlu. AttiecÄ«gi Å”is posms notiek, uzsākot bÅ«vniecÄ«bu OpenShift platformā.

Web App Builder attēla gadÄ«jumā tas ir atbildÄ«gs par jÅ«su lietojumprogrammas atkarÄ«bu instalÄ“Å”anu un bÅ«vējuma palaiÅ”anu. salikt skriptu. Pēc noklusējuma veidotāja attēls izmanto npm palaist bÅ«vkonstrukciju, taču to var ignorēt, izmantojot vides mainÄ«go NPM_BUILD.

Kā jau teicām iepriekÅ”, gatavās, jau izveidotās lietojumprogrammas atraÅ”anās vieta ir atkarÄ«ga no tā, kādus rÄ«kus izmantojat. Piemēram, React gadÄ«jumā tā bÅ«s mape ./build, bet Angular lietojumprogrammām tā bÅ«s mape project_name/dist. Un, kā jau parādÄ«ts iepriekŔējā ziņojumā, izvades direktorija atraÅ”anās vietu, kas pēc noklusējuma ir iestatÄ«ta izveidei, var ignorēt, izmantojot vides mainÄ«go OUTPUT_DIR. Tā kā izvades mapes atraÅ”anās vieta dažādās sistēmās atŔķiras, jÅ«s vienkārÅ”i kopējiet Ä£enerēto izvadi uz attēla standarta mapi, proti, /opt/apt-root/output. Tas ir svarÄ«gi, lai izprastu pārējo Ŕī raksta daļu, taču tagad ātri apskatÄ«sim nākamo posmu - palaiÅ”anas fāzi.

palaiŔanas fāze

Å is posms notiek, kad jaunajam attēlam, kas izveidots montāžas posmā, tiek veikts izsaukums Docker palaiÅ”anai. Tas pats notiek, izvietojot OpenShift platformā. Noklusējums palaist skriptu izmanto apkalpoÅ”anas modulis lai apkalpotu statisku saturu, kas atrodas iepriekÅ” minētajā standarta izvades direktorijā.

Å Ä« metode ir piemērota ātrai lietojumprogrammu izvietoÅ”anai, taču parasti nav ieteicams Ŕādā veidā apkalpot statisku saturu. Tā kā patiesÄ«bā mēs apkalpojam tikai statisku saturu, mÅ«su attēlā nav nepiecieÅ”ams instalēt Node.js ā€” pietiks ar tÄ«mekļa serveri.

Citiem vārdiem sakot, montējot mums vajag vienu lietu, izpildot citu. Šajā situācijā noder ķēdes būvējumi.

Ķēdes būves

Par to viņi raksta ķēdes būvē OpenShift dokumentācijā:

ā€œVar saistÄ«t kopā divus komplektus, no kuriem viens Ä£enerē kompilētu entÄ«tiju, bet otrs mitina Å”o entÄ«tiju atseviŔķā attēlā, ko izmanto Ŕīs entÄ«tijas palaiÅ”anai.ā€

Citiem vārdiem sakot, mēs varam izmantot Web App Builder attēlu, lai palaistu bÅ«vējumu, un pēc tam izmantot tÄ«mekļa servera attēlu, to paÅ”u NGINX, lai nodroÅ”inātu mÅ«su saturu.

Tādējādi mēs varam izmantot Web App Builder attēlu kā ā€œtÄ«ruā€ veidotāju un tajā paŔā laikā izmantot nelielu izpildlaika attēlu.

Tagad aplūkosim to ar konkrētu piemēru.

Treniņiem izmantosim vienkārÅ”a React lietojumprogramma, kas izveidota, izmantojot komandrindas rÄ«ku Create-react-app.

Tas mums palīdzēs visu apvienot OpenShift veidnes fails.

Apskatīsim Ŕo failu sīkāk un sāksim ar parametru sadaļu.

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

Å eit viss ir diezgan skaidrs, taču ir vērts pievērst uzmanÄ«bu parametram OUTPUT_DIR. Lietojumprogrammai React mÅ«su piemērā nav par ko uztraukties, jo React kā izvades mapi izmanto noklusējuma vērtÄ«bu, bet Angular vai kaut kā cita gadÄ«jumā Å”is parametrs bÅ«s jāmaina pēc vajadzÄ«bas.

Tagad apskatīsim sadaļu 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'

Apskatiet treÅ”o un ceturto attēlu. Tie abi ir definēti kā Docker attēli, un jÅ«s varat skaidri redzēt, no kurienes tie nāk.

TreÅ”ais attēls ir tÄ«mekļa lietotņu veidotājs, un tas nāk no nodeshift/ubi8-s2i-web-app, kas marķēts ar 10.x. Docker centrs.

Ceturtais ir NGINX attēls (versija 1.12) ar ieslēgtu jaunāko tagu Docker centrs.

Tagad apskatÄ«sim pirmos divus attēlus. Tie abi sākumā ir tukÅ”i un tiek izveidoti tikai veidoÅ”anas fāzē. Pirmais attēls, react-web-app-builder, bÅ«s montāžas darbÄ«bas rezultāts, kurā tiks apvienots tÄ«mekļa lietotņu veidotāja izpildlaika attēls un mÅ«su avota kods. Tāpēc Ŕī attēla nosaukumam pievienojām ā€œ-builderā€.

Otrais attēls ā€” react-web-app-runtime ā€” tiks iegÅ«ts, apvienojot nginx-image-runtime un dažus failus no react-web-app-builder attēla. Å is attēls tiks izmantots arÄ« izvietoÅ”anas laikā, un tajā bÅ«s tikai mÅ«su lietojumprogrammas tÄ«mekļa serveris un statiskais HTML, JavaScript un CSS.

Apjucis? Tagad apskatīsim būvniecības konfigurācijas, un tas kļūs nedaudz skaidrāks.

MÅ«su veidnei ir divas bÅ«vÄ“Å”anas konfigurācijas. Å eit ir pirmais, un tas ir diezgan standarta:

  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

Kā redzat, rindiņā ar iezÄ«mi 1 ir teikts, ka Ŕīs bÅ«ves rezultāts tiks ievietots tajā paŔā react-web-app-builder attēlā, ko redzējām nedaudz agrāk sadaļā ImageStreams.

Rinda ar 2 norāda, no kurienes iegÅ«t kodu. MÅ«su gadÄ«jumā Ŕī ir git repozitorijs, un atraÅ”anās vietu, ref un konteksta mapi nosaka parametri, kurus mēs jau redzējām iepriekÅ”.

Līnija, kas apzīmēta ar 3, ir tā, ko mēs jau redzējām parametru sadaļā. Tas pievieno vides mainīgo OUTPUT_DIR, kas mūsu piemērā ir uzbūve.
Rindā, kas apzīmēta ar 4, ir norādīts izmantot tīmekļa lietotņu veidotāja izpildlaika attēlu, ko mēs jau redzējām sadaļā ImageStream.

Rindā, kas apzÄ«mēta ar 5, ir teikts, ka mēs vēlamies izmantot pakāpenisku bÅ«vējumu, ja S2I attēls to atbalsta un Web App Builder attēls to atbalsta. Pirmajā palaiÅ”anas reizē pēc montāžas posma pabeigÅ”anas attēls mapi node_modules saglabās arhÄ«va failā. Pēc tam nākamajās palaistÄ«bās attēls vienkārÅ”i izpakos Å”o mapi, lai samazinātu izveides laiku.

Visbeidzot, rindiņa ar 6 ir tikai daži aktivizētāji, lai, kad kaut kas mainās, bÅ«vējums tiktu palaists automātiski, bez manuālas iejaukÅ”anās.

Kopumā Ŕī ir diezgan standarta konstrukcijas konfigurācija.

Tagad apskatÄ«sim otro bÅ«vējuma konfigurāciju. Tas ir ļoti lÄ«dzÄ«gs pirmajam, taču ir viena bÅ«tiska atŔķirÄ«ba.

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

Tātad otrās versijas konfigurācija ir react-web-app-runtime, un tā sākas diezgan standarta.

Rinda ar apzÄ«mējumu 1 nav nekas jauns ā€” tā vienkārÅ”i norāda, ka izveides rezultāts tiek ievietots react-web-app-runtime attēlā.

Rinda, kas apzÄ«mēta ar 2, tāpat kā iepriekŔējā konfigurācijā, norāda, no kurienes iegÅ«t avota kodu. Bet ievērojiet, ka Å”eit mēs sakām, ka tas ir ņemts no attēla. Turklāt no attēla, ko tikko izveidojām - no react-web-app-builder (norādÄ«ts rindā ar 3). Faili, kurus vēlamies izmantot, atrodas attēla iekÅ”pusē, un to atraÅ”anās vieta ir iestatÄ«ta rindā ar apzÄ«mējumu 4, mÅ«su gadÄ«jumā tā ir /opt/app-root/output/. Ja atceraties, Å”eit tiek glabāti faili, kas Ä£enerēti, pamatojoties uz mÅ«su lietojumprogrammas izveides rezultātiem.

MērÄ·a mape, kas norādÄ«ta terminā ar iezÄ«mi 5, ir vienkārÅ”i paÅ”reizējais direktorijs (atcerieties, tas ir viss, kas darbojas kādā maÄ£iskā lietā, ko sauc par OpenShift, nevis jÅ«su lokālajā datorā).

Stratēģijas sadaļa ā€” rindiņa ar apzÄ«mējumu 6 ā€” arÄ« ir lÄ«dzÄ«ga pirmās versijas konfigurācijai. Tikai Å”oreiz mēs izmantosim nginx-image-runtime, ko jau redzējām sadaļā ImageStream.

Visbeidzot, rindiņa ar 7 ir aktivizētāju sadaļa, kas aktivizēs Å”o bÅ«vējumu ikreiz, kad mainÄ«sies react-web-app-builder attēls.

Pretējā gadÄ«jumā Å”ajā veidnē ir ietverta diezgan standarta izvietoÅ”anas konfigurācija, kā arÄ« lietas, kas attiecas uz pakalpojumiem un marÅ”rutiem, taču mēs tajā neiedziļināsimies. LÅ«dzu, ņemiet vērā, ka attēls, kas tiks izvietots, ir react-web-app-runtime attēls.

Lietojumprogrammu izvietoŔana

Tagad, kad esam apskatÄ«juÅ”i veidni, redzēsim, kā to izmantot lietojumprogrammas izvietoÅ”anai.

Mēs varam izmantot OpenShift klienta rīku, ko sauc par oc, lai izvietotu mūsu veidni:

$ 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

Pirmā komanda iepriekÅ” redzamajā ekrānuzņēmumā ir apzināti izstrādāts veids, kā atrast veidni./openshiftio/application.yaml.

Otrā komanda vienkārŔi izveido jaunu lietojumprogrammu, pamatojoties uz Ŕo veidni.

Kad Ŕīs komandas darbosies, mēs redzēsim, ka mums ir divi bloki:

MÅ«sdienÄ«gas lietojumprogrammas OpenShift, 2. daļa: ķēdes veidojumi

Un, atgriežoties ekrānā Kopsavilkums, mēs redzēsim palaistu podziņu:

MÅ«sdienÄ«gas lietojumprogrammas OpenShift, 2. daļa: ķēdes veidojumi

NoklikŔķiniet uz saites, un mēs tiksim novirzÄ«ti uz mÅ«su lietotni, kas ir noklusējuma React App lapa:

MÅ«sdienÄ«gas lietojumprogrammas OpenShift, 2. daļa: ķēdes veidojumi

Papildinājums 1. gadam

Mums ir arī Angular mīļotājiem lietojumprogrammas piemērs.

Šeit redzamā shēma ir tāda pati, izņemot mainīgo OUTPUT_DIR.

Papildinājums 2. gadam

Å ajā rakstā mēs izmantojām NGINX kā tÄ«mekļa serveri, taču to ir diezgan viegli aizstāt ar Apache, vienkārÅ”i mainiet veidni failā NGINX attēls par Apache attēls.

Secinājums

Å Ä«s sērijas pirmajā daļā mēs parādÄ«jām, kā ātri izvietot modernas tÄ«mekļa lietojumprogrammas OpenShift platformā. Å odien mēs apskatÄ«jām, ko dara Web App attēls un kā to var apvienot ar tÄ«ru tÄ«mekļa serveri, piemēram, NGINX, izmantojot ķēdes bÅ«vējumus, lai izveidotu ražoÅ”anai gatavāku lietojumprogrammu bÅ«vējumu. Nākamajā un pēdējā Ŕīs sērijas rakstā mēs parādÄ«sim, kā palaist izstrādes serveri jÅ«su lietojumprogrammai OpenShift un nodroÅ”ināt vietējo un attālo failu sinhronizāciju.

Šīs rakstu sērijas saturs

Papildu resursi

Avots: www.habr.com

Pievieno komentāru