{"id":92048,"date":"2020-08-22T07:42:57","date_gmt":"2020-08-22T05:42:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines"},"modified":"2020-08-22T07:42:57","modified_gmt":"2020-08-22T05:42:57","slug":"sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Moderne toepassingen op OpenShift, deel 3: OpenShift als ontwikkelomgeving en OpenShift Pipelines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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.<\/p>\n

\"Moderne
\n
\nIn 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.<\/p>\n

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.
\n<\/a><\/noindex><\/p>\n

OpenShift als ontwikkelomgeving<\/h3>\n

<\/p>\n

Ontwikkelworkflow<\/h4>\n

\nZoals eerder genoemd in de eerste post<\/a><\/noindex>, 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.<\/p>\n

In de meeste moderne frameworks is zo'n 'ontwikkelserver' ingebouwd in de bijbehorende command-line tools.<\/p>\n

Lokaal voorbeeld<\/h4>\n

\nLaten we eerst kijken hoe dit werkt in het geval van lokaal draaien van applicaties. Als voorbeeld nemen we de applicatie React<\/a><\/noindex> uit eerdere artikelen, hoewel vrijwel dezelfde concepten voor de workflow ook in andere moderne frameworks van toepassing zijn.
\nDus om de 'ontwikkelserver' in ons React-voorbeeld te draaien, voeren we het volgende commando in:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nDan zien we ongeveer het volgende in het terminalvenster:<\/p>\n
\"Moderne<\/p>\n
En onze applicatie opent in de standaardbrowser:<\/p>\n
\"Moderne<\/p>\n
Nu, als we wijzigingen aanbrengen in het bestand, zou de applicatie in de browser moeten vernieuwen.<\/p>\n
Ok\u00e9, dat is duidelijk voor de lokale ontwikkelingsmodus, maar hoe bereiken we hetzelfde op OpenShift?<\/p>\n
Ontwikkelserver op OpenShift<\/h4>\n
\nAls je het je herinnert, hebben we in de vorige post<\/a><\/noindex>het zogenaamde opstartfase (run phase) van de S2I-image besproken en gezien dat standaard het module serve onze webapplicatie bedient.<\/p>\n
Als we echter beter kijken run script<\/a><\/noindex> In dit voorbeeld is er een omgevingsvariabele $NPM_RUN die het mogelijk maakt om je eigen commando uit te voeren.<\/p>\n
Je kunt bijvoorbeeld de nodeshift-module gebruiken om onze applicatie te implementeren:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN=\"yarn start\" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nOpmerking: het bovenstaande voorbeeld is verkort weergegeven om de algemene idee te illustreren.<\/i><\/p>\n
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.<\/p>\n
Als we naar de log van de draaiende pod kijken, zal het er ongeveer zo uitzien:<\/p>\n
\"Moderne<\/p>\n
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.<\/p>\n
Synchronisatie van externe en lokale code<\/h4>\n
\nGelukkig helpt nodeshift eenvoudig bij de synchronisatie, en voor het volgen van wijzigingen kun je de watch-opdracht gebruiken.<\/p>\n
Dus nadat we het commando hebben uitgevoerd om de ontwikkelserver voor onze applicatie te implementeren, kunnen we gerust het volgende commando gebruiken:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nHet 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.<\/p>\n
Daarom, als we nu het bestand src\/App.js bijwerken, zal het systeem reageren op deze wijzigingen, ze naar het externe cluster kopi\u00ebren en de ontwikkelserver starten, die vervolgens onze applicatie in de browser bijwerkt.<\/p>\n
Om het geheel compleet te maken, laten we zien hoe deze opdrachten er in hun geheel uitzien:<\/p>\n
$ 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\n\n$ npx nodeshift watch --strictSSL=false\n<\/code><\/pre>\n
\nHet watch-commando is een abstractie bovenop het oc rsync-commando, meer informatie over hoe dit werkt is beschikbaar. hier<\/a><\/noindex>.<\/p>\n
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.
\n\u2003<\/p>\n
OpenShift Pipelines<\/h3>\n
\"Moderne<\/p>\n
Verder gaan we het hebben over een tool genaamd OpenShift Pipelines, en hoe deze kan worden gebruikt als een alternatief voor gekoppelde builds.<\/p>\n
Wat zijn OpenShift Pipelines?<\/h4>\n
\nOpenShift 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.<\/p>\n
To understand this article, certain knowledge of Pipelines is required, so we strongly recommend familiarizing yourself with the official tutorial<\/a><\/noindex>.<\/p>\n
Setting Up the Working Environment<\/h4>\n
\nTo experiment with the examples in this article, you first need to prepare the working environment:<\/p>\n
    \n
  1. Install and configure an OpenShift 4 cluster. In our examples, we use CodeReady Containers (CRD), installation instructions for which can be found hier<\/a><\/noindex>.<\/li>\n
  2. 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<\/a><\/noindex>.<\/li>\n
  3. Download Tekton CLI<\/a><\/noindex> (tkn) hier<\/a><\/noindex>.<\/li>\n
  4. Run the create-react-app command-line tool to create an application that will be deployed later (this is a simple application React<\/a><\/noindex>).<\/li>\n
  5. (Optional) Clone the repository to run the application locally with the command npm install and then npm start.<\/li>\n<\/ol>\n
    \nThe 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<\/a><\/noindex>.<\/p>\n
    Let's get started<\/h4>\n
    \nFirst, 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:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nThe 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.<\/p>\n
    So, first things first...<\/p>\n
    Tasks<\/h4>\n
    \nLaten we een paar taken (tasks) cre\u00ebren die vervolgens helpen bij het implementeren van de applicatie binnen onze pipeline. De eerste taak \u2013 apply_manifests_task \u2013 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 \u2013 update_deployment_task \u2013 is verantwoordelijk voor het bijwerken van het al ge\u00efmplementeerde image naar het image dat door onze pipeline wordt aangemaakt.<\/p>\n
    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\u00ebren:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/tasks\/update_deployment_task.yaml\n$ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/tasks\/apply_manifests_task.yaml\n<\/code><\/pre>\n
    \nVervolgens controleren we met de tkn CLI-commando of de taken zijn aangemaakt:<\/p>\n
    $ tkn task ls\n\nNAME                AGE\napply-manifests     1 minute ago\nupdate-deployment   1 minute ago\n<\/code><\/pre>\n
    \nOpmerking: dit zijn lokale taken van je huidige project.<\/i><\/p>\n
    Cluster taken<\/h4>\n
    \nCluster 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:<\/p>\n
    $ tkn clustertask ls\n\nNAME                       AGE\nbuildah                    1 day ago\nbuildah-v0-10-0            1 day ago\njib-maven                  1 day ago\nkn                         1 day ago\nmaven                      1 day ago\nopenshift-client           1 day ago\nopenshift-client-v0-10-0   1 day ago\ns2i                        1 day ago\ns2i-go                     1 day ago\ns2i-go-v0-10-0             1 day ago\ns2i-java-11                1 day ago\ns2i-java-11-v0-10-0        1 day ago\ns2i-java-8                 1 day ago\ns2i-java-8-v0-10-0         1 day ago\ns2i-nodejs                 1 day ago\ns2i-nodejs-v0-10-0         1 day ago\ns2i-perl                   1 day ago\ns2i-perl-v0-10-0           1 day ago\ns2i-php                    1 day ago\ns2i-php-v0-10-0            1 day ago\ns2i-python-3               1 day ago\ns2i-python-3-v0-10-0       1 day ago\ns2i-ruby                   1 day ago\ns2i-ruby-v0-10-0           1 day ago\ns2i-v0-10-0                1 day ago\n<\/code><\/pre>\n
    \nLaten we nu twee clustertaken cre\u00ebren. 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.<\/p>\n
    We cre\u00ebren en verzenden het image<\/h4>\n
    \nBij 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.<\/p>\n
    Vraag je je af waar we dit allemaal vandaan hebben? Uit \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, we hebben het gewoon gekopieerd en aangepast naar onze wensen.<\/p>\n
    Laten we nu een cluster taak s2i-web-app aanmaken:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/s2i-web-app-task.yaml\n<\/code><\/pre>\n
    \nWe zullen dit niet in detail bespreken, maar alleen stilstaan bij de parameter OUTPUT_DIR:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: De locatie van de build output directory\n        default: build\n<\/code><\/pre>\n
    \nStandaard 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.<\/p>\n
    We bouwen een afbeelding op basis van NGINX<\/h4>\n
    \nWat 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.<\/p>\n
    Hiervoor zullen we - net als hiervoor - een cluster taak webapp-build-runtime aanmaken:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/webapp-build-runtime-task.yaml\n<\/code><\/pre>\n
    \nAls 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.<\/p>\n
    En hier gaan we elegant over naar het volgende punt...<\/p>\n
    Hulpmiddelen<\/h4>\n
    \nDus, aangezien, zoals we net zeiden, cluster taken zo algemeen mogelijk moeten zijn, moeten we bronnen cre\u00ebren 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:<\/p>\n
    # This resource is the location of the git repo with the web application source\napiVersion: tekton.dev\/v1alpha1\nkind: PipelineResource\nmetadata:\n  name: web-application-repo\nspec:\n  type: git\n  params:\n    - name: url\n      value: https:\/\/github.com\/nodeshift-starters\/react-pipeline-example\n    - name: revision\n      value: master\n<\/code><\/pre>\n
    \nHier 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).<\/p>\n
    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:<\/p>\n
    # This resource is the result of running "npm run build",  the resulting built files will be located in \/opt\/app-root\/output\napiVersion: tekton.dev\/v1alpha1\nkind: PipelineResource\nmetadata:\n  name: built-web-application-image\nspec:\n  type: image\n  params:\n    - name: url\n      value: image-registry.openshift-image-registry.svc:5000\/webapp-pipeline\/built-web-application:latest\n<\/code><\/pre>\n
    \nHier 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.<\/p>\n
    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:<\/p>\n
    # This resource is the image that will be just the static html, css, js files being run with nginx\napiVersion: tekton.dev\/v1alpha1\nkind: PipelineResource\nmetadata:\n  name: runtime-web-application-image\nspec:\n  type: image\n  params:\n    - name: url\n      value: image-registry.openshift-image-registry.svc:5000\/webapp-pipeline\/runtime-web-application:latest\n<\/code><\/pre>\n
    \nLet opnieuw op dat deze bron de afbeelding opslaat in de interne registry van OpenShift in de namespace webapp-pipeline.<\/p>\n
    Om al deze bronnen in \u00e9\u00e9n keer te cre\u00ebren, maken we gebruik van de create-opdracht:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nOm te controleren of de bronnen zijn aangemaakt, kan dat als volgt:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nNu we alle benodigde onderdelen hebben, zullen we de pipeline samenstellen door de volgende opdracht te geven:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/pipelines\/build-and-deploy-react.yaml\n<\/code><\/pre>\n
    \nMaar voordat we deze opdracht uitvoeren, laten we deze onderdelen eens goed bekijken. Ten eerste: de naam:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nVervolgens in de sectie spec zien we de vermelding van de bronnen die we eerder hebben aangemaakt:<\/p>\n
    spec:\n  resources:\n    - name: web-application-repo\n      type: git\n    - name: built-web-application-image\n      type: image\n    - name: runtime-web-application-image\n      type: image\n<\/code><\/pre>\n
    \nDaarna cre\u00ebren we de taken die onze pipeline moet uitvoeren. Allereerst moet hij de taak s2i-web-app uitvoeren die we eerder hebben aangemaakt:<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nDeze 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:<\/p>\n
    resources:\n        inputs:\n          - name: source\n            resource: web-application-repo\n        outputs:\n          - name: image\n            resource: built-web-application-image\n      params:\n        - name: TLSVERIFY\n          value: \"false\"\n<\/code><\/pre>\n
    \nDe volgende taak is bijna hetzelfde, alleen wordt hier de eerder door ons gemaakte cluster-taak webapp-build-runtime aangeroepen:<\/p>\n
    name: build-runtime-image\n    taskRef:\n      name: webapp-build-runtime\n      kind: ClusterTask\n<\/code><\/pre>\n
    \nNet 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:<\/p>\n
    resources:\n        inputs:\n          - name: image\n            resource: built-web-application-image\n        outputs:\n          - name: image\n            resource: runtime-web-application-image\n        params:\n        - name: TLSVERIFY\n          value: \"false\"\n      runAfter:\n        - build-web-application\n<\/code><\/pre>\n
    \nDe 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.<\/p>\n
    Pipeline starten<\/h4>\n
    \nAlle onderdelen van onze pipeline zijn dus gemaakt, en we zullen deze starten met de volgende opdracht:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nIn 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 \u2013 built-web-application-image, en tenslotte voor de tweede afbeelding \u2013 runtime-web-application-image:<\/p>\n
    ? Choose the git resource to use for web-application-repo: web-application-repo (https:\/\/github.com\/nodeshift-starters\/react-pipeline-example)\n? 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-\napplication:latest)\n? 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\ne-web-application:latest)\nPipelinerun started: build-and-deploy-react-run-4xwsr\n<\/code><\/pre>\n
    \nLaten we nu de status van de pipeline controleren met de volgende opdracht:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nNadat de pipeline is gestart en de applicatie is uitgevoerd, vragen we de gepubliceerde route op met de volgende opdracht:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nVoor een betere visualisatie kunnen we onze pipeline bekijken in de Developer-modus van de webconsole, in de sectie Pipelines<\/b>, zoals weergegeven in Figuur 1.<\/p>\n
    \"Moderne<\/p>\n
    Figuur 1. Overzicht van de draaiende pipelines.<\/i><\/p>\n
    Klikken op de draaiende pipeline toont extra details, zoals weergegeven in Figuur 2.<\/p>\n
    \"Moderne<\/p>\n
    Figuur 2. Extra details over de pipeline.<\/i><\/p>\n
    Na de extra details kunnen we de draaiende applicaties bekijken in de weergave Topologie<\/b>, zoals weergegeven in Figuur 3.<\/p>\n
    \"Moderne<\/p>\n
    Figuur 3. Draaiende pod.<\/i><\/p>\n
    Klikken op de cirkel in de rechterbovenhoek van het pictogram opent onze applicatie, zoals weergegeven in Figuur 4.<\/p>\n
    \"Moderne<\/p>\n
    Figuur 4. Draaiende React-applicatie.<\/i><\/p>\n
    Conclusie<\/h3>\n
    \nWe 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<\/a><\/noindex>.<\/p>\n
    Aanvullende bronnen (EN)<\/h3>\n
    <\/p>\n