{"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\/fr\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Applications modernes sur OpenShift, partie 3 : OpenShift en tant qu'environnement de d\u00e9veloppement et pipelines OpenShift Pipelines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour \u00e0 tous sur ce blog ! Voici la troisi\u00e8me publication d'une s\u00e9rie o\u00f9 nous montrons comment d\u00e9ployer des applications web modernes sur Red Hat OpenShift.<\/p>\n

\"Applications
\n
\nDans les deux pr\u00e9c\u00e9dentes publications, nous avons expliqu\u00e9 comment d\u00e9ployer des applications web modernes en quelques \u00e9tapes et comment utiliser une nouvelle image S2I accompagn\u00e9e d'une image de serveur HTTP pr\u00eate \u00e0 l'emploi, comme NGINX, gr\u00e2ce aux builds li\u00e9s pour organiser un d\u00e9ploiement en production.<\/p>\n

Aujourd'hui, nous allons vous montrer comment lancer un serveur de d\u00e9veloppement pour votre application sur la plateforme OpenShift et le synchroniser avec le syst\u00e8me de fichiers local, ainsi que discuter de ce que sont les OpenShift Pipelines et comment les utiliser comme alternative aux builds li\u00e9s.
\n<\/a><\/noindex><\/p>\n

OpenShift en tant qu'environnement de d\u00e9veloppement<\/h3>\n

<\/p>\n

Flux de travail de d\u00e9veloppement<\/h4>\n

\nComme d\u00e9j\u00e0 mentionn\u00e9 dans la premi\u00e8re publication<\/a><\/noindex>, un processus de d\u00e9veloppement typique pour les applications web modernes consiste simplement en un \u00ab serveur de d\u00e9veloppement \u00bb qui surveille les modifications des fichiers locaux. Lorsqu'une modification est d\u00e9tect\u00e9e, une compilation de l'application est lanc\u00e9e, puis celle-ci est mise \u00e0 jour dans le navigateur.<\/p>\n

Dans la plupart des frameworks modernes, un tel \u00ab serveur de d\u00e9veloppement \u00bb est int\u00e9gr\u00e9 dans les outils de ligne de commande appropri\u00e9s.<\/p>\n

Exemple local<\/h4>\n

\nPour commencer, voyons comment cela fonctionne dans le cas d'un lancement local d'applications. Prenons par exemple l'application React<\/a><\/noindex> des articles pr\u00e9c\u00e9dents, bien que les m\u00eames concepts de flux de travail s'appliquent \u00e9galement \u00e0 tous les autres frameworks modernes.
\nDonc, pour lancer un \u00ab serveur de d\u00e9veloppement \u00bb dans notre exemple avec React, nous allons entrer la commande suivante :<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nDans la fen\u00eatre du terminal, nous devrions voir quelque chose comme ceci :<\/p>\n
\"Applications<\/p>\n
Et notre application s'ouvrira dans le navigateur par d\u00e9faut :<\/p>\n
\"Applications<\/p>\n
Maintenant, si nous apportons des modifications au fichier, l'application devrait se mettre \u00e0 jour dans le navigateur.<\/p>\n
D'accord, le d\u00e9veloppement en mode local est clair, mais comment obtenir la m\u00eame chose sur OpenShift ?<\/p>\n
Serveur de d\u00e9veloppement sur OpenShift<\/h4>\n
\nSi vous vous souvenez, dans dans le pr\u00e9c\u00e9dent article<\/a><\/noindex>, nous avons examin\u00e9 ce qu'on appelle la phase de lancement (run phase) de l'image S2I et avons vu que par d\u00e9faut, le module serve se charge de notre application web.<\/p>\n
Cependant, si vous regardez de plus pr\u00e8s script d'ex\u00e9cution<\/a><\/noindex> de cet exemple, il y a une variable d'environnement $NPM_RUN, qui permet d'ex\u00e9cuter votre propre commande.<\/p>\n
Par exemple, vous pouvez utiliser le module nodeshift pour d\u00e9ployer notre application :<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nRemarque : l'exemple ci-dessus est pr\u00e9sent\u00e9 sous forme abr\u00e9g\u00e9e pour illustrer l'id\u00e9e g\u00e9n\u00e9rale.<\/i><\/p>\n
Ici, nous avons ajout\u00e9 \u00e0 notre d\u00e9ploiement la variable d'environnement NPM_RUN, qui indique \u00e0 l'\u00e9tape d'ex\u00e9cution qu'elle doit lancer la commande yarn start, d\u00e9marrant ainsi le serveur de d\u00e9veloppement React \u00e0 l'int\u00e9rieur de notre pod OpenShift.<\/p>\n
Si l'on consulte les journaux du pod en cours d'ex\u00e9cution, on obtiendra quelque chose de similaire :<\/p>\n
\"Applications<\/p>\n
Bien s\u00fbr, tout cela n'aura pas d'importance tant que nous ne pourrons pas synchroniser le code local avec le code qui est \u00e9galement contr\u00f4l\u00e9 pour des changements, mais qui vit sur un serveur distant.<\/p>\n
Synchronisation du code distant et local<\/h4>\n
\nHeureusement, la synchronisation est facilement facilit\u00e9e par nodeshift, et pour suivre les changements, on peut utiliser la commande watch.<\/p>\n
Ainsi, apr\u00e8s avoir ex\u00e9cut\u00e9 la commande pour d\u00e9ployer le serveur de d\u00e9veloppement de notre application, nous pouvons utiliser la commande suivante :<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nCela \u00e9tablira une connexion avec le pod en cours d'ex\u00e9cution que nous avons cr\u00e9\u00e9 un peu plus t\u00f4t, activera la synchronisation de nos fichiers locaux avec le cluster distant, et les fichiers de notre syst\u00e8me local commenceront \u00e0 \u00eatre surveill\u00e9s pour des changements.<\/p>\n
Par cons\u00e9quent, si nous mettons \u00e0 jour le fichier src\/App.js, le syst\u00e8me r\u00e9agira \u00e0 ces changements, les copiera sur le cluster distant et lancera le serveur de d\u00e9veloppement, qui mettra ensuite \u00e0 jour notre application dans le navigateur.<\/p>\n
Pour compl\u00e9ter le tableau, montrons comment ces commandes se pr\u00e9sentent dans leur int\u00e9gralit\u00e9 :<\/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
\nLa commande watch est une abstraction au-dessus de la commande oc rsync, vous pouvez en apprendre davantage sur son fonctionnement. ici<\/a><\/noindex>.<\/p>\n
C'\u00e9tait un exemple pour React, mais la m\u00eame m\u00e9thode peut \u00eatre utilis\u00e9e avec d'autres frameworks, il suffit d'\u00e9crire la variable d'environnement NPM_RUN de la mani\u00e8re appropri\u00e9e.
\n\u2003<\/p>\n
Pipelines OpenShift<\/h3>\n
\"Applications<\/p>\n
Ensuite, nous parlerons d'un outil appel\u00e9 OpenShift Pipelines et de la fa\u00e7on dont il peut \u00eatre utilis\u00e9 comme alternative aux builds li\u00e9s (chained builds).<\/p>\n
Qu'est-ce qu'OpenShift Pipelines ?<\/h4>\n
\nOpenShift Pipelines est un syst\u00e8me CI\/CD bas\u00e9 sur le cloud, con\u00e7u pour organiser des pipelines en utilisant Tekton. Tekton est un framework CI\/CD natif Kubernetes flexible et open source, permettant d'automatiser le d\u00e9ploiement sur diverses plateformes (Kubernetes, sans serveur, machines virtuelles, etc.) en abstrahant le niveau sous-jacent.<\/p>\n
Pour comprendre cet article, certaines connaissances sur les Pipelines sont n\u00e9cessaires, nous vous conseillons donc de consulter d'abord le manuel officiel<\/a><\/noindex>.<\/p>\n
Configuration de l'environnement de travail<\/h4>\n
\nPour exp\u00e9rimenter avec les exemples de cet article, vous devez d'abord pr\u00e9parer l'environnement de travail :<\/p>\n
    \n
  1. Installer et configurer un cluster OpenShift 4. Dans nos exemples, nous utilisons CodeReady Containers (CRD), les instructions d'installation peuvent \u00eatre trouv\u00e9es ici<\/a><\/noindex>.<\/li>\n
  2. Apr\u00e8s que le cluster soit pr\u00eat, vous devez installer le Pipeline Operator. Ne vous inqui\u00e9tez pas, c'est facile, les instructions d'installation ici<\/a><\/noindex>.<\/li>\n
  3. T\u00e9l\u00e9charger Tekton CLI<\/a><\/noindex> (tkn) ici<\/a><\/noindex>.<\/li>\n
  4. Lancer l'outil en ligne de commande create-react-app pour cr\u00e9er une application qui sera ensuite d\u00e9ploy\u00e9e (c'est une application simple React<\/a><\/noindex>).<\/li>\n
  5. (Optionnel) Cloner le d\u00e9p\u00f4t pour ex\u00e9cuter localement l'exemple d'application avec la commande npm install puis npm start.<\/li>\n<\/ol>\n
    \nDans le d\u00e9p\u00f4t de l'application, il y aura \u00e9galement un dossier k8s, o\u00f9 se trouveront les YAML de Kubernetes\/OpenShift utilis\u00e9s pour le d\u00e9ploiement de l'application. Il y aura des Tasks, ClusterTasks, Resources et Pipelines que nous cr\u00e9erons dans ce d\u00e9p\u00f4ts<\/a><\/noindex>.<\/p>\n
    Nous nous y mettons<\/h4>\n
    \nTout d'abord, pour notre exemple, nous devons cr\u00e9er un nouveau projet dans le cluster OpenShift. Nommez ce projet webapp-pipeline et cr\u00e9ez-le avec la commande suivante :<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nPar la suite, ce nom de projet appara\u00eetra dans le code, donc si vous d\u00e9cidez de l'appeler diff\u00e9remment, n'oubliez pas d'ajuster le code des exemples en cons\u00e9quence. \u00c0 partir de ce point, nous allons proc\u00e9der de bas en haut : c'est-\u00e0-dire, d'abord cr\u00e9er tous les composants du pipeline, puis le pipeline lui-m\u00eame.<\/p>\n
    Donc, tout d'abord\u2026<\/p>\n
    T\u00e2ches Tasks<\/h4>\n
    \nCr\u00e9ons deux t\u00e2ches (tasks) qui aideront ensuite \u00e0 d\u00e9ployer l'application dans notre pipeline. La premi\u00e8re t\u00e2che \u2013 apply_manifests_task \u2013 est responsable de l'application des ressources Kubernetes YAML (service, deployment et route) qui se trouvent dans le dossier k8s de notre application. La deuxi\u00e8me t\u00e2che \u2013 update_deployment_task \u2013 est responsable de la mise \u00e0 jour de l'image d\u00e9j\u00e0 d\u00e9ploy\u00e9e vers celle qui est cr\u00e9\u00e9e par notre pipeline.<\/p>\n
    Ne vous inqui\u00e9tez pas si ce n'est pas tr\u00e8s clair pour l'instant. En fait, ces t\u00e2ches sont quelque chose comme des utilitaires, et nous les examinerons plus en d\u00e9tail un peu plus tard. Pour l\u2019instant, cr\u00e9ons-les simplement :<\/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
    \nEnsuite, v\u00e9rifions que les t\u00e2ches ont \u00e9t\u00e9 cr\u00e9\u00e9es avec la commande tkn CLI :<\/p>\n
    $ tkn task ls\n\nNOM                     \u00c2GE\napply-manifests        il y a 1 minute\nupdate-deployment      il y a 1 minute\n<\/code><\/pre>\n
    \nRemarque : ce sont des t\u00e2ches locales pour votre projet actuel.<\/i><\/p>\n
    T\u00e2ches de cluster (Cluster tasks)<\/h4>\n
    \nLes t\u00e2ches de cluster sont en fait les m\u00eames que les simples t\u00e2ches. C'est-\u00e0-dire, une collection r\u00e9utilisable d'\u00e9tapes qui sont combin\u00e9es d'une mani\u00e8re ou d'une autre lors de l'ex\u00e9cution d'une t\u00e2che sp\u00e9cifique. La diff\u00e9rence est qu'une t\u00e2che de cluster est accessible partout dans le cluster. Pour voir la liste des t\u00e2ches de cluster qui sont automatiquement cr\u00e9\u00e9es lorsque l'on ajoute le Pipeline Operator, utilisons \u00e0 nouveau la commande tkn CLI :<\/p>\n
    $ tkn clustertask ls\n\nNOM                           \u00c2GE\nbuildah                        il y a 1 jour\nbuildah-v0-10-0               il y a 1 jour\njib-maven                      il y a 1 jour\nkn                             il y a 1 jour\nmaven                          il y a 1 jour\nopenshift-client               il y a 1 jour\nopenshift-client-v0-10-0      il y a 1 jour\ns2i                            il y a 1 jour\ns2i-go                         il y a 1 jour\ns2i-go-v0-10-0                 il y a 1 jour\ns2i-java-11                    il y a 1 jour\ns2i-java-11-v0-10-0            il y a 1 jour\ns2i-java-8                     il y a 1 jour\ns2i-java-8-v0-10-0             il y a 1 jour\ns2i-nodejs                     il y a 1 jour\ns2i-nodejs-v0-10-0             il y a 1 jour\ns2i-perl                       il y a 1 jour\ns2i-perl-v0-10-0               il y a 1 jour\ns2i-php                        il y a 1 jour\ns2i-php-v0-10-0                il y a 1 jour\ns2i-python-3                   il y a 1 jour\ns2i-python-3-v0-10-0           il y a 1 jour\ns2i-ruby                       il y a 1 jour\ns2i-ruby-v0-10-0               il y a 1 jour\ns2i-v0-10-0                    il y a 1 jour\n<\/code><\/pre>\n
    \nEt maintenant, cr\u00e9ons deux t\u00e2ches de cluster. La premi\u00e8re g\u00e9n\u00e9rera une image S2I et l'enverra dans le registre interne d'OpenShift ; la deuxi\u00e8me ex\u00e9cutera la construction de notre image bas\u00e9e sur NGINX, en utilisant comme contenu l'application que nous avons d\u00e9j\u00e0 construite.<\/p>\n
    Cr\u00e9ons et envoyons l'image<\/h4>\n
    \nLors de la cr\u00e9ation de la premi\u00e8re t\u00e2che, nous allons r\u00e9p\u00e9ter ce que nous avons d\u00e9j\u00e0 fait dans l'article pr\u00e9c\u00e9dent sur les builds li\u00e9s. Rappelons que nous avons utilis\u00e9 une image S2I (ubi8-s2i-web-app) pour \u00ab construire \u00bb notre application, et au final, nous obtenions une image stock\u00e9e dans le registre interne d'OpenShift. Maintenant, nous allons utiliser cette image S2I de l'application web pour cr\u00e9er un DockerFile pour notre application, puis nous allons utiliser Buildah pour effectuer la v\u00e9ritable construction et envoyer l'image obtenue dans le registre interne d'OpenShift, car c'est exactement ce qu'OpenShift fait lorsque vous d\u00e9ployez vos applications avec NodeShift.<\/p>\n
    Vous vous demandez d'o\u00f9 nous avons tir\u00e9 tout cela ? De \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, nous avons simplement copi\u00e9 cela et l'avons adapt\u00e9 pour nous.<\/p>\n
    Donc, maintenant, cr\u00e9ons la t\u00e2che de cluster s2i-web-app :<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/s2i-web-app-task.yaml\n<\/code><\/pre>\n
    \nNous ne d\u00e9taillerons pas cela, mais nous nous attarderons sur le param\u00e8tre OUTPUT_DIR :<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: L'emplacement du r\u00e9pertoire de sortie de la construction\n        default: build\n<\/code><\/pre>\n
    \nPar d\u00e9faut, ce param\u00e8tre est \u00e9gal \u00e0 build, c'est l\u00e0 que React stocke le contenu construit. D'autres frameworks utilisent d'autres chemins, par exemple, dans Ember, c'est dist. La sortie de notre premi\u00e8re t\u00e2che de cluster sera une image contenant le HTML, JavaScript et CSS que nous avons construits.<\/p>\n
    Construire une image bas\u00e9e sur NGINX<\/h4>\n
    \nEn ce qui concerne notre deuxi\u00e8me t\u00e2che de cluster, elle doit nous construire une image bas\u00e9e sur NGINX, en utilisant le contenu de notre application d\u00e9j\u00e0 construite. En essence, c'est la partie de la section pr\u00e9c\u00e9dente o\u00f9 nous avons examin\u00e9 les builds li\u00e9s.<\/p>\n
    Pour cela, nous allons \u2013 tout comme ci-dessus \u2013 cr\u00e9er la t\u00e2che de cluster webapp-build-runtime :<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/webapp-build-runtime-task.yaml\n<\/code><\/pre>\n
    \nSi nous regardons le code de ces t\u00e2ches de cluster, nous voyons qu'il n'y a pas de sp\u00e9cification du d\u00e9p\u00f4t Git avec lequel nous travaillons, ni des noms des images que nous cr\u00e9ons. Nous ne faisons qu'indiquer ce que nous transmettons \u00e0 Git, ou bien une image dans laquelle il faut exporter l'image finale. C'est pourquoi ces t\u00e2ches de cluster peuvent \u00eatre r\u00e9utilis\u00e9es lorsque nous travaillons avec d'autres applications.<\/p>\n
    Et ici, nous passons \u00e9l\u00e9gamment au point suivant\u2026<\/p>\n
    Ressources<\/h4>\n
    \nAinsi, comme nous venons de le dire, les t\u00e2ches de cluster doivent \u00eatre aussi g\u00e9n\u00e9ralis\u00e9es que possible, nous devons cr\u00e9er des ressources qui seront utilis\u00e9es en entr\u00e9e (d\u00e9p\u00f4t Git) et en sortie (images finales). La premi\u00e8re ressource dont nous avons besoin est Git, o\u00f9 se trouve notre application, quelque chose comme cela :<\/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
    \nIci, PipelineResource est de type git. La cl\u00e9 url dans la section params indique le d\u00e9p\u00f4t sp\u00e9cifique et d\u00e9finit la branche master (c'est optionnel, mais nous l'\u00e9crivons pour la compl\u00e9tude).<\/p>\n
    Maintenant, nous devons cr\u00e9er une ressource pour l'image, o\u00f9 seront enregistr\u00e9s les r\u00e9sultats de l'ex\u00e9cution de la t\u00e2che s2i-web-app, cela se fait comme suit :<\/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
    \nIci, PipelineResource est de type image, et la valeur du param\u00e8tre url pointe vers le registre d'images OpenShift interne, plus pr\u00e9cis\u00e9ment celui qui se trouve dans l'espace de noms webapp-pipeline. N'oubliez pas de changer ce param\u00e8tre si vous utilisez un autre espace de noms.<\/p>\n
    Et enfin, la derni\u00e8re ressource dont nous aurons besoin aura \u00e9galement le type image et ce sera l'image finale NGINX, qui sera ensuite utilis\u00e9e lors du d\u00e9ploiement :<\/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
    \nEt encore une fois, notez que cette ressource enregistre l'image dans le registre interne d'OpenShift dans l'espace de noms webapp-pipeline.<\/p>\n
    Pour cr\u00e9er toutes ces ressources en une seule fois, utilisons la commande create :<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nVous pouvez v\u00e9rifier que les ressources ont \u00e9t\u00e9 cr\u00e9\u00e9es comme cela :<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nMaintenant que nous avons tous les \u00e9l\u00e9ments n\u00e9cessaires, construisons le pipeline \u00e0 partir de ceux-ci en ex\u00e9cutant la commande suivante :<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/pipelines\/build-and-deploy-react.yaml\n<\/code><\/pre>\n
    \nMais avant d'ex\u00e9cuter cette commande, examinons ces \u00e9l\u00e9ments. Le premier est le nom :<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nEnsuite, dans la section spec, nous voyons la r\u00e9f\u00e9rence aux ressources que nous avons cr\u00e9\u00e9es pr\u00e9c\u00e9demment :<\/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
    \nEnsuite, nous cr\u00e9ons les t\u00e2ches que notre pipeline doit ex\u00e9cuter. Premi\u00e8rement, il doit ex\u00e9cuter la t\u00e2che s2i-web-app que nous avons d\u00e9j\u00e0 cr\u00e9\u00e9e :<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nCette t\u00e2che prend les param\u00e8tres d'entr\u00e9e (ressource gir) et de sortie (ressource built-web-application-image). Nous lui passons \u00e9galement un param\u00e8tre sp\u00e9cial pour qu'elle ne v\u00e9rifie pas le TLS, car nous utilisons des certificats auto-sign\u00e9s :<\/p>\n
    ressources:\n        entr\u00e9es:\n          - nom: source\n            ressource: web-application-repo\n        sorties:\n          - nom: image\n            ressource: built-web-application-image\n      params:\n        - nom: TLSVERIFY\n          valeur: "false"\n<\/code><\/pre>\n
    \nLa t\u00e2che suivante est presque identique, seulement ici nous appelons d\u00e9j\u00e0 la t\u00e2che de cluster que nous avons cr\u00e9\u00e9e, webapp-build-runtime :<\/p>\n
    nom: build-runtime-image\n    taskRef:\n      nom: webapp-build-runtime\n      type: ClusterTask\n<\/code><\/pre>\n
    \nComme pour la t\u00e2che pr\u00e9c\u00e9dente, nous transf\u00e9rons la ressource, mais maintenant il s'agit de built-web-application-image (la sortie de notre t\u00e2che pr\u00e9c\u00e9dente). Et en tant que sortie, nous demandons \u00e0 nouveau l'image. Comme cette t\u00e2che doit \u00eatre ex\u00e9cut\u00e9e apr\u00e8s la pr\u00e9c\u00e9dente, nous ajoutons le champ runAfter :<\/p>\n
    ressources:\n        entr\u00e9es:\n          - nom: image\n            ressource: built-web-application-image\n        sorties:\n          - nom: image\n            ressource: runtime-web-application-image\n        params:\n        - nom: TLSVERIFY\n          valeur: "false"\n      runAfter:\n        - build-web-application\n<\/code><\/pre>\n
    \nLes deux t\u00e2ches suivantes sont responsables de l'application des fichiers YAML du service, du routage et du d\u00e9ploiement, qui se trouvent dans le r\u00e9pertoire k8s de notre application Web, ainsi que de la mise \u00e0 jour de ce d\u00e9ploiement lors de la cr\u00e9ation de nouvelles images. Ces deux t\u00e2ches de cluster ont \u00e9t\u00e9 d\u00e9finies au d\u00e9but de l'article.<\/p>\n
    D\u00e9marrer le pipeline<\/h4>\n
    \nAinsi, toutes les parties de notre pipeline sont cr\u00e9\u00e9es, et nous allons le lancer avec la commande suivante :<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \n\u00c0 ce stade, la ligne de commande est utilis\u00e9e en mode interactif et il faut s\u00e9lectionner les ressources appropri\u00e9es en r\u00e9ponse \u00e0 chacune de ses demandes : pour la ressource git, nous choisissons web-application-repo, ensuite pour la premi\u00e8re image \u2013 built-web-application-image, et enfin pour la deuxi\u00e8me image \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
    \nMaintenant, v\u00e9rifions l'\u00e9tat du pipeline avec la commande suivante :<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nApr\u00e8s que le pipeline a d\u00e9marr\u00e9 et que l'application est d\u00e9ploy\u00e9e, interrogeons le route publi\u00e9 avec la commande suivante :<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nPour plus de visibilit\u00e9, nous pouvons voir notre pipeline en mode Developer dans la console Web dans la section Pipelines<\/b>, comme indiqu\u00e9 \u00e0 la Fig. 1.<\/p>\n
    \"Applications<\/p>\n
    Fig. 1. Vue d'ensemble des pipelines en cours d'ex\u00e9cution.<\/i><\/p>\n
    Cliquer sur le pipeline en cours d'ex\u00e9cution affiche des informations suppl\u00e9mentaires, comme indiqu\u00e9 \u00e0 la Fig. 2.<\/p>\n
    \"Applications<\/p>\n
    Fig. 2. Informations suppl\u00e9mentaires sur le pipeline.<\/i><\/p>\n
    Apr\u00e8s les informations suppl\u00e9mentaires, nous pouvons voir les applications en cours d'ex\u00e9cution dans la vue Topology<\/b>, comme indiqu\u00e9 \u00e0 la Fig. 3.<\/p>\n
    \"Applications<\/p>\n
    Fig 3. Pod en cours d'ex\u00e9cution.<\/i><\/p>\n
    Cliquer sur le cercle en haut \u00e0 droite de l'ic\u00f4ne ouvre notre application, comme indiqu\u00e9 \u00e0 la Fig. 4.<\/p>\n
    \"Applications<\/p>\n
    Fig. 4. Application React en cours d'ex\u00e9cution.<\/i><\/p>\n
    Conclusion<\/h3>\n
    \nNous avons donc montr\u00e9 comment d\u00e9ployer un serveur de d\u00e9veloppement pour votre application sur OpenShift et le synchroniser avec le syst\u00e8me de fichiers local. Nous avons \u00e9galement examin\u00e9 comment simuler un mod\u00e8le de chained-build \u00e0 l'aide des OpenShift Pipelines. Tous les codes d'exemple de cet article peuvent \u00eatre trouv\u00e9s ici<\/a><\/noindex>.<\/p>\n
    Ressources suppl\u00e9mentaires (EN)<\/h3>\n
    <\/p>\n