{"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\/es\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Aplicaciones modernas en OpenShift, parte 3: OpenShift como entorno de desarrollo y pipelines de OpenShift Pipelines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola a todos en este blog! Este es el tercer post de una serie en la que mostramos c\u00f3mo desplegar aplicaciones web modernas en Red Hat OpenShift.<\/p>\n

\"Aplicaciones
\n
\nEn las dos publicaciones anteriores, hablamos sobre c\u00f3mo desplegar aplicaciones web modernas en solo unos pocos pasos y c\u00f3mo usar una nueva imagen S2I junto con una imagen de servidor HTTP lista, como NGINX, con la ayuda de builds enlazados para organizar el despliegue de producci\u00f3n.<\/p>\n

Hoy mostraremos c\u00f3mo ejecutar un servidor de desarrollo para su aplicaci\u00f3n en la plataforma OpenShift y sincronizarlo con el sistema de archivos local, adem\u00e1s de hablar sobre qu\u00e9 son las OpenShift Pipelines y c\u00f3mo se pueden utilizar como alternativa a los builds enlazados.
\n<\/a><\/noindex><\/p>\n

OpenShift como entorno de desarrollo<\/h3>\n

<\/p>\n

Flujo de trabajo de desarrollo (development workflow)<\/h4>\n

\nComo se mencion\u00f3 en el primer post<\/a><\/noindex>, el proceso t\u00edpico de desarrollo para aplicaciones web modernas es simplemente un \"servidor de desarrollo\" que monitorea cambios en los archivos locales. Cuando ocurren, se inicia la construcci\u00f3n de la aplicaci\u00f3n y luego se actualiza en el navegador.<\/p>\n

En la mayor\u00eda de los frameworks modernos, dicho \"servidor de desarrollo\" est\u00e1 integrado en las herramientas de l\u00ednea de comandos correspondientes.<\/p>\n

Ejemplo local<\/h4>\n

\nPrimero, veamos c\u00f3mo funciona esto en el caso de ejecutar aplicaciones localmente. Tomemos como ejemplo la aplicaci\u00f3n React<\/a><\/noindex> de los art\u00edculos anteriores, aunque pr\u00e1cticamente las mismas conceptos del flujo de trabajo se aplican en todos los dem\u00e1s frameworks modernos.
\nAs\u00ed que, para iniciar el \"servidor de desarrollo\" en nuestro ejemplo con React, ingresamos el siguiente comando:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nEntonces, en la ventana de la terminal ver\u00edamos algo como esto:<\/p>\n
\"Aplicaciones<\/p>\n
Y nuestra aplicaci\u00f3n se abrir\u00e1 en el navegador por defecto:<\/p>\n
\"Aplicaciones<\/p>\n
Ahora, si hacemos cambios en el archivo, la aplicaci\u00f3n deber\u00eda actualizarse en el navegador.<\/p>\n
Bien, con el desarrollo en modo local todo est\u00e1 claro, \u00bfy c\u00f3mo conseguimos lo mismo en OpenShift?<\/p>\n
Servidor de desarrollo en OpenShift<\/h4>\n
\nSi recuerdas, en en la publicaci\u00f3n anterior<\/a><\/noindex>, revisamos la llamada fase de ejecuci\u00f3n (run phase) de la imagen S2I y vimos que por defecto el m\u00f3dulo serve se encarga de manejar nuestra aplicaci\u00f3n web.<\/p>\n
Sin embargo, si miramos m\u00e1s de cerca run script<\/a><\/noindex> de ese ejemplo, hay una variable de entorno $NPM_RUN que permite ejecutar su propio comando.<\/p>\n
Por ejemplo, se puede usar el m\u00f3dulo nodeshift para desplegar nuestra aplicaci\u00f3n:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN=\"yarn start\" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nNota: el ejemplo anterior se presenta de manera condensada para ilustrar la idea general.<\/i><\/p>\n
Aqu\u00ed hemos agregado a nuestro despliegue la variable de entorno NPM_RUN, que le indica al paso de ejecuci\u00f3n que debe ejecutar el comando yarn start, que inicia el servidor de desarrollo de React dentro de nuestro pod de OpenShift.<\/p>\n
Si miramos el registro del pod en funcionamiento, deber\u00eda verse algo as\u00ed:<\/p>\n
\"Aplicaciones<\/p>\n
Por supuesto, todo esto no tendr\u00e1 sentido hasta que podamos sincronizar el c\u00f3digo local con el c\u00f3digo que tambi\u00e9n se controla en cuanto a cambios, pero que reside en un servidor remoto.<\/p>\n
Sincronizaci\u00f3n de c\u00f3digo remoto y local<\/h4>\n
\nAfortunadamente, nodeshift facilita la sincronizaci\u00f3n, y para rastrear cambios se puede utilizar el comando watch.<\/p>\n
As\u00ed que despu\u00e9s de ejecutar el comando para desplegar el servidor de desarrollo para nuestra aplicaci\u00f3n, podemos usar el siguiente comando:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nComo resultado, se conectar\u00e1 al pod en ejecuci\u00f3n que creamos un poco antes, se activar\u00e1 la sincronizaci\u00f3n de nuestros archivos locales con el cl\u00faster remoto, y los archivos en nuestro sistema local comenzar\u00e1n a ser monitoreados en busca de cambios.<\/p>\n
Por lo tanto, si ahora actualizamos el archivo src\/App.js, el sistema reaccionar\u00e1 ante esos cambios, los copiar\u00e1 en el cl\u00faster remoto y ejecutar\u00e1 el servidor de desarrollo, que luego actualizar\u00e1 nuestra aplicaci\u00f3n en el navegador.<\/p>\n
Para completar la imagen, mostraremos c\u00f3mo lucen estos comandos en su totalidad:<\/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
\nEl comando watch es una abstracci\u00f3n sobre el comando oc rsync, para obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo funciona, puedes consultar. aqu\u00ed<\/a><\/noindex>.<\/p>\n
Este fue un ejemplo para React, pero el mismo m\u00e9todo se puede utilizar con otros frameworks, solo debes definir la variable de entorno NPM_RUN de la manera adecuada.
\n\u2003<\/p>\n
Pipelines de OpenShift<\/h3>\n
\"Aplicaciones<\/p>\n
A continuaci\u00f3n, hablaremos sobre la herramienta conocida como OpenShift Pipelines y c\u00f3mo se puede utilizar como una alternativa a las compilaciones encadenadas.<\/p>\n
\u00bfQu\u00e9 son los OpenShift Pipelines?<\/h4>\n
\nOpenShift Pipelines es un sistema de CI\/CD orientado a la nube, dise\u00f1ado para organizar tuber\u00edas utilizando Tekton. Tekton es un marco de CI\/CD nativo de Kubernetes, flexible y de c\u00f3digo abierto, que permite automatizar el despliegue en diversas plataformas (Kubernetes, serverless, m\u00e1quinas virtuales, etc.) al abstraer el nivel subyacente.<\/p>\n
Para entender este art\u00edculo, se necesitan ciertos conocimientos sobre Pipelines, por lo que recomendamos encarecidamente que primero revises la documentaci\u00f3n oficial<\/a><\/noindex>.<\/p>\n
Configuraci\u00f3n del entorno de trabajo<\/h4>\n
\nPara experimentar con los ejemplos de este art\u00edculo, primero debes preparar el entorno de trabajo:<\/p>\n
    \n
  1. Instalar y configurar un cl\u00faster OpenShift 4. En nuestros ejemplos, utilizamos CodeReady Containers (CRD), cuyas instrucciones de instalaci\u00f3n puedes encontrar aqu\u00ed<\/a><\/noindex>.<\/li>\n
  2. Una vez que el cl\u00faster est\u00e9 listo, debes instalar el Operator de Pipeline. No te preocupes, es f\u00e1cil, las instrucciones para la instalaci\u00f3n aqu\u00ed<\/a><\/noindex>.<\/li>\n
  3. Descargar Tekton CLI<\/a><\/noindex> (tkn) aqu\u00ed<\/a><\/noindex>.<\/li>\n
  4. Ejecutar la herramienta de l\u00ednea de comandos create-react-app para crear una aplicaci\u00f3n que luego ser\u00e1 desplegada (es una aplicaci\u00f3n simple React<\/a><\/noindex>).<\/li>\n
  5. (Opcional) Clonar el repositorio para ejecutar localmente el ejemplo de la aplicaci\u00f3n con el comando npm install y luego npm start.<\/li>\n<\/ol>\n
    \nEn el repositorio de la aplicaci\u00f3n tambi\u00e9n habr\u00e1 una carpeta k8s, donde estar\u00e1n los YAML de Kubernetes\/OpenShift utilizados para desplegar la aplicaci\u00f3n. All\u00ed habr\u00e1 Tasks, ClusterTasks, Resources y Pipelines que crearemos en este el repositorio<\/a><\/noindex>.<\/p>\n
    Comencemos<\/h4>\n
    \nLo primero que necesitamos hacer para nuestro ejemplo es crear un nuevo proyecto en el cl\u00faster de OpenShift. Llamaremos a este proyecto webapp-pipeline y lo crearemos con el siguiente comando:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nA partir de aqu\u00ed, este nombre de proyecto se utilizar\u00e1 en el c\u00f3digo, as\u00ed que si decides nombrarlo de otra manera, no olvides ajustar el c\u00f3digo de los ejemplos en consecuencia. Desde este punto, procederemos de abajo hacia arriba: es decir, primero crearemos todos los componentes de la tuber\u00eda, y luego la propia tuber\u00eda.<\/p>\n
    As\u00ed que, lo primero es...<\/p>\n
    Tareas Tasks<\/h4>\n
    \nCrearemos un par de tareas (tasks) que luego ayudar\u00e1n a desplegar la aplicaci\u00f3n dentro de nuestro pipeline. La primera tarea, apply_manifests_task, se encarga de aplicar los recursos YAML de Kubernetes (service, deployment y route) que se encuentran en la carpeta k8s de nuestra aplicaci\u00f3n. La segunda tarea, update_deployment_task, se encarga de actualizar la imagen ya desplegada a la que se crea en nuestro pipeline.<\/p>\n
    No te preocupes si a\u00fan no est\u00e1 muy claro. En realidad, estas tareas son algo as\u00ed como utilidades, y las exploraremos m\u00e1s en detalle un poco m\u00e1s adelante. Por ahora, simplemente las crearemos:<\/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
    \nLuego, usaremos el comando tkn CLI para verificar que se hayan creado las tareas:<\/p>\n
    $ tkn task ls\n\nNAME                AGE\napply-manifests     1 minute ago\nupdate-deployment   1 minute ago\n<\/code><\/pre>\n
    \nNota: estas son tareas locales de tu proyecto actual.<\/i><\/p>\n
    Tareas de cl\u00faster Cluster tasks<\/h4>\n
    \nLas tareas de cl\u00faster son, en general, lo mismo que las tareas normales. Es decir, son una colecci\u00f3n reutilizable de pasos que se combinan de diversas maneras al ejecutar una tarea espec\u00edfica. La diferencia es que las tareas de cl\u00faster est\u00e1n disponibles en todo el cl\u00faster. Para ver la lista de tareas de cl\u00faster que se crean autom\u00e1ticamente al agregar el Pipeline Operator, nuevamente usaremos el 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
    \nAhora crearemos dos tareas de cl\u00faster. La primera generar\u00e1 una imagen S2I y la enviar\u00e1 al registro interno de OpenShift; la segunda construir\u00e1 nuestra imagen basada en NGINX, utilizando como contenido la aplicaci\u00f3n que ya hemos compilado.<\/p>\n
    Creamos y enviamos la imagen<\/h4>\n
    \nAl crear la primera tarea, repetiremos lo que ya hicimos en el art\u00edculo anterior sobre construcciones relacionadas. Recordemos que usamos la imagen S2I (ubi8-s2i-web-app) para \"compilar\" nuestra aplicaci\u00f3n, y al final obtuvimos una imagen almacenada en el registro interno de OpenShift. Ahora utilizaremos esta imagen S2I de la aplicaci\u00f3n web para crear un DockerFile para nuestra aplicaci\u00f3n, y luego emplearemos Buildah para realizar la construcci\u00f3n real y enviar la imagen resultante al registro interno de OpenShift, ya que esto es exactamente lo que hace OpenShift cuando despliega sus aplicaciones usando NodeShift.<\/p>\n
    \u00bfSe preguntan de d\u00f3nde sacamos todo esto? De \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, solo la copiamos y la ajustamos a nuestras necesidades.<\/p>\n
    Entonces, ahora creamos la tarea de cl\u00faster 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
    \nNo vamos a revisar esto en detalle, solo nos detendremos en el par\u00e1metro OUTPUT_DIR:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: La ubicaci\u00f3n del directorio de salida de la construcci\u00f3n\n        default: build\n<\/code><\/pre>\n
    \nPor defecto, este par\u00e1metro es igual a build, exactamente donde React coloca el contenido construido. En otros frameworks se utilizan otras rutas, por ejemplo, en Ember es dist. La salida de nuestra primera tarea de cl\u00faster ser\u00e1 una imagen que contiene el HTML, JavaScript y CSS que hemos construido.<\/p>\n
    Construyendo la imagen basada en NGINX<\/h4>\n
    \nEn cuanto a nuestra segunda tarea de cl\u00faster, debe construir una imagen basada en NGINX, utilizando el contenido de la aplicaci\u00f3n que ya hemos construido. De hecho, esta es la parte del segmento anterior donde tratamos las construcciones encadenadas.<\/p>\n
    Para esto, \u2013exactamente como antes\u2013 crearemos la tarea de cl\u00faster 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 vemos el c\u00f3digo de estas tareas de cl\u00faster, podemos notar que no se especifica el repositorio Git con el que estamos trabajando, ni los nombres de las im\u00e1genes que estamos creando. Solo establecemos qu\u00e9 es lo que estamos pasando a Git, o alguna imagen que necesita recibir la imagen final. Por eso, estas tareas de cl\u00faster se pueden reutilizar al trabajar con otras aplicaciones.<\/p>\n
    Y aqu\u00ed pasamos elegantemente al siguiente punto\u2026<\/p>\n
    Recursos<\/h4>\n
    \nEntonces, como acabamos de decir, las tareas en cl\u00faster deben ser lo m\u00e1s generales posible, necesitamos crear recursos que se utilizar\u00e1n como entrada (repositorio Git) y salida (im\u00e1genes finales). El primer recurso que necesitamos es Git, donde se encuentra nuestra aplicaci\u00f3n, algo as\u00ed como esto:<\/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
    \nAqu\u00ed, PipelineResource tiene el tipo git. La clave url en la secci\u00f3n params indica el repositorio espec\u00edfico y establece la rama master (esto es opcional, pero lo escribimos para que sea completo).<\/p>\n
    Ahora necesitamos crear un recurso para la imagen, donde se guardar\u00e1n los resultados de la tarea s2i-web-app, esto se hace as\u00ed:<\/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
    \nAqu\u00ed, PipelineResource tiene el tipo imagen, y el valor del par\u00e1metro url indica el Registro de Im\u00e1genes interno de OpenShift, espec\u00edficamente el que se encuentra en el espacio de nombres webapp-pipeline. No olvides cambiar este par\u00e1metro si usas otro espacio de nombres.<\/p>\n
    Y, por \u00faltimo, el \u00faltimo recurso que necesitaremos tambi\u00e9n tendr\u00e1 el tipo imagen y ser\u00e1 la imagen final de NGINX, que luego se utilizar\u00e1 en el despliegue:<\/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
    \nY de nuevo, tenga en cuenta que este recurso guarda la imagen en el registro interno de OpenShift en el espacio de nombres webapp-pipeline.<\/p>\n
    Para crear estos recursos de una vez, usaremos el comando create:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nPuedes asegurarte de que los recursos se han creado as\u00ed:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nAhora que tenemos todos los componentes necesarios, vamos a ensamblar el pipeline, cre\u00e1ndolo con el siguiente 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
    \nPero, antes de ejecutar este comando, analicemos estos componentes. Primero, este es el nombre:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nLuego, en la secci\u00f3n spec, vemos la declaraci\u00f3n de los recursos que creamos anteriormente:<\/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
    \nLuego creamos las tareas que debe realizar nuestro pipeline. Primero debe ejecutar la tarea s2i-web-app que ya hemos creado:<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nEsta tarea toma los par\u00e1metros de entrada (recurso git) y salida (recurso built-web-application-image). Tambi\u00e9n le pasamos un par\u00e1metro especial para que no verifique TLS, ya que usamos certificados autofirmados:<\/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
    \nLa siguiente tarea es casi la misma, solo que aqu\u00ed se llama a la tarea de cl\u00faster que ya hemos creado: webapp-build-runtime:<\/p>\n
    nombre: imagen-runtime-de-construcci\u00f3n\n    referenciaTarea:\n      nombre: webapp-build-runtime\n      tipo: TareaDeCl\u00faster\n<\/code><\/pre>\n
    \nAl igual que con la tarea anterior, pasamos el recurso, pero ahora es la imagen-de-aplicaci\u00f3n-web-construida (la salida de nuestra tarea anterior). Y como salida, nuevamente definimos la imagen. Dado que esta tarea debe ejecutarse despu\u00e9s de la anterior, agregamos el 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
    \nLas siguientes dos tareas son responsables de aplicar los archivos YAML del servicio, la ruta y el despliegue, que residen en el directorio k8s de nuestra aplicaci\u00f3n web, as\u00ed como de actualizar este despliegue al crear nuevas im\u00e1genes. Estas dos tareas de cl\u00faster las definimos al principio del art\u00edculo.<\/p>\n
    Ejecutar el canal<\/h4>\n
    \nAs\u00ed que todas las partes de nuestro pipeline est\u00e1n creadas, y lo ejecutaremos con el siguiente comando:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nEn esta etapa, se utiliza la l\u00ednea de comandos en modo interactivo y hay que seleccionar los recursos adecuados en respuesta a cada solicitud: para el recurso git seleccionamos repositorio-de-aplicaciones-web, luego para el recurso de la primera imagen \u2013 imagen-de-aplicaci\u00f3n-web-construida, y finalmente, para el recurso de la segunda imagen \u2013 imagen-runtime-de-aplicaci\u00f3n-web:<\/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
    \nAhora verifiquemos el estado del pipeline con el siguiente comando:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nUna vez que el pipeline se inicie y la aplicaci\u00f3n est\u00e9 desplegada, solicitaremos la ruta publicada con el siguiente comando:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nPara una mejor visualizaci\u00f3n, podemos ver nuestro pipeline en el modo Desarrollador de la consola web en la secci\u00f3n Pipelines.<\/b>, como se muestra en la Fig. 1.<\/p>\n
    \"Aplicaciones<\/p>\n
    Fig.1. Visi\u00f3n general de los pipelines en ejecuci\u00f3n.<\/i><\/p>\n
    Hacer clic en el pipeline en ejecuci\u00f3n muestra informaci\u00f3n adicional, como se muestra en la Fig.2.<\/p>\n
    \"Aplicaciones<\/p>\n
    Fig. 2. Informaci\u00f3n adicional sobre el pipeline.<\/i><\/p>\n
    Despu\u00e9s de la informaci\u00f3n adicional, se pueden ver las aplicaciones en ejecuci\u00f3n en la vista Topolog\u00eda<\/b>, como se muestra en la Fig.3.<\/p>\n
    \"Aplicaciones<\/p>\n
    Fig 3. Pod en ejecuci\u00f3n.<\/i><\/p>\n
    Hacer clic en el c\u00edrculo en la esquina superior derecha del \u00edcono abre nuestra aplicaci\u00f3n, como se muestra en la Fig.4.<\/p>\n
    \"Aplicaciones<\/p>\n
    Fig. 4. Aplicaci\u00f3n React en ejecuci\u00f3n.<\/i><\/p>\n
    Conclusi\u00f3n<\/h3>\n
    \nAs\u00ed que hemos mostrado c\u00f3mo iniciar un servidor de desarrollo en OpenShift para su aplicaci\u00f3n y sincronizarlo con el sistema de archivos local. Tambi\u00e9n hemos explorado c\u00f3mo simular una plantilla de construcci\u00f3n encadenada utilizando OpenShift Pipelines. Todo el c\u00f3digo de los ejemplos de este art\u00edculo se puede encontrar aqu\u00ed<\/a><\/noindex>.<\/p>\n
    Recursos adicionales (EN)<\/h3>\n
    <\/p>\n