{"id":81600,"date":"2020-05-15T01:42:41","date_gmt":"2020-05-14T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund"},"modified":"2020-05-15T01:42:41","modified_gmt":"2020-05-14T23:42:41","slug":"neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund","title":{"rendered":"Dicas sobre como acelerar a constru\u00e7\u00e3o de imagens Docker. Por exemplo, em at\u00e9 30 segundos.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Antes que uma fun\u00e7\u00e3o v\u00e1 para produ\u00e7\u00e3o, em nossos tempos de orquestradores e CI\/CD complexos, ela passa por um longo caminho desde o commit at\u00e9 os testes e entrega. Antes, era poss\u00edvel simplesmente enviar novos arquivos via FTP (o que ningu\u00e9m faz mais hoje em dia, certo?), e o processo de 'deploy' levava segundos. Agora, \u00e9 necess\u00e1rio criar um merge request e esperar um bom tempo at\u00e9 que a fun\u00e7\u00e3o chegue aos usu\u00e1rios.<\/p>\n

<\/p>\n

Parte desse caminho \u00e9 a constru\u00e7\u00e3o da imagem Docker. \u00c0s vezes, a constru\u00e7\u00e3o leva minutos, outras vezes, dezenas de minutos, o que \u00e9 dif\u00edcil de considerar normal. Neste artigo, pegaremos um aplicativo simples, que empacotaremos em uma imagem, aplicaremos alguns m\u00e9todos para acelerar a constru\u00e7\u00e3o e discutiremos as nuances do funcionamento desses m\u00e9todos.<\/p>\n

<\/p>\n

\"Dicas<\/p>\n

<\/a><\/noindex><\/p>\n

Temos uma boa experi\u00eancia na cria\u00e7\u00e3o e manuten\u00e7\u00e3o de sites de m\u00eddia: TASS<\/a><\/noindex>, The Bell<\/a><\/noindex>, \"Nova Gazeta\"<\/a><\/noindex>, Republic<\/a><\/noindex>... Recentemente ampliamos nosso portf\u00f3lio, lan\u00e7ando o site da produ\u00e7\u00e3o Reminder<\/a><\/noindex>. E enquanto rapidamente aprimor\u00e1vamos novas fun\u00e7\u00f5es e corrig\u00edamos velhos bugs, o deploy lento se tornou um grande problema.<\/p>\n

<\/p>\n

Fazemos o deploy no GitLab. Constru\u00edmos as imagens, fazemos push no GitLab Registry e as distribu\u00edmos em produ\u00e7\u00e3o. O item que leva mais tempo nessa lista \u00e9 a constru\u00e7\u00e3o de imagens. Por exemplo: sem otimiza\u00e7\u00e3o, cada constru\u00e7\u00e3o do backend levava 14 minutos.<\/p>\n

<\/p>\n

\"Dicas<\/p>\n

<\/p>\n

No final, ficou claro que n\u00e3o pod\u00edamos continuar assim, e nos sentamos para entender por que as imagens estavam levando tanto tempo para serem constru\u00eddas. No final, conseguimos reduzir o tempo de constru\u00e7\u00e3o para 30 segundos!<\/p>\n

<\/p>\n

\"Dicas<\/p>\n

<\/p>\n

Para este artigo, a fim de n\u00e3o vincular ao ambiente do Reminder, vamos considerar um exemplo de constru\u00e7\u00e3o de um aplicativo vazio em Angular. Ent\u00e3o, vamos criar nosso aplicativo:<\/p>\n

<\/p>\n

ng n app<\/code><\/pre>\n
<\/p>\n
Adicionamos a ele PWA (somos progressivos):<\/p>\n
<\/p>\n
ng add @angular\/pwa --project app<\/code><\/pre>\n
<\/p>\n
Enquanto um milh\u00e3o de pacotes npm est\u00e3o sendo baixados, vamos entender como a imagem do docker \u00e9 estruturada. O Docker oferece a possibilidade de empacotar aplicativos e execut\u00e1-los em um ambiente isolado chamado cont\u00eainer. Gra\u00e7as \u00e0 isola\u00e7\u00e3o, \u00e9 poss\u00edvel executar muitos cont\u00eaineres ao mesmo tempo em um \u00fanico servidor. Os cont\u00eaineres s\u00e3o significativamente mais leves do que m\u00e1quinas virtuais, pois s\u00e3o executados diretamente no n\u00facleo do sistema. Para executar um cont\u00eainer com nosso aplicativo, precisamos primeiro criar uma imagem, na qual empacotaremos tudo que \u00e9 necess\u00e1rio para o funcionamento do nosso aplicativo. Essencialmente, a imagem \u00e9 uma c\u00f3pia do sistema de arquivos. Por exemplo, vamos considerar o Dockerfile:<\/p>\n
<\/p>\n
FROM node:12.16.2\nWORKDIR \/app\nCOPY . .\nRUN npm ci\nRUN npm run build --prod<\/code><\/pre>\n
<\/p>\n
Um Dockerfile \u00e9 um conjunto de instru\u00e7\u00f5es; ao executar cada uma delas, o Docker salva as altera\u00e7\u00f5es no sistema de arquivos e as aplica \u00e0s anteriores. Cada comando gera sua pr\u00f3pria camada. A imagem pronta \u00e9 a combina\u00e7\u00e3o de camadas.<\/p>\n
<\/p>\n
\u00c9 importante saber: cada camada do Docker pode ser armazenada em cache. Se nada mudou desde a \u00faltima constru\u00e7\u00e3o, o Docker usar\u00e1 a camada que j\u00e1 est\u00e1 pronta em vez de executar o comando novamente. Como o ganho principal na velocidade de constru\u00e7\u00e3o vem do uso do cache, nas medi\u00e7\u00f5es iremos nos concentrar na constru\u00e7\u00e3o da imagem com o cache j\u00e1 existente. Assim, em etapas:<\/p>\n
<\/p>\n
    \n
  1. Remova as imagens localmente, para que execu\u00e7\u00f5es anteriores n\u00e3o influenciem o teste.
    \ndocker rmi $(docker images -q)<\/code><\/li>\n
  2. Vamos executar a constru\u00e7\u00e3o pela primeira vez.
    \ntime docker build -t app .<\/code><\/li>\n
  3. Alteramos o arquivo src\/index.html \u2014 simulamos o trabalho de um programador.<\/li>\n
  4. Vamos executar a constru\u00e7\u00e3o pela segunda vez.
    \ntime docker build -t app .<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Se o ambiente para construir imagens estiver configurado corretamente (sobre isso falaremos um pouco mais abaixo), o Docker j\u00e1 ter\u00e1 v\u00e1rios caches prontos na hora de construir. Nossa tarefa \u00e9 aprender a usar o cache para que a constru\u00e7\u00e3o ocorra o mais rapidamente poss\u00edvel. Como presumimos que a constru\u00e7\u00e3o sem cache acontece apenas uma vez \u2014 a primeira \u2014 podemos desconsiderar qu\u00e3o lenta foi essa primeira vez. Em nossos testes, o que importa \u00e9 a segunda execu\u00e7\u00e3o da constru\u00e7\u00e3o, quando os caches j\u00e1 est\u00e3o quentes e estamos prontos para assar nosso bolo. No entanto, algumas dicas afetar\u00e3o tamb\u00e9m a primeira constru\u00e7\u00e3o.<\/p>\n
    <\/p>\n
    Coloque o Dockerfile, descrito acima, na pasta do projeto e inicie a constru\u00e7\u00e3o. Todos os listagens fornecidas foram abreviadas para facilitar a leitura.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnviando contexto de constru\u00e7\u00e3o para o daemon Docker 409MB\nPasso 1\/5 : FROM node:12.16.2\nStatus: Imagem mais nova baixada para node:12.16.2\nPasso 2\/5 : WORKDIR \/app\nPasso 3\/5 : COPY . .\nPasso 4\/5 : RUN npm ci\nadicionados 1357 pacotes em 22.47s\nPasso 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37581ms\nConstru\u00eddo com sucesso c8c279335f46\nMarcado com sucesso app:latest\n\nreal 5m4.541s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Altere o conte\u00fado de src\/index.html e inicie a segunda execu\u00e7\u00e3o.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnviando contexto de constru\u00e7\u00e3o para o daemon Docker 409MB\nPasso 1\/5 : FROM node:12.16.2\nPasso 2\/5 : WORKDIR \/app\n ---> Usando cache\nPasso 3\/5 : COPY . .\nPasso 4\/5 : RUN npm ci\nadicionados 1357 pacotes em 22.47s\nPasso 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37902ms\nConstru\u00eddo com sucesso 79f335df92d3\nMarcado com sucesso app:latest\n\nreal 3m33.262s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Para verificar se conseguimos gerar a imagem, execute o comando docker images<\/code>:<\/p>\n
    <\/p>\n
    REPOSIT\u00d3RIO   TAG      ID DE IMAGEM       CRIADO              TAMANHO\napp          latest   79f335df92d3   H\u00e1 cerca de um minuto atr\u00e1s   1.74GB<\/code><\/pre>\n
    <\/p>\n
    Antes de construir, o Docker pega todos os arquivos no contexto atual e os envia para seu daemon Enviando contexto de constru\u00e7\u00e3o para o daemon do Docker 409MB<\/code>. O contexto de constru\u00e7\u00e3o \u00e9 especificado como o \u00faltimo argumento do comando build. No nosso caso, este \u00e9 o diret\u00f3rio atual \u2014 \".\", e o Docker puxa tudo que temos nesta pasta. 409 Megabytes \u00e9 muito: vamos pensar em como corrigir isso.<\/p>\n
    <\/p>\n
    Reduzindo o contexto<\/h2>\n
    <\/p>\n
    Para reduzir o contexto, h\u00e1 duas op\u00e7\u00f5es. Ou colocamos todos os arquivos necess\u00e1rios para a constru\u00e7\u00e3o em uma pasta separada e especificamos o contexto para o Docker exatamente essa pasta. Isso pode n\u00e3o ser sempre conveniente, por isso h\u00e1 a possibilidade de especificar exce\u00e7\u00f5es: o que n\u00e3o deve ser inclu\u00eddo no contexto. Para isso, colocamos um arquivo .dockerignore no projeto e especificamos o que n\u00e3o \u00e9 necess\u00e1rio para a constru\u00e7\u00e3o:<\/p>\n
    <\/p>\n
    .git\n\/node_modules<\/code><\/pre>\n
    <\/p>\n
    e vamos executar a constru\u00e7\u00e3o novamente:<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnviando contexto de constru\u00e7\u00e3o para o daemon do Docker 607.2kB\nPasso 1\/5 : FROM node:12.16.2\nPasso 2\/5 : WORKDIR \/app\n ---> Usando cache\nPasso 3\/5 : COPY . .\nPasso 4\/5 : RUN npm ci\nadicionado 1357 pacotes em 22.47s\nPasso 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37313ms\nConstru\u00eddo com sucesso 4942f010792a\nMarcado com sucesso app:latest\n\nreal 1m47.763s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    607.2 Kbytes \u2014 muito melhor do que 409 Megabytes. Al\u00e9m disso, diminu\u00edmos o tamanho da imagem de 1.74 para 1.38GB:<\/p>\n
    <\/p>\n
    REPOSIT\u00d3RIO   TAG      ID DA IMAGEM       CRIADO         TAMANHO\napp          latest   4942f010792a   h\u00e1 3 minutos   1.38GB<\/code><\/pre>\n
    <\/p>\n
    Vamos tentar reduzir ainda mais o tamanho da imagem.<\/p>\n
    <\/p>\n
    Usando Alpine<\/h2>\n
    <\/p>\n
    Outra forma de economizar no tamanho da imagem \u2014 \u00e9 usar uma imagem base menor. A imagem base \u00e9 a imagem na qual nossa imagem \u00e9 constru\u00edda. A camada inferior \u00e9 especificada pelo comando FROM<\/code> no Dockerfile. No nosso caso, estamos usando uma imagem baseada no Ubuntu, que j\u00e1 tem nodejs. E pesa \u2026<\/p>\n
    <\/p>\n
    $ docker images -a | grep node\nnode 12.16.2 406aa3abbc6c h\u00e1 17 minutos 916MB<\/code><\/pre>\n
    <\/p>\n
    \u2026 quase um gigabyte. Podemos reduzir bastante o tamanho usando uma imagem baseada no Alpine Linux. Alpine \u2014 \u00e9 um Linux muito pequeno. A imagem Docker para nodejs baseada em Alpine pesa apenas 88.5 MB. Portanto, vamos substituir nossa imagem pesada:<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++\nWORKDIR \/app\nCOPY . .\nRUN npm ci\nRUN npm run build --prod<\/code><\/pre>\n
    <\/p>\n
    Tivemos que instalar algumas coisas necess\u00e1rias para construir o aplicativo. Sim, Angular n\u00e3o se compila sem Python \u00af(\u00b0_o)\\\/\u00af<\/p>\n
    <\/p>\n
    Mas o tamanho da imagem reduziu em 150 MB:<\/p>\n
    <\/p>\n
    REPOSIT\u00d3RIO   TAG      ID DA IMAGEM       CRIADO         TAMANHO\napp          latest   aa031edc315a   h\u00e1 22 minutos   761MB<\/code><\/pre>\n
    <\/p>\n
    Vamos mais longe.<\/p>\n
    <\/p>\n
    Constru\u00e7\u00e3o em m\u00faltiplas etapas<\/h2>\n
    <\/p>\n
    Nem tudo que est\u00e1 na imagem \u00e9 necess\u00e1rio em produ\u00e7\u00e3o.<\/p>\n
    <\/p>\n
    $ docker run app ls -lah\ntotal 576K\ndrwxr-xr-x 1 root root 4.0K Apr 16 19:54 .\ndrwxr-xr-x 1 root root 4.0K Apr 16 20:00 ..\n-rwxr-xr-x 1 root root 19 Apr 17 2020 .dockerignore\n-rwxr-xr-x 1 root root 246 Apr 17 2020 .editorconfig\n-rwxr-xr-x 1 root root 631 Apr 17 2020 .gitignore\n-rwxr-xr-x 1 root root 181 Apr 17 2020 Dockerfile\n-rwxr-xr-x 1 root root 1020 Apr 17 2020 README.md\n-rwxr-xr-x 1 root root 3.6K Apr 17 2020 angular.json\n-rwxr-xr-x 1 root root 429 Apr 17 2020 browserslist\ndrwxr-xr-x 3 root root 4.0K Apr 16 19:54 dist\ndrwxr-xr-x 3 root root 4.0K Apr 17 2020 e2e\n-rwxr-xr-x 1 root root 1015 Apr 17 2020 karma.conf.js\n-rwxr-xr-x 1 root root 620 Apr 17 2020 ngsw-config.json\ndrwxr-xr-x 1 root root 4.0K Apr 16 19:54 node_modules\n-rwxr-xr-x 1 root root 494.9K Apr 17 2020 package-lock.json\n-rwxr-xr-x 1 root root 1.3K Apr 17 2020 package.json\ndrwxr-xr-x 5 root root 4.0K Apr 17 2020 src\n-rwxr-xr-x 1 root root 210 Apr 17 2020 tsconfig.app.json\n-rwxr-xr-x 1 root root 489 Apr 17 2020 tsconfig.json\n-rwxr-xr-x 1 root root 270 Apr 17 2020 tsconfig.spec.json\n-rwxr-xr-x 1 root root 1.9K Apr 17 2020 tslint.json<\/code><\/pre>\n
    <\/p>\n
    Com docker run app ls -lah<\/code> lan\u00e7amos um cont\u00eainer com base na nossa imagem app<\/code> e executamos o comando nele ls -lah<\/code>, ap\u00f3s o qual o cont\u00eainer encerrou sua opera\u00e7\u00e3o.<\/p>\n
    <\/p>\n
    No ambiente de produ\u00e7\u00e3o, precisamos apenas da pasta dist<\/code>. No entanto, os arquivos precisam ser disponibilizados externamente. Podemos iniciar um servidor HTTP usando nodejs. Mas vamos fazer mais simples. Adivinhe a palavra russa que cont\u00e9m quatro letras \u00ab\u044b\u00bb. Corretamente! \u042b\u043d\u0436\u044b\u043d\u044b\u043a\u0441\u044b. Vamos pegar uma imagem com nginx e adicionar a pasta dist<\/code> e uma pequena configura\u00e7\u00e3o:<\/p>\n
    <\/p>\n
    server {\n    listen 80 default_server;\n    server_name localhost;\n    charset utf-8;\n    root \/app\/dist;\n\n    location \/ {\n        try_files $uri $uri\/ \/index.html;\n    }\n}<\/code><\/pre>\n
    <\/p>\n
    Tudo isso ser\u00e1 facilitado pelo multi-stage build. Vamos modificar nosso Dockerfile:<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11 as builder\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++\nWORKDIR \/app\nCOPY . .\nRUN npm ci\nRUN npm run build --prod\n\nFROM nginx:1.17.10-alpine\nRUN rm \/etc\/nginx\/conf.d\/default.conf\nCOPY nginx\/static.conf \/etc\/nginx\/conf.d\nCOPY --from=builder \/app\/dist\/app .<\/code><\/pre>\n
    <\/p>\n
    Agora temos duas instru\u00e7\u00f5es FROM<\/code> no Dockerfile, cada uma delas executa sua pr\u00f3pria etapa de constru\u00e7\u00e3o. A primeira n\u00f3s chamamos de builder<\/code>, e a partir da \u00faltima instru\u00e7\u00e3o FROM, nosso cont\u00eainer final ser\u00e1 preparado. A \u00faltima etapa \u00e9 copiar o artefato da nossa constru\u00e7\u00e3o na etapa anterior para a imagem final com nginx. O tamanho da imagem foi significativamente reduzido:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED          SIZE\napp          latest   2c6c5da07802   29 minutes ago   36MB<\/code><\/pre>\n
    <\/p>\n
    Vamos rodar o cont\u00eainer com nossa imagem e verificar se tudo est\u00e1 funcionando:<\/p>\n
    <\/p>\n
    docker run -p8080:80 app<\/code><\/pre>\n
    <\/p>\n
    Com a op\u00e7\u00e3o -p8080:80, conectamos a porta 8080 na nossa m\u00e1quina host \u00e0 porta 80 dentro do cont\u00eainer, onde o nginx est\u00e1 rodando. Abrimos no navegador http:\/\/localhost:8080\/<\/a><\/noindex> e vemos nosso aplicativo. Tudo funcionando!<\/p>\n
    <\/p>\n
    \"Dicas<\/p>\n
    <\/p>\n
    A redu\u00e7\u00e3o do tamanho da imagem de 1.74 GB para 36 MB diminui significativamente o tempo de entrega do seu aplicativo em produ\u00e7\u00e3o. Mas vamos voltar ao tempo de constru\u00e7\u00e3o.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nSending build context to Docker daemon 608.8kB\nStep 1\/11 : FROM node:12.16.2-alpine3.11 as builder\nStep 2\/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++\n ---> Using cache\nStep 3\/11 : WORKDIR \/app\n ---> Using cache\nStep 4\/11 : COPY . .\nStep 5\/11 : RUN npm ci\nadded 1357 packages in 47.338s\nStep 6\/11 : RUN npm run build --prod\nDate: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Time: 39948ms\n ---> 27f1479221e4\nStep 7\/11 : FROM nginx:stable-alpine\nStep 8\/11 : WORKDIR \/app\n ---> Using cache\nStep 9\/11 : RUN rm \/etc\/nginx\/conf.d\/default.conf\n ---> Using cache\nStep 10\/11 : COPY nginx\/static.conf \/etc\/nginx\/conf.d\n ---> Using cache\nStep 11\/11 : COPY --from=builder \/app\/dist\/app .\nSuccessfully built d201471c91ad\nSuccessfully tagged app:latest\n\nreal 2m17.700s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Mudamos a ordem das camadas<\/h2>\n
    <\/p>\n
    Os primeiros tr\u00eas passos foram armazenados em cache (dica Using cache<\/code>). Na quarta etapa, todos os arquivos do projeto s\u00e3o copiados e na quinta etapa, as depend\u00eancias s\u00e3o instaladas RUN npm ci<\/code> \u2014 inteiros 47,338s. Por que reinstalar as depend\u00eancias toda vez, se elas mudam raramente? Vamos entender por que elas n\u00e3o foram armazenadas em cache. A quest\u00e3o \u00e9 que o Docker verifica cada camada, camada por camada, para ver se o comando e os arquivos associados mudaram. Na quarta etapa, copiamos todos os arquivos do nosso projeto, e entre eles, claro, h\u00e1 mudan\u00e7as, portanto, o Docker n\u00e3o apenas n\u00e3o utiliza o cache para esta camada, mas tamb\u00e9m para todas as subsequentes! Vamos fazer pequenas altera\u00e7\u00f5es no Dockerfile.<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11 as builder\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm ci\nCOPY . .\nRUN npm run build --prod\n\nFROM nginx:1.17.10-alpine\nRUN rm \/etc\/nginx\/conf.d\/default.conf\nCOPY nginx\/static.conf \/etc\/nginx\/conf.d\nCOPY --from=builder \/app\/dist\/app .<\/code><\/pre>\n
    <\/p>\n
    Primeiro, os arquivos package.json e package-lock.json s\u00e3o copiados, em seguida, as depend\u00eancias s\u00e3o instaladas, e s\u00f3 depois disso todo o projeto \u00e9 copiado. Como resultado:<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnviando o contexto de constru\u00e7\u00e3o para o daemon Docker 608.8kB\nEtapa 1\/12 : FROM node:12.16.2-alpine3.11 as builder\nEtapa 2\/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++\n ---> Usando cache\nEtapa 3\/12 : WORKDIR \/app\n ---> Usando cache\nEtapa 4\/12 : COPY package*.json .\/\n ---> Usando cache\nEtapa 5\/12 : RUN npm ci\n ---> Usando cache\nEtapa 6\/12 : COPY . .\nEtapa 7\/12 : RUN npm run build --prod\nData: 2020-04-16T21:29:44.770Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 38287ms\n ---> 1b9448c73558\nEtapa 8\/12 : FROM nginx:stable-alpine\nEtapa 9\/12 : WORKDIR \/app\n ---> Usando cache\nEtapa 10\/12 : RUN rm \/etc\/nginx\/conf.d\/default.conf\n ---> Usando cache\nEtapa 11\/12 : COPY nginx\/static.conf \/etc\/nginx\/conf.d\n ---> Usando cache\nEtapa 12\/12 : COPY --from=builder \/app\/dist\/app .\nImagem constru\u00edda com sucesso a44dd7c217c3\nMarcada com sucesso app:latest\n\nreal 0m46.497s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    46 segundos em vez de 3 minutos \u2014 bem melhor! A ordem correta das camadas \u00e9 importante: primeiro copiamos o que n\u00e3o muda, depois o que muda raramente, e, por \u00faltimo, o que muda frequentemente.<\/p>\n
    <\/p>\n
    A seguir, algumas palavras sobre a constru\u00e7\u00e3o de imagens em sistemas CI\/CD.<\/p>\n
    <\/p>\n
    Uso de imagens anteriores como cache<\/h2>\n
    <\/p>\n
    Se usarmos uma solu\u00e7\u00e3o SaaS para a constru\u00e7\u00e3o, o cache local do Docker pode estar limpo e fresco. Para que o Docker tenha de onde obter as camadas constru\u00eddas, forne\u00e7a-lhe a imagem constru\u00edda anteriormente.<\/p>\n
    <\/p>\n
    Vamos considerar, como exemplo, a constru\u00e7\u00e3o do nosso aplicativo no GitHub Actions. Usaremos esta configura\u00e7\u00e3o<\/p>\n
    <\/p>\n
    on:\n  push:\n    branches:\n      - master\n\nname: Test docker build\n\njobs:\n  deploy:\n    name: Build\n    runs-on: ubuntu-latest\n    env:\n      IMAGE_NAME: docker.pkg.github.com\/${{ github.repository }}\/app\n      IMAGE_TAG: ${{ github.sha }}\n\n    steps:\n    - name: Checkout\n      uses: actions\/checkout@v2\n\n    - name: Login to GitHub Packages\n      env:\n        TOKEN: ${{ secrets.GITHUB_TOKEN }}\n      run: |\n        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN\n\n    - name: Build\n      run: |\n        docker build \n          -t $IMAGE_NAME:$IMAGE_TAG \n          -t $IMAGE_NAME:latest \n          .\n\n    - name: Push image to GitHub Packages\n      run: |\n        docker push $IMAGE_NAME:latest\n        docker push $IMAGE_NAME:$IMAGE_TAG\n\n    - name: Logout\n      run: |\n        docker logout docker.pkg.github.com<\/code><\/pre>\n
    <\/p>\n
    A imagem \u00e9 constru\u00edda e enviada para o GitHub Packages em duas minutos e 20 segundos:<\/p>\n
    <\/p>\n
    \"Dicas<\/p>\n
    <\/p>\n
    Agora vamos modificar a constru\u00e7\u00e3o para que use o cache baseado nas imagens constru\u00eddas anteriormente:<\/p>\n
    <\/p>\n
    on:\n  push:\n    branches:\n      - master\n\nname: Test docker build\n\njobs:\n  deploy:\n    name: Build\n    runs-on: ubuntu-latest\n    env:\n      IMAGE_NAME: docker.pkg.github.com\/${{ github.repository }}\/app\n      IMAGE_TAG: ${{ github.sha }}\n\n    steps:\n    - name: Checkout\n      uses: actions\/checkout@v2\n\n    - name: Login to GitHub Packages\n      env:\n        TOKEN: ${{ secrets.GITHUB_TOKEN }}\n      run: |\n        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN\n\n    - name: Pull latest images\n      run: |\n        docker pull $IMAGE_NAME:latest || true\n        docker pull $IMAGE_NAME-builder-stage:latest || true\n\n    - name: Images list\n      run: |\n        docker images\n\n    - name: Build\n      run: |\n        docker build \n          --target builder \n          --cache-from $IMAGE_NAME-builder-stage:latest \n          -t $IMAGE_NAME-builder-stage \n          .\n        docker build \n          --cache-from $IMAGE_NAME-builder-stage:latest \n          --cache-from $IMAGE_NAME:latest \n          -t $IMAGE_NAME:$IMAGE_TAG \n          -t $IMAGE_NAME:latest \n          .\n\n    - name: Push image to GitHub Packages\n      run: |\n        docker push $IMAGE_NAME-builder-stage:latest\n        docker push $IMAGE_NAME:latest\n        docker push $IMAGE_NAME:$IMAGE_TAG\n\n    - name: Logout\n      run: |\n        docker logout docker.pkg.github.com<\/code><\/pre>\n
    <\/p>\n
    Para come\u00e7ar, precisamos explicar por que s\u00e3o executados dois comandos build<\/code>. O fato \u00e9 que, em uma constru\u00e7\u00e3o de m\u00faltiplos est\u00e1gios, a imagem resultante ser\u00e1 um conjunto de camadas do \u00faltimo est\u00e1gio. As camadas dos est\u00e1gios anteriores n\u00e3o estar\u00e3o na imagem. Portanto, ao usar a imagem final da constru\u00e7\u00e3o anterior, o Docker n\u00e3o conseguir\u00e1 encontrar as camadas preparadas para a constru\u00e7\u00e3o da imagem com nodejs (est\u00e1gio builder). Para resolver esse problema, uma imagem intermedi\u00e1ria \u00e9 criada $IMAGE_NAME-builder-stage<\/code> e enviada para o GitHub Packages, para que possa ser usada em constru\u00e7\u00f5es futuras como fonte de cache.<\/p>\n
    <\/p>\n
    \"Dicas<\/p>\n
    <\/p>\n
    O tempo total de constru\u00e7\u00e3o foi reduzido para um minuto e meio. Trinta segundos s\u00e3o gastos puxando as imagens anteriores.<\/p>\n
    <\/p>\n
    Pr\u00e9-cria\u00e7\u00e3o de imagens<\/h2>\n
    <\/p>\n
    Outra maneira de resolver o problema do cache limpo do Docker \u00e9 mover parte das camadas para outro Dockerfile, constru\u00ed-lo separadamente, enviar para o Container Registry e us\u00e1-lo como pai.<\/p>\n
    <\/p>\n
    Criamos nossa imagem Node.js para compilar aplicativos Angular. Criamos um Dockerfile.node no projeto.<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++<\/code><\/pre>\n
    <\/p>\n
    Constru\u00edmos e enviamos a imagem p\u00fablica para o Docker Hub:<\/p>\n
    <\/p>\n
    docker build -t exsmund\/node-for-angular -f Dockerfile.node .\ndocker push exsmund\/node-for-angular:latest<\/code><\/pre>\n
    <\/p>\n
    Agora, em nosso Dockerfile principal, usamos a imagem pronta:<\/p>\n
    <\/p>\n
    FROM exsmund\/node-for-angular:latest as builder\n...<\/code><\/pre>\n
    <\/p>\n
    No nosso exemplo, o tempo de constru\u00e7\u00e3o n\u00e3o diminuiu, mas imagens pr\u00e9-criadas podem ser \u00fateis se voc\u00ea tiver muitos projetos e tiver que instalar depend\u00eancias iguais em cada um deles.<\/p>\n
    <\/p>\n
    \"Dicas<\/p>\n
    <\/p>\n
    Examinamos v\u00e1rios m\u00e9todos para acelerar a constru\u00e7\u00e3o de imagens Docker. Se voc\u00ea deseja que o deploy ocorra rapidamente, tente aplicar em seu projeto:<\/p>\n
    <\/p>\n