Continuando nossa série sobre Docker e containers, nosso #cloudspecialist Thiago Marques está de volta para explicar o conceito de DockerFile

O pai tá on!!
Após uma pequena explicação da arquitetura do docker, podemos avançar em pontos mais interessantes, por isso agora falaremos sobre como criar nossas próprias imagens.
Vamos utilizar um exemplo de uma aplicação simples de CRUD que efetua cadastro de clientes, e já estamos utilizando um container em ubuntu. Contudo algumas coisas ainda são manuais e demandam muito tempo para realizar o deploy como:
1. Fazer o upgrade dos pacotes do SO;
2. Instalar os requisitos para a aplicação (banco, python e flask);
3. Copiar os arquivos da aplicação para dentro do container;
4. Configurar a aplicação com os parâmetros necessários;
5. Efetuar o deploy da aplicação;
Veja que todas essas alterações feitas depois que se sobe o container levam tempo, e partindo de uma lógica que uma das razões de utilizá-lo é justamente para se ganhar agilidade, acaba se tornando contra produtivo.
Assim, para otimizar esses trabalhos, vamos construir uma imagem com base no ubuntu já com nossa aplicação instalada utilizando o Dockerfile para fazer o build.

O que é DockerFile, e como funciona?

Dockerfile é a forma de criar nossas próprias imagens, com as características necessárias para a aplicação funcionar. Lembre-se que uma IMAGEM é imutável, seria como se fosse um template para subir um container, ou seja, você sempre vai precisar de uma imagem para realizar essa ação.
Ele funciona basicamente como um ‘livro de receitas’ onde é executada cada instrução em top-down, criando para cada instrução um step. Depois do arquivo criado, você executa o build, que criará uma nova imagem, e assim poderá utilizar a imagem já pronta com sua aplicação.

Fonte

Instruções no Dockerfile

Existem diversas instruções que podem ser usadas no dockerfile, contudo vamos focar nas principais. Para isso utilizaremos o exemplo abaixo:

Agora analisando cada comando/instrução dentro do Dockerfile, temos:
• FROM
o Instrução obrigatória. É nela que temos a imagem base. Entenda ela como o SO que você vai utilizar no container, sendo que ele já pode vir com alguma aplicação instalada (um node.js por exemplo).
• LABEL:
o Insere um metadado na imagem. Nesse caso adicionei quem é o responsável pela aplicação.
• RUN:
o Instrução para rodar comandos dentro do container, e pode ser utilizada mais de uma vez. Todos os comandos que você utiliza o RUN são executados na criação da imagem, e não na criação do container. Assim você não precisa executá-los novamente quando o container é criado.
• EXPOSE:
o Instrução um tanto quando interessante. Ela tem uma função diferente do docker-compose, onde de fato você expõe a porta da aplicação. No Dockerfile, ela NÃO faz isso. Aqui ela basicamente funciona para documentar em qual porta a aplicação vai funcionar. Para expor de fato a porta você vai precisar do ‘-p’ no docker run, ou do expose no docker-compose.
• WORKDIR:
o Instrução que indica em qual pasta as instruções de CMD, RUN, ADD, COPY etc. vão usar para executar suas tarefas. Ela também vai servir para definir qual diretório será aberto quando o container iniciar.
• CMD:
o Instrução que é executada quando o container se inicia. Note que o CMD (e o ENTRYPOINT) são instruções que são executadas no pós, e não na criação da imagem. No caso do CMD você pode ter mais de um no Dockerfile, contudo ele só executa o último (o ENTRYPOINT faz a mesma coisa, mas não sobre escreve);

Outras instruções no Dockerfile

Além dessas instruções, existem outras que podem ser interessantes quando você está criando uma imagem, cito-as:
• ADD
o Faz a cópia de arquivos locais ou externos para dentro do container. Dessa forma você pode copiar arquivos de URLs, e até mesmo descompactar automaticamente arquivos que estão em .tar.
• COPY
o Faz cópia de arquivos locais para dentro do container. Note que aqui você não tem opção de fazer download e/ou descompactação.]
• ENV
o Seta variáveis de ambiente dentro que estarão disponíveis dentro do container.
• ARG
o Também seta variáveis de ambiente, contudo apenas durante o build. Útil por exemplo, se você precisa definir um HTTP_PROXY apenas durante o build.

That’s all folks! Be Happy!!!

OUTRAS PUBLICAÇÕES

Tudo sobre AWS Outposts

Você sabia que a AWS possui uma solução para On Premises? Veja o artigo sobre o serviço AWS Outposts! Entenda como ele pode te ajudar!

Novidade da Semana – 24/08 a 04/09

Todos os dias a AWS lança uma série novidades e atualizações em seus produtos que visam melhorar a vida de seus usuários. Confira as novidades das duas últimas semanas.

BIOS vs UEFI

Entenda a diferença ente BIOS e UEFI neste artigo escrito pelo nosso #cloudspecialist José Anderson Vila Nova

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações