ProHoster > Blog > Administrimi > Aplikacionet moderne në OpenShift, pjesa 2: ndërlidhja e ndërtimeve të varura

Aplikacionet moderne në OpenShift, pjesa 2: ndërlidhja e ndërtimeve të varura

Përshëndetje të gjithëve! Ky është postimi ynë i dytë nga seria ku ne tregojmë si të drejtojmë aplikacione moderne web në Red Hat OpenShift.

Aplikacionet moderne në OpenShift, pjesa 2: ndërlidhja e ndërtimeve të varura

Në postimin e kaluar, ne diskutuan lehtë mbi mundësitë e imazhit të ri builder S2I (source-to-image), i cili është i destinuar për ndërtimin dhe drejtpërdrejtimin e aplikacioneve moderne web në platformën OpenShift. Atëherë u interesuam për temën e drejtimeve të shpejta të aplikacionit, ndërsa sot do të shqyrtojmë se si të përdorim imazhin S2I si një 'builder' të pastër dhe ta bashkojmë atë me ndërtimet e lidhura të OpenShift.

Builder i pastër

Siç e pĂ«rmendĂ«m nĂ« pjesĂ«n e parĂ«, shumica e aplikacioneve moderne web kanĂ« njĂ« fazĂ« ndĂ«rtimi, nĂ« tĂ« cilĂ«n zakonisht kryhen operacione si transpiling kod, bashkimi i disa skedarĂ«ve dhe minifikimi. SkedarĂ«t e rezultuar nga kĂ«to operacione – qĂ« pĂ«rfshijnĂ« HTML statik, JavaScript dhe CSS – grumbullohen nĂ« dosjen e output-it. Lokacioni i kĂ«saj dosjeje zakonisht varet nga mjetet e ndĂ«rtimit qĂ« pĂ«rdoren, dhe pĂ«r React, kjo do tĂ« jetĂ« dosja ./build (do tĂ« kthehemi pĂ«r kĂ«tĂ« mĂ« poshtĂ«).

Source-to-Image (S2I)

Në këtë post, ne nuk do të diskutojmë fare temën 'çfarë është S2I dhe si ta përdorim' (mund të lexoni më shumë për këtë këtu), por është e rëndësishme të kuptojmë qartë dy fazat e këtij procesi, në mënyrë që të kuptojmë çfarë bënë imazhi i Web App Builder.

Faza e asambletimit (assemble phase)

Faza e asambletimit është në thelb shumë e ngjashme me atë që ndodh kur keni ekzekutuar docker build dhe si rezultat merrni një imazh të ri Docker. Prandaj, kjo fazë ndodh kur filloni ndërtimin në platformën OpenShift.

Në rastin e imazhit të Web App Builder, për instalimin e varësive të aplikacionit tuaj dhe për të filluar ndërtimin është përgjegjës skripti i asambletimit. Me default, imazhi builder përdor ndërtimin npm run build, por mund të tejkaloni këtë përmes variablit të mjedisit NPM_BUILD.

Siç e kemi thĂ«nĂ« mĂ« parĂ«, vendndodhja e aplikacionit tĂ« gatshĂ«m, tĂ« ndĂ«rtuar, varet nga cilat mjete pĂ«rdoren. PĂ«r shembull, nĂ« rastin e React, kjo do tĂ« jetĂ« dosja ./build, ndĂ«rsa pĂ«r aplikacionet Angular – dosja project_name/dist. Dhe, siç u tregua nĂ« postimin e kaluar, vendndodhja e dosjes sĂ« output-it, e cila Ă«shtĂ« caktuar si build nga default, mund tĂ« tejkalohet pĂ«rmes variablit tĂ« mjedisit OUTPUT_DIR. Dhe pĂ«r sa kohĂ« qĂ« vendndodhja e dosjes sĂ« output-it ndryshon nga njĂ« framework nĂ« tjetrin, thjesht kopjoni output-in e generuar nĂ« dosjen standarde tĂ« imazhit, qĂ« Ă«shtĂ« /opt/apt-root/output. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r tĂ« kuptuar pjesĂ«n tjetĂ«r tĂ« kĂ«tij artikulli, ndĂ«rsa le tĂ« shqyrtojmĂ« shpejt fazĂ«n tjetĂ«r – faza e ekzekutimit.

Faza e ekzekutimit (run phase)

Kjo fazë ndodh kur bëhet thirrje docker run për imazhin e ri, të krijuar në fazën e asambletimit. Kjo ndodh gjithashtu gjatë ekzekutimit të drejtimit në platformën OpenShift. Me default, run script përdor moduli serve për shërbimin e përmbajtjes statike, e cila ndodhet në dosjen standarde të output-it të përmendur më lart.

Ky metodĂ« Ă«shtĂ« e mirĂ« pĂ«r drejtime tĂ« shpejta tĂ« aplikacioneve, por nĂ« tĂ« vĂ«rtetĂ« nuk rekomandohet tĂ« shĂ«rbehet pĂ«rmbajtja statike nĂ« kĂ«tĂ« mĂ«nyrĂ«. E thĂ«nĂ« ndryshe, ndonjĂ«herĂ« ne shĂ«rbejmĂ« vetĂ«m pĂ«rmbajtje statike, ndonjĂ«herĂ« Node.js i instaluar brenda imazhit tonĂ« nuk Ă«shtĂ« i nevojshĂ«m – njĂ« server web mjafton.

Këtë në kuptimin se gjatë ndërtimit na duhet një gjë, gjatë ekzekutimit një tjetër. Në këtë situatë do të jenë të dobishme ndërtimet e lidhura.

Ndërtimet e lidhura (chained builds)

Kështu që këtu është çfarë thotë për ndërtimet e lidhura në dokumentacionin OpenShift:

‘Dy ndĂ«rtime mund tĂ« lidhen me njĂ«ra-tjetrĂ«n, ku njĂ«ra gjeneron njĂ« ent tĂ« pĂ«rpunuar, ndĂ«rsa tjetra vendos kĂ«tĂ« ent nĂ« njĂ« imazh tĂ« veçantĂ«, i cili pĂ«rdoret pĂ«r tĂ« drejtuar kĂ«tĂ« ent.’

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

Kështu, ne mund të aplikojmë imazhin Web App Builder si një 'builder' të pastër dhe të kemi një imazh runtime të vogël.

Tani le të shqyrtojmë këtë në një shembull konkret.

Për këtë trajnim do të përdorim një aplikacion të thjeshtë React, i krijuar me ndihmën e mjetit të linjës së komandave create-react-app.

Për të përmbledhur gjithçka së bashku, na ndihmon skedari i shabllonit OpenShift.

Le të shqyrtojmë më në detaje këtë skedar, duke filluar me seksionin e parametrave.

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: URL-ja burimore për aplikacionin
    displayName: URL Burimore
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: Emri i degës për aplikacionin
    displayName: Degë Burimore
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: Vendndodhja brenda repos burimor të aplikacionit
    displayName: Dosja Burimore
    value: .
    required: true
  - name: OUTPUT_DIR
    description: Vendndodhja e skedarëve statikë të përpunuar nga ndërtuesi i aplikacioneve web
    displayName: Dosja e Output-it
    value: build
    required: false

Këtu çdo gjë është mjaft e qartë, por duhet t'i kushtojmë vëmendje parametrin OUTPUT_DIR. Për aplikacionin React nga shembulli ynë, nuk ka asgjë për t'u shqetësuar, pasi React përdor si vlerë të default për folderin e output, ndërsa në rastin e Angular ose ndonjë gjëje tjetër, ky parametër do të duhet të ndryshohet siç është e nevojshme.

Tani, le të shikojmë seksionin e ImageStream-eve.

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

Shikoni imazhet e tretë dhe të katërt. Të dyja janë të përcaktuara si imazhe Docker dhe është e qartë nga e ku e marrin atë.

Imazhi i tretë është web-app-builder dhe merret nga nodeshift/ubi8-s2i-web-app me tag 10.x në Docker hub.

Imazhi i katërt është imazhi NGINX (versioni 1.12) me tag latest në Docker hub.

Tani le tĂ« shikojmĂ« dy imazhet e para. TĂ« dyja janĂ« tĂ« zbrazĂ«ta nĂ« fillim dhe krijohen vetĂ«m nĂ« fazĂ«n e ndĂ«rtimit. Imazhi i parĂ«, react-web-app-builder, do tĂ« jetĂ« rezultati i fazĂ«s sĂ« asamblesĂ«, e cila do tĂ« bashkojĂ« imazhin web-app-builder-runtime dhe kodin tonĂ« burimor. PikĂ«risht pĂ«r kĂ«tĂ« arsye, e kemi pĂ«rfshirĂ« ‘-builder’ nĂ« emrin e kĂ«tij imazhi.

Imazhi i dytë, react-web-app-runtime, do të jetë rezultati i bashkimit të nginx-image-runtime dhe disa skedarëve nga imazhi react-web-app-builder. Ky imazh gjithashtu do të përdoret në shpërndarje dhe do të përmbajë vetëm serverin e webit dhe HTML, JavaScript, CSS statik të aplikacionit tonë.

E komplikuar? Tani le të shikojmë konfiguracionet e ndërtimit dhe do të bëhet pak më e qartë.

Në shabllonin tonë ka dy konfiguracione ndërtimi. Ja e para, dhe është mjaft standarde:

  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ç e shohim, linja me etiketë 1 tregon se rezultati i këtij ndërtimi do të vendoset në atë imazhin e react-web-app-builder, të cilin e pamë pak më herët në seksionin e ImageStream-eve.

Linja me etiketë 2 tregon se nga ku do të merret kodi. Në rastin tonë, ky është një repository git, dhe lokacioni, ref dhe folderi i kontekstit përcaktohen nga parametrat që i kemi parë më sipër.

Linja me etiketĂ« 3 – kĂ«tĂ« e kemi parĂ« mĂ« herĂ«t nĂ« seksionin e parametrave. Ajo shton njĂ« variabĂ«l ambienti OUTPUT_DIR, e cila nĂ« shembullin tonĂ« Ă«shtĂ« e barabartĂ« me build.
Linja me etiketë 4 thotë të përdorim imazhin web-app-builder-runtime, të cilin e kemi parë më herët në seksionin e ImageStream.

Linja me etiketë 5 thotë që duam të përdorim një ndërtim inkremental, nëse imazhi S2I e mbështet atë, dhe imazhi Web App Builder e mbështet. Në fillim, pas përfundimit të fazës së asamblesë, imazhi do të ruajë folderin node_modules në një skedar arkiv. Më pas, gjatë startimeve të ardhshme, imazhi do thjesht ta zbërthejë këtë folder për të shkurtuar kohën e ndërtimit.

Dhe, nĂ« fund, linja me etiketĂ« 6 – janĂ« disa trigera qĂ« lejojnĂ« ndĂ«rtimin tĂ« fillojĂ« automatikisht, pa ndĂ«rhyrje manuale, kur ndodhin ndryshime.

Në tërësi, kjo është një konfiguracion ndërtimi mjaft standard.

Tani le të shikojmë konfigurimin e dytë të ndërtimit. Ai është shumë të ngjashëm me të parin, por ka një dallim 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 – react-web-app-runtime, dhe ai fillon mjaft standard.

NĂ« linjĂ«n me etiketĂ« 1 nuk ka asgjĂ« tĂ« re – thjesht thotĂ« se rezultati i ndĂ«rtimit vendoset nĂ« imazhin react-web-app-runtime.

Rreshtia me etiketĂ« 2, ashtu si nĂ« konfigurimin e mĂ«parshĂ«m, tregon nga e ku duhet tĂ« marrĂ«sh kodin burimor. Por kushtojini vĂ«mendje, kĂ«tu flasim se ai merret nga imazhi. PĂ«r mĂ« tepĂ«r, nga ai imazh qĂ« sapo krijuam – nga react-web-app-builder (i pĂ«rmendur nĂ« rreshtin me etiketĂ« 3). SkedarĂ«t qĂ« dĂ«shirojmĂ« tĂ« pĂ«rdorim janĂ« brenda imazhit dhe vendndodhja e tyre aty caktohet nĂ« rreshtin me etiketĂ« 4, nĂ« rastin tonĂ« Ă«shtĂ« /opt/app-root/output/. NĂ«se e mbani mend, pikĂ«risht aty vendosen skedarĂ«t e gjeneruar nga rezultatet e ndĂ«rtimit tĂ« aplikacionit tonĂ«.

Dosja e destinacionit, e cila caktohet nĂ« rreshtin me etiketĂ« 5 – Ă«shtĂ« thjesht katalogu aktual (kjo gjithçka, kujtojmĂ«, funksionon brenda njĂ« gjĂ«je magjike tĂ« quajtur OpenShift, e jo nĂ« kompjuterin tuaj lokal).

Sekcioni strategji – rreshti me etiketĂ« 6 – ashtu si nĂ« konfigurimin e parĂ« tĂ« ndĂ«rtimit. VetĂ«m kĂ«saj here ne do tĂ« pĂ«rdorim nginx-image-runtime, tĂ« cilin e kemi parĂ« tashmĂ« nĂ« seksionin ImageStream.

Finalmente, rreshti me etiketĂ« 7 – Ă«shtĂ« seksioni i aktivizuesve, i cili aktivizon kĂ«tĂ« ndĂ«rtim sa herĂ« qĂ« ndryshohet imazhi react-web-app-builder.

Nga ana tjetĂ«r, ky model pĂ«rmban njĂ« konfigurim tĂ« standardizuar tĂ« shpĂ«rndarjes, si dhe gjĂ«ra qĂ« lidhen me shĂ«rbimet dhe rrugĂ«t, por ne nuk do tĂ« thellohemi nĂ« kĂ«tĂ«. Kushtoni vĂ«mendje se imazhi qĂ« do tĂ« shpĂ«rndahet– Ă«shtĂ« imazhi react-web-app-runtime.

Zhvillimi i aplikacionit

Prandaj, pasi të kemi parë modelin, le të shohim se si ta përdorim atë për të shpërndarë aplikacionin.

Ne mund të përdorim mjetin klient të OpenShift të quajtur oc, për të shpërndarë modelin 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Ă« ekranin mĂ« sipĂ«r – Ă«shtĂ« njĂ« mĂ«nyrĂ« inxhinierike pĂ«r tĂ« gjetur modelin ./openshiftio/application.yaml.

Komanda e dytë thjesht krijon një aplikacion të ri mbi këtë model.

Pasi të funksionojnë këto urdhra, do të shohim se kemi dy ndërtime:

Aplikacionet moderne në OpenShift, pjesa 2: ndërlidhja e ndërtimeve të varura

Dhe duke u kthyer në ekranin Overview, do të shohim pod-in që është aktivizuar:

Aplikacionet moderne në OpenShift, pjesa 2: ndërlidhja e ndërtimeve të varura

NjĂ« klikim nĂ« link – dhe ne do tĂ« kalojmĂ« nĂ« aplikacionin tonĂ«, i cili pĂ«rbĂ«het nga faqja e aplikacionit React App nga defaulti:

Aplikacionet moderne në OpenShift, pjesa 2: ndërlidhja e ndërtimeve të varura

Shtesë 1

Për adhuruesit e Angular, kemi gjithashtu një shembuj të aplikacionit.

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

Shtesa 2

Në këtë artikull ne përdorëm si server web NGINX, por është mjaft e lehtë ta zëvendësojmë me Apache, thjesht duke ndryshuar në skedarin e modelit imazhi NGINX në imazhi Apache.

PĂ«rfundimi

Në pjesën e parë të kësaj serie ne treguam se si të shpërndajmë shpejt aplikacione moderne web në platformën OpenShift. Sot, kemi shqyrtuar se çfarë bën imazhi Web App dhe si mund të kombinohet me një server web të pastër si NGINX përmes ndërtimeve të lidhura (chained build) për të organizuar një ndërtim më të përshtatshëm për kushtet e prodhimit. Në artikullin e ardhshëm, përfundimtar të kësaj serie, ne do të tregojmë se si të aktivizoni në OpenShift serverin e zhvillimit për aplikacionin tuaj dhe të sigurojmë sinkronizimin e skedarëve lokalë dhe atyre të largët.

Përmbajtja e kësaj serie artikujsh

  • Pjesa 1: si tĂ« shpĂ«rndajmĂ« aplikacione moderne web nĂ« vetĂ«m disa hapa;
  • Pjesa 2: si tĂ« aplikoni imazhin e ri S2I sĂ« bashku me imazhin ekzistues tĂ« serverit HTTP, si NGINX, duke pĂ«rdorur ndĂ«rtimet e lidhura OpenShift, pĂ«r tĂ« organizuar shpĂ«rndarjen e prodhimit;
  • Pjesa 3: si tĂ« aktivizoni nĂ« platformĂ«n OpenShift serverin e zhvillimit pĂ«r aplikacionin tuaj dhe ta sinkronizoni atĂ« me sistemin e skedarĂ«ve lokal.

Burime shtesë

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster