{"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":"Applicazioni moderne su OpenShift, parte 3: OpenShift come ambiente di sviluppo e pipeline 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 in cui mostriamo come distribuire applicazioni web moderne su Red Hat OpenShift.<\/p>\n

\"Applicazioni
\n
\nNei due post precedenti, abbiamo illustrato come distribuire applicazioni web moderne in pochi passaggi e come usare la nuova immagine S2I insieme a un'immagine di server HTTP predefinita, come NGINX, utilizzando build collegate (chained builds) per organizzare distribuzioni in produzione.<\/p>\n

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

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

<\/p>\n

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

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

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

Esempio locale<\/h4>\n

\nPer iniziare, vediamo come funziona nel caso di un'esecuzione locale delle applicazioni. Prendiamo come esempio l'applicazione React<\/a><\/noindex> tratta nei precedenti articoli, anche se praticamente gli stessi concetti di flusso di lavoro si applicano in tutti gli altri moderni framework.
\nDunque, 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 del genere:<\/p>\n
\"Applicazioni<\/p>\n
E la nostra applicazione si aprir\u00e0 nel browser predefinito:<\/p>\n
\"Applicazioni<\/p>\n
Ora, se apportiamo modifiche al file, l'applicazione dovrebbe aggiornarsi nel browser.<\/p>\n
OK, con lo sviluppo in modalit\u00e0 locale \u00e8 tutto chiaro, ma come ottenere lo stesso su OpenShift?<\/p>\n
Server di sviluppo su OpenShift<\/h4>\n
\nSe ricordate, nel post precedente<\/a><\/noindex>, abbiamo esaminato la cosiddetta fase di esecuzione (run phase) dell'immagine S2I e abbiamo visto che per impostazione predefinita la nostra applicazione web \u00e8 gestita dal modulo serve.<\/p>\n
Tuttavia, se guardiamo pi\u00f9 da vicino run script<\/a><\/noindex> Da quell'esempio, c'\u00e8 una variabile di ambiente $NPM_RUN che consente di eseguire anche il proprio comando.<\/p>\n
Ad esempio, \u00e8 possibile 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 fornito in forma abbreviata per illustrare l'idea generale.<\/i><\/p>\n
Qui abbiamo aggiunto alla nostra distribuzione la variabile di ambiente NPM_RUN, che comunica al processo di esecuzione di avviare il comando yarn start, il quale avvia il server di sviluppo React all'interno del nostro pod OpenShift.<\/p>\n
Se esaminiamo il log del pod in esecuzione, troveremo circa il seguente output:<\/p>\n
\"Applicazioni<\/p>\n
Certo, tutto ci\u00f2 non avr\u00e0 senso fino a quando non saremo in grado di sincronizzare il codice locale con il codice che viene anch'esso monitorato per le modifiche, ma si trova su un server remoto.<\/p>\n
Sincronizzazione del codice remoto e locale<\/h4>\n
\nFortunatamente, nodeshift facilita la sincronizzazione, e per monitorare le modifiche possiamo utilizzare il comando watch.<\/p>\n
Quindi, dopo aver eseguito il comando per distribuire il server di sviluppo per la nostra applicazione, possiamo tranquillamente usare il seguente comando:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nDi conseguenza, verr\u00e0 stabilita una connessione al pod in esecuzione che abbiamo creato poco prima, attivando la sincronizzazione dei nostri file locali con il cluster remoto, e i file nel nostro sistema locale inizieranno a essere monitorati per le modifiche.<\/p>\n
Quindi, se ora aggiorniamo il file src\/App.js, il sistema reagir\u00e0 a queste modifiche, copier\u00e0 le modifiche sul cluster remoto e avvier\u00e0 il server di sviluppo, il quale aggiorner\u00e0 quindi la nostra applicazione nel browser.<\/p>\n
Per completezza, mostriamo 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, per maggiori informazioni su come funziona, si pu\u00f2 leggere qui<\/a><\/noindex>.<\/p>\n
Questo \u00e8 stato un esempio per React, ma la stessa metodologia pu\u00f2 essere utilizzata anche con altri framework, basta impostare la variabile di ambiente NPM_RUN nel modo corretto.
\n\u2003<\/p>\n
Pipeline di OpenShift Pipelines<\/h3>\n
\"Applicazioni<\/p>\n
Successivamente parleremo di uno strumento chiamato OpenShift Pipelines e di come pu\u00f2 essere utilizzato come alternativa alle build concatenate.<\/p>\n
Che cos'\u00e8 OpenShift Pipelines<\/h4>\n
\nOpenShift Pipelines \u00e8 un sistema CI\/CD basato sul cloud per l'integrazione continua e la consegna, progettato per organizzare pipeline utilizzando Tekton. Tekton \u00e8 un framework CI\/CD nativo Kubernetes flessibile e open source, che consente di automatizzare il deployment su varie piattaforme (Kubernetes, serverless, macchine virtuali, ecc.) astrarre rispetto al livello sottostante.<\/p>\n
Per capire questo articolo \u00e8 necessaria una certa familiarit\u00e0 con i Pipelines, quindi ti consigliamo vivamente di iniziare consultando il manuale ufficiale<\/a><\/noindex>.<\/p>\n
Configurazione dell'ambiente di lavoro<\/h4>\n
\nPer sperimentare con gli esempi di questo articolo, devi prima preparare l'ambiente di lavoro:<\/p>\n
    \n
  1. Installa e configura un cluster OpenShift 4. Nei nostri esempi utilizziamo CodeReady Containers (CRD), le istruzioni per l'installazione possono essere trovate qui<\/a><\/noindex>.<\/li>\n
  2. Una volta che il cluster \u00e8 pronto, sar\u00e0 necessario installare il Pipeline Operator. Non preoccuparti, \u00e8 facile, le istruzioni per l'installazione qui<\/a><\/noindex>.<\/li>\n
  3. Scarica 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 verr\u00e0 poi distribuita (si tratta di un'app semplice React<\/a><\/noindex>).<\/li>\n
  5. (Facoltativo) Clona il repository per eseguire localmente l'esempio dell'app con 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 utilizzati per il deployment dell'applicazione. Ci saranno Tasks, ClusterTasks, Resources e Pipelines che creeremo in questo repository<\/a><\/noindex>.<\/p>\n
    Iniziamo<\/h4>\n
    \nPer prima cosa, per il nostro esempio, \u00e8 necessario creare un nuovo progetto nel cluster OpenShift. Chiamiamo questo progetto webapp-pipeline e lo creiamo con il seguente comando:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nIn seguito questo nome del progetto apparir\u00e0 nel codice, quindi, se decidi di dargli un nome diverso, non dimenticare di modificare di conseguenza il codice degli esempi. Da questo punto in poi procederemo dal basso verso l'alto: prima creeremo tutti i componenti della pipeline e solo successivamente la pipeline stessa.<\/p>\n
    Quindi, prima di tutto\u2026<\/p>\n
    Tasks<\/h4>\n
    \nCreeremo un paio di attivit\u00e0 (tasks) che poi aiuteranno a implementare l'applicazione nel nostro pipeline. La prima attivit\u00e0 \u2013 apply_manifests_task \u2013 si occupa dell'applicazione dei YAML dei risorse Kubernetes (service, deployment e route) che si trovano nella cartella k8s della nostra applicazione. La seconda attivit\u00e0 \u2013 update_deployment_task \u2013 \u00e8 responsabile dell'aggiornamento dell'immagine gi\u00e0 implementata a quella creata dal nostro pipeline.<\/p>\n
    Non preoccuparti se non \u00e8 ancora molto chiaro. In realt\u00e0, queste attivit\u00e0 sono una sorta di utilit\u00e0 e le esamineremo pi\u00f9 in dettaglio tra poco. 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, usando il comando tkn CLI, verifichiamo che le attivit\u00e0 siano state create:<\/p>\n
    $ tkn task ls\n\nNAME                AGE\napply-manifests     1 minute ago\nupdate-deployment   1 minute ago\n<\/code><\/pre>\n
    \nNota: queste sono attivit\u00e0 locali del tuo progetto attuale.<\/i><\/p>\n
    Attivit\u00e0 cluster (Cluster tasks)<\/h4>\n
    \nLe attivit\u00e0 cluster sono fondamentalmente le stesse delle normali attivit\u00e0. Cio\u00e8, sono una collezione riutilizzabile di passaggi che vengono combinati in vari modi quando si esegue una specifica attivit\u00e0. La differenza \u00e8 che un'attivit\u00e0 cluster \u00e8 disponibile ovunque all'interno del cluster. Per vedere l'elenco delle attivit\u00e0 cluster, che vengono create automaticamente quando si aggiunge il Pipeline Operator, utilizziamo di nuovo il comando tkn CLI:<\/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
    \nOra creiamo due attivit\u00e0 cluster. La prima generer\u00e0 un'immagine S2I e la invier\u00e0 al registry interno di OpenShift; la seconda eseguir\u00e0 la costruzione della nostra immagine basata su NGINX, utilizzando come contenuto l'applicazione gi\u00e0 costruita da noi.<\/p>\n
    Creiamo e inviamo l'immagine<\/h4>\n
    \nNella creazione della prima attivit\u00e0, 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 \"compilare\" la nostra applicazione, ottenendo infine un'immagine memorizzata nel registro interno di OpenShift. Ora utilizzeremo questa immagine S2I dell'app web per creare un DockerFile per la nostra applicazione, e quindi utilizzeremo Buildah per eseguire una compilazione reale e inviare l'immagine risultante al registro interno di OpenShift, poich\u00e9 \u00e8 esattamente ci\u00f2 che OpenShift fa quando distribuisci le tue applicazioni utilizzando NodeShift.<\/p>\n
    Ti chiedi da dove abbiamo preso 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 a noi.<\/p>\n
    Ora creiamo l'attivit\u00e0 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 fermeremo 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 uguale a build, ed \u00e8 l\u00ec che React colloca il contenuto compilato. In altri framework si utilizzano percorsi diversi, ad esempio in Ember si usa dist. L'output della nostra prima attivit\u00e0 cluster sar\u00e0 un'immagine contenente l'HTML, il JavaScript e il CSS che abbiamo compilato.<\/p>\n
    Compiliamo un'immagine basata su NGINX<\/h4>\n
    \nPer quanto riguarda la nostra seconda attivit\u00e0 cluster, questa deve costruire un'immagine basata su NGINX, utilizzando il contenuto della nostra applicazione gi\u00e0 compilata. In sostanza, questa \u00e8 la parte della sezione precedente in cui abbiamo esaminato le build collegate.<\/p>\n
    A tal fine, proprio come sopra, creeremo l'attivit\u00e0 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
    \nSe guardiamo il codice di queste attivit\u00e0 cluster, vediamo che non viene specificato il repository Git con cui stiamo lavorando, n\u00e9 i nomi delle immagini che stiamo creando. Stiamo solo specificando cosa vogliamo passare in Git, o un'immagine in cui deve essere prodotto l'immagine finale. \u00c8 per questo che queste attivit\u00e0 cluster possono essere riutilizzate anche quando si lavora con altre applicazioni.<\/p>\n
    E qui passiamo elegantemente al punto successivo\u2026<\/p>\n
    Risorse<\/h4>\n
    \nQuindi, poich\u00e9, come abbiamo appena detto, i task di cluster devono essere il pi\u00f9 generali possibile, dobbiamo creare risorse che saranno utilizzate 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 PipelineResource \u00e8 di tipo git. La chiave url nella sezione params punta a un repository specifico e imposta il branch master (questo \u00e8 facoltativo, ma lo scriviamo per completezza).<\/p>\n
    Ora dobbiamo creare una risorsa per l'immagine, dove saranno salvati i risultati dell'esecuzione del task s2i-web-app, si fa cos\u00ec:<\/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 image, e il valore del parametro url punta al registro delle immagini interno di OpenShift, specificamente a quello che si trova nello spazio dei nomi webapp-pipeline. Non dimenticare di cambiare questo parametro se utilizzi un altro spazio dei nomi.<\/p>\n
    E, infine, l'ultima risorsa di cui avremo bisogno avr\u00e0 anch'essa il tipo image e sar\u00e0 l'immagine finale di NGINX, che verr\u00e0 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
    \nE ancora, 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, utilizziamo 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 controllare che le risorse siano state create in questo modo:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline del pipeline<\/h4>\n
    \nOra che abbiamo tutti gli elementi necessari, creiamo 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, diamo un'occhiata a questi elementi. Il primo \u00e8 il nome:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nPoi, 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
    \nSuccessivamente, creiamo i task che il nostro pipeline deve eseguire. Per prima cosa deve eseguire il task s2i-web-app che abbiamo 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 task prende i parametri di input (risorsa gir) e di output (risorsa built-web-application-image). Inoltre, le passiamo un parametro speciale per evitare la verifica di TLS, poich\u00e9 utilizziamo certificati self-signed:<\/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
    \nIl prossimo compito \u00e8 quasi identico, solo che qui viene chiamato il compito cluster webapp-build-runtime gi\u00e0 creato da noi:<\/p>\n
    nome: build-runtime-image\n    taskRef:\n      nome: webapp-build-runtime\n      tipo: ClusterTask\n<\/code><\/pre>\n
    \nCome per il compito precedente, stiamo passando una risorsa, ma ora si tratta di built-web-application-image (l'output del nostro compito precedente). E come output impostiamo di nuovo un'immagine. Poich\u00e9 questo compito deve essere eseguito dopo il precedente, aggiungiamo il campo runAfter:<\/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
    \nI prossimi due compiti sono responsabili dell'applicazione dei file YAML del servizio, del percorso e del deployment, che si trovano nella cartella k8s della nostra applicazione web, e anche di aggiornare questo deployment quando vengono creati nuovi modelli. Questi due compiti cluster li abbiamo definiti all'inizio dell'articolo.<\/p>\n
    Avvio della pipeline<\/h4>\n
    \nQuindi, tutte le parti della nostra pipeline sono state create, e la 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 corrispondenti in risposta a ciascuna sua richiesta: per la risorsa git scegliamo web-application-repo, quindi per la risorsa della prima immagine \u2013 built-web-application-image, e infine per la risorsa della seconda 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 controlliamo lo stato della pipeline con 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, richiediamo il percorso pubblicato con il seguente comando:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nPer una maggiore visibilit\u00e0, possiamo visualizzare la nostra pipeline in modalit\u00e0 Developer nella web console nella sezione Pipelines<\/b>, come mostrato nella Fig. 1.<\/p>\n
    \"Applicazioni<\/p>\n
    Fig.1. Panoramica delle pipeline in esecuzione.<\/i><\/p>\n
    Cliccando sulla pipeline in esecuzione si visualizzano ulteriori informazioni, come mostrato nella Fig.2.<\/p>\n
    \"Applicazioni<\/p>\n
    Fig. 2. Ulteriori informazioni sulla pipeline.<\/i><\/p>\n
    Dopo ulteriori informazioni, possiamo visualizzare le applicazioni in esecuzione nella vista Topology<\/b>, come mostrato nella Fig.3.<\/p>\n
    \"Applicazioni<\/p>\n
    Fig 3. Pod in esecuzione.<\/i><\/p>\n
    Cliccando sul cerchio nell'angolo in alto a destra dell'icona si apre la nostra applicazione, come mostrato nella Fig.4.<\/p>\n
    \"Applicazioni<\/p>\n
    Fig. 4. Applicazione React in esecuzione.<\/i><\/p>\n
    Conclusione<\/h3>\n
    \nQuindi, abbiamo mostrato come avviare un server di sviluppo su OpenShift per la propria applicazione e sincronizzarlo con il sistema di file locale. Abbiamo anche esaminato come simulare un modello di chained-build utilizzando OpenShift Pipelines. Tutti i codici di esempio di questo articolo possono essere trovati qui<\/a><\/noindex>.<\/p>\n
    Risorse aggiuntive (EN)<\/h3>\n
    <\/p>\n