Simplificando o Docker — parte 2

Na parte 1 fizemos algo não tão produtivo, que foi conectar a um container e rodar coisas nele. Claro que dá para automatizar isto, mas seria uma gambiarra (digo um script para automatizar as tarefas após conectar no container).

Vamos precisar criar um arquivo Dockerfile (sem ponto e sem extensão) com o conteúdo abaixo:

> from nginx

Só isto? Por enquanto só vamos dizer que a base será esta imagem no Nginx. Por enquanto.

E vamos construir ou “buildar” a imagem:

>sudo docker build . -t nginx-andre

Construímos a imagem, certo? Então podemos listá-la:

> sudo docker images | grep nginx-andre

Fizemos o “grep” acima só para filtrar o que tiver a tag desajada. A imagem apareceu na lista. Então vamos fazer um “run”.

> sudo docker run -p 8000:80 nginx-andre

Veja o resultado:

É só isto? Para o começo sim, só isto. Então vamos dar uma “garibada” nesta imagem.

Crie o index.html que coloquei no https://pastebin.com/yP1ZkkjN . Eu coloquei lá no pastebin porque a indentação aqui não ficou e você não e acharia muito legal se eu colocasse uma imagem.

Vamos completar o Dockerfile, deixando-o como está abaixo:

from nginx

copy index.html /usr/share/nginx/html/index.html

Agora vamos para o processo de construção:

Comandos:

Construção da imagem com a tag novo-nginx-andre-2:

> sudo docker build . -t novo-nginx-andre-2

Verificação da imagem, limpando a saída com o “grep”:

> sudo docker images | grep novo-nginx-andre-2

Criando o container com base na imagem

> sudo docker run -d -p 8005:80 novo-nginx-2

Resultado:

Agora estou nojento com isto kkk, quero fazer até o mapeamento de portas no Dockerfile. Vamos acrescentar a última linha, ficando o Dockerfile assim:
from nginx
copy index.html /usr/share/nginx/html/index.html
E expor uma porta? Bem, vamos ver o https://www.whitesourcesoftware.com/free-developer-tools/blog/docker-expose-port/

Lá fala:

“How publishing ports works
By default, if you use the docker run or docker create command to run or create a container, they do not make any Docker’s ports accessible by services in the outside world.
So, while it’s possible for your Docker containers to connect to the outside world without making any changes to your code, it’s not possible for the outside world to connect to your Docker containers.
If you want to override this default behavior, you can use either the -P or the -p flag in your Docker run string.How publishing ports works
By default, if you use the docker run or docker create command to run or create a container, they do not make any Docker’s ports accessible by services in the outside world.
So, while it’s possible for your Docker containers to connect to the outside world without making any changes to your code, it’s not possible for the outside world to connect to your Docker containers.
If you want to override this default behavior, you can use either the -P or the -p flag in your Docker run string.”

Então, não vai dar para colocar a exposição de portas no Dockerfile. Até dá para fazer um “expose” lá (eu tentei), mas acessar o Nginx com a porta que você coloca no “expose” sem usar o “-p” no “sudo docker run” não dá.

Faz sentido se pensarmos com calma, né? Se eu posso ter vários objetos (containers) a partir da classe (receita, imagem), a porta tem que estar no container e não na imagem, se não como posso criar vários containers a partir da mesma imagem se todos usarem a mesma porta?

Vamos pensar no que fizemos até agora, só o que for relevante:

• Um run em uma imagem;
• Buildamos uma imagem baseando-nos em um Dockerfile e depois criamos um container com base nesta imagem. Veja, criamos uma imagem (“classe”) e depois pricisamos fazer um “run” nesta imagem para criarmos 1-N containers (“objetos”). Se podemos ter N containers, faz sentido colocarmos a porta na imagem ou em sua “receita” (Dockerfile)? Creio que não.

Então creio que fizemos o suficiente para a parte 2. Na parte 3 vou criar mais de um container comunicá-los.
Até mais :) !