Ahoj všichni! Toto je druhý příspěvek v naší sérii, ve kterém ukazujeme, jak nasadit moderní webové aplikace na Red Hat OpenShift.
V předchozím příspěvku jsme se lehce dotkli možností nového image builderu S2I (source-to-image), který je určen pro budování a nasazování moderních webových aplikací na platformě OpenShift. Poté nás zajímalo téma rychlého nasazení aplikace a dnes se podíváme na to, jak použít S2I image jako „čistý“ builder image a zkombinovat jej se souvisejícími sestavami OpenShift.
Čistý obrázek stavitele
Jak jsme zmínili v XNUMX. části, většina moderních webových aplikací má takzvanou fázi sestavení, která obvykle provádí operace, jako je transpilace kódu, vícenásobné zřetězení souborů a minifikace. Soubory získané v důsledku těchto operací - a to je statický HTML, JavaScript a CSS - jsou uloženy ve výstupní složce. Umístění této složky obvykle závisí na tom, jaké nástroje sestavení se používají, a pro React to bude složka ./build (k tomu se vrátíme podrobněji níže).
Source-to-Image (S2I)
V tomto příspěvku se nedotýkáme tématu „co je S2I a jak jej používat“ (o tomto si můžete přečíst více ), ale je důležité si ujasnit dva kroky v tomto procesu, abyste pochopili, co dělá obrázek Web App Builder.
Fáze montáže
Fáze sestavení je ve své podstatě velmi podobná tomu, co se stane, když spustíte sestavení dockeru a skončíte s novým obrazem Dockeru. V souladu s tím tato fáze nastává při spuštění sestavení na platformě OpenShift.
V případě obrázku Web App Builder je zodpovědný za instalaci závislostí vaší aplikace a spuštění sestavení. . Ve výchozím nastavení používá obraz tvůrce konstrukci sestavení spuštění npm, ale to lze přepsat pomocí proměnné prostředí NPM_BUILD.
Jak jsme řekli dříve, umístění hotové, již vytvořené aplikace závisí na tom, jaké nástroje používáte. Například v případě React to bude složka ./build a pro aplikace Angular to bude složka project_name/dist. A jak již bylo ukázáno v předchozím příspěvku, umístění výstupního adresáře, který je standardně nastaven na sestavení, lze přepsat pomocí proměnné prostředí OUTPUT_DIR. Protože umístění výstupní složky se liší framework od frameworku, jednoduše zkopírujete vygenerovaný výstup do standardní složky v obrázku, konkrétně /opt/apt-root/output. To je důležité pro pochopení zbytku tohoto článku, ale nyní se v rychlosti podívejme na další fázi – fázi běhu.
fáze běhu
K této fázi dochází, když je provedeno volání spuštění ukotvitelného panelu na novém obrazu vytvořeném během fáze sestavení. Totéž se děje při nasazení na platformě OpenShift. Výchozí použití aby obsluhoval statický obsah umístěný ve výše uvedeném standardním výstupním adresáři.
Tato metoda je dobrá pro rychlé nasazení aplikací, ale obecně se nedoporučuje poskytovat statický obsah tímto způsobem. No, protože ve skutečnosti poskytujeme pouze statický obsah, nepotřebujeme Node.js nainstalovaný v našem obrazu – postačí webový server.
Jinými slovy, při montáži potřebujeme jednu věc, při provádění potřebujeme jinou. V této situaci se hodí zřetězené sestavení.
Zřetězené stavby
O tom píšou v dokumentaci OpenShift:
"Dvě sestavy lze propojit, přičemž jedna generuje zkompilovanou entitu a druhá hostuje tuto entitu v samostatném obrazu, který se používá ke spuštění této entity."
Jinými slovy, můžeme použít obrázek Web App Builder ke spuštění našeho sestavení a poté použít obrázek webového serveru, stejný NGINX, k poskytování našeho obsahu.
Můžeme tedy použít image Web App Builder jako „čistý“ builder a zároveň mít malý runtime image.
Nyní se na to podívejme na konkrétním příkladu.
Pro trénink budeme používat vytvořený pomocí nástroje příkazového řádku create-react-app.
Pomůže nám dát vše dohromady .
Podívejme se na tento soubor podrobněji a začněme sekcí parametrů.
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
Vše je zde docela jasné, ale stojí za to věnovat pozornost parametru OUTPUT_DIR. Pro aplikaci React v našem příkladu se není čeho obávat, protože React používá výchozí hodnotu jako výstupní složku, ale v případě Angular nebo něčeho jiného bude nutné tento parametr podle potřeby změnit.
Nyní se podíváme na sekci 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'
Podívejte se na třetí a čtvrtý obrázek. Oba jsou definovány jako obrázky Docker a můžete jasně vidět, odkud pocházejí.
Třetí obrázek je web-app-builder a pochází z nodeshift/ubi8-s2i-web-app označené 10.x na .
Čtvrtý je obrázek NGINX (verze 1.12) s nejnovější značkou .
Nyní se podívejme na první dva obrázky. Oba jsou prázdné na začátku a jsou vytvořeny pouze během fáze sestavení. První obrázek, reagovat-web-app-builder, bude výsledkem montážního kroku, který bude kombinovat obrázek web-app-builder-runtime a náš zdrojový kód. Proto jsme k názvu tohoto obrázku přidali „-builder“.
Druhý obrázek - reagovat-web-app-runtime - bude výsledkem kombinace nginx-image-runtime a některých souborů z obrazu reagovat-web-app-builder. Tento obrázek bude také použit během nasazení a bude obsahovat pouze webový server a statické HTML, JavaScript, CSS naší aplikace.
Zmatený? Nyní se podíváme na konfigurace sestavení a bude to trochu jasnější.
Naše šablona má dvě konfigurace sestavení. Zde je první 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 můžete vidět, řádek s popiskem 1 říká, že výsledek tohoto sestavení bude umístěn do stejného obrázku reagovat-web-app-builder, který jsme viděli o něco dříve v sekci ImageStreams.
Řádek označený 2 vám říká, odkud kód získat. V našem případě se jedná o git repozitář a umístění, ref a kontextová složka jsou určeny parametry, které jsme již viděli výše.
Řádek označený 3 je to, co jsme již viděli v sekci parametrů. Přidá proměnnou prostředí OUTPUT_DIR, což je v našem příkladu build.
Řádek označený 4 říká, že se má použít obrázek web-app-builder-runtime, který jsme již viděli v sekci ImageStream.
Řádek označený 5 říká, že chceme použít přírůstkové sestavení, pokud to obrázek S2I podporuje a obrázek Web App Builder ano. Při prvním spuštění, po dokončení fáze sestavení, obraz uloží složku node_modules do archivního souboru. Poté při dalších spuštěních obraz jednoduše rozbalí tuto složku, aby se zkrátila doba sestavení.
A konečně řádek označený 6 je jen několik spouštěčů, aby se sestavení spustilo automaticky, bez ručního zásahu, když se něco změní.
Celkově se jedná o docela standardní sestavovací konfiguraci.
Nyní se podíváme na druhou konfiguraci sestavení. Je velmi podobný prvnímu, ale je zde 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í je reagovat-web-aplikace-runtime a začíná docela standardně.
Řádek označený 1 není žádnou novinkou – jednoduše říká, že výsledek sestavení je vložen do obrazu reagovat-web-app-runtime.
Řádek označený 2, stejně jako v předchozí konfiguraci, označuje, odkud získat zdrojový kód. Ale všimněte si, že zde říkáme, že je to převzato z obrázku. Navíc z obrázku, který jsme právě vytvořili - z respond-web-app-builder (uvedeno v řádku označeném 3). Soubory, které chceme použít, jsou uvnitř obrázku a jejich umístění je tam nastaveno na řádku označeném 4, v našem případě je to /opt/app-root/output/. Pokud si vzpomínáte, zde se ukládají soubory vygenerované na základě výsledků budování naší aplikace.
Cílová složka zadaná v termínu s popiskem 5 je jednoduše aktuální adresář (toto je vše, pamatujte, běžící uvnitř nějaké magické věci zvané OpenShift, a ne na vašem lokálním počítači).
Sekce strategie – řádek označený 6 – je také podobná první konfiguraci sestavení. Pouze tentokrát použijeme nginx-image-runtime, který jsme již viděli v sekci ImageStream.
A konečně, řádek označený 7 je částí spouštěčů, které aktivují toto sestavení pokaždé, když se změní obrázek reagovat-web-app-builder.
Jinak tato šablona obsahuje docela standardní konfiguraci nasazení a také věci, které se týkají služeb a tras, ale nebudeme to zabíhat do přílišných podrobností. Vezměte prosím na vědomí, že obraz, který bude nasazen, je obraz reagovat-web-app-runtime.
Nasazení aplikací
Nyní, když jsme se podívali na šablonu, pojďme se podívat, jak ji použít k nasazení aplikace.
K nasazení naší šablony můžeme použít klientský nástroj OpenShift s názvem oc:
$ 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 snímku obrazovky výše je záměrně navržený způsob, jak najít šablonu./openshiftio/application.yaml.
Druhý příkaz jednoduše vytvoří novou aplikaci založenou na této šabloně.
Poté, co tyto příkazy fungují, uvidíme, že máme dvě sestavení:
A po návratu na obrazovku Přehled uvidíme spuštěný modul:
Klikněte na odkaz a budeme přesměrováni do naší aplikace, což je výchozí stránka aplikace React:
Dodatek 1
Pro milovníky Angular máme také .
Vzor je zde stejný, s výjimkou proměnné OUTPUT_DIR.
Dodatek 2
V tomto článku jsme použili NGINX jako webový server, ale je docela snadné jej nahradit Apache, stačí změnit šablonu v souboru na .
Závěr
V prvním díle této série jsme si ukázali, jak rychle nasadit moderní webové aplikace na platformě OpenShift. Dnes jsme se podívali na to, co dělá obrázek webové aplikace a jak jej lze zkombinovat s čistým webovým serverem, jako je NGINX, pomocí zřetězených sestavení, aby se vytvořilo sestavení aplikace více připravené na produkci. V dalším a posledním článku této série si ukážeme, jak spustit vývojový server pro vaši aplikaci na OpenShift a zajistit synchronizaci lokálních a vzdálených souborů.
Obsah této série článků
- Část 1: ;
- Část 2: Jak používat nový obraz S2I se stávajícím obrazem serveru HTTP, jako je NGINX, pomocí přidružených sestav OpenShift pro produkční nasazení;
- Část 3: jak spustit vývojový server pro vaši aplikaci na platformě OpenShift a synchronizovat ji s místním souborovým systémem.
Dodatečné zdroje
- Zdarma e-kniha .
- Informace o .
Zdroj: www.habr.com