{"id":90874,"date":"2020-08-07T01:42:20","date_gmt":"2020-08-06T23:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds"},"modified":"2020-08-07T01:42:20","modified_gmt":"2020-08-06T23:42:20","slug":"sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Aplica\u00e7\u00f5es modernas no OpenShift, parte 2: constru\u00e7\u00f5es encadeadas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1 a todos! Estamos de volta com o segundo post da nossa s\u00e9rie, onde mostramos como implantar aplica\u00e7\u00f5es web modernas no Red Hat OpenShift. <\/p>\n

\"Aplica\u00e7\u00f5es
\n
\nNo post anterior, introduzimos as capacidades da nova imagem builder S2I (source-to-image), destinada \u00e0 constru\u00e7\u00e3o e implanta\u00e7\u00e3o de aplica\u00e7\u00f5es web modernas na plataforma OpenShift. Naquela ocasi\u00e3o, focamos no tema da r\u00e1pida implanta\u00e7\u00e3o de aplica\u00e7\u00f5es, e hoje veremos como usar a imagem S2I como uma imagem builder \"pura\" e combin\u00e1-la com constru\u00e7\u00f5es encadeadas do OpenShift.
\n<\/a><\/noindex><\/p>\n

Imagem builder pura<\/h3>\n

\nComo mencionamos na primeira parte, a maioria das aplica\u00e7\u00f5es web modernas possui uma chamada fase de constru\u00e7\u00e3o, onde normalmente s\u00e3o realizadas opera\u00e7\u00f5es como transpira\u00e7\u00e3o de c\u00f3digo, concatena\u00e7\u00e3o de arquivos e minifica\u00e7\u00e3o. Os arquivos resultantes dessas opera\u00e7\u00f5es \u2013 incluindo HTML est\u00e1tico, JavaScript e CSS \u2013 s\u00e3o armazenados na pasta de sa\u00edda. O local dessa pasta depende das ferramentas de constru\u00e7\u00e3o utilizadas, e para o React, ser\u00e1 a pasta .\/build (voltaremos a esse ponto mais adiante).<\/p>\n

Source-to-Image (S2I)<\/h4>\n

\nNeste post, n\u00e3o abordaremos o tema \"o que \u00e9 S2I e como us\u00e1-lo\" (pode-se ler mais sobre isso aqui<\/a><\/noindex>), mas \u00e9 importante ter uma vis\u00e3o clara das duas etapas desse processo para entender o que a imagem Web App Builder realmente faz.<\/p>\n

Fase de montagem (assemble phase)<\/h4>\n

\nA fase de montagem \u00e9 muito semelhante ao que acontece quando voc\u00ea executa um docker build e, como resultado, obt\u00e9m uma nova imagem Docker. Portanto, essa fase ocorre ao iniciar uma constru\u00e7\u00e3o na plataforma OpenShift.<\/p>\n

No caso da imagem Web App Builder, a instala\u00e7\u00e3o das depend\u00eancias da sua aplica\u00e7\u00e3o e o in\u00edcio da constru\u00e7\u00e3o \u00e9 responsabilidade do script de montagem<\/a><\/noindex>. Por padr\u00e3o, a imagem builder utiliza o comando npm run build, mas isso pode ser sobrescrito atrav\u00e9s da vari\u00e1vel de ambiente NPM_BUILD.<\/p>\n

Como mencionamos anteriormente, a localiza\u00e7\u00e3o do aplicativo final, j\u00e1 montado, depende das ferramentas utilizadas. Por exemplo, no caso do React, ser\u00e1 a pasta .\/build, enquanto para aplicativos Angular, ser\u00e1 a pasta project_name\/dist. E, como j\u00e1 mostrado na postagem anterior, a localiza\u00e7\u00e3o do diret\u00f3rio de sa\u00edda, que por padr\u00e3o \u00e9 definido como build, pode ser redefinida atrav\u00e9s da vari\u00e1vel de ambiente OUTPUT_DIR. E como a localiza\u00e7\u00e3o da pasta de sa\u00edda varia de framework para framework, voc\u00ea simplesmente copia a sa\u00edda gerada para a pasta padr\u00e3o na imagem, ou seja, para \/opt\/apt-root\/output. Isso \u00e9 importante para entender a pr\u00f3xima parte deste artigo, mas agora vamos rapidamente revisar a pr\u00f3xima etapa \u2013 a fase de execu\u00e7\u00e3o.<\/p>\n

Fase de execu\u00e7\u00e3o<\/h4>\n

\nEsta fase ocorre quando uma nova imagem, criada na fase de montagem, \u00e9 chamada usando docker run. Ela tamb\u00e9m acontece ao realizar a implanta\u00e7\u00e3o na plataforma OpenShift. Por padr\u00e3o script run<\/a><\/noindex> usa m\u00f3dulo serve<\/a><\/noindex> para servir conte\u00fado est\u00e1tico localizado no diret\u00f3rio de sa\u00edda padr\u00e3o mencionado acima.<\/p>\n

Esse m\u00e9todo \u00e9 bom para implanta\u00e7\u00f5es r\u00e1pidas de aplicativos, mas, na verdade, n\u00e3o \u00e9 recomendado servir conte\u00fado est\u00e1tico dessa forma. Como na verdade estamos servindo apenas conte\u00fado est\u00e1tico, o Node.js instalado dentro da nossa imagem n\u00e3o \u00e9 necess\u00e1rio \u2013 um servidor web \u00e9 suficiente.<\/p>\n

Ou seja, ao construir precisamos de uma coisa, ao executar \u2013 outra. Nessa situa\u00e7\u00e3o, constru\u00e7\u00f5es encadeadas ser\u00e3o \u00fateis.<\/p>\n

Constru\u00e7\u00f5es encadeadas<\/h3>\n

\nVeja o que dizem sobre constru\u00e7\u00f5es encadeadas<\/a><\/noindex> na documenta\u00e7\u00e3o do OpenShift:<\/p>\n

\u00abDuas constru\u00e7\u00f5es podem ser vinculadas, onde uma gera a entidade compilada e a outra coloca essa entidade em uma imagem separada, que \u00e9 usada para executar essa entidade\u00bb.\n<\/p><\/blockquote>\n

\nEm outras palavras, podemos usar a imagem do Web App Builder para executar nossa constru\u00e7\u00e3o e, em seguida, usar a imagem do servidor web, como o NGINX, para servir nosso conte\u00fado.<\/p>\n

Assim, podemos usar a imagem do Web App Builder como um construtor \"limpo\" e ter uma imagem de runtime pequena.<\/p>\n

Agora vamos analisar isso com um exemplo espec\u00edfico.<\/p>\n

Para a pr\u00e1tica, usaremos um aplicativo React simples<\/a><\/noindex>, criado com a ferramenta de linha de comando create-react-app.<\/p>\n

Para juntar tudo, usaremos o arquivo de modelo do OpenShift<\/a><\/noindex>.<\/p>\n

Vamos analisar este arquivo em detalhes, come\u00e7ando pela se\u00e7\u00e3o de par\u00e2metros.<\/p>\n

parameters:\n  - name: SOURCE_REPOSITORY_URL\n    description: A URL de origem para o aplicativo\n    displayName: URL de Origem\n    required: true\n  - name: SOURCE_REPOSITORY_REF\n    description: O nome do branch para o aplicativo\n    displayName: Branch de Origem\n    value: master\n    required: true\n  - name: SOURCE_REPOSITORY_DIR\n    description: O local dentro do reposit\u00f3rio de origem do aplicativo\n    displayName: Diret\u00f3rio de Origem\n    value: .\n    required: true\n  - name: OUTPUT_DIR\n    description: O local dos arquivos est\u00e1ticos compilados do seu construtor de aplicativos web\n    displayName: Diret\u00f3rio de Sa\u00edda\n    value: build\n    required: false\n<\/code><\/pre>\n
\nAqui tudo \u00e9 bastante claro, mas vale a pena prestar aten\u00e7\u00e3o no par\u00e2metro OUTPUT_DIR. Para o aplicativo React do nosso exemplo, n\u00e3o h\u00e1 com o que se preocupar, pois o React usa como pasta de sa\u00edda o valor padr\u00e3o. No entanto, para aplica\u00e7\u00f5es Angular ou algo semelhante, este par\u00e2metro precisar\u00e1 ser alterado adequadamente.<\/p>\n
Agora vamos dar uma olhada na se\u00e7\u00e3o de ImageStreams.<\/p>\n
- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-builder  \/\/ 1 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-runtime  \/\/ 2 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: web-app-builder-runtime \/\/ 3\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: nginx-image-runtime \/\/ 4\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nObserve as terceira e quarta imagens. Ambas est\u00e3o definidas como imagens Docker, e fica claro de onde elas v\u00eam.<\/p>\n
A terceira imagem \u00e9 o web-app-builder, e ela \u00e9 originada de nodeshift\/ubi8-s2i-web-app com a tag 10.x no Docker hub<\/a><\/noindex>.<\/p>\n
A quarta imagem \u00e9 a imagem NGINX (vers\u00e3o 1.12) com a tag latest no Docker hub<\/a><\/noindex>.<\/p>\n
Agora vamos olhar as duas primeiras imagens. Ambas est\u00e3o vazias no in\u00edcio e s\u00e3o criadas apenas na fase de constru\u00e7\u00e3o (build phase). A primeira imagem, react-web-app-builder, ser\u00e1 o resultado da fase de montagem, que combinar\u00e1 a imagem web-app-builder-runtime e nosso c\u00f3digo fonte. \u00c9 por isso que inclu\u00edmos no nome dessa imagem \"-builder\".<\/p>\n
A segunda imagem, react-web-app-runtime, ser\u00e1 o resultado da combina\u00e7\u00e3o de nginx-image-runtime e alguns arquivos da imagem react-web-app-builder. Esta imagem tamb\u00e9m ser\u00e1 utilizada durante o deploy e conter\u00e1 apenas o servidor web e o HTML, JavaScript e CSS est\u00e1tico do nosso aplicativo.<\/p>\n
Confuso? Vamos dar uma olhada nas configura\u00e7\u00f5es de constru\u00e7\u00e3o e ficar\u00e1 um pouco mais claro.<\/p>\n
No nosso template, h\u00e1 duas configura\u00e7\u00f5es de constru\u00e7\u00e3o. Aqui est\u00e1 a primeira delas, que \u00e9 bastante padr\u00e3o:<\/p>\n
  apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-builder\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-builder:latest \\\/\\\/ 1\n    source:   \\\/\\\/ 2 \n      git:\n        uri: ${SOURCE_REPOSITORY_URL}\n        ref: ${SOURCE_REPOSITORY_REF}\n      contextDir: ${SOURCE_REPOSITORY_DIR}\n      type: Git\n    strategy:\n      sourceStrategy:\n        env:\n          - name: OUTPUT_DIR \\\/\\\/ 3 \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \\\/\\\/ 4\n        incremental: true \\\/\\\/ 5\n      type: Source\n    triggers: \\\/\\\/ 6\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nComo podemos ver, a linha com a etiqueta 1 nos diz que o resultado desta constru\u00e7\u00e3o ser\u00e1 colocado na imagem react-web-app-builder, que vimos anteriormente na se\u00e7\u00e3o de ImageStreams.<\/p>\n
A linha com a etiqueta 2 indica de onde pegar o c\u00f3digo. Neste caso, \u00e9 um reposit\u00f3rio git, e o local, ref e diret\u00f3rio de contexto s\u00e3o definidos pelas vari\u00e1veis que j\u00e1 vimos acima.<\/p>\n
A linha com a etiqueta 3 \u00e9 algo que j\u00e1 vimos na se\u00e7\u00e3o de par\u00e2metros. Ela adiciona a vari\u00e1vel de ambiente OUTPUT_DIR, que em nosso exemplo \u00e9 igual a build.
\nA linha com a etiqueta 4 indica que devemos usar a imagem web-app-builder-runtime, que j\u00e1 vimos na se\u00e7\u00e3o de ImageStreams.<\/p>\n
A linha com a etiqueta 5 diz que queremos usar a constru\u00e7\u00e3o incremental, se a imagem S2I a suportar, e a imagem Web App Builder \u2013 suporta. Na primeira execu\u00e7\u00e3o, ap\u00f3s a conclus\u00e3o da fase de montagem, a imagem salvar\u00e1 a pasta node_modules em um arquivo compactado. Ent\u00e3o, nas execu\u00e7\u00f5es seguintes, a imagem apenas descompactar\u00e1 essa pasta para reduzir a dura\u00e7\u00e3o da constru\u00e7\u00e3o.<\/p>\n
E, finalmente, a linha com a etiqueta 6 \u2013 s\u00e3o apenas alguns gatilhos para que a constru\u00e7\u00e3o seja iniciada automaticamente, sem interven\u00e7\u00e3o manual, quando algo muda.<\/p>\n
Em geral, esta \u00e9 uma configura\u00e7\u00e3o de constru\u00e7\u00e3o bastante padr\u00e3o.<\/p>\n
Agora, vamos olhar para a segunda configura\u00e7\u00e3o de constru\u00e7\u00e3o. Ela \u00e9 muito parecida com a primeira, mas h\u00e1 uma diferen\u00e7a importante.<\/p>\n
apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-runtime\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-runtime:latest \\\/\\\/ 1\n    source: \\\/\\\/ 2\n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \\\/\\\/ 3\n          paths:\n            - sourcePath: \\\/opt\\\/app-root\\\/output\\\/.\n              destinationDir: .  \\\/\\\/ 5\n             \n    strategy: \\\/\\\/ 6\n      sourceStrategy:\n        from:\n          kind: ImageStreamTag\n          name: nginx-image-runtime:latest\n        incremental: true\n      type: Source\n    triggers:\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - type: ImageChange\n      imageChange: {}\n    - type: ImageChange\n      imageChange:\n        from:\n          kind: ImageStreamTag\n          name: react-web-app-builder:latest \\\/\\\/ 7\n<\/code><\/pre>\n
\nEnt\u00e3o, a segunda configura\u00e7\u00e3o do build \u00e9 react-web-app-runtime, e ela come\u00e7a de maneira bastante padr\u00e3o.<\/p>\n
Na linha com o r\u00f3tulo 1, n\u00e3o h\u00e1 nada de novo \u2014 ela apenas indica que o resultado do build \u00e9 colocado na imagem react-web-app-runtime.<\/p>\n
A linha com o r\u00f3tulo 2, assim como na configura\u00e7\u00e3o anterior, indica de onde obter o c\u00f3digo-fonte. Mas note que aqui estamos dizendo que ele vem da imagem. E, especificamente, da imagem que acabamos de criar \u2014 a react-web-app-builder (indicada na linha com o r\u00f3tulo 3). Os arquivos que queremos usar est\u00e3o dentro da imagem, e sua localiza\u00e7\u00e3o \u00e9 definida na linha com o r\u00f3tulo 4, que neste caso \u00e9 \/opt\/app-root\/output\/. Se voc\u00ea se lembra, \u00e9 exatamente para l\u00e1 que s\u00e3o colocados os arquivos gerados como resultado da constru\u00e7\u00e3o do nosso aplicativo.<\/p>\n
A pasta de destino, especificada na linha com o r\u00f3tulo 5, \u00e9 simplesmente o diret\u00f3rio atual (todo esse processo, lembre-se, acontece dentro de uma coisa m\u00e1gica chamada OpenShift, e n\u00e3o em seu computador local).<\/p>\n
A se\u00e7\u00e3o strategy \u2014 a linha com o r\u00f3tulo 6 \u2014 tamb\u00e9m \u00e9 semelhante \u00e0 primeira configura\u00e7\u00e3o do build. Mas desta vez, vamos usar o nginx-image-runtime, que j\u00e1 vimos na se\u00e7\u00e3o ImageStream.<\/p>\n
Finalmente, a linha com o r\u00f3tulo 7 \u00e9 a se\u00e7\u00e3o de gatilhos que ativa esse build toda vez que a imagem react-web-app-builder \u00e9 alterada.<\/p>\n
No restante, este template cont\u00e9m uma configura\u00e7\u00e3o de implanta\u00e7\u00e3o bastante padr\u00e3o, al\u00e9m de coisas relacionadas a servi\u00e7os e rotas, mas n\u00e3o vamos nos aprofundar nisso. Observe que a imagem que ser\u00e1 implantada \u00e9 a imagem react-web-app-runtime.<\/p>\n
Implanta\u00e7\u00e3o do aplicativo<\/h3>\n
\nEnt\u00e3o, depois de olharmos para o template, vejamos como us\u00e1-lo para implantar um aplicativo.<\/p>\n
Podemos usar a ferramenta de linha de comando OpenShift chamada oc, para implantar nosso template:<\/p>\n
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f\n\n$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https:\/\/github.com\/lholmquist\/react-web-app\n<\/code><\/pre>\n
\nO primeiro comando na tela acima \u00e9 uma maneira intencionalmente t\u00e9cnica de encontrar o template \/openshiftio\/application.yaml.<\/p>\n
O segundo comando simplesmente cria um novo aplicativo com base nesse template.<\/p>\n
Depois que esses comandos forem executados, veremos que tivemos duas builds:<\/p>\n
\"Aplica\u00e7\u00f5es<\/p>\n
E voltando \u00e0 tela de Vis\u00e3o Geral, veremos um pod em execu\u00e7\u00e3o:<\/p>\n
\"Aplica\u00e7\u00f5es<\/p>\n
Um clique no link nos levar\u00e1 ao nosso aplicativo, que se apresenta como a p\u00e1gina padr\u00e3o do React App:<\/p>\n
\"Aplica\u00e7\u00f5es<\/p>\n
Complemento 1<\/h3>\n
\nPara os f\u00e3s do Angular, tamb\u00e9m temos exemplo de aplica\u00e7\u00e3o<\/a><\/noindex>.<\/p>\n
O padr\u00e3o aqui \u00e9 o mesmo, exceto pela vari\u00e1vel OUTPUT_DIR.<\/p>\n
Complemento 2<\/h3>\n
\nNeste artigo, usamos o NGINX como servidor web, mas \u00e9 bastante f\u00e1cil substitu\u00ed-lo pelo Apache, basta alterar no arquivo de modelo imagem do NGINX<\/a><\/noindex> para imagem do Apache<\/a><\/noindex>.<\/p>\n
Conclus\u00e3o<\/h3>\n
\nNa primeira parte desta s\u00e9rie, mostramos como implantar rapidamente aplica\u00e7\u00f5es web modernas na plataforma OpenShift. Hoje, exploramos o que faz a imagem da Web App e como ela pode ser combinada com um servidor web puro como o NGINX usando builds encadeados (chained builds) para organizar uma constru\u00e7\u00e3o mais adequada para condi\u00e7\u00f5es de produ\u00e7\u00e3o. No pr\u00f3ximo e \u00faltimo artigo desta s\u00e9rie, mostraremos como executar um servidor de desenvolvimento no OpenShift para sua aplica\u00e7\u00e3o e garantir a sincroniza\u00e7\u00e3o de arquivos locais e remotos.<\/p>\n
Conte\u00fado desta s\u00e9rie de artigos<\/h3>\n
<\/p>\n