Hei kaikille tässä blogissa! Tämä on kolmas viesti sarjassa, jossa näytämme kuinka ottaa käyttöön moderneja verkkosovelluksia Red Hat OpenShiftissä.
Kahdessa edellisessä viestissä osoitimme, kuinka modernit verkkosovellukset otetaan käyttöön muutamassa vaiheessa ja kuinka uutta S2I-kuvaa käytetään yhdessä valmiin HTTP-palvelimen kuvan kanssa, kuten NGINX, käyttämällä ketjutettuja koontiversioita tuotannon käyttöönottojen ohjaamiseen. .
Tänään näytämme kuinka ajaa kehityspalvelinta sovelluksellesi OpenShift-alustalla ja synkronoida se paikallisen tiedostojärjestelmän kanssa, ja puhumme myös siitä, mitä OpenShift Pipelines ovat ja kuinka niitä voidaan käyttää vaihtoehtona linkitetyille kokoonpanoille.
OpenShift kehitysympäristönä
Kehityksen työnkulku
Kuten kohdassa jo todettiin , tyypillinen nykyaikaisten verkkosovellusten kehitysprosessi on yksinkertaisesti jonkinlainen "kehityspalvelin", joka seuraa paikallisten tiedostojen muutoksia. Kun ne tapahtuvat, sovelluskoonti käynnistyy ja sitten se päivitetään selaimeen.
Useimmissa nykyaikaisissa kehyksissä tällainen "kehityspalvelin" on sisäänrakennettu vastaaviin komentorivityökaluihin.
Paikallinen esimerkki
Katsotaanpa ensin, kuinka tämä toimii, kun sovelluksia käytetään paikallisesti. Otetaan sovellus esimerkkinä aiemmista artikkeleista, vaikka lähes samat työnkulkukonseptit pätevät kaikissa muissa moderneissa kehyksissä.
Joten käynnistääksemme "dev-palvelimen" React-esimerkissämme annamme seuraavan komennon:
$ npm run start
Sitten terminaali-ikkunassa näemme jotain tällaista:
Ja sovelluksemme avautuu oletusselaimessa:
Jos nyt teemme muutoksia tiedostoon, sovelluksen pitäisi päivittää selaimessa.
OK, kaikki on selvää paikallisessa tilassa tapahtuvan kehityksen kanssa, mutta kuinka saavuttaa sama OpenShiftissä?
OpenShiftin kehityspalvelin
Jos muistat, sisään , tarkastelimme S2I-kuvan ns. ajovaihetta ja huomasimme, että oletusarvoisesti servomoduuli vastaa verkkosovelluksemme huollosta.
Jos kuitenkin katsoo tarkemmin tästä esimerkistä se sisältää ympäristömuuttujan $NPM_RUN, jonka avulla voit suorittaa komentosi.
Voimme esimerkiksi käyttää nodeshift-moduulia sovelluksemme käyttöönottamiseksi:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Huomautus: Yllä oleva esimerkki on lyhennetty havainnollistamaan yleistä ideaa.
Tässä olemme lisänneet käyttöönottoomme NPM_RUN-ympäristömuuttujan, joka käskee suoritusajan suorittamaan yarn start -komennon, joka käynnistää React-kehityspalvelimen OpenShift-kotelossamme.
Jos katsot juoksevan podin lokia, se näyttää suunnilleen tältä:
Tämä kaikki ei tietenkään ole mitään, ennen kuin voimme synkronoida paikallisen koodin koodin kanssa, jota myös seurataan muutosten varalta, mutta joka elää etäpalvelimella.
Synkronoi kauko- ja paikalliskoodia
Onneksi nodeshift auttaa helposti synkronoinnissa, ja voit seurata muutoksia watch-komennolla.
Joten kun olemme suorittaneet komennon ottaa käyttöön kehityspalvelin sovelluksellemme, voimme turvallisesti käyttää seuraavaa komentoa:
$ npx nodeshift watch
Tämän seurauksena muodostetaan yhteys vähän aikaisemmin luomaan käynnissä olevaan podiin, paikallisten tiedostojemme synkronointi etäklusterin kanssa aktivoituu ja paikallisen järjestelmämme tiedostoja aletaan tarkkailla muutosten varalta.
Siksi, jos nyt päivitämme src/App.js-tiedoston, järjestelmä reagoi näihin muutoksiin, kopioi ne etäklusteriin ja käynnistää kehityspalvelimen, joka päivittää sitten sovelluksemme selaimessa.
Täydentääksesi kuvan, näytetään, miltä nämä koko komennot näyttävät:
$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000
$ npx nodeshift watch --strictSSL=false
Watch-komento on abstraktio oc rsync -komennon päällä. Saat lisätietoja sen toiminnasta .
Tämä oli esimerkki Reactille, mutta täsmälleen samaa menetelmää voidaan käyttää muissa kehyksissä, aseta vain NPM_RUN-ympäristömuuttuja tarpeen mukaan.
Openshift-putkistot
Seuraavaksi puhumme OpenShift Pipelinesin kaltaisesta työkalusta ja kuinka sitä voidaan käyttää vaihtoehtona ketjutetuille rakennelmille.
Mitä ovat OpenShift-putkistot
OpenShift Pipelines on pilvipohjainen CI/CD jatkuvan integroinnin ja toimitusjärjestelmä, joka on suunniteltu putkien järjestämiseen Tektonin avulla. Tekton on joustava avoimen lähdekoodin Kubernetes-natiivi CI/CD-kehys, jonka avulla voit automatisoida käyttöönoton eri alustoilla (Kubernetes, palvelimettomat, virtuaalikoneet jne.) irrottautumalla alla olevasta kerroksesta.
Tämän artikkelin ymmärtäminen vaatii jonkin verran tietoa putkistosta, joten suosittelemme, että luet ensin .
Työympäristösi luominen
Jotta voit leikkiä tämän artikkelin esimerkeillä, sinun on ensin valmisteltava työympäristösi:
- Asenna ja määritä OpenShift 4 -klusteri. Esimerkeissämme käytetään CodeReady Containers (CRD) -säilöjä, joiden asennusohjeet löytyvät .
- Kun klusteri on valmis, sinun on asennettava Pipeline Operator siihen. Älä pelkää, se on helppoa, asennusohjeet .
- Lataa (tkn) .
- Suorita create-react-app komentorivityökalu luodaksesi sovelluksen, jonka otat sitten käyttöön (tämä on yksinkertainen sovellus ).
- (Valinnainen) Kloonaa arkisto suorittaaksesi esimerkkisovelluksen paikallisesti npm installilla ja sitten npm startilla.
Sovellusvarastossa on myös k8s-kansio, joka sisältää sovelluksen käyttöönotossa käytetyt Kubernetes/OpenShift YAML:t. Luomme tässä tehtävät, klusteritehtävät, resurssit ja putkistot .
Aloitetaan
Ensimmäinen askel esimerkissämme on luoda uusi projekti OpenShift-klusteriin. Kutsutaan tätä projektia webapp-pipelineksi ja luodaan se seuraavalla komennolla:
$ oc new-project webapp-pipeline
Tämä projektin nimi näkyy koodissa myöhemmin, joten jos päätät nimetä sille jotain muuta, älä unohda muokata esimerkkikoodia vastaavasti. Tästä pisteestä alkaen emme mene ylhäältä alas, vaan alhaalta ylös: eli luomme ensin kaikki kuljettimen komponentit ja vasta sitten itse kuljettimen.
Eli ensinnäkin...
Tehtävät
Luodaan pari tehtävää, jotka auttavat sitten ottamaan sovelluksen käyttöön prosessissamme. Ensimmäinen tehtävä - apply_manifests_task - vastaa niiden Kubernetes-resurssien (palvelu, käyttöönotto ja reitti) YAML:n käyttöönotosta, jotka sijaitsevat sovelluksemme k8s-kansiossa. Toinen tehtävä – update_deployment_task – vastaa jo käyttöön otetun kuvan päivittämisestä putkistomme luomaan.
Älä huoli, jos se ei ole vielä kovin selkeä. Itse asiassa nämä tehtävät ovat jotain apuohjelmia, ja tarkastelemme niitä tarkemmin hieman myöhemmin. Toistaiseksi luodaan ne:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml
Sitten tkn CLI -komennolla tarkistamme, että tehtävät on luotu:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Huomautus: Nämä ovat paikallisia tehtäviä nykyiselle projektille.
Klusteritehtävät
Klusteritehtävät ovat periaatteessa samoja kuin yksinkertaiset tehtävät. Toisin sanoen se on uudelleenkäytettävä kokoelma vaiheita, jotka yhdistetään tavalla tai toisella tiettyä tehtävää suoritettaessa. Erona on, että klusteritehtävä on käytettävissä kaikkialla klusterin sisällä. Jos haluat nähdä luettelon klusteritehtävistä, jotka luodaan automaattisesti, kun lisäät Pipeline Operatoria, käytämme jälleen tkn CLI -komentoa:
$ tkn clustertask ls
NAME AGE
buildah 1 day ago
buildah-v0-10-0 1 day ago
jib-maven 1 day ago
kn 1 day ago
maven 1 day ago
openshift-client 1 day ago
openshift-client-v0-10-0 1 day ago
s2i 1 day ago
s2i-go 1 day ago
s2i-go-v0-10-0 1 day ago
s2i-java-11 1 day ago
s2i-java-11-v0-10-0 1 day ago
s2i-java-8 1 day ago
s2i-java-8-v0-10-0 1 day ago
s2i-nodejs 1 day ago
s2i-nodejs-v0-10-0 1 day ago
s2i-perl 1 day ago
s2i-perl-v0-10-0 1 day ago
s2i-php 1 day ago
s2i-php-v0-10-0 1 day ago
s2i-python-3 1 day ago
s2i-python-3-v0-10-0 1 day ago
s2i-ruby 1 day ago
s2i-ruby-v0-10-0 1 day ago
s2i-v0-10-0 1 day ago
Luodaan nyt kaksi klusteritehtävää. Ensimmäinen luo S2I-kuvan ja lähettää sen sisäiseen OpenShift-rekisteriin; toinen on rakentaa imagomme NGINX:n pohjalta käyttämällä sisältönä jo rakentamaamme sovellusta.
Luo ja lähetä kuva
Kun luot ensimmäistä tehtävää, toistamme sen, mitä teimme jo edellisessä linkitettyjä kokoonpanoja koskevassa artikkelissa. Muista, että käytimme S2I-kuvaa (ubi8-s2i-web-app) sovelluksemme "rakentamiseen", ja päädyimme OpenShiftin sisäiseen rekisteriin tallennettuun kuvaan. Nyt käytämme tätä S2I-verkkosovelluskuvaa DockerFilen luomiseen sovelluksellemme ja käytämme sitten Buildahia varsinaisen koontiversion tekemiseen ja työnnä tuloksena olevan kuvan OpenShiftin sisäiseen rekisteriin, koska juuri niin OpenShift tekee, kun otat sovelluksia käyttöön NodeShiftin avulla. .
Mistä me tiesimme tämän kaiken, kysyt? From , kopioimme sen ja muokkasimme sitä itsellemme.
Joten nyt luodaan s2i-web-sovellusklusteritehtävä:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Emme analysoi tätä yksityiskohtaisesti, vaan keskitymme vain parametriin OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Oletuksena tämä parametri on sama kuin build, johon React sijoittaa kootun sisällön. Muut kehykset käyttävät erilaisia polkuja, esimerkiksi Emberissä se on dist. Ensimmäisen klusteritehtävän tulos on kuva, joka sisältää keräämämme HTML-, JavaScript- ja CSS-koodit.
Rakenna kuva NGINX:n perusteella
Mitä tulee toiseen klusteritehtäväämme, sen pitäisi rakentaa meille NGINX-pohjainen kuva käyttämällä jo rakentamamme sovelluksen sisältöä. Pohjimmiltaan tämä on osa edellisestä osiosta, jossa tarkastelimme ketjutettuja rakennelmia.
Tätä varten luomme - täsmälleen samalla tavalla kuin yllä - klusteritehtävän webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Jos katsot näiden klusteritehtävien koodia, huomaat, että se ei määritä käsittelemäämme Git-tietovarastoa tai luomiemme kuvien nimiä. Määritämme vain sen, mitä tarkalleen siirrämme Gitiin tai tietyn kuvan, johon lopullinen kuva tulee tulostaa. Tästä syystä näitä klusteritehtäviä voidaan käyttää uudelleen työskennellessäsi muiden sovellusten kanssa.
Ja tässä siirrytään sulavasti seuraavaan kohtaan...
voimavarat
Joten koska, kuten juuri sanoimme, klusteritehtävien tulisi olla mahdollisimman yleisiä, meidän on luotava resursseja, joita käytetään syötteenä (Git-arkisto) ja lähtönä (lopulliset kuvat). Ensimmäinen tarvitsemamme resurssi on Git, jossa sovelluksemme sijaitsee, jotain tällaista:
# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: web-application-repo
spec:
type: git
params:
- name: url
value: https://github.com/nodeshift-starters/react-pipeline-example
- name: revision
value: master
Tässä PipelineResource on tyyppiä git. Paramet-osion url-avain osoittaa tiettyyn arkistoon ja määrittää päähaaran (tämä on valinnainen, mutta kirjoitamme sen täydellisyyden vuoksi).
Nyt meidän on luotava kuvalle resurssi, johon s2i-web-app-tehtävän tulokset tallennetaan, tämä tehdään seuraavasti:
# This resource is the result of running "npm run build", the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: built-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest
Tässä PipelineResource on tyyppiä image, ja url-parametrin arvo osoittaa sisäiseen OpenShift-kuvarekisteriin, erityisesti siihen, joka sijaitsee webapp-pipeline-nimiavaruudessa. Älä unohda muuttaa tätä asetusta, jos käytät eri nimiavaruutta.
Ja lopuksi, viimeinen tarvitsemamme resurssi on myös tyyppikuva, ja tämä on viimeinen NGINX-kuva, jota käytetään sitten käyttöönoton aikana:
# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: runtime-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest
Huomaa jälleen, että tämä resurssi tallentaa kuvan sisäiseen OpenShift-rekisteriin webapp-pipeline-nimiavaruudessa.
Luodaksemme kaikki nämä resurssit kerralla käytämme create-komentoa:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Voit varmistaa, että resurssit on luotu seuraavasti:
$ tkn resource ls
Kuljetinputki
Nyt kun meillä on kaikki tarvittavat komponentit, kootaan niistä putkisto luomalla se seuraavalla komennolla:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Mutta ennen kuin suoritamme tämän komennon, katsotaanpa näitä komponentteja. Ensimmäinen on nimi:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Sitten spec-osiossa näemme osoituksen aiemmin luomistamme resursseista:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Luomme sitten tehtävät, jotka meidän on suoritettava. Ensinnäkin sen on suoritettava jo luomamme s2i-web-app -tehtävä:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Tämä tehtävä ottaa syöteparametreja (gir-resurssi) ja lähtöparametreja (built-web-application-image-resurssi). Välitämme sille myös erityisen parametrin, jotta se ei tarkista TLS:ää, koska käytämme itse allekirjoitettuja varmenteita:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Seuraava tehtävä on melkein sama, vain tässä jo luomamme webapp-build-runtime-klusteritehtävä on nimeltään:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Kuten edellisessä tehtävässä, välitämme resurssin, mutta nyt se on built-web-application-image (edellisen tehtävämme tulos). Ja ulostuloksi asetimme jälleen kuvan. Koska tämä tehtävä on suoritettava edellisen jälkeen, lisäämme runAfter-kentän:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
Seuraavat kaksi tehtävää vastaavat verkkosovelluksemme k8s-hakemistossa olevien palvelu-, reitti- ja käyttöönotto-YAML-tiedostojen käytöstä sekä tämän käyttöönoton päivittämisestä uusia kuvia luotaessa. Määritimme nämä kaksi klusteritehtävää artikkelin alussa.
Kuljettimen käynnistäminen
Joten kaikki putkistomme osat luodaan, ja suoritamme sen seuraavalla komennolla:
$ tkn pipeline start build-and-deploy-react
Tässä vaiheessa komentoriviä käytetään vuorovaikutteisesti, ja sinun on valittava sopivat resurssit vastauksena jokaiseen sen pyyntöön: valitse git-resurssille web-application-repo, sitten ensimmäiselle kuvaresurssille sisäänrakennettu verkkosovellus. -image ja lopuksi toiselle kuvaresurssille –runtime-web-application-image:
? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr
Tarkastetaan nyt liukuhihnan tila seuraavalla komennolla:
$ tkn pipeline logs -f
Kun putkisto on alkanut ja sovellus on otettu käyttöön, voimme pyytää julkaistua reittiä seuraavalla komennolla:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Parempaa visualisointia varten voit tarkastella putkistoamme verkkokonsolin kehittäjätilassa osiossa putkistojen, kuten kuvassa näkyy. 1.
Kuva 1. Käynnissä olevien putkien tarkastelu.
Käynnissä olevan putkilinjan napsauttaminen näyttää lisätietoja, kuten kuvassa 2.
Riisi. 2. Lisätietoja putkistosta.
Lisätietojen jälkeen näet käynnissä olevat sovellukset näkymässä topologia, kuten kuvassa 3 on esitetty.
Kuva 3. Laukaisukotelo.
Napsauttamalla ympyrää kuvakkeen oikeassa yläkulmassa avaa sovelluksemme, kuten kuvassa 4.
Riisi. 4. React-sovellus käynnissä.
Johtopäätös
Joten näytimme, kuinka voit käyttää kehityspalvelinta sovelluksellesi OpenShiftissä ja synkronoida se paikallisen tiedostojärjestelmän kanssa. Tarkastelimme myös kuinka simuloida ketjutettua rakennusmallia OpenShift-putkien avulla. Kaikki tämän artikkelin esimerkkikoodit löytyvät .
Lisäresurssit (EN)
- Ilmainen e-kirja
- Muut artikkelit Red Hatin verkkosivuilla
Ilmoitukset tulevista webinaareista
Aloitamme perjantaina webinaarisarjan natiivikokemuksesta Red Hat OpenShift Container Platformin ja Kubernetesin avulla:
Lähde: will.com