{"id":90874,"date":"2020-08-07T01:42:20","date_gmt":"2020-08-06T23:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds"},"modified":"2020-08-07T01:42:20","modified_gmt":"2020-08-06T23:42:20","slug":"sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Moderne applicaties op OpenShift, deel 2: chained builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo allemaal! Dit is de tweede post in onze serie waarin we laten zien hoe je moderne webapplicaties op Red Hat OpenShift kunt implementeren. <\/p>\n

\"Moderne
\n
\nIn de vorige post hebben we kort de mogelijkheden van de nieuwe S2I (source-to-image) builder-afbeelding aangeraakt, die bedoeld is voor het bouwen en implementeren van moderne webapplicaties op het OpenShift-platform. Toen lag de focus op het snel implementeren van een applicatie, en vandaag bekijken we hoe we een S2I-afbeelding kunnen gebruiken als een 'schone' builder-afbeelding en deze kunnen combineren met gerelateerde builds op OpenShift.
\n<\/a><\/noindex><\/p>\n

Schone builder-afbeelding<\/h3>\n

\nZoals we in het eerste deel hebben vermeld, hebben de meeste moderne webapplicaties een zogenaamde bouwfase, waarin meestal operaties zoals code-transpilatie, het samenvoegen van meerdere bestanden en minificatie plaatsvinden. De bestanden die uit deze operaties voortkomen \u2013 dat zijn statische HTML, JavaScript en CSS \u2013 worden in de output-map opgeslagen. De locatie van deze map hangt meestal af van de gebruikte build-tools, en voor React is dit de map .\\\/build (hierover komen we later meer terug).<\/p>\n

Source-to-Image (S2I)<\/h4>\n

\nIn deze post behandelen we helemaal niet het onderwerp 'wat is S2I en hoe gebruik je het' (hierover kun je meer lezen hier<\/a><\/noindex>), maar het is belangrijk om een goed begrip te hebben van de twee fasen van dit proces, om te begrijpen wat de Web App Builder-afbeelding doet.<\/p>\n

Assemblagefase<\/h4>\n

\nDe assemblagefase lijkt in wezen sterk op wat er gebeurt wanneer je docker build uitvoert en uiteindelijk een nieuwe Docker-afbeelding ontvangt. Deze fase treedt op wanneer je een build op het OpenShift-platform start.<\/p>\n

In het geval van de Web App Builder-afbeelding is het assemble script<\/a><\/noindex>. standaard gebruikt de builder-afbeelding de constructie npm run build, maar deze kan worden overschreven via de omgevingsvariabele NPM_BUILD.<\/p>\n

Zoals eerder vermeld, hangt de locatie van de kant-en-klare, samengevoegde applicatie af van welke tools worden gebruikt. In het geval van React bevindt dit zich in de map .\/build, en voor Angular-applicaties is dat de map project_name\/dist. En zoals in de vorige post al werd aangetoond, kan de locatie van de output-map, die standaard is ingesteld als build, worden overschreven via de omgevingsvariabele OUTPUT_DIR. Aangezien de locatie van de output-map verschilt van framework tot framework, hoeft u alleen de gegenereerde output te kopi\u00ebren naar de standaardmap in de afbeelding, namelijk naar \/opt\/apt-root\/output. Dit is belangrijk voor het begrijpen van het vervolg van dit artikel, maar laten we nu snel de volgende fase bekijken \u2013 de uitvoeringsfase (run phase).<\/p>\n

Uitvoeringsfase (run phase)<\/h4>\n

\nDeze fase komt in beeld wanneer voor een nieuwe afbeelding, die is gemaakt tijdens de assemblagefase, een docker run-oproep wordt gedaan. Dit gebeurt ook bij het implementeren op het OpenShift-platform. Standaard run script<\/a><\/noindex> gebruikt serve module<\/a><\/noindex> voor het serveren van statische inhoud, die in de hierboven genoemde standaard output-map ligt.<\/p>\n

Deze methode is goed voor een snelle implementatie van applicaties, maar in feite is het niet aan te raden om statische inhoud op deze manier te serveren. Aangezien we daadwerkelijk alleen statische inhoud serveren, is de ge\u00efnstalleerde Node.js binnen onze afbeelding niet nodig \u2013 een webserver is voldoende.<\/p>\n

Met andere woorden, tijdens de assemblage hebben we \u00e9\u00e9n ding nodig, tijdens de uitvoering iets anders. In zo'n situatie zijn gekoppelde builds (chained builds) handig.<\/p>\n

Gekoppelde builds (chained builds)<\/h3>\n

\nDit is wat erover wordt gezegd in gekoppelde builds<\/a><\/noindex> in de OpenShift-documentatie:<\/p>\n

\u00abTwee builds kunnen aan elkaar worden gekoppeld, waarbij de ene een gecompileerde entiteit genereert en de andere deze entiteit in een aparte afbeelding plaatst, die wordt gebruikt om deze entiteit uit te voeren.\u00bb\n<\/p><\/blockquote>\n

\nMet andere woorden, we kunnen de Web App Builder-image gebruiken om onze build uit te voeren, en vervolgens de webserver-image, zoals NGINX, gebruiken om onze inhoud te serveren.<\/p>\n

Op deze manier kunnen we de Web App Builder-image gebruiken als een 'schone' builder en tegelijkertijd een kleine runtime-image hebben.<\/p>\n

Laten we dit nu bekijken met een specifiek voorbeeld.<\/p>\n

Voor de oefening gebruiken we een eenvoudige React-applicatie<\/a><\/noindex>, gemaakt met behulp van de commandoregeltool create-react-app.<\/p>\n

Om alles samen te voegen zal ons helpen de OpenShift-sjabloonbestand<\/a><\/noindex>.<\/p>\n

Laten we dit bestand nader bekijken en beginnen met het gedeelte parameters.<\/p>\n

parameters:\n  - name: SOURCE_REPOSITORY_URL\n    description: De bron-URL voor de applicatie\n    displayName: Bron-URL\n    required: true\n  - name: SOURCE_REPOSITORY_REF\n    description: De taknaam voor de applicatie\n    displayName: Bron-tak\n    value: master\n    required: true\n  - name: SOURCE_REPOSITORY_DIR\n    description: De locatie binnen de bronrepo van de applicatie\n    displayName: Bronmap\n    value: .\n    required: true\n  - name: OUTPUT_DIR\n    description: De locatie van de gecompileerde statische bestanden van uw webapps-bouwer\n    displayName: Output-map\n    value: build\n    required: false\n<\/code><\/pre>\n
\nHet is allemaal vrij duidelijk hier, maar het is belangrijk om aandacht te besteden aan de parameter OUTPUT_DIR. Voor de React-applicatie uit ons voorbeeld hoeft u zich geen zorgen te maken, omdat React als output-map de standaardwaarde gebruikt, maar voor Angular of iets anders moet deze parameter op de juiste manier worden aangepast.<\/p>\n
Laten we nu kijken naar het gedeelte ImageStreams.<\/p>\n
- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-builder  \/\/ 1 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-runtime  \/\/ 2 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: web-app-builder-runtime \/\/ 3\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: nginx-image-runtime \/\/ 4\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nKijk naar de derde en vierde afbeeldingen. Ze zijn beide gedefinieerd als Docker-afbeeldingen, en het is duidelijk waar ze vandaan komen.<\/p>\n
De derde afbeelding is de web-app-builder, en deze komt uit nodeshift\/ubi8-s2i-web-app met tag 10.x op Docker hub<\/a><\/noindex>.<\/p>\n
De vierde afbeelding is de NGINX-afbeelding (versie 1.12) met tag latest op Docker hub<\/a><\/noindex>.<\/p>\n
Laten we nu kijken naar de eerste twee afbeeldingen. Beide zijn leeg bij de start en worden alleen tijdens de bouwfase aangemaakt. De eerste afbeelding, react-web-app-builder, wordt het resultaat van de assemblagefase, die de web-app-builder-runtime afbeelding en onze broncode combineert. Daarom hebben we '-builder' aan de naam van deze afbeelding toegevoegd.<\/p>\n
De tweede afbeelding, react-web-app-runtime, is het resultaat van de combinatie van nginx-image-runtime en enkele bestanden van de react-web-app-builder afbeelding. Deze afbeelding zal ook worden gebruikt tijdens de implementatie en zal alleen de webserver en de statische HTML, JavaScript, CSS van onze applicatie bevatten.<\/p>\n
Verwarrend? Laten we nu kijken naar de bouwconfiguraties en het zal iets duidelijker worden.<\/p>\n
In onze sjabloon zijn er twee bouwconfiguraties. Hier is de eerste, en deze is vrij standaard:<\/p>\n
  apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-builder\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-builder:latest \n    source:   \n      git:\n        uri: ${SOURCE_REPOSITORY_URL}\n        ref: ${SOURCE_REPOSITORY_REF}\n      contextDir: ${SOURCE_REPOSITORY_DIR}\n      type: Git\n    strategy:\n      sourceStrategy:\n        env:\n          - name: OUTPUT_DIR \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \n        incremental: true \n      type: Source\n    triggers: \n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nZoals te zien is, zegt de regel met label 1 dat het resultaat van deze bouw zal worden opgeslagen in het beeld react-web-app-builder, dat we eerder in de sectie ImageStreams hebben gezien.<\/p>\n
De regel met label 2 geeft aan waar de code vandaan komt. In ons geval is dit een git-repository, en de locatie, ref en contextdirectory zijn gedefinieerd door de parameters die we hierboven al hebben gezien.<\/p>\n
De regel met label 3 hebben we eerder gezien in de sectie parameters. Deze voegt de omgevingsvariabele OUTPUT_DIR toe, die in ons voorbeeld gelijk is aan build.
\nDe regel met label 4 zegt dat we het beeld web-app-builder-runtime willen gebruiken, dat we al hebben gezien in de sectie ImageStreams.<\/p>\n
De regel met label 5 geeft aan dat we een incrementele build willen gebruiken, mits de S2I-image dit ondersteunt, wat het beeld Web App Builder doet. Bij de eerste uitvoering, na het voltooien van de assembly-fase, zal de afbeelding de map node_modules in een archiefbestand opslaan. Bij daaropvolgende uitvoeringen zal de afbeelding deze map gewoon weer uitpakken om de bouwtijd te verkorten.<\/p>\n
En ten slotte, de regel met label 6 zijn slechts enkele triggers zodat de bouw automatisch wordt gestart, zonder handmatige tussenkomst, wanneer er iets verandert.<\/p>\n
Over het algemeen is dit een vrij standaard bouwconfiguratie.<\/p>\n
Laten we nu eens kijken naar de tweede bouwconfiguratie. Deze lijkt erg op de eerste, maar er is \u00e9\u00e9n belangrijk verschil.<\/p>\n
apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-runtime\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-runtime:latest \n    source: \n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \n          paths:\n            - sourcePath: \/opt\/app-root\/output\/.  \n              destinationDir: .  \n             \n    strategy: \n      sourceStrategy:\n        from:\n          kind: ImageStreamTag\n          name: nginx-image-runtime:latest\n        incremental: true\n      type: Source\n    triggers:\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - type: ImageChange\n      imageChange: {}\n    - type: ImageChange\n      imageChange:\n        from:\n          kind: ImageStreamTag\n          name: react-web-app-builder:latest\n<\/code><\/pre>\n
\nDus, de tweede configuratie is react-web-app-runtime, en die begint vrij standaard.<\/p>\n
In de regel met label 1 is er niets nieuws \u2013 deze zegt gewoon dat de uitkomst van de build in de afbeelding react-web-app-runtime wordt geplaatst.<\/p>\n
De regel met label 2, zoals in de vorige configuratie, geeft aan waar de broncode vandaan komt. Maar let op dat we hier zeggen dat deze uit een afbeelding komt. En wel uit de afbeelding die we zojuist hebben gemaakt \u2013 uit react-web-app-builder (vermeld in de regel met label 3). De bestanden die we willen gebruiken, bevinden zich binnen de afbeelding en hun locatie daar wordt bepaald in de regel met label 4, in ons geval is dat \/opt\/app-root\/output\/. Als je het je herinnert, daar worden de bestanden opgeslagen die zijn gegenereerd als resultaat van de build van onze applicatie.<\/p>\n
De doelmap, ingesteld in de regel met label 5 \u2013 is gewoon de huidige catalogus (dit draait allemaal, laten we niet vergeten, binnen een soort magische machine genaamd OpenShift, en niet op jouw lokale computer).<\/p>\n
De sectie strategy \u2013 regel met label 6 \u2013 lijkt ook op de eerste buildconfiguratie. Maar deze keer gaan we nginx-image-runtime gebruiken, dat we al in de sectie ImageStream hebben gezien.<\/p>\n
Tenslotte is de regel met label 7 de triggersectie die deze build activeert elke keer wanneer de afbeelding react-web-app-builder verandert.<\/p>\n
Verder bevat deze sjabloon een vrij standaard configuratie voor implementatie, evenals elementen die betrekking hebben op diensten en routes, maar we zullen daar niet dieper op ingaan. Let op dat de afbeelding die ge\u00efmplementeerd zal worden\u2013 de afbeelding react-web-app-runtime is.<\/p>\n
Implementatie van de applicatie<\/h3>\n
\nDus, nadat we naar de sjabloon hebben gekeken, laten we eens kijken hoe we deze kunnen gebruiken om de applicatie te implementeren.<\/p>\n
We kunnen de clienttool OpenShift genaamd oc gebruiken om onze sjabloon te implementeren:<\/p>\n
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f\n\n$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https:\/\/github.com\/lholmquist\/react-web-app\n<\/code><\/pre>\n
\nDe eerste opdracht op de afbeelding hierboven is een opzettelijk technische manier om de sjabloon \/openshiftio\/application.yaml te vinden.<\/p>\n
De tweede opdracht maakt gewoon een nieuwe applicatie op basis van deze sjabloon.<\/p>\n
Nadat deze opdrachten zijn uitgevoerd, zullen we zien dat we twee builds hebben ontvangen:<\/p>\n
\"Moderne<\/p>\n
En door terug te keren naar het overzichtsscherm, zien we de gestartte pod:<\/p>\n
\"Moderne<\/p>\n
Een klik op de link \u2013 en we worden doorgestuurd naar onze applicatie, die een standaard React App-pagina is:<\/p>\n
\"Moderne<\/p>\n
Aanvulling 1<\/h3>\n
\nVoor Angular-liefhebbers hebben we ook voorbeeld applicatie<\/a><\/noindex>.<\/p>\n
De sjabloon is hier hetzelfde, behalve de variabele OUTPUT_DIR.<\/p>\n
Aanvulling 2<\/h3>\n
\nIn dit artikel hebben we NGINX als webserver gebruikt, maar het is vrij eenvoudig om het te vervangen door Apache, gewoon door het sjabloonbestand aan te passen. NGINX afbeelding<\/a><\/noindex> en een werkende opdracht krijgen. Apache afbeelding<\/a><\/noindex>.<\/p>\n
Conclusie<\/h3>\n
\nIn het eerste deel van deze serie hebben we laten zien hoe je moderne webapplicaties snel kunt implementeren op het OpenShift-platform. Vandaag hebben we bekeken wat de Web App afbeelding doet en hoe deze kan worden gecombineerd met een lichte webserver zoals NGINX met behulp van gekoppelde builds (chained builds) om een productiegeschikte applicatie-build te organiseren. In het volgende, afsluitende artikel van deze serie, zullen we laten zien hoe je een ontwikkelserver voor je applicatie op OpenShift kunt draaien en de synchronisatie tussen lokale en externe bestanden kunt waarborgen.<\/p>\n
Inhoud van deze artikelenserie<\/h3>\n
<\/p>\n