Aplikacione moderne në OpenShift, pjesa 2: ndërtime me zinxhirë

Pershendetje te gjitheve! Ky është postimi i dytë në serinë tonë në të cilin ne tregojmë se si të vendosim aplikacione moderne në internet në Red Hat OpenShift.

Në postimin e mëparshëm, ne prekëm pak aftësitë e imazhit të ri të ndërtuesit S2I (burim në imazh), i cili është krijuar për ndërtimin dhe vendosjen e aplikacioneve moderne në internet në platformën OpenShift. Pastaj ne ishim të interesuar për temën e vendosjes së shpejtë të një aplikacioni, dhe sot do të shikojmë se si të përdorim një imazh S2I si një imazh ndërtues "të pastër" dhe ta kombinojmë atë me asambletë përkatëse OpenShift.

Imazhi i pastër i ndërtuesit

Siç e përmendëm në Pjesën XNUMX, shumica e aplikacioneve moderne të ueb-it kanë një të ashtuquajtur fazë ndërtimi, e cila zakonisht kryen operacione të tilla si transpilimi i kodit, bashkimi i shumëfishtë i skedarëve dhe minifikimi. Skedarët e marrë si rezultat i këtyre operacioneve - dhe ky është HTML statik, JavaScript dhe CSS - ruhen në dosjen e daljes. Vendndodhja e kësaj dosjeje zakonisht varet nga mjetet e ndërtimit që përdoren, dhe për React do të jetë dosja ./build (do t'i kthehemi kësaj më në detaje më poshtë).

Burimi në imazh (S2I)

Në këtë postim ne nuk prekim temën "çfarë është S2I dhe si ta përdorim atë" (mund të lexoni më shumë rreth kësaj këtu), por është e rëndësishme të jesh i qartë në lidhje me dy hapat në këtë proces për të kuptuar se çfarë bën një imazh i ndërtuesit të aplikacioneve në ueb.

Faza e montimit

Faza e montimit është shumë e ngjashme në natyrë me atë që ndodh kur ekzekutoni ndërtimin e docker dhe përfundoni me një imazh të ri Docker. Prandaj, kjo fazë ndodh kur filloni një ndërtim në platformën OpenShift.

Në rastin e një imazhi të ndërtuesit të aplikacionit në ueb, ai është përgjegjës për instalimin e varësive të aplikacionit tuaj dhe ekzekutimin e ndërtimit. montoni skriptin. Si parazgjedhje, imazhi i ndërtuesit përdor konstruktin e ndërtimit të ekzekutimit npm, por kjo mund të anashkalohet përmes ndryshores së mjedisit NPM_BUILD.

Siç thamë më herët, vendndodhja e aplikacionit të përfunduar, tashmë të ndërtuar varet nga mjetet që përdorni. Për shembull, në rastin e React kjo do të jetë dosja ./build, dhe për aplikacionet Angular do të jetë dosja project_name/dist. Dhe, siç është treguar tashmë në postimin e mëparshëm, vendndodhja e drejtorisë së daljes, e cila është caktuar të ndërtohet si parazgjedhje, mund të anashkalohet përmes ndryshores së mjedisit OUTPUT_DIR. Epo, meqenëse vendndodhja e dosjes së daljes ndryshon nga korniza në kornizë, thjesht kopjoni daljen e gjeneruar në dosjen standarde në imazh, përkatësisht /opt/apt-root/output. Kjo është e rëndësishme për të kuptuar pjesën tjetër të këtij artikulli, por tani për tani le të shohim shpejt fazën tjetër - fazën e ekzekutimit.

faza e ekzekutimit

Kjo fazë ndodh kur bëhet një thirrje për ekzekutimin e docker në imazhin e ri të krijuar gjatë fazës së montimit. E njëjta gjë ndodh kur vendoset në platformën OpenShift. E paracaktuar ekzekutoni skenarin përdor moduli i shërbimit për të shërbyer përmbajtje statike të vendosura në direktorinë e mësipërme standarde të daljes.

Kjo metodë është e mirë për vendosjen e shpejtë të aplikacioneve, por në përgjithësi nuk rekomandohet të shërbehet në këtë mënyrë përmbajtje statike. Epo, meqenëse në realitet ne shërbejmë vetëm përmbajtje statike, nuk kemi nevojë për Node.js të instaluar brenda imazhit tonë - një server në internet do të mjaftojë.

Me fjalë të tjera, kur montojmë na duhet një gjë, kur ekzekutojmë na duhet një tjetër. Në këtë situatë, ndërtimet me zinxhirë vijnë në ndihmë.

Ndërton me zinxhirë

Për këtë shkruajnë ndërton me zinxhirë në dokumentacionin OpenShift:

"Dy asamble mund të lidhen së bashku, ku njëri gjeneron një entitet të përpiluar dhe tjetri e pret atë entitet në një imazh të veçantë që përdoret për të drejtuar atë ent."

Me fjalë të tjera, ne mund të përdorim imazhin e Web App Builder për të ekzekutuar ndërtimin tonë, dhe më pas të përdorim imazhin e serverit të uebit, të njëjtin NGINX, për të shërbyer përmbajtjen tonë.

Kështu, ne mund të përdorim imazhin e Web App Builder si një ndërtues "të pastër" dhe në të njëjtën kohë të kemi një imazh të vogël të ekzekutimit.

Tani le ta shohim këtë me një shembull specifik.

Për trajnim do të përdorim aplikacion i thjeshtë React, krijuar duke përdorur veglën e linjës së komandës Creative-react-app.

Do të na ndihmojë të bashkojmë gjithçka Skedari i shabllonit OpenShift.

Le ta shohim këtë skedar në më shumë detaje dhe të fillojmë me seksionin e parametrave.

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

Gjithçka këtu është mjaft e qartë, por ia vlen t'i kushtohet vëmendje parametrit OUTPUT_DIR. Për aplikacionin React në shembullin tonë, nuk ka asgjë për t'u shqetësuar, pasi React përdor vlerën e paracaktuar si dosje dalëse, por në rastin e Angular ose diçka tjetër, ky parametër do të duhet të ndryshohet sipas nevojës.

Tani le të hedhim një vështrim në seksionin 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'

Hidhini një sy imazheve të tretë dhe të katërt. Të dyja përcaktohen si imazhe Docker dhe ju mund të shihni qartë se nga vijnë.

Imazhi i tretë është ndërtuesi i aplikacioneve uebi dhe vjen nga nodeshift/ubi8-s2i-web-app i etiketuar 10.x në Docker qendër.

E katërta është një imazh NGINX (versioni 1.12) me etiketën më të fundit Docker qendër.

Tani le të shohim dy imazhet e para. Ata janë të dy bosh në fillim dhe krijohen vetëm gjatë fazës së ndërtimit. Imazhi i parë, react-web-app-builder, do të jetë rezultat i një hapi të montimit që do të kombinojë imazhin e web-app-builder-runtime dhe kodin tonë burimor. Kjo është arsyeja pse ne kemi shtuar "-builder" në emrin e këtij imazhi.

Imazhi i dytë - react-web-app-runtime - do të jetë rezultat i kombinimit të nginx-image-runtime dhe disa skedarëve nga imazhi react-web-app-builder. Ky imazh do të përdoret gjithashtu gjatë vendosjes dhe do të përmbajë vetëm serverin e uebit dhe HTML statike, JavaScript, CSS të aplikacionit tonë.

Të hutuar? Tani le të hedhim një vështrim në konfigurimet e ndërtimit dhe do të bëhet pak më e qartë.

Shablloni ynë ka dy konfigurime ndërtimi. Këtu është i pari, dhe është mjaft standard:

  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

Siç mund ta shihni, rreshti me etiketën 1 thotë se rezultati i këtij ndërtimi do të vendoset në të njëjtin imazh të react-web-app-builder që pamë pak më parë në seksionin ImageStreams.

Rreshti i etiketuar 2 ju tregon se nga ta merrni kodin. Në rastin tonë, kjo është një depo git, dhe vendndodhja, ref dhe dosja e kontekstit përcaktohen nga parametrat që kemi parë më lart.

Linja e emërtuar 3 është ajo që kemi parë tashmë në seksionin e parametrave. Ai shton variablin e mjedisit OUTPUT_DIR, i cili në shembullin tonë është i ndërtuar.
Linja e etiketuar 4 thotë që të përdoret imazhi i ndërtuesit të aplikacionit në ueb-runtime, të cilin e kemi parë tashmë në seksionin ImageStream.

Rreshti i etiketuar 5 thotë se ne duam të përdorim një ndërtim në rritje nëse imazhi S2I e mbështet atë, dhe imazhi i Ndërtuesit të Uebit të Aplikacioneve e bën këtë. Në nisjen e parë, pasi të përfundojë faza e montimit, imazhi do të ruajë dosjen node_modules në një skedar arkiv. Më pas, në ekzekutimet e mëvonshme, imazhi thjesht do të hapë këtë dosje për të zvogëluar kohën e ndërtimit.

Dhe së fundi, linja e emërtuar 6 është vetëm disa shkas për të bërë që ndërtimi të funksionojë automatikisht, pa ndërhyrje manuale, kur diçka ndryshon.

Në përgjithësi, ky është një konfigurim mjaft standard ndërtimi.

Tani le të hedhim një vështrim në konfigurimin e dytë të ndërtimit. Është shumë e ngjashme me të parën, por ka një ndryshim të rëndësishëm.

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

Pra, konfigurimi i dytë i ndërtimit është react-web-app-runtime, dhe fillon mjaft standard.

Linja e etiketuar 1 nuk është asgjë e re - thjesht thotë se rezultati i ndërtimit vendoset në imazhin react-web-app-runtime.

Rreshti i etiketuar 2, si në konfigurimin e mëparshëm, tregon se nga mund të merrni kodin burimor. Por vini re se këtu po themi se është marrë nga imazhi. Për më tepër, nga imazhi që sapo krijuam - nga react-web-app-builder (treguar në rreshtin e etiketuar 3). Skedarët që duam të përdorim janë brenda imazhit dhe vendndodhja e tyre është vendosur në rreshtin e emërtuar 4, në rastin tonë është /opt/app-root/output/. Nëse ju kujtohet, këtu ruhen skedarët e krijuar bazuar në rezultatet e ndërtimit të aplikacionit tonë.

Dosja e destinacionit e specifikuar në termin me etiketën 5 është thjesht direktoria aktuale (kjo është e gjitha, mbani mend, që funksionon brenda një gjëje magjike të quajtur OpenShift, dhe jo në kompjuterin tuaj lokal).

Seksioni i strategjisë - rreshti i emërtuar 6 - është gjithashtu i ngjashëm me konfigurimin e parë të ndërtimit. Vetëm këtë herë do të përdorim nginx-image-runtime, të cilën e kemi parë tashmë në seksionin ImageStream.

Së fundi, linja e emërtuar 7 është një pjesë e nxitësve që do ta aktivizojnë këtë ndërtim sa herë që ndryshon imazhi i react-web-app-builder.

Përndryshe, ky shabllon përmban një konfigurim mjaft standard të vendosjes, si dhe gjëra që kanë të bëjnë me shërbimet dhe rrugët, por ne nuk do të hyjmë në atë shumë detaje. Ju lutemi vini re se imazhi që do të vendoset është imazhi react-web-app-runtime.

Vendosja e aplikacionit

Pra, tani që kemi parë shabllonin, le të shohim se si ta përdorim atë për të vendosur një aplikacion.

Ne mund të përdorim mjetin e klientit OpenShift të quajtur oc për të vendosur shabllonin tonë:

$ 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

Komanda e parë në pamjen e mësipërme është një mënyrë inxhinierike e qëllimshme për të gjetur një shabllon./openshiftio/application.yaml.

Komanda e dytë thjesht krijon një aplikacion të ri bazuar në këtë shabllon.

Pasi të funksionojnë këto komanda, do të shohim se kemi dy asamble:

Dhe duke u kthyer në ekranin e Përmbledhjes, do të shohim podin e nisur:

Klikoni lidhjen dhe ne do të çojmë te aplikacioni ynë, i cili është faqja e parazgjedhur e aplikacionit React:

Suplement 1

Për adhuruesit e Angular kemi gjithashtu shembull aplikimi.

Modeli këtu është i njëjtë, me përjashtim të ndryshores OUTPUT_DIR.

Suplement 2

Në këtë artikull ne kemi përdorur NGINX si një server në internet, por është mjaft e lehtë ta zëvendësoni atë me Apache, thjesht ndryshoni shabllonin në skedar Imazhi NGINX mbi Imazhi Apache.

Përfundim

Në pjesën e parë të kësaj serie, ne treguam se si të vendosim shpejt aplikacionet moderne në ueb në platformën OpenShift. Sot ne shikuam se çfarë bën një imazh i aplikacionit në ueb dhe si mund të kombinohet me një server të pastër ueb si NGINX duke përdorur struktura të lidhura me zinxhirë për të krijuar një ndërtim aplikacioni më të gatshëm për prodhim. Në artikullin tjetër dhe të fundit të kësaj serie, ne do të tregojmë se si të ekzekutoni një server zhvillimi për aplikacionin tuaj në OpenShift dhe të sigurojmë sinkronizimin e skedarëve lokalë dhe të largët.

Përmbajtja e kësaj serie artikujsh

• Pjesa 1: si të vendosni aplikacione moderne në internet në vetëm disa hapa;
• Pjesa 2: Si të përdorni një imazh të ri S2I me një imazh ekzistues të serverit HTTP, siç është NGINX, duke përdorur asambletë e lidhura OpenShift për vendosjen e prodhimit;
• Pjesa 3: si të ekzekutoni një server zhvillimi për aplikacionin tuaj në platformën OpenShift dhe ta sinkronizoni atë me sistemin lokal të skedarëve.

Burime Shtesë

• Libër elektronik falas Vendosja në OpenShift.
• Informacion mbi OpenShift dhe Kubernetes.

Burimi: www.habr.com