{"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\/pt\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Aplicativos modernos no OpenShift, parte 3: OpenShift como ambiente de desenvolvimento e pipelines do OpenShift","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1 a todos neste blog! Este \u00e9 o terceiro post de uma s\u00e9rie onde mostramos como implantar aplica\u00e7\u00f5es web modernas no Red Hat OpenShift.<\/p>\n

\"Aplicativos
\n
\nNos dois posts anteriores, falamos sobre como implantar aplica\u00e7\u00f5es web modernas em apenas alguns passos e como utilizar a nova imagem S2I junto com uma imagem pronta de servidor HTTP, como o NGINX, com a ajuda de builds encadeados (chained builds) para organizar a implanta\u00e7\u00e3o em produ\u00e7\u00e3o.<\/p>\n

Hoje, mostraremos como iniciar na plataforma OpenShift um servidor de desenvolvimento para sua aplica\u00e7\u00e3o e sincroniz\u00e1-lo com o sistema de arquivos local, al\u00e9m de discutir o que s\u00e3o os OpenShift Pipelines e como podem ser aplicados como uma alternativa aos builds encadeados.
\n<\/a><\/noindex><\/p>\n

OpenShift como ambiente de desenvolvimento<\/h3>\n

<\/p>\n

Fluxo de trabalho de desenvolvimento<\/h4>\n

\nComo mencionado no primeiro post<\/a><\/noindex>, o processo t\u00edpico de desenvolvimento para aplica\u00e7\u00f5es web modernas \u00e9 simplesmente um \"servidor de desenvolvimento\" que monitora mudan\u00e7as nos arquivos locais. Quando ocorrem, uma nova build da aplica\u00e7\u00e3o \u00e9 iniciada e, em seguida, ela \u00e9 atualizada no navegador.<\/p>\n

Na maioria dos frameworks modernos, um \"servidor de desenvolvimento\" est\u00e1 embutido nas ferramentas de linha de comando apropriadas.<\/p>\n

Exemplo local<\/h4>\n

\nPara come\u00e7ar, vamos ver como isso funciona no caso de uma execu\u00e7\u00e3o local de aplica\u00e7\u00f5es. Como exemplo, usaremos a aplica\u00e7\u00e3o React<\/a><\/noindex> dos artigos anteriores, embora praticamente os mesmos conceitos de fluxo de trabalho se apliquem a todos os outros frameworks modernos.
\nEnt\u00e3o, para iniciar o \"servidor de desenvolvimento\" em nosso exemplo com React, digitamos o seguinte comando:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nEnt\u00e3o, na janela do terminal, veremos algo como o seguinte:<\/p>\n
\"Aplicativos<\/p>\n
E nossa aplica\u00e7\u00e3o ser\u00e1 aberta no navegador padr\u00e3o:<\/p>\n
\"Aplicativos<\/p>\n
Agora, se fizermos altera\u00e7\u00f5es no arquivo, a aplica\u00e7\u00e3o dever\u00e1 ser atualizada no navegador.<\/p>\n
OK, o desenvolvimento em modo local est\u00e1 claro, mas como obter o mesmo no OpenShift?<\/p>\n
Servidor de desenvolvimento no OpenShift<\/h4>\n
\nSe voc\u00ea se lembra, no post anterior<\/a><\/noindex>, discutimos a fase de execu\u00e7\u00e3o (run phase) da imagem S2I e vimos que, por padr\u00e3o, o m\u00f3dulo serve \u00e9 respons\u00e1vel por atender nossa aplica\u00e7\u00e3o web.<\/p>\n
No entanto, se olharmos mais de perto script run<\/a><\/noindex> No exemplo, h\u00e1 a vari\u00e1vel de ambiente $NPM_RUN, que permite executar seu pr\u00f3prio comando.<\/p>\n
Por exemplo, podemos usar o m\u00f3dulo nodeshift para implantar nosso aplicativo:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN=\"yarn start\" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nNota: o exemplo acima \u00e9 apresentado de forma resumida para ilustrar a ideia geral.<\/i><\/p>\n
Aqui, adicionamos \u00e0 nossa implanta\u00e7\u00e3o a vari\u00e1vel de ambiente NPM_RUN, que informa \u00e0 etapa de execu\u00e7\u00e3o que deve iniciar o comando yarn start, que inicia o servidor de desenvolvimento React dentro do nosso pod no OpenShift.<\/p>\n
Se olharmos os logs do pod em execu\u00e7\u00e3o, veremos algo como:<\/p>\n
\"Aplicativos<\/p>\n
Claro, isso n\u00e3o ter\u00e1 valor at\u00e9 que possamos sincronizar o c\u00f3digo local com o c\u00f3digo que tamb\u00e9m est\u00e1 sob controle de altera\u00e7\u00f5es, mas reside em um servidor remoto.<\/p>\n
Sincroniza\u00e7\u00e3o do c\u00f3digo remoto e local<\/h4>\n
\nFelizmente, a sincroniza\u00e7\u00e3o \u00e9 facilitada pelo nodeshift, e para rastrear altera\u00e7\u00f5es, podemos usar o comando watch.<\/p>\n
Assim, ap\u00f3s executarmos o comando para implantar o servidor de desenvolvimento do nosso aplicativo, podemos usar o seguinte comando:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nComo resultado, ser\u00e1 estabelecida uma conex\u00e3o com o pod em execu\u00e7\u00e3o que criamos anteriormente, a sincroniza\u00e7\u00e3o de nossos arquivos locais com o cluster remoto ser\u00e1 ativada e os arquivos em nosso sistema local come\u00e7ar\u00e3o a ser monitorados quanto a altera\u00e7\u00f5es.<\/p>\n
Portanto, se agora atualizarmos o arquivo src\/App.js, o sistema reagir\u00e1 a essas altera\u00e7\u00f5es, copiar\u00e1 para o cluster remoto e iniciar\u00e1 o servidor de desenvolvimento, que ent\u00e3o atualizar\u00e1 nosso aplicativo no navegador.<\/p>\n
Para completar o quadro, vamos mostrar como esses comandos se parecem na \u00edntegra:<\/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
\nO comando watch \u00e9 uma abstra\u00e7\u00e3o sobre o comando oc rsync; mais detalhes sobre como isso funciona podem ser encontrados. aqui<\/a><\/noindex>.<\/p>\n
Este foi um exemplo para React, mas o mesmo m\u00e9todo pode ser usado com outros frameworks, basta definir a vari\u00e1vel de ambiente NPM_RUN corretamente.
\n\u2003<\/p>\n
Pipelines do OpenShift<\/h3>\n
\"Aplicativos<\/p>\n
A seguir, falaremos sobre uma ferramenta chamada OpenShift Pipelines e como ela pode ser usada como uma alternativa \u00e0s compila\u00e7\u00f5es encadeadas.<\/p>\n
O que s\u00e3o OpenShift Pipelines<\/h4>\n
\nOpenShift Pipelines \u00e9 um sistema de CI\/CD baseado na nuvem, projetado para organizar pipelines utilizando Tekton. Tekton \u00e9 um framework CI\/CD flex\u00edvel, nativo do Kubernetes e de c\u00f3digo aberto, que permite automatizar a implementa\u00e7\u00e3o em v\u00e1rias plataformas (Kubernetes, serverless, m\u00e1quinas virtuais etc.) ao abstrair o n\u00edvel subjacente.<\/p>\n
Para entender este artigo, s\u00e3o necess\u00e1rios alguns conhecimentos sobre Pipelines, portanto, recomendamos fortemente que voc\u00ea comece consultando o manual oficial<\/a><\/noindex>.<\/p>\n
Configurando o ambiente de trabalho<\/h4>\n
\nPara experimentar os exemplos deste artigo, primeiro voc\u00ea precisa preparar o ambiente de trabalho:<\/p>\n
    \n
  1. Instalar e configurar um cluster OpenShift 4. Em nossos exemplos, utilizamos o CodeReady Containers (CRD), cujas instru\u00e7\u00f5es de instala\u00e7\u00e3o podem ser encontradas aqui<\/a><\/noindex>.<\/li>\n
  2. Depois que o cluster estiver pronto, voc\u00ea deve instalar o Pipeline Operator. N\u00e3o se preocupe, \u00e9 f\u00e1cil, as instru\u00e7\u00f5es para instala\u00e7\u00e3o est\u00e3o aqui<\/a><\/noindex>.<\/li>\n
  3. Baixar Tekton CLI<\/a><\/noindex> (tkn) aqui<\/a><\/noindex>.<\/li>\n
  4. Executar a ferramenta de linha de comando create-react-app para criar um aplicativo que ser\u00e1 implantado depois (este \u00e9 um aplicativo simples React<\/a><\/noindex>).<\/li>\n
  5. (Opcional) Clonar o reposit\u00f3rio para executar localmente o exemplo do aplicativo com o comando npm install e, em seguida, npm start.<\/li>\n<\/ol>\n
    \nNo reposit\u00f3rio do aplicativo tamb\u00e9m haver\u00e1 uma pasta k8s, onde estar\u00e3o os YAMLs do Kubernetes\/OpenShift usados para a implanta\u00e7\u00e3o do aplicativo. Haver\u00e1 Tasks, ClusterTasks, Resources e Pipelines que criaremos neste reposit\u00f3rio<\/a><\/noindex>.<\/p>\n
    Vamos come\u00e7ar<\/h4>\n
    \nPrimeiramente, para nosso exemplo, precisamos criar um novo projeto no cluster OpenShift. Vamos chamar este projeto de webapp-pipeline e criar com o seguinte comando:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nA partir de agora, esse nome de projeto aparecer\u00e1 no c\u00f3digo, ent\u00e3o, se voc\u00ea decidir nome\u00e1-lo de forma diferente, n\u00e3o se esque\u00e7a de ajustar o c\u00f3digo dos exemplos apropriadamente. A partir daqui, iremos de baixo para cima: ou seja, primeiro criaremos todos os componentes do pipeline antes de criar o pr\u00f3prio.<\/p>\n
    Ent\u00e3o, primeiro...<\/p>\n
    Tarefas Tasks<\/h4>\n
    \nVamos criar duas tarefas (tasks), que depois ajudar\u00e3o a implantar o aplicativo dentro do nosso pipeline. A primeira tarefa \u2013 apply_manifests_task \u2013 \u00e9 respons\u00e1vel por aplicar os recursos YAML do Kubernetes (service, deployment e route) que est\u00e3o na pasta k8s do nosso aplicativo. A segunda tarefa \u2013 update_deployment_task \u2013 \u00e9 respons\u00e1vel por atualizar a imagem j\u00e1 implantada para a que est\u00e1 sendo criada pelo nosso pipeline.<\/p>\n
    N\u00e3o se preocupe se ainda n\u00e3o estiver muito claro. Na verdade, essas tarefas s\u00e3o como utilit\u00e1rios, e n\u00f3s as exploraremos com mais detalhes mais tarde. Por enquanto, apenas vamos cri\u00e1-las:<\/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
    \nEm seguida, usaremos o comando tkn CLI para verificar se as tarefas foram criadas:<\/p>\n
    $ tkn task ls\n\nNOME                IDADE\napply-manifests     1 minuto atr\u00e1s\nupdate-deployment   1 minuto atr\u00e1s\n<\/code><\/pre>\n
    \nNota: estas s\u00e3o tarefas locais do seu projeto atual.<\/i><\/p>\n
    Tarefas do Cluster<\/h4>\n
    \nTarefas do Cluster s\u00e3o basicamente a mesma coisa que apenas tarefas. Ou seja, \u00e9 uma cole\u00e7\u00e3o reutiliz\u00e1vel de etapas que s\u00e3o combinadas de uma forma ou de outra ao executar uma tarefa espec\u00edfica. A diferen\u00e7a \u00e9 que a tarefa do cluster est\u00e1 dispon\u00edvel em toda a extens\u00e3o do cluster. Para ver a lista de tarefas do cluster que s\u00e3o criadas automaticamente ao adicionar o Pipeline Operator, novamente usaremos o comando tkn CLI:<\/p>\n
    $ tkn clustertask ls\n\nNOME                       IDADE\nbuildah                    1 dia atr\u00e1s\nbuildah-v0-10-0            1 dia atr\u00e1s\njib-maven                  1 dia atr\u00e1s\nkn                         1 dia atr\u00e1s\nmaven                      1 dia atr\u00e1s\nopenshift-client           1 dia atr\u00e1s\nopenshift-client-v0-10-0   1 dia atr\u00e1s\ns2i                        1 dia atr\u00e1s\ns2i-go                     1 dia atr\u00e1s\ns2i-go-v0-10-0             1 dia atr\u00e1s\ns2i-java-11                1 dia atr\u00e1s\ns2i-java-11-v0-10-0        1 dia atr\u00e1s\ns2i-java-8                 1 dia atr\u00e1s\ns2i-java-8-v0-10-0         1 dia atr\u00e1s\ns2i-nodejs                 1 dia atr\u00e1s\ns2i-nodejs-v0-10-0         1 dia atr\u00e1s\ns2i-perl                   1 dia atr\u00e1s\ns2i-perl-v0-10-0           1 dia atr\u00e1s\ns2i-php                    1 dia atr\u00e1s\ns2i-php-v0-10-0            1 dia atr\u00e1s\ns2i-python-3               1 dia atr\u00e1s\ns2i-python-3-v0-10-0       1 dia atr\u00e1s\ns2i-ruby                   1 dia atr\u00e1s\ns2i-ruby-v0-10-0           1 dia atr\u00e1s\ns2i-v0-10-0                1 dia atr\u00e1s\n<\/code><\/pre>\n
    \nAgora vamos criar duas tarefas do cluster. A primeira ir\u00e1 gerar uma imagem S2I e envi\u00e1-la para o registro interno do OpenShift; a segunda ir\u00e1 realizar a compila\u00e7\u00e3o da nossa imagem baseada no NGINX, utilizando como conte\u00fado o aplicativo que j\u00e1 constru\u00edmos.<\/p>\n
    Criando e enviando a imagem<\/h4>\n
    \nAo criar a primeira tarefa, iremos repetir o que j\u00e1 fizemos no artigo anterior sobre builds relacionados. Lembre-se de que utilizamos a imagem S2I (ubi8-s2i-web-app) para 'compilar' nosso aplicativo, e no final obtivemos uma imagem armazenada no registro interno do OpenShift. Agora, usaremos esta imagem S2I do aplicativo web para criar um DockerFile para nosso aplicativo e, em seguida, utilizaremos o Buildah para realizar a constru\u00e7\u00e3o real e enviar a imagem resultante ao registro interno do OpenShift, pois \u00e9 isso que o OpenShift faz ao implantar seus aplicativos com o NodeShift.<\/p>\n
    Pergunta-se de onde sabemos tudo isso? De \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, simplesmente copiamos e ajustamos para nossas necessidades.<\/p>\n
    Ent\u00e3o, vamos criar a tarefa 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
    \nN\u00e3o vamos analisar isso em detalhes, apenas nos deteremos no par\u00e2metro OUTPUT_DIR:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: O local do diret\u00f3rio de sa\u00edda da constru\u00e7\u00e3o\n        default: build\n<\/code><\/pre>\n
    \nPor padr\u00e3o, este par\u00e2metro \u00e9 definido como build; \u00e9 para l\u00e1 que o React armazena o conte\u00fado compilado. Outros frameworks usam caminhos diferentes, por exemplo, no Ember \u00e9 dist. A sa\u00edda da nossa primeira tarefa de cluster ser\u00e1 uma imagem contendo o HTML, JavaScript e CSS que compilamos.<\/p>\n
    Construindo uma imagem baseada no NGINX<\/h4>\n
    \nQuanto \u00e0 nossa segunda tarefa de cluster, ela deve compilar uma imagem baseada no NGINX, usando o conte\u00fado do aplicativo que j\u00e1 compilamos. Na verdade, esta \u00e9 a parte da se\u00e7\u00e3o anterior onde discutimos builds encadeados.<\/p>\n
    Para isso, assim como fizemos acima, criaremos a tarefa 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
    \nAo olhar o c\u00f3digo dessas tarefas de cluster, \u00e9 vis\u00edvel que n\u00e3o h\u00e1 especifica\u00e7\u00e3o do reposit\u00f3rio Git com o qual estamos trabalhando ou dos nomes das imagens que estamos criando. Apenas definimos o que exatamente estamos passando para o Git ou alguma imagem para a qual o resultado final deve ser enviado. \u00c9 por isso que essas tarefas de cluster podem ser reutilizadas ao trabalhar com outros aplicativos.<\/p>\n
    E aqui elegantemente passamos para o pr\u00f3ximo ponto...<\/p>\n
    Recursos<\/h4>\n
    \nAssim, j\u00e1 que, como dissemos, as tarefas em cluster devem ser maximizadas em sua generalidade, precisamos criar recursos que ser\u00e3o utilizados na entrada (reposit\u00f3rio Git) e na sa\u00edda (imagens finais). O primeiro recurso que precisamos \u00e9 o Git, onde nosso aplicativo est\u00e1 localizado, algo como isto:<\/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
    \nAqui o PipelineResource tem o tipo git. A chave url na se\u00e7\u00e3o params indica o reposit\u00f3rio espec\u00edfico e define o ramo master (opcional, mas inclu\u00edmos para completude).<\/p>\n
    Agora precisamos criar um recurso para a imagem, onde os resultados da execu\u00e7\u00e3o da tarefa s2i-web-app ser\u00e3o salvos, isso \u00e9 feito assim:<\/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
    \nAqui o PipelineResource tem o tipo image, e o valor do par\u00e2metro url aponta para o registro de imagens interno do OpenShift, especificamente para aquele que est\u00e1 no namespace webapp-pipeline. N\u00e3o se esque\u00e7a de alterar esse par\u00e2metro se voc\u00ea estiver usando outro namespace.<\/p>\n
    E, finalmente, o \u00faltimo recurso que precisamos tamb\u00e9m ter\u00e1 o tipo image e ser\u00e1 a imagem final do NGINX, que ser\u00e1 utilizada durante a implanta\u00e7\u00e3o:<\/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 novamente, observe que este recurso salva a imagem no registro interno do OpenShift no namespace webapp-pipeline.<\/p>\n
    Para criar todos esses recursos de uma vez, usaremos o comando create:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nVoc\u00ea pode verificar se os recursos foram criados assim:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nAgora que temos todos os componentes necess\u00e1rios, vamos mont\u00e1-los em um pipeline, criando-o com o seguinte 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
    \nMas, antes de executar esse comando, vamos analisar esses componentes. O primeiro \u00e9 o nome:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nEm seguida, na se\u00e7\u00e3o spec, vemos a especifica\u00e7\u00e3o dos recursos que criamos 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
    \nDepois criamos as tarefas que nosso pipeline deve executar. Primeiro, ele deve executar a tarefa s2i-web-app que j\u00e1 criamos:<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nEssa tarefa pega os par\u00e2metros de entrada (recurso gir) e de sa\u00edda (recurso built-web-application-image). Tamb\u00e9m passamos um par\u00e2metro especial para que ela n\u00e3o verifique o TLS, uma vez que estamos usando certificados autoassinados:<\/p>\n
    recursos:\n        entradas:\n          - nome: fonte\n            recurso: web-application-repo\n        sa\u00eddas:\n          - nome: imagem\n            recurso: built-web-application-image\n      par\u00e2metros:\n        - nome: TLSVERIFY\n          valor: \"false\"\n<\/code><\/pre>\n
    \nA pr\u00f3xima tarefa \u00e9 quase a mesma, s\u00f3 que aqui chamamos a tarefa de cluster j\u00e1 criada, webapp-build-runtime:<\/p>\n
    nome: construir-imagem-runtime\n    refer\u00eanciaTarefa:\n      nome: webapp-build-runtime\n      tipo: TarefaDeCluster\n<\/code><\/pre>\n
    \nAssim como na tarefa anterior, passamos o recurso, mas agora \u00e9 a imagem-de-aplica\u00e7\u00e3o-web-constru\u00edda (sa\u00edda da nossa tarefa anterior). E como sa\u00edda, novamente especificamos a imagem. Como esta tarefa deve ser executada ap\u00f3s a anterior, adicionamos o campo runAfter:<\/p>\n
    recursos:\n        entradas:\n          - nome: imagem\n            recurso: built-web-application-image\n        sa\u00eddas:\n          - nome: imagem\n            recurso: runtime-web-application-image\n        par\u00e2metros:\n        - nome: TLSVERIFY\n          valor: \"false\"\n      executarAp\u00f3s:\n        - build-web-application\n<\/code><\/pre>\n
    \nAs duas pr\u00f3ximas tarefas s\u00e3o respons\u00e1veis pela aplica\u00e7\u00e3o dos arquivos YAML do servi\u00e7o, rota e implanta\u00e7\u00e3o, que est\u00e3o no diret\u00f3rio k8s da nossa aplica\u00e7\u00e3o web, bem como pela atualiza\u00e7\u00e3o dessa implanta\u00e7\u00e3o ao criar novas imagens. Essas duas tarefas de cluster foram definidas no in\u00edcio do artigo.<\/p>\n
    Execu\u00e7\u00e3o do pipeline<\/h4>\n
    \nEnt\u00e3o, todas as partes do nosso pipeline foram criadas, e n\u00f3s o iniciaremos com o seguinte comando:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nNesta etapa, a linha de comando \u00e9 usada em modo interativo e \u00e9 necess\u00e1rio escolher os recursos correspondentes em resposta a cada solicita\u00e7\u00e3o: para o recurso git escolhemos reposit\u00f3rio-de-aplica\u00e7\u00f5es-web, em seguida, para o recurso da primeira imagem \u2013 imagem-de-aplica\u00e7\u00e3o-web-constru\u00edda, e, finalmente, para o recurso da segunda imagem \u2013 imagem-de-aplica\u00e7\u00e3o-web-runtime:<\/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
    \nAgora vamos verificar o status do pipeline com o seguinte comando:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nAp\u00f3s o in\u00edcio do pipeline e a aplica\u00e7\u00e3o ser implantada, solicitamos a rota publicada com o seguinte comando:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nPara uma melhor visualiza\u00e7\u00e3o, podemos ver nosso pipeline no Modo Desenvolvedor do console web na se\u00e7\u00e3o Pipelines<\/b>, como mostrado na Fig. 1.<\/p>\n
    \"Aplicativos<\/p>\n
    Fig.1. Vis\u00e3o geral dos pipelines em execu\u00e7\u00e3o.<\/i><\/p>\n
    Um clique no pipeline em execu\u00e7\u00e3o exibe informa\u00e7\u00f5es adicionais, como mostrado na Fig.2.<\/p>\n
    \"Aplicativos<\/p>\n
    Fig. 2. Informa\u00e7\u00f5es adicionais sobre o pipeline.<\/i><\/p>\n
    Ap\u00f3s as informa\u00e7\u00f5es adicionais, \u00e9 poss\u00edvel ver as aplica\u00e7\u00f5es em execu\u00e7\u00e3o na vis\u00e3o Topologia<\/b>, como mostrado na Fig.3.<\/p>\n
    \"Aplicativos<\/p>\n
    Fig 3. Pod em execu\u00e7\u00e3o.<\/i><\/p>\n
    Um clique no c\u00edrculo no canto superior direito do \u00edcone abre nossa aplica\u00e7\u00e3o, como mostrado na Fig.4.<\/p>\n
    \"Aplicativos<\/p>\n
    Fig. 4. Aplica\u00e7\u00e3o React em execu\u00e7\u00e3o.<\/i><\/p>\n
    Conclus\u00e3o<\/h3>\n
    \nAssim, mostramos como iniciar um servidor de desenvolvimento para seu aplicativo no OpenShift e sincroniz\u00e1-lo com o sistema de arquivos local. Tamb\u00e9m abordamos como simular um template de constru\u00e7\u00e3o encadeada usando OpenShift Pipelines. Todo o c\u00f3digo de exemplos deste artigo pode ser encontrado aqui<\/a><\/noindex>.<\/p>\n
    Recursos adicionais (EN)<\/h3>\n
    <\/p>\n