ProHoster > Blogg > Administration > Moderna applikationer pÄ OpenShift, del 2: Kedjade byggen (chained builds)

Moderna applikationer pÄ OpenShift, del 2: Kedjade byggen (chained builds)

Hej alla! HÀr Àr det andra inlÀgget i vÄr serie dÀr vi visar hur man distribuerar moderna webbapplikationer pÄ Red Hat OpenShift.

Moderna applikationer pÄ OpenShift, del 2: Kedjade byggen (chained builds)

I det tidigare inlÀgget berörde vi nÄgot av de nya möjligheterna med builder-bilden S2I (source-to-image), som Àr avsedd för byggande och distribution av moderna webbapplikationer pÄ OpenShift-plattformen. DÄ fokuserade vi pÄ snabb distribution av applikationen, och idag ska vi se hur man anvÀnder S2I-bilden som en "ren" builder-bild och kombinera den med relaterade OpenShift-byggnader.

Ren builder-bild

Som vi nĂ€mnde i den första delen har de flesta moderna webbapplikationer en sĂ„ kallad byggfas dĂ€r operationer som kodtranspilering, konkatenering av flera filer och minifiering normalt utförs. De resulterande filerna – det vill sĂ€ga statisk HTML, JavaScript och CSS – placeras i output-mappen. Platsen för denna mapp beror vanligtvis pĂ„ vilka byggverktyg som anvĂ€nds, och för React kommer det att vara mappen . /build (vi Ă„terkommer till denna frĂ„ga lĂ€ngre ner).

Source-to-Image (S2I)

I detta inlÀgg berör vi inte alls Àmnet "vad Àr S2I och hur man anvÀnder det" (mer om detta kan lÀsas hÀr), men det Àr viktigt att tydligt ha en förstÄelse för de tvÄ stegen i denna process för att förstÄ vad Web App Builder-bilden gör.

Assemblagefasen (assemble phase)

Assemblagefasen liknar i grunden vad som hÀnder nÀr du kör docker build och fÄr en ny Docker-bild som resultat. DÀrför intrÀffar detta steg nÀr en byggprocess startas pÄ OpenShift-plattformen.

I fallet med Web App Builder-bilden ansvarar assemble script. Som standard anvÀnder builder-bilden kommandot npm run build, men det kan överskridas via miljövariabeln NPM_BUILD.

Som vi nĂ€mnde tidigare beror platsen för den fĂ€rdiga, redan byggda applikationen pĂ„ vilka verktyg som anvĂ€nds. I fallet med React kommer detta att vara mappen ./build, och för Angular-applikationer – mappen project_name/dist. Och som redan visats i det tidigare inlĂ€gget kan platsen för output-katalogen, som som standard Ă€r angiven som build, överskrivas via miljövariabeln OUTPUT_DIR. Eftersom platsen för output-mappen skiljer sig frĂ„n ramverk till ramverk kopierar du helt enkelt den genererade outputen till standardmappen i bilden, nĂ€mligen i /opt/apt-root/output. Detta Ă€r viktigt för att förstĂ„ den fortsatta delen av denna artikel, men lĂ„t oss snabbt gĂ„ igenom nĂ€sta steg – körning (run phase).

Körningssteget (run phase)

Detta steg intrÀffar nÀr det nya objektet som skapats under assembleringssteget anropas med docker run. Det intrÀffar ocksÄ vid distribution pÄ OpenShift-plattformen. Som standard kör skript anvÀnder betjÀningsmodul för att servera statiskt innehÄll som ligger i den angivna standardoutput-katalogen.

Denna metod Ă€r bra för snabb distribution av applikationer, men det rekommenderas egentligen inte att servera statiskt innehĂ„ll pĂ„ detta sĂ€tt. Eftersom vi faktiskt endast serverar statiskt innehĂ„ll behövs inte Node.js som Ă€r installerat i vĂ„r bild – en webbserver rĂ€cker.

Med andra ord, vi behöver en sak vid byggandet och en annan vid körningen. I en sÄdan situation Àr relaterade byggen (chained builds) anvÀndbara.

Relaterade byggen (chained builds)

HÀr Àr vad som sÀgs om chained builds i dokumentationen för OpenShift:

„TvĂ„ byggen kan lĂ€nkas samman, dĂ€r det ena genererar en kompilerad entitet och det andra placerar denna entitet i en separat bild som anvĂ€nds för att köra denna entitet.”

Med andra ord kan vi anvÀnda bilden Web App Builder för att köra vÄr byggprocess, och sedan anvÀnda bilden av webbservern, samma NGINX, för att betjÀna vÄrt innehÄll.

SÄledes kan vi anvÀnda bilden Web App Builder som en 'ren' byggare och fortfarande ha en liten storlek pÄ runtime-bilden.

LÄt oss nu gÄ igenom detta med ett konkret exempel.

För trÀning kommer vi att anvÀnda en enkel React-applikation, som skapats med verktyget create-react-app.

Att samla allt i ett kan hjÀlpa oss med OpenShift-mallfilen.

LÄt oss titta nÀrmare pÄ den hÀr filen, och börja med avsnittet för parametrar.

parametrar:
  - namn: SOURCE_REPOSITORY_URL
    beskrivning: KÀll-URL för applikationen
    visaNamn: KĂ€ll-URL
    krÀvs: true
  - namn: SOURCE_REPOSITORY_REF
    beskrivning: Grennamn för applikationen
    visaNamn: KĂ€llgren
    vÀrde: master
    krÀvs: true
  - namn: SOURCE_REPOSITORY_DIR
    beskrivning: Platsen inom kÀllrepo för applikationen
    visaNamn: KĂ€llkatalog
    vÀrde: .
    krÀvs: true
  - namn: OUTPUT_DIR
    beskrivning: Platsen för de kompilerade statiska filerna frÄn din webbapps byggare
    visaNamn: Utdata-katalog
    vÀrde: build
    krÀvs: false

HÀr Àr allt ganska tydligt, men det Àr viktigt att uppmÀrksamma parameter OUTPUT_DIR. För React-applikationen i vÄrt exempel behöver man inte oroa sig, eftersom React anvÀnder som utdata-mapp det förinstÀllda vÀrdet, men i fallet med Angular eller nÄgot annat, behöver denna parameter justeras pÄ rÀtt sÀtt.

Nu lÄt oss ta en titt pÄ avsnittet för ImageStreams.

- apiVersion: v1
  typ: ImageStream
  metadata:
    namn: react-web-app-builder  // 1 
  specifikation: {}
- apiVersion: v1
  typ: ImageStream
  metadata:
    namn: react-web-app-runtime  // 2 
  specifikation: {}
- apiVersion: v1
  typ: ImageStream
  metadata:
    namn: web-app-builder-runtime // 3
  specifikation:
    taggar:
    - namn: latest
      frÄn:
        typ: DockerImage
        namn: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
  typ: ImageStream
  metadata:
    namn: nginx-image-runtime // 4
  specifikation:
    taggar:
    - namn: latest
      frÄn:
        typ: DockerImage
        namn: 'centos/nginx-112-centos7:latest'

Titta pÄ den tredje och fjÀrde bilden. De definieras bÄda som Docker-bilder, och det Àr tydligt var de kommer ifrÄn.

Den tredje bilden Àr web-app-builder, och den hÀmtas frÄn nodeshift/ubi8-s2i-web-app med taggen 10.x pÄ Docker hub.

Den fjÀrde bilden Àr en NGINX-bild (version 1.12) med taggen latest pÄ Docker hub.

Nu tar vi en titt pĂ„ de tvĂ„ första bilderna. De Ă€r bĂ„da tomma i början och skapas endast under byggfasen. Den första bilden – react-web-app-builder – kommer att bli resultatet av assemblage-steget, som kommer att kombinera bilden web-app-builder-runtime och vĂ„r kĂ€llkod. Det Ă€r dĂ€rför vi har skrivit "-builder" i namnet pĂ„ den hĂ€r bilden.

Den andra bilden – react-web-app-runtime – kommer att bli resultatet av kombinationen av nginx-image-runtime och vissa filer frĂ„n bilden react-web-app-builder. Denna bild kommer ocksĂ„ att anvĂ€ndas vid distribution och kommer endast att innehĂ„lla webbservern och den statiska HTML, JavaScript, CSS för vĂ„r applikation.

Förvirrat? LÄt oss titta pÄ byggkonfigurationerna, sÄ blir det lite klarare.

I vÄr mall finns det tvÄ byggkonfigurationer. HÀr Àr den första, och den Àr ganska 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

Som vi ser, sÀger raden med etikett 1 att resultatet av denna byggprocess kommer att placeras i den bild som heter react-web-app-builder, som vi tidigare sÄg i avsnittet om ImageStreams.

Raden med etikett 2 sÀger varifrÄn koden ska hÀmtas. I vÄrt fall handlar det om ett git-repo, och plats, ref och kontextmapp definieras av parametrar som vi redan har sett ovan.

Raden med etikett 3 Àr nÄgot vi redan har sett i avsnittet om parametrar. Den lÀgger till en miljövariabel OUTPUT_DIR, som i vÄrt exempel Àr lika med build.
Raden med etikett 4 sÀger att vi ska anvÀnda bilden web-app-builder-runtime, som vi redan har sett i avsnittet om ImageStreams.

Raden med etikett 5 sÀger att vi vill anvÀnda en inkrementell byggnad, om S2I-bilden stödjer det, och bilden Web App Builder gör det. Vid första körningen, efter att byggprocessen Àr klar, kommer bilden att spara mappen node_modules i en arkivfil. DÀrefter vid efterföljande körningar kommer bilden helt enkelt att packa upp den mappen för att förkorta byggtiden.

Och slutligen, raden med etikett 6 Àr bara nÄgra triggers sÄ att byggnaden startas automatiskt, utan manuell intervention, nÀr nÄgot förÀndras.

Sammanfattningsvis Àr detta en ganska standard byggkonfiguration.

LÄt oss nu ta en titt pÄ den andra byggkonfigurationen. Den liknar mycket den första, men det finns en viktig skillnad.

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

SÄ, den andra byggkonfigurationen Àr react-web-app-runtime, och den börjar ganska standardmÀssigt.

I raden med etikett 1 finns det inget nytt – den sĂ€ger bara att resultatet av byggprocessen sparas i bilden react-web-app-runtime.

Raden med etikett 2, precis som i den föregĂ„ende konfigurationen, anger var kĂ€llkoden ska hĂ€mtas ifrĂ„n. Men observera att hĂ€r sĂ€ger vi att den kommer frĂ„n en bild. Faktum Ă€r att den kommer frĂ„n den bild vi just har skapat – frĂ„n react-web-app-builder (anges i raden med etikett 3). Filerna som vi vill anvĂ€nda finns inuti bilden och deras plats dĂ€r anges i raden med etikett 4, i vĂ„rt fall Ă€r det /opt/app-root/output/. Om ni minns, Ă€r det dit filer som genereras som resultat av vĂ„r applikationsbyggnad hamnar.

Mappen som anges i raden med etikett 5 Àr helt enkelt den aktuella katalogen (detta, lÄt oss pÄminna, körs inom ett slags magiskt system som heter OpenShift, och inte pÄ din lokala dator).

Sektionen strategy – raden med etikett 6 – liknar Ă€ven den första byggkonfigurationen. Men den hĂ€r gĂ„ngen planerar vi att anvĂ€nda nginx-image-runtime, som vi redan har sett i avsnittet ImageStream.

Slutligen, raden med etikett 7 – detta Ă€r triggersavsnittet som aktiverar denna byggprocess varje gĂ„ng bilden react-web-app-builder Ă€ndras.

I övrigt innehÄller denna mall en ganska standard konfiguration för distribution, samt olika saker som rör tjÀnster och rutter, men vi kommer inte att gÄ djupare in i det. Observera att bilden som kommer att distribueras Àr bilden react-web-app-runtime.

Distribution av applikation

SÄ, efter att ha sett pÄ mallen, lÄt oss titta pÄ hur vi kan anvÀnda den för att distribuera applikationen.

Vi kan anvÀnda klientverktyget OpenShift som kallas oc för att distribuera vÄr mall:

$ 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

Den första kommandot pÄ skÀrmen ovan Àr ett avsiktligt tekniskt sÀtt att hitta mallen ./openshiftio/application.yaml.

Den andra kommandot skapar helt enkelt en ny applikation baserad pÄ denna mall.

NÀr dessa kommandon har körts, kommer vi att se att vi har tvÄ byggprocesser:

Moderna applikationer pÄ OpenShift, del 2: Kedjade byggen (chained builds)

Och nÀr vi gÄr tillbaka till Overview-skÀrmen, ser vi den startade podden:

Moderna applikationer pÄ OpenShift, del 2: Kedjade byggen (chained builds)

Ett klick pĂ„ lĂ€nken – och vi gĂ„r till vĂ„r applikation, som utgör en standard React App-sida:

Moderna applikationer pÄ OpenShift, del 2: Kedjade byggen (chained builds)

Bilaga 1

För Angular-Àlskare har vi ocksÄ ett exempel pÄ en applikation.

Mallen hÀr Àr densamma, förutom variabeln OUTPUT_DIR.

TillÀgg 2

I denna artikel har vi anvÀnt NGINX som webbserver, men det Àr ganska enkelt att byta till Apache genom att bara Àndra i mallfilen. nginx-avbildning till apache-avbildning.

Slutsats

I den första delen av denna serie visade vi hur man snabbt distribuerar moderna webbapplikationer pÄ OpenShift-plattformen. Idag tittade vi pÄ vad som gör Web App-avbildningen och hur den kan kombineras med en ren webbserver av typen NGINX med hjÀlp av kedjade byggen (chained build) för att organisera en mer produktionsanpassad byggen för applikationer. I nÀsta och sista artikel i denna serie kommer vi att visa hur man kör en utvecklingsserver för sin applikation pÄ OpenShift och sÀkerstÀller synkronisering av lokala och fjÀrrfiler.

InnehÄll i denna artikelserie

  • Del 1: hur man distribuerar moderna webbapplikationer pĂ„ bara nĂ„gra steg;
  • Del 2: hur man anvĂ€nder den nya S2I-avbildningen tillsammans med en befintlig HTTP-serveravbildning, till exempel NGINX, med hjĂ€lp av OpenShifts kedjade byggen för att organisera produktionsdistribuering;
  • Del 3: hur man kör en utvecklingsserver pĂ„ OpenShift-plattformen för sin applikation och synkroniserar den med den lokala filsystemet.

Ytterligare resurser

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster