Forem: Matheus Andrade

Docker Images, Read-Only/Writable Layers, CoW e Dive

Matheus Andrade — Wed, 06 Jan 2021 15:29:43 +0000

Saudações!

No post anterior vimos a definição de imagens, além da conceituação de layers e como estas são intrínsecas ao assunto. Entendemos também a existência de filesystem layers, assim como empty layers no processo de formação de uma imagem, a partir de instruções (nem todas geram layers) de um Dockerfile.

O objetivo deste post é continuar dissecando o tema, com alguns estudos/experimentações que nos permitam entender mais como imagens Docker funcionam e são construídas.

TL;DR.

Em relação às filesystem layers, podemos categorizá-las em camadas ReadOnly ou Writable;
Camadas de Imagens são ReadOnly;
Camada do Container é Writable;
O CoW: Copy on Write acontece tanto no momento do build, quanto com um container em execução, quando há a necessidade de uma modificação em um arquivo/objeto;
Ferramentas externas como o Dive auxiliam no processo de análises das camadas.

Read-Only Layers e Writable Layers

Há uma relação indissociável entre imagem e layers. Neste ponto, já entendemos que uma imagem pode ser definida como um agrupamento ordenado de layers, sendo estas ultimas, modificações imutáveis resultados de instruções presentes no Dockerfile.

A palavra em destaque aqui nesta seção é imutabilidade, ou seja, a layer representa uma modificação realizada na imagem e esta modificação é permanente no contexto da *layer. Se desejarmos fazer uma segunda modificação, após a primeira já ter sido persistida, tal alteração estará registrada em uma *layer posterior.

Em resumo:

Layers de Imagens são **Read Only.**

Aqui também é importante destacar que uma filesystem layer possuirá persistido apenas os arquivos modificados em relação à camada anterior. Por isso, a ordenação das layers é importante.

E o que, ou melhor, de quem seria uma layer gravável? A resposta: Container!

Containers nada mais são (do ponto de vista de camadas e armazenamento), do que a adição de uma layer gravável sobre as layers que formam uma imagem. Quando um container é instanciado, uma nova camada, desta vez writable, é criada no topo da imagem (camadas read-only de formação). Quando o container morre (e deletado do host), a camada rw é destruída:

Container adiciona uma layer gravável sobre as layers que formam a imagem.


https://docs.docker.com/storage/storagedriver/images/sharing-layers.jpg

Neste ponto, já é possível perceber o ganho que obtemos, em relação ao espaço em disco consumido, ao instanciar vários containers (réplicas) oriundos de uma mesma imagem. Se instanciarmos 10 containers de uma imagem alpine, por exemplo, as layers read-only da imagem não serão multiplicadas por 10, mas sim reaproveitadas e 10 camadas writables serão criadas e associadas cada uma à um container em execução.

No Docker, temos 2 propriedades que nos mostram tais valores: size e virtual size:

size: o tamanho da camada gravável do container;
virtual size: o tamanho total das layers que fazem o container funcionar: image layers + writable layer.

No exemplo abaixo, 4 containers já encerrados, oriundos da imagem alpine, sendo que 3 não escreveram em sua camada writable (size 0) e 1 container teve escrita:

$ docker ps -as
CONTAINER ID   IMAGE     COMMAND   CREATED          STATUS                      PORTS     NAMES             SIZE
789d0f43e596   alpine    "sh"      6 seconds ago    Exited (0) 5 seconds ago              upbeat_rubin      0B (virtual 5.58MB)
fee34efca016   alpine    "sh"      10 seconds ago   Exited (0) 8 seconds ago              reverent_kalam    0B (virtual 5.58MB)
40c0882f562d   alpine    "sh"      14 seconds ago   Exited (0) 12 seconds ago             upbeat_sinoussi   0B (virtual 5.58MB)
90b23b31f6aa   alpine    "sh"      56 seconds ago   Exited (0) 29 seconds ago             musing_swirles    6.89MB (virtual 12.5MB)

Quanto de espaço em disco total estamos consumindo em nosso host, em relação às layers? A respostá é 12,5Mb.

CoW: Copy on Write

Agora que sabemos quais layers são read-only e quais são read-write, vamos meter mão na massa para entender um conceito: CoW.

Tomemos como exemplo o conteúdo do arquivo file1.txt e do Dockerfile:

#file1.txt
Primeira linha

#Dockerfile
FROM alpine
WORKDIR /exemplo
COPY file1.txt .
RUN echo "segunda linha" >> file1.txt

Realizando o build da imagem:

$ docker build -t exemplo:01 .

Step 1/4 : FROM alpine
latest: Pulling from library/alpine
801bfaa63ef2: Pull complete
Digest: sha256:3c7497bf0c7af93428242d6176e8f7905f2201d8fc5861f45be7a346b5f23436
Status: Downloaded newer image for alpine:latest
 ---> 389fef711851
Step 2/4 : WORKDIR /exemplo
 ---> Running in 90cd105624a7
Removing intermediate container 90cd105624a7
 ---> f1b5e463de89
Step 3/4 : COPY file1.txt .
 ---> 6d149ef7f9fd
Step 4/4 : RUN echo "segunda linha" >> file1.txt
 ---> Running in 536635e86c81
Removing intermediate container 536635e86c81
 ---> c741d831be62
Successfully built c741d831be62
Successfully tagged exemplo:01

Tranquilo perceber que as 4 instruções criaram layers e que todas elas são filesystem layers, concorda? Nossa imagem, no final, possui 05 layers sendo 02 provenientes da imagem alpine (instrução FROM) e 3 layers das instruções adicionais:

$ docker image history exemplo:01

IMAGE          CREATED              CREATED BY                                      SIZE      COMMENT
c741d831be62   About a minute ago   /bin/sh -c echo "segunda linha" >> file1.txt    29B
6d149ef7f9fd   About a minute ago   /bin/sh -c #(nop) COPY file:91615d60f2e8bc41…   15B
f1b5e463de89   About a minute ago   /bin/sh -c #(nop) WORKDIR /exemplo              0B
389fef711851   2 weeks ago          /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      2 weeks ago          /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

$ docker image inspect exemplo:01 --format='{{.RootFS}}'

{layers [
    sha256:777b2c648970480f50f5b4d0af8f9a8ea798eea43dbcf40ce4a8c7118736bdcf 
    sha256:cd894f30417890083791614709bacc9b0f771366be38bda720ea6f622b02ad1c 
    sha256:8062d1a8dd2c9a137a8d0e90bff7d94511f014bb37f8fafb22edad46b4ca2cbe 
    sha256:2bc55ad19ad6d5fb5992402b70becd7e6973dc69ed10ce36a59681815cf9bd78
    ]
}

Olhemos as nossas 4 filesystem layers armazenadas em nosso diretório de armazenamento das layers no Docker:

$ ll /var/lib/docker/overlay2
drwx------. 5 matheus root     69 Jan  2 10a4d6010850c9ea40dc684d7ec90d5e0cf90d790d06b8be9365f54465bd426c
drwx------. 5 matheus root     69 Jan  2 14be73d49e9d43672ee62a42250873a6eb4d8994d28d7f2d40228dc548de3735
drwx------. 5 matheus root     69 Jan  2 86899162aaea64b2c0e2ab86279f4f21d41317bbe9566df29d6362cb770c2bff
drwx------. 5 matheus root     69 Jan  2 aada6a14754e4e648f22adcc5f92b2c744dbc0e12db5f5f622300db6127a0046
drwx------. 2 matheus root   8192 Jan  9 l

A layer do alpine é a pasta 14be73d49e9d43... e temos parte de seu conteúdo mostrado abaixo:

$ ll /var/lib/docker/overlay2/14be73d49e9d43672ee62a42250873a6eb4d8994d28d7f2d40228dc548de3735/diff
drwx------. 5 matheus root     69 Jan  2 bin
drwx------. 5 matheus root     69 Jan  2 dev
drwx------. 5 matheus root     69 Jan  2 etc
drwx------. 5 matheus root     69 Jan  2 home
drwx------. 5 matheus root     69 Jan  2 lib
drwx------. 5 matheus root     69 Jan  2 media
drwx------. 5 matheus root     69 Jan  2 mnt
...

A conteúdo gerado pela instrução WORKDIR /exemplo apenas criou a pasta:

$ ll /var/lib/docker/overlay2/10a4d6010850c9ea40dc684d7ec90d5e0cf90d790d06b8be9365f54465bd426c/diff
drwx------. 5 matheus root     69 Jan  2 exemplo


$ ll /var/lib/docker/overlay2/10a4d6010850c9ea40dc684d7ec90d5e0cf90d790d06b8be9365f54465bd426c/diff/exemplo
drwx------. 5 matheus root     69 Jan  2 ./
drwx------. 5 matheus root     69 Jan  2 ../

Já na layer 86899162a..., temos o arquivo copiado pela instrução COPY file1.txt:

$ ll /var/lib/docker/overlay2/86899162aaea64b2c0e2ab86279f4f21d41317bbe9566df29d6362cb770c2bff/diff/exemplo/
-rwx------. 5 matheus root     69 Jan  2 file1.txt

$ cat /var/lib/docker/overlay2/86899162aaea64b2c0e2ab86279f4f21d41317bbe9566df29d6362cb770c2bff/diff/exemplo/file1.txt
primeira linha

Enquanto na layer pertencente à instrução RUN, temos o novo arquivo file1.txt persistido:

$ ll /var/lib/docker/overlay2/aada6a14754e4e648f22adcc5f92b2c744dbc0e12db5f5f622300db6127a0046/diff/exemplo/
-rwx------. 5 matheus root     69 Jan  2 file1.txt


$ cat /var/lib/docker/overlay2/aada6a14754e4e648f22adcc5f92b2c744dbc0e12db5f5f622300db6127a0046/diff/exemplo/file1.txt
primeira linha
segunda linha

Perceba que o arquivo file1.txt está presente em 2 layers diferentes e por conseguinte em 2 diretórios no filesystem, pois foi "tocado" por 2 instruções que o criou/modificou.

CoW é exatamente este comportamento: Copy on Write. Quando uma layer precisa modificar um arquivo/diretório, este é copiado para dentro da nova layer e então, modificado. Já quando há apenas leitura de um objeto, esta ação é realizada na layer em que o arquivo/diretório é encontrado.

O exemplo acima mostrou o CoW no momento do build de uma imagem, mas o processo também acontece quando um container está em execução e precisa modificar um arquivo/dietório, afinal, o container também possui sua layer, lembra? O objeto é copiado para a top layer (container) e nela realizadas suas modificações.

Veja o exemplo abaixo, em que é instanciado um container a partir da imagem exemplo:01, que altera o arquivo file1.txt:

$ docker container run exemplo:01 /bin/sh -c 'echo "linha escrita pelo container" >> /exemplo/file1.txt'

O container acima é instanciado e por causa de sua instrução, copia o arquivo para sua layer e efetua a modificação. Podemos ver a layer do container abaixo:

$ ll /var/lib/docker/overlay2/cdc6c284aef2e9dfac02c905c2aa3dda3d9e11d3ef37bd9d2d15fe4429dd9519/diff/exemplo/
-rwx------. 5 matheus root     69 Jan  2 file1.txt


$ cat /var/lib/docker/overlay2/cdc6c284aef2e9dfac02c905c2aa3dda3d9e11d3ef37bd9d2d15fe4429dd9519/diff/exemplo/file1.txt
primeira linha
segunda linha
linha escrita pelo container

Enquanto o container estiver presente no host, sua layer estará também presente (e consumindo espaço em disco).

CoW acontece tanto no momento do build de uma imagem, quanto na execução de um container, quando este precisa alterar um arquivo/diretório.

Aqui neste ponto, já podemos pensar que é uma boa prática, reduzir ao máximo o número de layers em que um arquivo aparece, ou seja, concentrar o máximo possível as modificações de um arquivo na mesma layer que o criou, para evitar aumento de espaço em disco. Nem sempre é possível, mas quanto mais alcançar tal objetivo, melhor a utilização/consumo de espaço.

Um outro aprendizado que podemos ter é que a camada do container inicia-se sempre com o menor tamanho possível, e somente quando precisa-se modificar um objeto, há o aumento de tamanho desta camada.

OBS: o modo como o Copy on Write é implementado pode variar a depender do Storage Driver implementado. Entretanto, a estratégia e objetivo é sempre este: leitura na camada onde o objeto se encontra em seu estado mais recente (de acordo com a ordem das camadas na imagem) e cópia do objeto para a alteração.

Dive: Visualizando melhor as Layers

Neste post e em outros, sempre recorri à comandos docker como history ou inspect para visualizar as layers, além claro, de visualizar as modificações no filesystem lá no diretório /var/lib/docker/overlay2.

O Dive é uma ferramenta externa bem legal que auxilia bastante na exploração de uma imagem docker, conteúdo das camadas, além de ajudar na descoberta de alternativas para melhorar o tamanho de suas imagens. O legal é que você pode rodar ela como container!

Uma vez instalado o Dive, basta apenas chamar ele passando a imagem: dive <image>.

Página da ferramenta Dive: https://github.com/wagoodman/dive

Vamos utilizar o Dive em container. Para melhorar a usabilidade, eu criei o seguinte alias:

alias dive='sudo docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive'

E agora, posso analisar a imagem exemplo:01:

$ dive imagem:01

A saída é no próprio terminal, onde vc tem várias opções para melhorar a análise e investigação das layers. Na imagem abaixo, analisando a layer referente à instrução COPYde nossa imagem, consigo visualizar quais arquivos foram adicionados/removidos/modificados, inclusive com destaque de cores para cada cenário.

Vale a pena conferir!


Analisando a imagem exemplo:01 com o Dive

Conclusão

Em grandes empresas, com muitos times, produtos e/ou serviços, a tendência é uma alta quantidade de imagens gerenciadas. Para que isso não vire um problema, atentar-se para o tamanho das imagens, a relação entre elas (imagens que são construídas a partir de outras), o número de layers que as formam, além de claro, como cada layer é construída são alguns pontos de atenção. Um melhor entendimento sobre Layers e suas categorizações podem auxiliar nos processos de trabalho sobre estes pontos.

Abraços!

Post originalmente publicado em meu site pessoal
https://matheuslao.dev/posts/docker-images-ro-rw-layers-cow-dive/

Docker Images, Empty Layers e FileSystem Layers

Matheus Andrade — Sat, 02 Jan 2021 15:14:01 +0000

Saudações!

Containers não são mais novidades. Hoje, Devs e Ops lidam diariamente com aplicações containerizadas e são responsáveis pela construção da imagem da aplicação a ser implantada em produção.

Mas, como anda o processo de construção das imagens das aplicações de sua empresa? Todos os membros do time compreendem o que acontece no building de uma imagem? Há uma busca por otimizações em reaproveitamento, consumo de espaço em disco, processos de atualização das imagens de todos os apps?

Entender imagens (de containers) e construí-las de forma otimizada não é tão trivial para um iniciante no assunto, mas também nada tão difícil. Pensando nisso, tentarei publicar em alguns posts informações que achei interessante durante meu aprendizado.

O assunto desta publicação é Layers, principalmente por causa de uma dúvida que aparece muito nas equipes de trabalho:

Afinal, quais instruções do Dockerfile geram Layers e/ou aumentam o espaço em disco consumido?

TL;DR

O conceito de layers nem sempre está atrelado à existência de alterações no sistema de arquivos (filesystem layers);
Nem todas as instruções do Dockerfile geram layers (sejam quais forem) . Exemplo: instrução ARG;
Nem sempre a instrução RUN gera uma filesystem layer, como aparentemente indica a documentação;
Outras instruções podem gerar uma filesystem layer como a WORKDIR, e não somente RUN, COPY e ADD como, aparentemente, indica uma página da documentação.
Atentar-se sempre ao contexto da palavra layer presente nos livros, documentação, etc., pois podem referenciar somente filesystem layers.

O que é uma Imagem Docker?

Fui procurar na documentação oficial da Docker o conceito de imagem. No Glossário, temos a seguinte definição:

"Docker images are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered filesystems stacked on top of each other. An image does not have state and it never changes."

Praticamente diz tudo. Aqui deixo a minha tradução livre:

coleção ordenada de mudanças imutáveis no sistema de arquivos mais parâmetros de execução em camadas empilhadas umas sobre as outras;

Na grande maioria dos casos, estas camadas são construídas através das instruções presentes no famoso arquivo Dockerfile.


Fonte: https://medium.com/platformer-blog/practical-guide-on-writing-a-dockerfile-for-your-application-89376f88b3b5

PS: Não gosto nem de lembrar, mas temos que assumir que existe outro método de gerar imagens, a partir de containers: docker commit. :D

O que são Layers?

Recorrendo novamente ao Glossário do Docker temos:

"In an image, a layer is modification to the image, represented by an instruction in the Dockerfile. Layers are applied in sequence to the base image to create the final image. When an image is updated or rebuilt, only layers that change need to be updated, and unchanged layers are cached locally. This is part of why Docker images are so fast and lightweight. The sizes of each layer add up to equal the size of the final image."

Aqui, mais uma vez, deixo minha tradução livre e resumida do que considero importante:

Modificação da imagem representada por uma instrução do Dockerfile aplicadas em sequência à imagem base para criar outra imagem final.

Repare que é bem sutil (e por isso, confuso numa primeira vez) o conceito de Layer e Imagem. Muitas vezes usamos a definição de layer para imagem, concorda?

Podemos, por exemplo, afirmar que 1 layer é uma imagem intermediária, já que o empilhamento ordenado de N camadas representará a imagem final.

Guardemos, por ora, que uma imagem é um agrupamento ordenado de layers e estas são as modificações imutáveis, resultados de instruções presentes no Dockerfile.

Layers: Quantas são?

Vamos visualizar, metendo a "mão na massa"! Baixemos uma das imagens mais famosas (e menores) que existem:

$ docker image pull alpine
Using default tag: latest
latest: Pulling from library/alpine
801bfaa63ef2: Pulling fs layer
801bfaa63ef2: Verifying Checksum
801bfaa63ef2: Download complete
801bfaa63ef2: Pull complete
Digest: sha256:3c7497bf0c7af93428242d6176e8f7905f2201d8fc5861f45be7a346b5f23436
Status: Downloaded newer image for alpine:latest
docker.io/library/alpine:latest

Pela saída de texto do comando acima executado, podemos verificar que 1 layer, identificada pelo hash 801bfaa63ef2, foi baixada. Vamos rodar o comando inspect, fazendo um filtro no formato de saída:

$ docker image inspect alpine --format='{{.RootFS}}'
{layers [sha256:777b2c648970480f50f5b4d0af8f9a8ea798eea43dbcf40ce4a8c7118736bdcf] }

O retorno também é 1 layer, identificada por um hash sha256. Se formos mais curiosos, encontraremos a camada baixada no sistema de arquivos, onde o Docker a armazena (usando Linux, storage driver overlay2 e sem alteração do local de instalação do Docker):

$ ll /var/lib/docker/overlay2/
drwx------. 5 matheus root     69 Oct 19 b29be06af013d08aa3a729693e9368e2b43f3a7fd4de362caaaee93ef3dc2c59
drwx------. 2 matheus root   8192 Nov  9 l

Perceba que apenas 1 pasta identificada por um hash está presente. E despreze que os hashes não batem, pois não é mesmo pra acontecer.

Agora, vamos utilizar o comando history para dissecar um pouco mais a imagem:

$ docker image history alpine
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
389fef711851   2 weeks ago   /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      2 weeks ago   /bin/sh -c #(nop) ADD file:ec475c2abb2d46435ÔÇª   5.58MB

Desprezando a falta do identificador da layer mais baixa (<missing> que explicarei em outro post), verificamos que a imagem alpine é composta por 2 layers, cujas instruções de construção são:

ADD file:a4845c3840a3fd0e41e4635a179cce20c81afc6c02e34e3fd5bd2d535698918b in / 
CMD ["/bin/sh"]

Podemos confirmar também lá no Docker Hub:


Visualizando as camadas da imagem alpine:latest no Docker Hub

E agora? 1 ou 2 camadas na imagem alpine?

Empty Layers e FileSystem Layers

A resposta para a pergunta anterior é: 2 camadas!

A "pegadinha" acontece que apenas 1 camada gera persistência, alteração no sistema de arquivos, enquanto a outra camada é "vazia" em modificação/alteração do filesystem.

Neste ponto, podemos dizer que a camada que vemos o docker pull baixar (a mesma vista no inspect e presente no /var/lib/docker/overlay) pode ser categorizada como uma FS layer, ou seja, uma camada de sistema de arquivos. Já a camada construída pela instrução CMD ["/bin/sh"] pode ser categorizada como uma Empty Layer, pois não gera alteração no filesystem, não consumindo espaço, e portanto, não sendo baixada.

Aqui que reside a confusão conceitual de Layers. Em versões anteriores do Docker e de construção de imagens, as layers sempre estavam associadas à modificações no filesystem. Contudo, em versões atuais, há instruções presentes no Dockerfile que não alteram o filesystem e precisam ser definidas como layers, pois fazem parte do processo de construção (empilhamento ordenado de instruções) de uma imagem.

Lembre-se das definições atuais de Imagens e Layers lá do Glossário do Docker:

imagens: coleção ordenada de mudanças no filesystem e parâmetros de execução;
layers: modificação da imagem, através de uma instrução.

Todas instruções do Dockerfile geram Layers?

Aqui, mais uma vez, vamos meter mão na massa!

Em uma página da documentação oficial do Docker que versa sobre boas práticas no processo de construção de imagens, temos a seguinte informação:

"Only the instructions RUN, COPY, ADD create layers. Other instructions create temporary intermediate images, and do not increase the size of the build."

Opa, respondido? Talvez. Uma leitura mais atenta e você pode notar que:

RUN, COPY, ADD criam layers;
outras instruções criam temporary intermediate images.

Pelo que já apresentamos, podemos definir layers como imagens intermediárias, logo, determinadas instruções criariam camadas temporárias que não aumentariam o espaço consumido do build.

Repare que aqui a documentação nos confunde com o conceito de layers: somente RUN, COPY e ADD criam filesystem layers, enquanto outras não (empty layers).

Neste ponto, gostaria de levantar alguma dúvidas para testarmos/validarmos, pois me confundiu muito no início:

Dúvida 01: A instrução RUN sempre vai gerar uma FS Layer ?
Dúvida 02: A instrução WORKDIR quando cria um novo path (uma alteração no filesystem), geraria uma FS Layer?
Dúvida 03: Alguma instrução do Dockerfile não gera Layer (seja filesystem layers ou empty layers)?

Vamos testar algumas das principais instruções de utilização na construção de imagens docker para validar os conceitos apresentados e hipóteses levantadas. Todas as instruções possíveis estão presentes no Dockerfile Reference.

Tomemos como exemplo o Dockerfile abaixo onde tentei utilizar as instruções mais conhecidas:

ARG  VERSION=latest
FROM alpine:${VERSION}
LABEL mantainer="matheuslao.dev"
ENV URL "https://artefatos.empresa.com.br/app-1.2.3.jar"
WORKDIR /
RUN addgroup -g 10001 francisco && adduser -u 10001 francisco -G francisco -s /sbin/nologin --disabled-password
RUN apk add curl \
    && curl -o app.jar $URL
WORKDIR /myapp
COPY file1.txt .
ADD file2.txt .
RUN export USER="francisco" \
    && echo $USER
USER francisco
CMD ["/bin/sh"]
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]
EXPOSE 80

Analisemos o resultado do build da imagem (saída do comando sem o buildkit):

$ docker image build -t minha-imagem .

Sending build context to Docker daemon  4.608kB
Step 1/15 : ARG  VERSION=latest
Step 2/15 : FROM alpine:${VERSION}
 ---> 389fef711851
Step 3/15 : LABEL mantainer="matheuslao.dev"
 ---> Running in 7b372ffdfc95
Removing intermediate container 7b372ffdfc95
 ---> 6a5c0a8519d8
Step 4/15 : ENV URL "https://raw.githubusercontent.com/matheuslao/matheuslao.dev/main/static/img/matheuslao.jpg"
 ---> Running in c376576063ff
Removing intermediate container c376576063ff
 ---> 12828b25bdff
Step 5/15 : WORKDIR /
 ---> Running in 65cf9d3a17bb
Removing intermediate container 65cf9d3a17bb
 ---> e3d131d4c8f9
Step 6/15 : RUN addgroup -g 10001 francisco && adduser -u 10001 francisco -G francisco -s /sbin/nologin --disabled-password
 ---> Running in 1144c1a690da
Removing intermediate container 1144c1a690da
 ---> 370ee1418f66
Step 7/15 : RUN apk add curl     && curl -o app.jar $URL
 ---> Running in aee90a4a5f09
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20191127-r4)
(2/4) Installing nghttp2-libs (1.41.0-r0)
(3/4) Installing libcurl (7.69.1-r3)
(4/4) Installing curl (7.69.1-r3)
Executing busybox-1.31.1-r19.trigger
Executing ca-certificates-20191127-r4.trigger
OK: 7 MiB in 18 packages
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 21926  100 21926    0     0  32872      0 --:--:-- --:--:-- --:--:-- 32823
Removing intermediate container aee90a4a5f09
 ---> 5afd3449a399
Step 8/15 : WORKDIR /myapp
 ---> Running in 1e1d3f15d239
Removing intermediate container 1e1d3f15d239
 ---> d1ccd41ed16e
Step 9/15 : COPY file1.txt .
 ---> 476f0884009f
Step 10/15 : ADD file2.txt .
 ---> 8e8b4ed9127d
Step 11/15 : RUN export USER="francisco"     && echo $USER
 ---> Running in ca95419bbf81
francisco
Removing intermediate container ca95419bbf81
 ---> 4b75a0feb0de
Step 12/15 : USER francisco
 ---> Running in a510fe377aff
Removing intermediate container a510fe377aff
 ---> 562d417df13d
Step 13/15 : CMD ["/bin/sh"]
 ---> Running in c7db6aabcd80
Removing intermediate container c7db6aabcd80
 ---> 0054ff10e607
Step 14/15 : ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]
 ---> Running in fc1f9065fc21
Removing intermediate container fc1f9065fc21
 ---> 5c7cd86d14a3
Step 15/15 : EXPOSE 80
 ---> Running in fa19fc0c27e3
Removing intermediate container fa19fc0c27e3
 ---> 986b3c714918
Successfully built 986b3c714918
Successfully tagged minha-imagem:latest

São 15 instruções em nosso Dockerfile que geram 15 steps (passos) no build:

Step 1/15: Repare que nenhuma informação adicional é gerada como a criação/geração de uma layer;
Step 2/15: A FS Layer da imagem alpine é referenciada aqui (mas já sabemos que no fundo, a imagem alpine possui 2 layers);
Step 3/15: Um container de hash 7b372ffdfc95 sobe, executa a instrução, morre e uma layer de hash 6a5c0a8519d8 é gerada;
Step 4/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 5/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 6/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 7/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 8/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 9/15: Uma layer é gerada com a transferência do arquivo copiado;
Step 10/15: Uma layer é gerada com a transferência do arquivo adicionado;
Step 11/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 12/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 13/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 14/15: Um container sobe, executa a instrução, morre e uma layer é gerada;
Step 15/15: Um container sobe, executa a instrução, morre e uma layer é gerada;

A Dúvida 03 já tem um candidato para a resposta:

Com exceção da instrução ARG, todas as outras utilizadas geraram layers.

Vamos utilizar o history para validar/confirmar:

$ docker image history minha-imagem

IMAGE          CREATED              CREATED BY                                      SIZE      COMMENT
9f338caaa516   About a minute ago   /bin/sh -c #(nop)  EXPOSE 80                    0B
6449ad4000e5   About a minute ago   /bin/sh -c #(nop)  ENTRYPOINT ["java" "-XX:+…   0B
65a889958083   About a minute ago   /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
1abacd6cfbe6   About a minute ago   /bin/sh -c #(nop)  USER francisco               0B
2a1a85501e97   About a minute ago   /bin/sh -c export USER="francisco"     && ec…   0B
f055068ccc6c   About a minute ago   /bin/sh -c #(nop) ADD file:328c2a0fff8f5e953…   10B
6085fb888a33   About a minute ago   /bin/sh -c #(nop) COPY file:bb441069227b280c…   10B
cba01884fddf   About a minute ago   /bin/sh -c #(nop) WORKDIR /myapp                0B
9a12d9d412ae   About a minute ago   /bin/sh -c apk add curl     && curl -o app.j…   3.12MB
8f54af3a2563   About a minute ago   /bin/sh -c addgroup -g 10001 francisco && ad…   4.7kB
cb8c60e24f29   About a minute ago   /bin/sh -c #(nop) WORKDIR /                     0B
bfe0e88f7ca5   About a minute ago   /bin/sh -c #(nop)  ENV URL=https://raw.githu…   0B
d1ba00e0a9d5   About a minute ago   /bin/sh -c #(nop)  LABEL mantainer=matheusla…   0B
389fef711851   2 weeks ago          /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      2 weeks ago          /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

É fácil visualizar a presença de 16 layers, concorda? Também não é dificíl dizer que as 2 primeiras layers (de baixo pra cima) são as layers da imagem base alpine. Assim, temos 14 layers registradas adicionalmente (ordenadas e empilhadas conforme instruções) que batem com os 14 steps que geraram-as.

Analisemos agora o tamanho das layers. Baseado na experiência anterior, afirmaríamos que 05 são FS Layers, pois possuem tamanho > 0.

Vamos validar?

$ docker image inspect minha-imagem --format='{{.RootFS}}'

{layers [
    sha256:777b2c648970480f50f5b4d0af8f9a8ea798eea43dbcf40ce4a8c7118736bdcf 
    sha256:9caf12dafc34f81365ffeefa58af5c52eb19e6e58260158f8931f51223a025a6 
    sha256:e184369701b73ed92ccb30cb4e4f34cc817a6093bfb35ec6b6a9a36946f841fd 
    sha256:ac91c339ff12c9965379a1eeac8ff51cdf9a4f1d3f229316650aa4d7e2d81bc3 
    sha256:3449aa1a02c6e90dae7e4785fd52b5b1b09128ee73e88f76fa6149fb2746bfe2 
    sha256:cfbf011495adad103cc9c9b6c7f8d9525427a3f90b34d49a6db1cf5cde812f09
    ]
}

Oh, não! São 06 camadas!

Vamos procurar lá em nossa pasta /var/lib/docker/overlay2:

$ ll /var/lib/docker/overlay2/
drwx------. 5 matheus root     69 Oct 19 b29be06af013d08aa3a729693e9368e2b43f3a7fd4de362caaaee93ef3dc2c59
drwx------. 5 matheus root     69 Oct 19 6efd98d05213572a70e59f16840758d6072c7298f42621609cd7b286354cda9b
drwx------. 5 matheus root     69 Oct 19 46b740c355ed78e37fa9f6af8a94c23f63b1ed00d98e797d9468e557d67620f4
drwx------. 5 matheus root     69 Oct 19 090b364761d9bd50b7d634cf3aecd17794a8264d24d430c198e69deea5d54f5c
drwx------. 5 matheus root     69 Oct 19 335aa592cb4a89b7165017f78c7b01a0b92c5df78a91c9ceb569c56520f13329
drwx------. 5 matheus root     69 Oct 19 d7f4b90503fa2bba199564c7714d553080bb45ed1425501da8cdd698208a0803
drwx------. 2 matheus root   8192 Nov  9 l

Novamente, 06 camadas!

Tínhamos uma hipótese se a instrução WORKDIR quando cria um diretório não existente resultaria em uma camada de persistência. Pois bem, apesar do tamanho mostrado lá no comando history estar SIZE 0, a instrução WORKDIR /myapp de nosso Dockerfile cria uma camada no filesystem para persistir.

Se olharmos o diffde cada camada (explicarei em outro post), encontrarei uma que representa a instrução em questão. Em nosso exemplo, foi a seguinte layer:

ll /var/lib/docker/overlay2/6efd98d05213572a70e59f16840758d6072c7298f42621609cd7b286354cda9b/diff
drwx------. 5 matheus root     69 Oct 19 myapp

ll /var/lib/docker/overlay2/6efd98d05213572a70e59f16840758d6072c7298f42621609cd7b286354cda9b/diff/myapp/
drwx------. 5 matheus root     69 Oct 19 ./
drwx------. 5 matheus root     69 Oct 19 ../

Assim, a Dúvida 02 é respondida com um SIM.

Por fim, podemos também responder a Dúvida 01. Repare que o Step 11/15, que é a instrução RUN executando um export e um echo gera uma layer de tamanho zero. Se você tentar procurar no sistema de arquivos, não vai achar a representação desta instrução também. Assim, podemos perceber que nem sempre a instrução RUN vai alterar o sistema de arquivos e consequentemente persistir em uma camada FS Layer, consumindo espaço em disco.

Conclusão

Com a popularização da containerização, entender um pouco mais como dá-se a construção e formação das imagens pode proporcionar condições de melhorias futuras no processo de desenvolvimento e implantação das aplicações.

Vimos que, para entender o que é uma Imagem Docker, precisamos internalizar o conceito de Layer, parte fundamental e indissociável de sua formação. Também faz-se importante destacar a interpretação correta e o contexto do termo layer presentes em livros, documentações, etc, pois muitas vezes referenciam somente à um tipo de layer: aquelas que criam alterações em sistemas de arquivos, consumindo espaço em disco. Contudo, sabemos que na formação de Imagens Docker, há layers que não geram persistência, mas sim, guardam outras informações cruciais e indispensáveis para a caracterização de uma imagem final.

Abraços!

Post originalmente publicado em meu site pessoal https://matheuslao.dev/posts/docker-imagens-empty-filesystem-layers/

06 Exemplos de Uso de Credenciais (04 não recomendadas) durante o Build de Imagens Docker

Matheus Andrade — Wed, 23 Dec 2020 18:59:52 +0000

Em quase todo o processo de construção de imagens Docker, há a necessidade de baixar artefatos (ex: zip, war, jar, etc.) de alguma URL para compor a imagem de nossa aplicação. Por vezes, estas URLs exigem autenticação e precisamos de credenciais para ter acesso ao conteúdo.

Como construir imagens Docker sem comprometer credenciais, como usuários e senhas de acesso?

Os exemplos abaixo seguirão uma ordem, aparentemente natural de boas práticas, onde há uma preocupação em não expor informação sensível na imagem Docker gerada, além de continuar garantindo sua portabilidade.

O Desafio: Contextualizando a situação

Suponha que tenhamos a missão de construir a imagem de uma simples aplicação Java, cujo artefato buildado encontra-se disponível em uma URL que é o repositório de artefatos de sua empresa. (https://artefatos.empresa.com.br/)

Detalhe 01 : a URL do repositório exige autenticação e você possui as credenciais de acesso.

Detalhe 02 : a imagem será compatilhada para outras empresas/clientes implantarem a aplicação.

Exemplo 01: Codando "na mão grande" as credenciais

Eu nem deveria começar por este exemplo, porque acredito que ninguém deve fazer assim. Contudo, vamos evoluindo exemplo a exemplo. Analisemos o Dockerfile abaixo:

FROM alpine
WORKDIR /
RUN apk add curl
RUN curl -u francisco:abc123 -o app.jar "https://artefatos.empresa.com.br/app-1.2.3.jar"
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

Se preocupe somente com a segunda linha da intrução RUN, onde foi escrito literalmente as credenciais de acesso. Nem preciso dizer que isso aqui é bem ruim, não é? Mas vamos buildar a imagem e taguear com uma versão:

docker build -t app:01 .

A partir da imagem gerada (e que será distribuída para outras pessoas), façamos uma inspeção:

docker image history app:01

Está lá, para todo o mundo ver, as credenciais de acesso:

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
e4d60e8650d7   2 minutes ago   /bin/sh -c #(nop)  ENTRYPOINT ["java" "-XX:+…   0B
68e3c9068540   2 minutes ago   /bin/sh -c curl -u francisco:abc123 -o app.j…   1.23kB
c1a9701b7132   5 minutes ago   /bin/sh -c apk add curl                         3.1MB
c44f6da443d7   5 minutes ago   /bin/sh -c #(nop) WORKDIR /                     0B
389fef711851   6 days ago      /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      6 days ago      /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

Exemplo 02: Usando ENVs para as credenciais

Uma evolução do exemplo acima, seria a tentativa de buildar a imagem com a utilização de ENVs. Segue o Dockerfile:

FROM alpine
ENV USER francisco
ENV PASSWORD abc123
WORKDIR /
RUN apk add curl
RUN curl -u $USER:$PASSWORD -o app.jar "https://artefatos.empresa.com.br/app-1.2.3.jar"
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

Possa ser que você ache que agora não vai persistir as credenciais de acesso, pois leu que a instrução ENV não cria layer na imagem. Vamos conferir?

docker build -t app:02 .

Inspecionando a imagem com o comando docker image inspect app:02:

[...]
 "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "USER=francisco",
                "PASSWORD=abc123"
            ],
            "Cmd": null,
[...]

E com o mesmo comando do exemplo anterior docker image history:

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
284ee6fffad5   3 minutes ago   /bin/sh -c #(nop)  ENTRYPOINT ["java" "-XX:+…"   0B
904ec10bf219   3 minutes ago   /bin/sh -c curl -u $USER:$PASSWORD -o app.ja…   14B
cc4d45436465   3 minutes ago   /bin/sh -c apk add curl                         3.1MB
35e0fe7f8c92   3 minutes ago   /bin/sh -c #(nop) WORKDIR /                     0B
51c378578679   3 minutes ago   /bin/sh -c #(nop)  ENV PASSWORD=abc123          0B
9ab41a3c7fa5   3 minutes ago   /bin/sh -c #(nop)  ENV USER=francisco           0B
389fef711851   6 days ago      /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      6 days ago      /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

Abordarei em outro post, com mais detalhes, as questões de quando layers são geradas ou não. Por enquanto, nos atentemos que é possível a identificação/visualização das credencenciais com a inspeção da imagem gerada.

Código 03: Usando variáveis de ambiente e RUN em uma mesma LAYER

Nova ideia: utilizar variáveis de ambiente junto instrução RUN para a construção de uma única camada (layer) da imagem. O novo Dockerfile ficaria assim:

FROM alpine
WORKDIR /
RUN apk add curl
RUN export USER="francisco" \
    && export PASSWORD="abc123" \
    && curl -u $USER:$PASSWORD -o app.jar "https://artefatos.empresa.com.br/app-1.2.3.jar"
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

Gerando versão 03 da aplicação:

docker build -t app:03

E vamos conferir o resultado, analisando a imagem gerada com o docker image history:

IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
406c7ce82cf0   37 seconds ago   /bin/sh -c #(nop)  ENTRYPOINT ["java" "-XX:+…   0B
325c0a507c68   37 seconds ago   /bin/sh -c export USER="francisco" && export …  14B
c1a9701b7132   24 minutes ago   /bin/sh -c apk add curl                         3.1MB
c44f6da443d7   24 minutes ago   /bin/sh -c #(nop) WORKDIR /                     0B
389fef711851   6 days ago       /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      6 days ago       /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

É... também não deu certo. :(

Código 04: Usando ARGS

Conhecemos o atributo ARGS, 'similar' a ENV, e percebemos que podemos ganhar uma mobilidade ao passar as credenciais de acesso no comando de execução do build da imagem (não ter as credenciais escritas no Dockerfile!)

FROM alpine
ARG USER=fake
ARG PASSWORD=fake
WORKDIR /
RUN apk add curl
RUN curl -u $USER:$PASSWORD -o app.jar "https://artefatos.empresa.com.br/app-1.2.3.jar"
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

E o comando para buildar a imagem seria:

docker build --build-arg USER=francisco --build-arg PASSWORD=abc123 -t app:04 .

Contudo, ao analisar a imagem com o docker image history:

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
e9956a610c1f   5 minutes ago   /bin/sh -c #(nop)  ENTRYPOINT ["java" "-XX:+…   0B
4bcdfdea08f9   5 minutes ago   |2 PASSWORD=abc123 USER=francisco /bin/sh -c…   14B
1f56fb7ca086   5 minutes ago   |2 PASSWORD=abc123 USER=francisco /bin/sh -c…   3.1MB
0ccf29f3aadf   5 minutes ago   /bin/sh -c #(nop) WORKDIR /                     0B
556f62d21750   5 minutes ago   /bin/sh -c #(nop)  ARG PASSWORD=fake            0B
a726e9660660   5 minutes ago   /bin/sh -c #(nop)  ARG USER=fake                0B
389fef711851   6 days ago      /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      6 days ago      /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

Se olharmos a documentação neste link, perceberemos que aconteceu exatamente como o descrito: credenciais ainda visíveis.

Código 05: Adicionando Script auxiliar

Podemos tentar fazer um workaround: utilizar um script intermediário para auxiliar no download do artefato, atrás de uma URL autenticada. Nosso projeto agora ficaria com os seguintes arquivos:

Dockerfile
build.sh

Conteúdo do build.sh:

#!/bin/sh
curl -u francisco:abc123 -o app.jar "https://artefatos.empresa.com.br/app-1.2.3.jar"

E o Dockerfile, faz uso do artefato já baixado:

FROM alpine
WORKDIR /
COPY app.jar /
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

A sequência de ações seria:

chmod +x build.sh
./build.sh
docker build -t app:05 .

Percebe-se claramente ao inspecionar a imagem que não há credenciais de acesso nela, confere? Coube a um script auxiliar realizar a autenticação (utilizando as credenciais de acesso), baixar o artefato e apresentá-lo ao contexto do build da imagem.

It works!

Código 06: multi-stage builds

Apesar do exemplo anterior ter cumprido seu propósito (imagem docker sem exposição de credenciais sensíveis), tive a sensação (e espero que você também) de que algo ficou estranho: Tivemos que recorrer a arquivos auxiliares, fora do escopo do Docker para resolver o problema.

Se analisarmos um pouco, basicamente o que fizemos foi dividir o processo de build em 2 estágios:

estágio 01 que baixou os artefatos sob credenciais (script auxiliar)
estágio 02 que compilou a imagem (Docker)

Lendo mais a documentação da Docker, percebemos que podemos fazer similar utilizando o conceito de multi-stage builds.

Nosso Dockerfile:

FROM alpine AS download
ARG USER
ARG PASSWORD
RUN apk add curl
RUN curl -u $USER:$PASSWORD -o /app.jar "https://artefatos.empresa.com.br/app-1.2.3.jar"

FROM alpine
WORKDIR /
COPY --from=download /app.jar .
ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

Perceba que fizemos exatamente a mesma coisa, agora usando apenas o Docker: Dividimos nosso build em 2 estágios.

no primeiro estágio, uma imagem intermediária é criada (e suas respectivas layers e informações) com o download da aplicação, atrás da autenticação.
no segundo estágio, a imagem em construção (a oficial) copia apenas o app.jar da imagem anterior.

Fácil perceber que, na imagem final não visualizaremos as credenciais. Além disso, a imagem intermediária é destruída ao final do processo de build.

IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
72ef8382df33   3 minutes ago   /bin/sh -c #(nop)  ENTRYPOINT ["java" "-XX:+…   0B
32a3816fdcd3   3 minutes ago   /bin/sh -c #(nop) COPY file:297d62e63eaf8490…   14B
29385377e66f   3 minutes ago   /bin/sh -c #(nop) WORKDIR /                     0B
389fef711851   6 days ago      /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      6 days ago      /bin/sh -c #(nop) ADD file:ec475c2abb2d46435…   5.58MB

Funciona! E parece-nos uma solução bem inteligente, não acha?

PLUS: BuildKit

Uma funcionalidade "nova" no Docker é o uso do BuildKit para ajudar no manuseio de credenciais durante o processo de construção de imagens.

Ainda não brinquei com este recurso, assim tentarei em breve atualizar este post com um exemplo adicional.

Caso deseje ver como funciona, não deixe de ler a documentação oficial

Post originalmente publicado em meu site pessoal https://matheuslao.dev/posts/uso-credenciais-construcao-imagens-docker/