{"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\/it\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"App moderne su OpenShift, parte 3: OpenShift come ambiente di sviluppo e tubazioni di OpenShift Pipelines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti in questo blog! Questo \u00e8 il terzo post di una serie che mostra come distribuire moderne applicazioni web su Red Hat OpenShift.<\/p>\n

\"App
\n
\nNei due post precedenti, abbiamo spiegato come distribuire moderne applicazioni web in pochi passaggi e come utilizzare la nuova immagine S2I insieme a un'immagine HTTP server gi\u00e0 pronta, come NGINX, con l'aiuto delle build concatenate per organizzare una distribuzione in produzione.<\/p>\n

Oggi mostreremo come avviare un server di sviluppo per la tua applicazione sulla piattaforma OpenShift e sincronizzarlo con il file system locale, e parleremo anche di cosa sono le OpenShift Pipelines e come possono essere utilizzate come alternativa alle build concatenate.
\n<\/a><\/noindex><\/p>\n

OpenShift come ambiente di sviluppo<\/h3>\n

<\/p>\n

Flusso di lavoro di sviluppo<\/h4>\n

\nCome gi\u00e0 menzionato nel primo post<\/a><\/noindex>, il processo tipico di sviluppo per le moderne applicazioni web \u00e8 essenzialmente un \"server di sviluppo\" che monitora le modifiche nei file locali. Quando si verificano, viene avviata la build dell'applicazione e successivamente viene aggiornata nel browser.<\/p>\n

Nella maggior parte dei moderni framework, un tale \"server di sviluppo\" \u00e8 integrato negli strumenti della riga di comando corrispondenti.<\/p>\n

Esempio locale<\/h4>\n

\nPer prima cosa, vediamo come funziona in caso di avvio locale delle applicazioni. Come esempio, utilizzERemo l'applicazione React<\/a><\/noindex> nelle precedenti articoli, sebbene praticamente gli stessi concetti di flusso di lavoro si applichino anche in tutti gli altri moderni framework.
\nQuindi, per avviare il \"server di sviluppo\" nel nostro esempio con React, inseriamo il seguente comando:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nAllora nella finestra del terminale vedremo qualcosa di simile:<\/p>\n
\"App<\/p>\n
E la nostra applicazione si aprir\u00e0 nel browser predefinito:<\/p>\n
\"App<\/p>\n
Ora, se apportiamo modifiche al file, l'applicazione dovrebbe aggiornarsi nel browser.<\/p>\n
OK, lo sviluppo in modalit\u00e0 locale \u00e8 chiaro, ma come ottenere lo stesso su OpenShift?<\/p>\n
Server di sviluppo su OpenShift<\/h4>\n
\nSe vi ricordate, in post precedente<\/a><\/noindex>, abbiamo esaminato il cosiddetto stadio di avvio (run phase) dell'immagine S2I e abbiamo visto che, per impostazione predefinita, il modulo serve gestisce la nostra applicazione web.<\/p>\n
Tuttavia, se diamo un'occhiata pi\u00f9 da vicino script di esecuzione<\/a><\/noindex> di quell'esempio, c'\u00e8 una variabile d'ambiente $NPM_RUN che consente di eseguire il proprio comando.<\/p>\n
Ad esempio, puoi utilizzare il modulo nodeshift per distribuire la nostra applicazione:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN=\"yarn start\" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nNota: l'esempio sopra \u00e8 riportato in forma abbreviata per illustrare l'idea generale.<\/i><\/p>\n
Qui abbiamo aggiunto alla nostra distribuzione la variabile d'ambiente NPM_RUN, che indica al processo di esecuzione di avviare il comando yarn start, che avvia il server di sviluppo React all'interno del nostro pod OpenShift.<\/p>\n
Se guardi il log del pod in funzione, ci sar\u00e0 pi\u00f9 o meno questo:<\/p>\n
\"App<\/p>\n
Certo, tutto ci\u00f2 non avr\u00e0 senso finch\u00e9 non riusciremo a sincronizzare il codice locale con quello che \u00e8 anche monitorato per le modifiche, ma vive su un server remoto.<\/p>\n
Sincronizzazione del codice remoto e locale<\/h4>\n
\nFortunatamente, nodeshift semplifica la sincronizzazione e per monitorare le modifiche possiamo utilizzare il comando watch.<\/p>\n
Dopo aver eseguito il comando per distribuire il server di sviluppo per la nostra applicazione, possiamo usare senza problemi questo comando:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nDi conseguenza, verr\u00e0 stabilita una connessione al pod avviato che abbiamo creato poco prima, attivando la sincronizzazione dei nostri file locali con il cluster remoto, e i file nella nostra sistema locale inizieranno a essere monitorati per eventuali modifiche.<\/p>\n
Pertanto, se ora aggiorniamo il file src\/App.js, il sistema reagir\u00e0 a queste modifiche, le copier\u00e0 sul cluster remoto e avvier\u00e0 il server di sviluppo che poi aggiorner\u00e0 la nostra applicazione nel browser.<\/p>\n
Per completezza, mostreremo come appaiono questi comandi nella loro interezza:<\/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
\nIl comando watch \u00e8 un'astrazione sopra il comando oc rsync, maggiori informazioni su come funziona possono essere trovate qui<\/a><\/noindex>.<\/p>\n
Questo era un esempio per React, ma lo stesso metodo pu\u00f2 essere utilizzato anche con altri framework, basta impostare correttamente la variabile ambientale NPM_RUN.
\n\u2003<\/p>\n
OpenShift Pipelines<\/h3>\n
\"App<\/p>\n
In seguito parleremo di uno strumento chiamato OpenShift Pipelines e di come pu\u00f2 essere utilizzato come alternativa alle build collegate chained build.<\/p>\n
Che cos'\u00e8 OpenShift Pipelines<\/h4>\n
\nOpenShift Pipelines \u00e8 un sistema CI\/CD basato su cloud per l'integrazione e la consegna continua, progettato per gestire pipeline utilizzando Tekton. Tekton \u00e8 un framework CI\/CD Kubernetes-native flessibile e open source che consente di automatizzare il deployment su diverse piattaforme (Kubernetes, serverless, macchine virtuali, ecc.) astrarre dal livello sottostante.<\/p>\n
Per comprendere questo articolo sono necessarie alcune conoscenze sulle Pipelines, quindi ti consigliamo di iniziare a leggere il manuale ufficiale<\/a><\/noindex>.<\/p>\n
Impostazione dell'ambiente di lavoro<\/h4>\n
\nPer sperimentare con gli esempi di questo articolo, \u00e8 necessario prima preparare l'ambiente di lavoro:<\/p>\n
    \n
  1. Installare e configurare un cluster OpenShift 4. Nei nostri esempi utilizziamo CodeReady Containers (CRD), le istruzioni per l'installazione sono disponibili qui<\/a><\/noindex>.<\/li>\n
  2. Una volta che il cluster \u00e8 pronto, dovrai installare il Pipeline Operator. Non preoccuparti, \u00e8 semplice, e le istruzioni per l'installazione sono qui<\/a><\/noindex>.<\/li>\n
  3. Carica Tekton CLI<\/a><\/noindex> (tkn) qui<\/a><\/noindex>.<\/li>\n
  4. Esegui lo strumento da riga di comando create-react-app per creare un'applicazione che successivamente verr\u00e0 distribuita (si tratta di un'applicazione semplice React<\/a><\/noindex>).<\/li>\n
  5. (Opzionale) Clona il repository per eseguire localmente l'applicazione usando il comando npm install e poi npm start.<\/li>\n<\/ol>\n
    \nNel repository dell'applicazione ci sar\u00e0 anche una cartella k8s, dove si troveranno i file YAML di Kubernetes\/OpenShift usati per il deployment dell'applicazione. Qui ci saranno Tasks, ClusterTasks, Resources e Pipelines che creeremo in questo repository<\/a><\/noindex>.<\/p>\n
    Iniziamo<\/h4>\n
    \nPer il nostro esempio, dobbiamo prima creare un nuovo progetto nel cluster OpenShift. Chiamiamo questo progetto webapp-pipeline e creiamolo con il seguente comando:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nSuccessivamente, questo nome del progetto verr\u00e0 utilizzato nel codice, quindi, se decidete di chiamarlo diversamente, non dimenticate di correggere il codice degli esempi di conseguenza. A partire da questo punto, procederemo non dall'alto verso il basso, ma dal basso verso l'alto: cio\u00e8, prima creeremo tutte le componenti della pipeline, e solo dopo quella stessa.<\/p>\n
    Quindi, la prima cosa da fare\u2026<\/p>\n
    Tasks<\/h4>\n
    \nCreeremo un paio di attivit\u00e0 (tasks) che aiuteranno a distribuire l'applicazione all'interno del nostro congegno pipeline. La prima attivit\u00e0 \u2013 apply_manifests_task \u2013 si occupa di applicare i file YAML delle risorse Kubernetes (service, deployment e route) presenti nella cartella k8s della nostra applicazione. La seconda attivit\u00e0 \u2013 update_deployment_task \u2013 \u00e8 responsabile dell'aggiornamento dell'immagine gi\u00e0 distribuita con quella che viene creata dal nostro congegno.<\/p>\n
    Non preoccuparti se non hai ancora ben chiaro. In effetti, queste attivit\u00e0 sono simili a utility, e le esploreremo pi\u00f9 nel dettaglio pi\u00f9 avanti. Ma per ora creiamole semplicemente:<\/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
    \nPoi, con il comando tkn CLI, verifichiamo che le attivit\u00e0 siano state create:<\/p>\n
    $ tkn task ls\n\nNOME                ET\u00c0\napply-manifests     1 minuto fa\nupdate-deployment   1 minuto fa\n<\/code><\/pre>\n
    \nNota: queste sono attivit\u00e0 locali del tuo progetto attuale.<\/i><\/p>\n
    Attivit\u00e0 cluster Cluster tasks<\/h4>\n
    \nI task cluster sono fondamentalmente la stessa cosa delle semplici attivit\u00e0. Cio\u00e8, si tratta di una collezione riutilizzabile di passaggi che vengono combinati in un modo o nell'altro quando si avvia un'attivit\u00e0 specifica. La differenza \u00e8 che i task cluster sono accessibili ovunque all'interno del cluster. Per vedere l'elenco dei task cluster che vengono creati automaticamente quando si aggiunge un Pipeline Operator, utilizziamo di nuovo il comando tkn CLI:<\/p>\n
    $ tkn clustertask ls\n\nNOME                        ET\u00c0\nbuildah                     1 giorno fa\nbuildah-v0-10-0             1 giorno fa\njib-maven                   1 giorno fa\nkn                          1 giorno fa\nmaven                       1 giorno fa\nopenshift-client            1 giorno fa\nopenshift-client-v0-10-0    1 giorno fa\ns2i                         1 giorno fa\ns2i-go                      1 giorno fa\ns2i-go-v0-10-0              1 giorno fa\ns2i-java-11                 1 giorno fa\ns2i-java-11-v0-10-0         1 giorno fa\ns2i-java-8                  1 giorno fa\ns2i-java-8-v0-10-0          1 giorno fa\ns2i-nodejs                  1 giorno fa\ns2i-nodejs-v0-10-0          1 giorno fa\ns2i-perl                    1 giorno fa\ns2i-perl-v0-10-0            1 giorno fa\ns2i-php                     1 giorno fa\ns2i-php-v0-10-0             1 giorno fa\ns2i-python-3                1 giorno fa\ns2i-python-3-v0-10-0        1 giorno fa\ns2i-ruby                    1 giorno fa\ns2i-ruby-v0-10-0            1 giorno fa\ns2i-v0-10-0                 1 giorno fa\n<\/code><\/pre>\n
    \nOra creiamo due task di cluster. Il primo generer\u00e0 un'immagine S2I e la invier\u00e0 al registro interno di OpenShift; il secondo eseguir\u00e0 la build della nostra immagine basata su NGINX, utilizzando come contenuto l'applicazione gi\u00e0 costruita.<\/p>\n
    Creiamo e inviamo l'immagine<\/h4>\n
    \nCreando la prima task, ripeteremo ci\u00f2 che abbiamo gi\u00e0 fatto nell'articolo precedente sulle build collegate. Ricordiamo che abbiamo utilizzato l'immagine S2I (ubi8-s2i-web-app) per \"costruire\" la nostra applicazione, e alla fine abbiamo ottenuto un'immagine archiviata nel registro interno di OpenShift. Ora utilizzeremo questa immagine S2I dell'applicazione web per creare un DockerFile per la nostra applicazione, e poi impiegheremo Buildah per effettuare la reale build e inviare l'immagine risultante al registro interno di OpenShift, poich\u00e9 \u00e8 esattamente ci\u00f2 che OpenShift fa quando distribuite le vostre applicazioni tramite NodeShift.<\/p>\n
    Vi state chiedendo da dove abbiamo avuto tutte queste informazioni? Da \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, l'abbiamo semplicemente copiata e adattata alle nostre esigenze.<\/p>\n
    Bene, ora creiamo la task di 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
    \nNon entreremo nei dettagli, ma ci soffermeremo solo sul parametro OUTPUT_DIR:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: La posizione della directory di output della build\n        default: build\n<\/code><\/pre>\n
    \nPer impostazione predefinita, questo parametro \u00e8 impostato su build, ed \u00e8 qui che React salva i contenuti compilati. Altri framework utilizzano percorsi diversi, ad esempio, in Ember si usa dist. L'output del nostro primo compito di clustering sar\u00e0 un'immagine contenente gli HTML, JavaScript e CSS che abbiamo raccolto.<\/p>\n
    Costruiremo un'immagine basata su NGINX<\/h4>\n
    \nPer quanto riguarda il nostro secondo compito di clustering, questo deve costruire un'immagine basata su NGINX, utilizzando il contenuto dell'applicazione che abbiamo gi\u00e0 compilato. Fondamentalmente, questa \u00e8 la parte del precedente capitolo in cui abbiamo esaminato le build concatenate.<\/p>\n
    Per fare ci\u00f2, esattamente come sopra, creeremo il compito di clustering 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
    \nAnalizzando il codice di questi task cluster, si nota che non viene specificato il repository Git con cui lavoriamo, n\u00e9 i nomi delle immagini che creiamo. Indichiamo solo cosa trasferiamo in Git o un\u2019immagine dove salvare l\u2019immagine finale. \u00c8 per questo motivo che questi task cluster possono essere riutilizzati anche per altri applicativi.<\/p>\n
    E qui passiamo elegantemente al punto successivo\u2026<\/p>\n
    Risorse<\/h4>\n
    \nQuindi, poich\u00e9, come abbiamo appena detto, i task cluster devono essere il pi\u00f9 generali possibile, dobbiamo creare risorse da usare in input (repository Git) e in output (immagini finali). La prima risorsa di cui abbiamo bisogno \u00e8 Git, dove si trova la nostra applicazione, qualcosa del genere:<\/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
    \nQui, il PipelineResource \u00e8 di tipo git. La chiave url nella sezione params indica il repository specifico e imposta il ramo master (opzionale, ma lo scriviamo per completezza).<\/p>\n
    Adesso dobbiamo creare una risorsa per l\u2019immagine in cui verranno salvati i risultati dell'esecuzione del task s2i-web-app, ecco come fare:<\/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
    \nQui, PipelineResource \u00e8 di tipo immagine, e il valore del parametro url indica il registro delle immagini interno di OpenShift, specificamente quello che si trova nello spazio dei nomi webapp-pipeline. Ricorda di modificare questo parametro se utilizzi un altro spazio dei nomi.<\/p>\n
    E infine, l'ultima risorsa di cui avremo bisogno avr\u00e0 anch'essa tipo immagine e sar\u00e0 l'immagine finale di NGINX, che verr\u00e0 poi utilizzata durante il deployment:<\/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
    \nInoltre, nota che questa risorsa salva l'immagine nel registro interno di OpenShift nello spazio dei nomi webapp-pipeline.<\/p>\n
    Per creare tutte queste risorse in una volta, useremo il comando create:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nPuoi verificare che le risorse siano state create in questo modo:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nOra che abbiamo tutti i componenti necessari, costruiamo il pipeline utilizzando il seguente comando:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/pipelines\/build-and-deploy-react.yaml\n<\/code><\/pre>\n
    \nMa prima di eseguire questo comando, esaminiamo questi componenti. Il primo \u00e8 il nome:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nSuccessivamente, nella sezione spec vediamo l'indicazione delle risorse che abbiamo creato in precedenza:<\/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
    \nPoi creiamo i compiti che il nostro pipeline deve eseguire. Prima di tutto, deve eseguire il compito s2i-web-app gi\u00e0 creato:<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nQuesto compito prende i parametri di input (risorsa gir) e di output (risorsa built-web-application-image). Passiamo anche un parametro speciale affinch\u00e9 non verifichi TLS, poich\u00e9 utilizziamo certificati autofirmati:<\/p>\n
    risorse:\n        input:\n          - nome: fonte\n            risorsa: web-application-repo\n        output:\n          - nome: immagine\n            risorsa: built-web-application-image\n      parametri:\n        - nome: TLSVERIFY\n          valore: \"false\"\n<\/code><\/pre>\n
    \nIl compito successivo \u00e8 quasi identico, solo che qui viene chiamato il compito cluster webapp-build-runtime gi\u00e0 creato:<\/p>\n
    name: build-runtime-image\n    taskRef:\n      name: webapp-build-runtime\n      kind: ClusterTask\n<\/code><\/pre>\n
    \nCome nella precedente attivit\u00e0, passiamo la risorsa, ma ora si tratta di un'immagine dell'applicazione web costruita (il risultato della nostra attivit\u00e0 precedente). E come output di nuovo definiamo l'immagine. Poich\u00e9 questa attivit\u00e0 deve essere eseguita dopo la precedente, aggiungiamo il campo runAfter:<\/p>\n
    risorse:\n        input:\n          - nome: immagine\n            risorsa: built-web-application-image\n        output:\n          - nome: immagine\n            risorsa: runtime-web-application-image\n        parametri:\n        - nome: TLSVERIFY\n          valore: \"false\"\n      eseguiDopo:\n        - build-web-application\n<\/code><\/pre>\n
    \nLe due attivit\u00e0 successive sono responsabili dell'applicazione dei file YAML del servizio, del percorso e del deployment, che si trovano nella directory k8s della nostra applicazione web, e di aggiornare questo deployment quando vengono creati nuovi immagini. Queste due attivit\u00e0 del cluster sono state definite all'inizio dell'articolo.<\/p>\n
    Avvio del pipeline<\/h4>\n
    \nQuindi, tutte le parti del nostro pipeline sono state create, e lo avvieremo con il seguente comando:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nA questo punto, la riga di comando viene utilizzata in modalit\u00e0 interattiva e bisogna selezionare le risorse appropriate in risposta a ciascuna delle sue richieste: per la risorsa git scegliamo web-application-repo, poi per la prima risorsa dell'immagine \u2013 built-web-application-image, e infine per la seconda risorsa dell'immagine \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
    \nOra verificheremo lo stato della pipeline utilizzando il seguente comando:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nDopo che la pipeline \u00e8 stata avviata e l'applicazione \u00e8 stata distribuita, richiederemo il percorso pubblicato con il seguente comando:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nPer maggiore chiarezza, possiamo visualizzare la nostra pipeline in modalit\u00e0 Developer nella console web nella sezione Pipeline<\/b>, come mostrato nella Fig. 1.<\/p>\n
    \"App<\/p>\n
    Fig. 1. Panoramica delle pipeline in esecuzione.<\/i><\/p>\n
    Cliccando sulla pipeline in esecuzione, verranno visualizzati ulteriori dettagli, come mostrato nella Fig. 2.<\/p>\n
    \"App<\/p>\n
    Fig. 2. Ulteriori dettagli sulla pipeline.<\/i><\/p>\n
    Dopo ulteriori dettagli, possiamo visualizzare le applicazioni in esecuzione nella vista Topology<\/b>, come mostrato nella Fig. 3.<\/p>\n
    \"App<\/p>\n
    Fig. 3. Pod in esecuzione.<\/i><\/p>\n
    Cliccando sulla pallina nell'angolo in alto a destra dell'icona si apre la nostra applicazione, come mostrato nella Fig. 4.<\/p>\n
    \"App<\/p>\n
    Fig. 4. Applicazione React in esecuzione.<\/i><\/p>\n
    Conclusione<\/h3>\n
    \nQuindi, abbiamo dimostrato come avviare un server di sviluppo OpenShift per la propria applicazione e sincronizzarlo con il file system locale. Abbiamo anche esaminato come simulare un template chained-build utilizzando OpenShift Pipelines. Tutti i codici degli esempi di questo articolo possono essere trovati qui<\/a><\/noindex>.<\/p>\n
    Risorse aggiuntive (EN)<\/h3>\n
    <\/p>\n