ProHoster > Blog > Administrace > Moderní aplikace na OpenShift, část 2: spojené sestavy chained builds

Moderní aplikace na OpenShift, část 2: spojené sestavy chained builds

Ahoj všichni! Zde je druhý příspěvek z naší série, ve které ukazujeme, jak nasazovat moderní webové aplikace na Red Hat OpenShift.

Moderní aplikace na OpenShift, část 2: spojené sestavy chained builds

V předchozím příspěvku jsme se lehce dotkli možností nového builder obrazu S2I (source-to-image), který je určen pro stavbu a nasazení moderních webových aplikací na platformě OpenShift. Tehdy nás zajímalo téma rychlého nasazení aplikací, ale dnes se podíváme, jak používat S2I obraz jako "čistý" builder obraz a kombinovat ho se spojenými sestavami OpenShift.

Čistý builder obraz

Jak jsme zmínili v první části, většina moderních webových aplikací má takzvanou fázi sestavení, ve které se obvykle provádějí operace, jako je transpilační kód, spojování několika souborů a minifikace. Tyto soubory, což jsou statické HTML, JavaScript a CSS, se ukládají do výstupní složky. Umístění této složky obvykle závisí na tom, jaké nástroje pro sestavení se používají, a pro React to bude složka .\/build (k této otázce se ještě podrobněji vrátíme níže).

Source-to-Image (S2I)

V tomto příspěvku se vůbec necítíme téma "co je S2I a jak ho používat" (více o tom si můžete přečíst zde), ale je důležité jasně si představit dvě fáze tohoto procesu, abychom pochopili, co vlastně obraz Web App Builder dělá.

Fáze sestavování (assemble phase)

Fáze sestavování je sama o sobě velmi podobná tomu, co se stane, když spustíte příkaz docker build a výsledek získáte nový Docker obraz. Odpovídajícím způsobem tato fáze nastává, když spustíte sestavení na platformě OpenShift.

V případě obrazu Web App Builder za instalaci závislostí vaší aplikace a spuštění sestavení odpovídá assemble script. Ve výchozím nastavení builder obraz používá konstrukci npm run build, ale lze ji přepsat prostřednictvím proměnné prostředí NPM_BUILD.

Jak jsme již zmínili, umístění hotové, již zkompilované aplikace závisí na použitém nástroji. Například v případě React to bude složka \/build, a pro aplikace Angular – složka project_name\/dist. A jak již bylo zmíněno v předchozím příspěvku, umístění output adresáře, které je ve výchozím nastavení nastaveno na build, lze předefinovat pomocí proměnné prostředí OUTPUT_DIR. A protože se umístění output složky liší mezi frameworky, prostě zkopírujete vygenerovaný output do standardní složky v obraze, konkrétně do \/opt\/apt-root\/output. To je důležité pro pochopení další části tohoto článku, ale teď si rychle přehledně projdeme další krok – spouštění (run phase).

Fáze spouštění (run phase)

Tato fáze nastává, když je pro nový obraz vytvořený během fáze sestavení proveden příkaz docker run. To se také děje při nasazení na platformě OpenShift. Ve výchozím nastavení run script používá serve module k servírování statického obsahu uloženého v uvedeném standardním output adresáři.

Tato metoda je dobrá pro rychlé nasazení aplikací, ale obecně se nedoporučuje servírovat statický obsah tímto způsobem. A protože skutečně obsluhujeme pouze statický obsah, není potřeba mít uvnitř našeho obrazu Node.js – stačí webový server.

To znamená, že při sestavování potřebujeme něco jiného než při vykonávání. V takové situaci se hodí propojované sestavy (chained builds).

Propojované sestavy (chained builds)

Co se píše o chained builds v dokumentaci OpenShift:

„Dvě sestavy lze propojit, přičemž jedna generuje zkompilovaný výstup a druhá umístí tento výstup do samostatného obrazu, který se používá pro spuštění tohoto výstupu.“

Jinými slovy, můžeme použít obraz Web App Builder pro spuštění naší sestavy a poté použít obraz webového serveru, například NGINX, k servírování našeho obsahu.

Takto můžeme použít obraz Web App Builder jako „čistého“ buildera a mít zároveň malý runtime obraz.

Teď si to vysvětlíme na konkrétním příkladu.

Na cvičení použijeme jednoduchou aplikaci React, vytvořenou pomocí nástroje příkazového řádku create-react-app.

Sestavit vše dohromady nám pomůže šablonový soubor OpenShift.

Podívejme se na tento soubor podrobněji a začneme sekcí parametrů.

parametry:
  - název: SOURCE_REPOSITORY_URL
    popis: Zdrojová URL pro aplikaci
    zobrazovanéNázev: Zdrojová URL
    povinné: true
  - název: SOURCE_REPOSITORY_REF
    popis: Název větve pro aplikaci
    zobrazovanéNázev: Zdroje větve
    hodnota: master
    povinné: true
  - název: SOURCE_REPOSITORY_DIR
    popis: Umístění v rámci zdrojového repozitáře aplikace
    zobrazovanéNázev: Zdroje adresář
    hodnota: .
    povinné: true
  - název: OUTPUT_DIR
    popis: Umístění zkompilovaných statických souborů z vašeho generátoru webových aplikací
    zobrazovanéNázev: Výstupní adresář
    hodnota: build
    povinné: false

Vše je zde docela jasné, ale stojí za to věnovat pozornost parametru OUTPUT_DIR. Pro React aplikaci z našeho příkladu se nemusíme obávat, protože React používá jako výstupní složku hodnotu podle výchozího nastavení, zatímco v případě Angularu nebo něčeho jiného bude třeba tento parametr změnit na požadovaný.

Nyní se podívejme na sekci ImageStream.

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

Podívejte se na třetí a čtvrtý obraz. Oba jsou definovány jako Docker obrazy a zřetelně vidíme, odkud pocházejí.

Třetí obraz je web-app-builder a pochází z nodeshift/ubi8-s2i-web-app s tagem 10.x na Docker hub.

Čtvrtý obraz je NGINX (verze 1.12) s tagem latest na Docker hub.

Nyní se podívejme na dva první obrazy. Oba jsou na začátku prázdné a vytvářejí se pouze během fáze sestavení (build phase). První obraz – react-web-app-builder – bude výsledkem fáze sestavování, která spojí obraz web-app-builder-runtime a náš zdrojový kód. Právě proto jsme do názvu tohoto obrazu přidali „-builder“.

Druhý obraz – react-web-app-runtime – bude výsledkem spojení nginx-image-runtime a některých souborů z obrazu react-web-app-builder. Tento obraz bude také použit při nasazení a bude obsahovat pouze webový server a statický HTML, JavaScript, CSS naší aplikace.

Zmatené? Podívejme se nyní na konfigurace sestavení a bude to trochu jasnější.

V naší šabloně jsou dvě konfigurace sestavení. Zde je první z nich a je docela standardní:

  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

Jak vidíme, řádek s označením 1 říká, že výsledek této sestavy bude umístěn do obrazu react-web-app-builder, který jsme viděli dříve v sekci ImageStreamů.

Řádek s označením 2 říká, odkud brát kód. V našem případě je to git repozitář, a umístění, ref a adresář kontextu jsou určeny parametry, které jsme již viděli výše.

Řádek s označením 3 – to jsme již viděli v sekci parameters. Přidává proměnnou prostředí OUTPUT_DIR, která je v našem příkladu rovna build.
Řádek s označením 4 říká, že máme použít obraz web-app-builder-runtime, který jsme už viděli v sekci ImageStream.

Řádek s označením 5 říká, že chceme použít inkrementální build, pokud S2I-obraz to podporuje, a obraz Web App Builder – podporuje. Při prvním spuštění, po dokončení fáze skládání, obraz uloží složku node_modules do archivu. Při následných spuštěních bude obraz prostě rozbalit tuto složku, aby zkrátil dobu sestavení.

A nakonec, řádek s označením 6 – to jsou prostě některé spouštěče, aby se sestava spouštěla automaticky, bez ručního zásahu, když se něco mění.

Obecně je to docela standardní konfigurace sestavy.

Nyní se podívejme na druhou konfiguraci sestavy. Je velmi podobná první, ale má jeden důležitý rozdíl.

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

Takže druhá konfigurace sestavení – react-web-app-runtime, a začíná docela standardně.

V řádku s označením 1 není nic nového – pouze říká, že výsledek sestavení je uložen v obraze react-web-app-runtime.

Řádek s označením 2, stejně jako v předchozí konfiguraci, uvádí, odkud brát zdrojový kód. Ale vezměte na vědomí, že zde říkáme, že je brán z obrazu. A to z toho obrazu, který jsme právě vytvořili – z react-web-app-builder (uvedeného v řádku s označením 3). Soubory, které chceme použít, se nacházejí uvnitř obrazu a jejich umístění tam je definováno v řádku s označením 4, v našem případě to je /opt/app-root/output/. Pokud si vzpomínáte, právě tam se ukládají soubory vygenerované na základě výsledků sestavení naší aplikace.

Cílová složka, určená v řádku s označením 5 – to je prostě aktuální adresář (to všechno se přitom točí uvnitř nějaké magické věci zvané OpenShift, a ne na vašem lokálním počítači).

Sekce strategie – řádek s označením 6 – se také podobá první konfiguraci sestavení. Tentokrát se chystáme použít nginx-image-runtime, který jsme již viděli v části ImageStream.

Nakonec, řádek s označením 7 – to je sekce spouštěčů, která aktivuje toto sestavení pokaždé, když se změní obraz react-web-app-builder.

Jinak tento šablon obsahuje docela standardní konfiguraci nasazení, stejně jako věci, které se týkají služeb a tras, ale nebudeme se do toho pouštět. Všimněte si, že obraz, který bude nasazen – je obraz react-web-app-runtime.

Nasazení aplikace

Takže, poté co jsme se podívali na šablonu, se podívejme, jak ji použít k nasazení aplikace.

Můžeme použít klientský nástroj OpenShift nazvaný oc, abychom nasadili naši šablonu:

$ 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

První příkaz na obrazovce výše je úmyslně inženýrský způsob, jak najít šablonu ./openshiftio/application.yaml.

Druhý příkaz jednoduše vytváří novou aplikaci na základě této šablony.

Po provedení těchto příkazů uvidíme, že máme dvě sestavení:

Moderní aplikace na OpenShift, část 2: spojené sestavy chained builds

A pokud se vrátíme na obrazovku přehledu, uvidíme spuštěný pod:

Moderní aplikace na OpenShift, část 2: spojené sestavy chained builds

Kliknutím na odkaz přejdeme k naší aplikaci, která představuje výchozí stránku aplikace React App:

Moderní aplikace na OpenShift, část 2: spojené sestavy chained builds

Dodatek 1

Pro milovníky Angularu máme také příklad aplikace.

Šablona je zde stejná, s výjimkou proměnné OUTPUT_DIR.

Dodatek 2

V tomto článku jsme použili jako webový server NGINX, ale lze ho snadno nahradit Apache, stačí změnit v šablonovém souboru obraz NGINX na obraz Apache.

Závěr

V první části této série jsme ukázali, jak rychle nasadit moderní webové aplikace na platformě OpenShift. Dnes jsme zkoumali, co dělá obraz Web App a jak ho lze kombinovat s čistým webovým serverem typu NGINX pomocí spojených sestavení (chained build) k vytvoření lepšího prostředí pro produkci. V následujícím, závěrečném článku této série ukážeme, jak spustit na OpenShift vývojový server pro svou aplikaci a synchronizovat místní a vzdálené soubory.

Obsah této série článků

  • Část 1: jak nasadit moderní webové aplikace za pouhých několik kroků;
  • Část 2: jak použít nový obraz S2I spolu s již existujícím obrazem HTTP serveru, například NGINX, pomocí spojených sestavení OpenShift pro organizaci produkčního nasazení;
  • Část 3: jak spustit na platformě OpenShift vývojový server pro svou aplikaci a synchronizovat ho s místním souborovým systémem.

Další zdroje

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster