Hallo iedereen op deze blog! Dit is het derde bericht in een serie waarin we laten zien hoe je moderne webapplicaties kunt implementeren op Red Hat OpenShift.
In de vorige twee berichten hebben we laten zien hoe je moderne webapplicaties in slechts een paar stappen kunt implementeren en hoe je een nieuwe S2I-image kunt gebruiken samen met een kant-en-klare HTTP-serverimage, zoals NGINX, met behulp van geketende builds om productie-implementaties te orkestreren .
Vandaag zullen we laten zien hoe u een ontwikkelserver voor uw applicatie op het OpenShift-platform kunt draaien en deze kunt synchroniseren met het lokale bestandssysteem, en ook zullen bespreken wat OpenShift Pipelines zijn en hoe ze kunnen worden gebruikt als alternatief voor gekoppelde assemblages.
OpenShift als ontwikkelomgeving
Ontwikkelingsworkflow
Zoals al vermeld in , is het typische ontwikkelingsproces voor moderne webapplicaties eenvoudigweg een soort ‘ontwikkelserver’ die wijzigingen in lokale bestanden bijhoudt. Wanneer ze zich voordoen, wordt de applicatie-build geactiveerd en vervolgens bijgewerkt naar de browser.
In de meeste moderne raamwerken is zo'n "ontwikkelserver" ingebouwd in de overeenkomstige opdrachtregelprogramma's.
Lokaal voorbeeld
Laten we eerst eens kijken hoe dit werkt bij het lokaal uitvoeren van applicaties. Laten we de toepassing als voorbeeld nemen uit eerdere artikelen, hoewel vrijwel dezelfde workflowconcepten van toepassing zijn in alle andere moderne raamwerken.
Dus om de "dev server" in ons React-voorbeeld te starten, voeren we de volgende opdracht in:
$ npm run start
Vervolgens zien we in het terminalvenster zoiets als dit:
En onze applicatie wordt geopend in de standaardbrowser:
Als we nu wijzigingen in het bestand aanbrengen, zou de applicatie in de browser moeten worden bijgewerkt.
Oké, alles is duidelijk met ontwikkeling in de lokale modus, maar hoe bereik je hetzelfde op OpenShift?
Ontwikkelingsserver op OpenShift
Als je het je herinnert, binnen , we keken naar de zogenaamde run-fase van de S2I-image en zagen dat de serve-module standaard verantwoordelijk is voor het onderhoud van onze webapplicatie.
Als je echter beter kijkt uit dat voorbeeld bevat het de omgevingsvariabele $NPM_RUN, waarmee u uw opdracht kunt uitvoeren.
We kunnen bijvoorbeeld de nodeshift-module gebruiken om onze applicatie te implementeren:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Opmerking: het bovenstaande voorbeeld is afgekort om het algemene idee te illustreren.
Hier hebben we de omgevingsvariabele NPM_RUN aan onze implementatie toegevoegd, die de runtime vertelt de opdracht garen start uit te voeren, waarmee de React-ontwikkelserver in onze OpenShift-pod wordt gestart.
Als je naar het logboek van een running pod kijkt, ziet het er ongeveer zo uit:
Dit alles zal natuurlijk niets zijn totdat we de lokale code kunnen synchroniseren met de code, die ook wordt gecontroleerd op wijzigingen, maar op een externe server staat.
Synchroniseren van externe en lokale code
Gelukkig kan nodeshift gemakkelijk helpen bij de synchronisatie, en kun je de watch-opdracht gebruiken om wijzigingen bij te houden.
Dus nadat we de opdracht hebben uitgevoerd om de ontwikkelingsserver voor onze applicatie te implementeren, kunnen we veilig de volgende opdracht gebruiken:
$ npx nodeshift watch
Als gevolg hiervan wordt er verbinding gemaakt met de actieve pod die we iets eerder hebben gemaakt, wordt de synchronisatie van onze lokale bestanden met het externe cluster geactiveerd en worden de bestanden op ons lokale systeem gecontroleerd op wijzigingen.
Als we nu het bestand src/App.js bijwerken, zal het systeem op deze wijzigingen reageren, deze naar het externe cluster kopiëren en de ontwikkelingsserver starten, die vervolgens onze applicatie in de browser zal bijwerken.
Laten we, om het plaatje compleet te maken, laten zien hoe deze volledige opdrachten eruit zien:
$ 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
Het watch-commando is een abstractie bovenop het oc rsync-commando. Je kunt meer leren over hoe het werkt .
Dit was een voorbeeld voor React, maar exact dezelfde methode kan worden gebruikt met andere frameworks; stel gewoon de omgevingsvariabele NPM_RUN in als dat nodig is.
Openshift-pijpleidingen
Vervolgens zullen we het hebben over een tool als OpenShift Pipelines en hoe deze kan worden gebruikt als alternatief voor geketende builds.
Wat is OpenShift-pijplijnen
OpenShift Pipelines is een cloud-native CI/CD-systeem voor continue integratie en levering, ontworpen voor het organiseren van pijpleidingen met behulp van Tekton. Tekton is een flexibel open-source Kubernetes-native CI/CD-framework waarmee u de implementatie op verschillende platforms (Kubernetes, serverless, virtuele machines, etc.) kunt automatiseren door te abstraheren van de onderliggende laag.
Om dit artikel te begrijpen, is enige kennis van Pipelines vereist, dus we raden u ten zeerste aan dit eerst te lezen .
Inrichten van uw werkomgeving
Om met de voorbeelden in dit artikel te spelen, moet u eerst uw werkomgeving voorbereiden:
- Installeer en configureer een OpenShift 4-cluster. Onze voorbeelden gebruiken hiervoor CodeReady Containers (CRD), hiervoor vindt u installatie-instructies .
- Nadat het cluster gereed is, moet u Pipeline Operator erop installeren. Wees niet bang, het is eenvoudig, installatie-instructies .
- Downloaden (tkn) .
- Voer het opdrachtregelprogramma create-react-app uit om een applicatie te maken die u vervolgens gaat implementeren (dit is een eenvoudige applicatie ).
- (Optioneel) Kloon de repository om de voorbeeldtoepassing lokaal uit te voeren met npm install en vervolgens npm start.
De applicatierepository zal ook een k8s-map hebben, die de Kubernetes/OpenShift YAML's zal bevatten die worden gebruikt om de applicatie te implementeren. Er zullen Taken, ClusterTaken, Resources en Pipelines zijn die we hierin zullen creëren .
Naar beneden gaan
De eerste stap voor ons voorbeeld is het maken van een nieuw project in het OpenShift-cluster. Laten we dit project webapp-pipeline noemen en het maken met de volgende opdracht:
$ oc new-project webapp-pipeline
Deze projectnaam zal later in de code verschijnen, dus als u besluit het een andere naam te geven, vergeet dan niet de voorbeeldcode dienovereenkomstig te bewerken. Vanaf dit punt gaan we niet top-down, maar bottom-up: dat wil zeggen dat we eerst alle componenten van de transportband zullen creëren, en pas daarna de transportband zelf.
Dus allereerst...
Taken
Laten we een aantal taken maken, die vervolgens zullen helpen bij het implementeren van de applicatie binnen onze pijplijn. De eerste taak - apply_manifests_task - is verantwoordelijk voor het toepassen van de YAML van de Kubernetes-bronnen (service, implementatie en route) die zich in de k8s-map van onze applicatie bevinden. De tweede taak – update_deployment_task – is verantwoordelijk voor het bijwerken van een reeds geïmplementeerde image naar de image die door onze pijplijn is gemaakt.
Maak je geen zorgen als het nog niet helemaal duidelijk is. In feite zijn deze taken zoiets als hulpprogramma's, en we zullen ze later in meer detail bekijken. Laten we ze voorlopig gewoon maken:
$ 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
Vervolgens zullen we met behulp van de opdracht tkn CLI controleren of de taken zijn gemaakt:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Let op: Dit zijn lokale taken voor uw huidige project.
Clustertaken
Clustertaken zijn in principe hetzelfde als eenvoudige taken. Dat wil zeggen, het is een herbruikbare verzameling stappen die op de een of andere manier worden gecombineerd bij het uitvoeren van een specifieke taak. Het verschil is dat een clustertaak overal binnen het cluster beschikbaar is. Om de lijst met clustertaken te zien die automatisch worden aangemaakt bij het toevoegen van Pipeline Operator, zullen we opnieuw de opdracht tkn CLI gebruiken:
$ 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
Laten we nu twee clustertaken maken. De eerste genereert de S2I-image en stuurt deze naar het interne OpenShift-register; de tweede is om ons imago op te bouwen op basis van NGINX, met behulp van de applicatie die we al als inhoud hebben gebouwd.
Maak en verzend de afbeelding
Bij het maken van de eerste taak herhalen we wat we al deden in het vorige artikel over gekoppelde samenstellingen. Bedenk dat we de S2I-image (ubi8-s2i-web-app) gebruikten om onze applicatie te "bouwen", en uiteindelijk een image hadden opgeslagen in het interne OpenShift-register. Nu gebruiken we deze S2I-webapp-image om een DockerFile voor onze app te maken en vervolgens Buildah om de daadwerkelijke build uit te voeren en de resulterende image naar het interne OpenShift-register te pushen, aangezien dat precies is wat OpenShift doet wanneer u uw applicaties implementeert met NodeShift .
Hoe wisten we dit allemaal, vraag je? Van , we hebben het gewoon gekopieerd en voor onszelf aangepast.
Laten we nu de s2i-web-app-clustertaak maken:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
We zullen dit niet in detail analyseren, maar ons alleen concentreren op de parameter OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Standaard is deze parameter gelijk aan build, en dat is waar React de samengestelde inhoud plaatst. Andere raamwerken gebruiken verschillende paden, in Ember is dit bijvoorbeeld dist. De uitvoer van onze eerste clustertaak zal een afbeelding zijn met de HTML, JavaScript en CSS die we hebben verzameld.
Bouw een image op basis van NGINX
Wat onze tweede clustertaak betreft, deze zou een op NGINX gebaseerde afbeelding voor ons moeten bouwen, met behulp van de inhoud van de applicatie die we al hebben gebouwd. In wezen is dit het deel van de vorige sectie waarin we naar geketende builds keken.
Om dit te doen, zullen we - precies hetzelfde als hierboven - een clustertaak webapp-build-runtime maken:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Als je naar de code van deze clustertaken kijkt, kun je zien dat deze niet de Git-repository specificeert waarmee we werken of de namen van de afbeeldingen die we maken. We specificeren alleen wat we precies naar Git overbrengen, of een bepaalde afbeelding waar de uiteindelijke afbeelding moet worden uitgevoerd. Daarom kunnen deze clustertaken hergebruikt worden bij het werken met andere applicaties.
En hier gaan we gracieus verder naar het volgende punt...
Ресурсы
Dus omdat, zoals we zojuist zeiden, clustertaken zo algemeen mogelijk moeten zijn, moeten we bronnen creëren die gebruikt zullen worden als invoer (de Git-repository) en als uitvoer (de uiteindelijke afbeeldingen). De eerste bron die we nodig hebben is Git, waar onze applicatie zich bevindt, ongeveer als volgt:
# 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
Hier is PipelineResource van het type git. De url-sleutel in de params-sectie verwijst naar een specifieke repository en specificeert de master branch (dit is optioneel, maar we schrijven dit voor de volledigheid).
Nu moeten we een bron voor de afbeelding maken waar de resultaten van de s2i-web-app-taak zullen worden opgeslagen, dit gaat als volgt:
# 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
Hier is de PipelineResource van het type image, en de waarde van de url-parameter verwijst naar het interne OpenShift Image Registry, met name degene die zich in de webapp-pipeline-naamruimte bevindt. Vergeet niet deze instelling te wijzigen als u een andere naamruimte gebruikt.
En ten slotte zal de laatste bron die we nodig hebben ook van het type image zijn en dit zal de uiteindelijke NGINX-image zijn die vervolgens tijdens de implementatie zal worden gebruikt:
# 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
Houd er opnieuw rekening mee dat deze bron de afbeelding opslaat in het interne OpenShift-register in de webapp-pipeline-naamruimte.
Om al deze bronnen in één keer te maken, gebruiken we de opdracht create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
U kunt ervoor zorgen dat de bronnen als volgt zijn gemaakt:
$ tkn resource ls
Transportband pijpleiding
Nu we alle benodigde componenten hebben, gaan we er een pijplijn van samenstellen door deze te maken met de volgende opdracht:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Maar voordat we deze opdracht uitvoeren, kijken we naar deze componenten. De eerste is de naam:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Vervolgens zien we in de specificatiesectie een indicatie van de bronnen die we eerder hebben gemaakt:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Vervolgens creëren we de taken die onze pijplijn moet voltooien. Allereerst moet het de s2i-web-app-taak uitvoeren die we al hebben gemaakt:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Voor deze taak zijn invoerparameters (gir-resource) en uitvoerparameters (ingebouwde webapplicatie-imagebron) nodig. We geven er ook een speciale parameter aan zodat TLS niet wordt geverifieerd, omdat we zelfondertekende certificaten gebruiken:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
De volgende taak is vrijwel hetzelfde, alleen heet hier de webapp-build-runtime clustertaak die we al hebben gemaakt:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Net als bij de vorige taak geven we een bron door, maar nu is het een ingebouwde webapplicatie-image (de uitvoer van onze vorige taak). En als uitvoer stellen we de afbeelding opnieuw in. Omdat deze taak na de vorige moet worden uitgevoerd, voegen we het veld runAfter toe:
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
De volgende twee taken zijn verantwoordelijk voor het gebruik van de service-, route- en implementatie-YAML-bestanden die in de k8s-directory van onze webapplicatie staan, en ook voor het bijwerken van deze implementatie bij het maken van nieuwe images. We hebben deze twee clustertaken aan het begin van het artikel gedefinieerd.
Het starten van de transportband
Dus alle delen van onze pijplijn zijn gemaakt en we zullen deze uitvoeren met de volgende opdracht:
$ tkn pipeline start build-and-deploy-react
In dit stadium wordt de opdrachtregel interactief gebruikt en moet je de juiste bronnen selecteren als reactie op elk van zijn verzoeken: voor de git-bron selecteer je web-application-repo, en vervolgens voor de eerste afbeeldingsbron, ingebouwde web-applicatie -image, en tenslotte, voor de tweede afbeeldingsbron –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
Laten we nu de status van de pijplijn controleren met behulp van de volgende opdracht:
$ tkn pipeline logs -f
Zodra de pijplijn is gestart en de applicatie is geïmplementeerd, kunnen we de gepubliceerde route opvragen met het volgende commando:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Voor een betere visualisatie kunt u onze pijplijn bekijken in de ontwikkelaarsmodus van de webconsole in de sectie Pijpleidingen, zoals weergegeven in afb. 1.
Figuur 1. Beoordeling van lopende pijpleidingen.
Als u op een actieve pijplijn klikt, worden aanvullende details weergegeven, zoals weergegeven in Figuur 2.
Rijst. 2. Aanvullende informatie over de pijpleiding.
Na meer informatie kunt u actieve applicaties in de weergave zien topologie, zoals weergegeven in figuur 3.
Fig 3. Gelanceerde pod.
Als u op de cirkel in de rechterbovenhoek van het pictogram klikt, wordt onze applicatie geopend, zoals weergegeven in figuur 4.
Rijst. 4. React-applicatie uitvoeren.
Conclusie
We hebben dus laten zien hoe u een ontwikkelserver voor uw toepassing op OpenShift kunt draaien en deze kunt synchroniseren met het lokale bestandssysteem. We hebben ook gekeken hoe je een chained-build-sjabloon kunt simuleren met behulp van OpenShift Pipelines. Alle voorbeeldcodes uit dit artikel zijn te vinden .
Aanvullende bronnen (EN)
- Gratis e-boek
- Meer artikelen over op de Red Hat-website
Aankondigingen van aankomende webinars
We starten een reeks vrijdagwebinars over native ervaringen met het gebruik van Red Hat OpenShift Container Platform en Kubernetes:
Bron: www.habr.com