🥇 moderne applicaties op OpenShift, deel 3: OpenShift als ontwikkelomgeving en OpenShift Pipelines

Hallo allemaal op deze blog! Dit is de derde post in de serie waarin we laten zien hoe je moderne webapplicaties kunt implementeren op Red Hat OpenShift.

In de vorige twee berichten hebben we verteld hoe je moderne webapplicaties in slechts een paar stappen kunt implementeren en hoe je de nieuwe S2I-image kunt gebruiken samen met een vooraf gebouwde HTTP-serverimage, zoals NGINX, met behulp van chained builds voor productie-implementatie.

Vandaag laten we zien hoe je een ontwikkelserver voor je applicatie op het OpenShift-platform kunt draaien en deze kunt synchroniseren met het lokale bestandssysteem, en we zullen ook bespreken wat OpenShift Pipelines zijn en hoe je deze kunt gebruiken als alternatief voor chained builds.

OpenShift als ontwikkelomgeving

Ontwikkelworkflow

Zoals eerder genoemd in de eerste post, is het typische ontwikkelproces voor moderne webapplicaties simpelweg een soort 'ontwikkelserver' die wijzigingen in lokale bestanden volgt. Wanneer deze wijzigingen plaatsvinden, wordt de applicatie gebouwd en vervolgens wordt deze bijgewerkt in de browser.

In de meeste moderne frameworks is zo'n 'ontwikkelserver' ingebouwd in de bijbehorende command-line tools.

Lokaal voorbeeld

Laten we eerst kijken hoe dit werkt in het geval van lokaal draaien van applicaties. Als voorbeeld nemen we de applicatie React uit eerdere artikelen, hoewel vrijwel dezelfde concepten voor de workflow ook in andere moderne frameworks van toepassing zijn.
Dus om de 'ontwikkelserver' in ons React-voorbeeld te draaien, voeren we het volgende commando in:

$ npm run start

Dan zien we ongeveer het volgende in het terminalvenster:

En onze applicatie opent in de standaardbrowser:

Nu, als we wijzigingen aanbrengen in het bestand, zou de applicatie in de browser moeten vernieuwen.

Oké, dat is duidelijk voor de lokale ontwikkelingsmodus, maar hoe bereiken we hetzelfde op OpenShift?

Ontwikkelserver op OpenShift

Als je het je herinnert, hebben we in de vorige posthet zogenaamde opstartfase (run phase) van de S2I-image besproken en gezien dat standaard het module serve onze webapplicatie bedient.

Als we echter beter kijken run script In dit voorbeeld is er een omgevingsvariabele $NPM_RUN die het mogelijk maakt om je eigen commando uit te voeren.

Je kunt 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 verkort weergegeven om de algemene idee te illustreren.

Hier hebben we de omgevingsvariabele NPM_RUN toegevoegd aan onze implementatie, die de uitvoeringsfase vertelt dat het het commando yarn start moet uitvoeren, wat de React-ontwikkelserver binnen onze OpenShift-pod start.

Als we naar de log van de draaiende pod kijken, zal het er ongeveer zo uitzien:

Natuurlijk is dit allemaal niet veel waard totdat we onze lokale code kunnen synchroniseren met de code die ook gecontroleerd wordt op wijzigingen, maar op een externe server leeft.

Synchronisatie van externe en lokale code

Gelukkig helpt nodeshift eenvoudig bij de synchronisatie, en voor het volgen van wijzigingen kun je de watch-opdracht gebruiken.

Dus nadat we het commando hebben uitgevoerd om de ontwikkelserver voor onze applicatie te implementeren, kunnen we gerust het volgende commando gebruiken:

$ npx nodeshift watch

Het resultaat is dat er verbinding wordt gemaakt met de eerder gemaakte pod, waardoor de synchronisatie van onze lokale bestanden met het externe cluster wordt geactiveerd, en de bestanden op ons lokale systeem beginnen te worden gevolgd op wijzigingen.

Daarom, als we nu het bestand src/App.js bijwerken, zal het systeem reageren op deze wijzigingen, ze naar het externe cluster kopiëren en de ontwikkelserver starten, die vervolgens onze applicatie in de browser bijwerkt.

Om het geheel compleet te maken, laten we zien hoe deze opdrachten er in hun geheel uitzien:

$ 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, meer informatie over hoe dit werkt is beschikbaar. hier.

Dit was een voorbeeld voor React, maar dezelfde methode kan ook worden gebruikt met andere frameworks; schrijf gewoon de omgevingsvariabele NPM_RUN op de juiste manier.

OpenShift Pipelines

Verder gaan we het hebben over een tool genaamd OpenShift Pipelines, en hoe deze kan worden gebruikt als een alternatief voor gekoppelde builds.

Wat zijn OpenShift Pipelines?

OpenShift Pipelines is a cloud-oriented CI/CD system for continuous integration and delivery, designed for organizing pipelines using Tekton. Tekton is a flexible Kubernetes-native CI/CD framework with open source that allows automation of deployment across various platforms (Kubernetes, serverless, virtual machines, etc.) by abstracting from the underlying layer.

To understand this article, certain knowledge of Pipelines is required, so we strongly recommend familiarizing yourself with the official tutorial.

Setting Up the Working Environment

To experiment with the examples in this article, you first need to prepare the working environment:

Install and configure an OpenShift 4 cluster. In our examples, we use CodeReady Containers (CRD), installation instructions for which can be found hier.
Once the cluster is ready, you need to install the Pipeline Operator on it. Don't worry, it's easy; installation instructions are available hier.
Download Tekton CLI (tkn) hier.
Run the create-react-app command-line tool to create an application that will be deployed later (this is a simple application React).
(Optional) Clone the repository to run the application locally with the command npm install and then npm start.

The application repository will also contain a k8s folder, where the YAML files for Kubernetes/OpenShift used for deploying the application will be located. There will be Tasks, ClusterTasks, Resources, and Pipelines that we will create in this de repository.

Let's get started

First, for our example, you need to create a new project in the OpenShift cluster. Let's name this project webapp-pipeline and create it with the following command:

$ oc new-project webapp-pipeline

The project name will be referenced in the code, so if you decide to name it differently, remember to update the code in the examples accordingly. From this point, we will go from the bottom up: that is, we will first create all the components of the pipeline and only then the pipeline itself.

So, first things first...

Tasks

Laten we een paar taken (tasks) creëren die vervolgens helpen bij het implementeren van de applicatie binnen onze pipeline. De eerste taak – apply_manifests_task – is verantwoordelijk voor het toepassen van de YAML-configuraties van de Kubernetes-resources (service, deployment en route) die zich in de k8s-map van onze applicatie bevinden. De tweede taak – update_deployment_task – is verantwoordelijk voor het bijwerken van het al geïmplementeerde image naar het image dat door onze pipeline wordt aangemaakt.

Maak je geen zorgen als het nu nog niet helemaal duidelijk is. Eigenlijk zijn deze taken een soort hulpprogramma's, en we zullen ze later in meer detail bespreken. Laten we ze voorlopig gewoon creëren:

$ 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 controleren we met de tkn CLI-commando of de taken zijn aangemaakt:

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

Opmerking: dit zijn lokale taken van je huidige project.

Cluster taken

Cluster taken zijn in feite hetzelfde als gewone taken. Dit zijn herbruikbare verzamelingen stappen die op verschillende manieren gecombineerd worden bij het uitvoeren van een specifieke taak. Het verschil is dat een clustertaak overal binnen het cluster beschikbaar is. Om de lijst van clustertaken te zien die automatisch worden aangemaakt bij het toevoegen van de Pipeline Operator, gebruiken we opnieuw het tkn CLI-commando:

$ 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 creëren. De eerste zal een S2I-image genereren en deze naar de interne OpenShift-register sturen; de tweede zal onze image bouwen op basis van NGINX, waarbij we de al door ons gebouwde applicatie als inhoud gebruiken.

We creëren en verzenden het image

Bij het aanmaken van de eerste taak herhalen we wat we al hebben gedaan in het vorige artikel over gekoppelde builds. We herinneren ons dat we het S2I (ubi8-s2i-web-app) afbeelding hebben gebruikt om onze applicatie te 'bouwen', en uiteindelijk hadden we een afbeelding die werd opgeslagen in de interne registry van OpenShift. Nu zullen we deze S2I-afbeelding van de webapplicatie gebruiken om een DockerFile voor onze applicatie te maken, en vervolgens gebruiken we Buildah om de daadwerkelijke build uit te voeren en de verkregen afbeelding naar de interne registry van OpenShift te sturen, aangezien dit precies is wat OpenShift doet wanneer je je applicaties implementeert met NodeShift.

Vraag je je af waar we dit allemaal vandaan hebben? Uit официальной версии official Node.js, we hebben het gewoon gekopieerd en aangepast naar onze wensen.

Laten we nu een cluster taak s2i-web-app aanmaken:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

We zullen dit niet in detail bespreken, maar alleen stilstaan bij de parameter OUTPUT_DIR:

params:
      - name: OUTPUT_DIR
        description: De locatie van de build output directory
        default: build

Standaard is deze parameter ingesteld op build, daar plaatst React de samengestelde inhoud. In andere frameworks worden andere paden gebruikt, bijvoorbeeld in Ember is dit dist. De output van onze eerste cluster taak zal een afbeelding zijn die de door ons samengestelde HTML, JavaScript en CSS bevat.

We bouwen een afbeelding op basis van NGINX

Wat betreft onze tweede cluster taak, deze moet een afbeelding op basis van NGINX voor ons bouwen, gebruikmakend van de inhoud van onze reeds samengestelde applicatie. Dit is in feite dat deel van de vorige sectie waarin we de gekoppelde builds bespraken.

Hiervoor zullen we - net als hiervoor - een cluster taak webapp-build-runtime aanmaken:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

Als we naar de code van deze cluster taken kijken, zien we dat er geen specifiek Git-repository wordt genoemd waar we mee werken, of de namen van de afbeeldingen die we maken. We geven alleen aan wat we naar Git sturen, of een bepaalde afbeelding waar we de uiteindelijke afbeelding moeten afgeven. Daarom kunnen deze cluster taken hergebruikt worden en ook gebruikt worden bij andere applicaties.

En hier gaan we elegant over naar het volgende punt...

Hulpmiddelen

Dus, aangezien, zoals we net zeiden, cluster taken zo algemeen mogelijk moeten zijn, moeten we bronnen creëren die als invoer (Git-repository) en uitvoer (eindafbeeldingen) worden gebruikt. De eerste bron die we nodig hebben, is Git, waar onze applicatie zich bevindt, iets als dit:

# 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 heeft PipelineResource het type git. De sleutel url in de params sectie wijst op de specifieke repository en stelt de master-tak in (dit is optioneel, maar we schrijven het voor de volledigheid).

Nu moeten we een bron aanmaken voor de afbeelding waarin de resultaten van het uitvoeren van de s2i-web-app taak worden opgeslagen, dit doen we 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 heeft PipelineResource het type image, en de waarde van de parameter url verwijst naar de interne OpenShift Image Registry, specifiek die in de namespace webapp-pipeline. Vergeet niet deze parameter te wijzigen als je een andere namespace gebruikt.

En tenslotte, de laatste bron die we nodig hebben, zal ook het type image hebben en dit zal de eindafbeelding van NGINX zijn, die vervolgens zal worden gebruikt bij de implementatie:

# 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

Let opnieuw op dat deze bron de afbeelding opslaat in de interne registry van OpenShift in de namespace webapp-pipeline.

Om al deze bronnen in één keer te creëren, maken we gebruik van de create-opdracht:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

Om te controleren of de bronnen zijn aangemaakt, kan dat als volgt:

$ tkn resource ls

Pipeline

Nu we alle benodigde onderdelen hebben, zullen we de pipeline samenstellen door de volgende opdracht te geven:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

Maar voordat we deze opdracht uitvoeren, laten we deze onderdelen eens goed bekijken. Ten eerste: de naam:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

Vervolgens in de sectie spec zien we de vermelding van de bronnen die we eerder hebben aangemaakt:

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

Daarna creëren we de taken die onze pipeline moet uitvoeren. Allereerst moet hij de taak s2i-web-app uitvoeren die we eerder hebben aangemaakt:

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

Deze taak neemt de invoer (git-bron) en uitvoer (bron built-web-application-image) parameters. We geven ook een speciale parameter door, zodat deze TLS niet verifieert, 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 bijna hetzelfde, alleen wordt hier de eerder door ons gemaakte cluster-taak webapp-build-runtime aangeroepen:

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

Net als bij de vorige taak, geven we een resource door, maar nu is dat de built-web-application-image (de output van onze vorige taak). En als output geven we opnieuw een afbeelding op. Aangezien deze taak na de vorige moet worden uitgevoerd, voegen we de runAfter-parameter 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 toepassen van de YAML-bestanden van de service, de route en de deployment, die zich in de k8s-directory van onze webapp bevinden, evenals voor het updaten van deze deployment bij het maken van nieuwe afbeeldingen. Deze twee cluster-taken hebben we aan het begin van het artikel gedefinieerd.

Pipeline starten

Alle onderdelen van onze pipeline zijn dus gemaakt, en we zullen deze starten met de volgende opdracht:

$ tkn pipeline start build-and-deploy-react

In deze fase wordt de commandoregel interactief gebruikt en moeten de juiste resources worden gekozen als reactie op elke aanvraag: voor de git-resource kiezen we web-application-repo, vervolgens voor de eerste afbeelding – built-web-application-image, en tenslotte voor de tweede afbeelding – 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 pipeline controleren met de volgende opdracht:

$ tkn pipeline logs -f

Nadat de pipeline is gestart en de applicatie is uitgevoerd, vragen we de gepubliceerde route op met de volgende opdracht:

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

Voor een betere visualisatie kunnen we onze pipeline bekijken in de Developer-modus van de webconsole, in de sectie Pipelines, zoals weergegeven in Figuur 1.

Figuur 1. Overzicht van de draaiende pipelines.

Klikken op de draaiende pipeline toont extra details, zoals weergegeven in Figuur 2.

Figuur 2. Extra details over de pipeline.

Na de extra details kunnen we de draaiende applicaties bekijken in de weergave Topologie, zoals weergegeven in Figuur 3.

Figuur 3. Draaiende pod.

Klikken op de cirkel in de rechterbovenhoek van het pictogram opent onze applicatie, zoals weergegeven in Figuur 4.

Figuur 4. Draaiende React-applicatie.

Conclusie

We have shown how to launch a development server for your application on OpenShift and synchronize it with the local file system. We also discussed how to simulate a chained-build template using OpenShift Pipelines. All example codes from this article can be found hier.