Containers Docker Series — Containers

Seja Bem Vindo(a), Estou animado com o fato de você querer aprender o docker.

O seu ambiente e o seu projeto só vai existir se tiver imagens, temo duas forma de criar uma imagem, fazendo build usando Dockerfile e docker commit.

Obs: docker commit não é aconselhável usar esse tipo de imagem

Usando Dockerfile

Dockerfile é o arquivo de build das imagens Docker, ele é escrito com uma
syntax simples no formato “YML” ou “YAML”.

O Dockerfile define o que acontece no ambiente dentro do seu contêiner.
O acesso ao recurso como interfaces de rede e drives de disco é virtualizdo dentro deste ambiente, que é isolado do seu sistema, então você precisa mapear as portas para o mundo externo, e ser específico sobre quais arquivos você quer “copiar” esse ambiente.

Conhecendo Dockerfile

• FROM: Define qual imagem base a ser utilizada para iniciar o estágio de compilação. Você pode encontra imagens oficiais aqui.
• RUN: você passa as instruções do que será construído em tempo de execução do Dockerfile
• LABEL: Adiciona metadados a uma imagem no formato chave-valor, é extremamente importante para identificação da imagem e inclusive para automação é muito utilizado.
• EXPOSE: Expõe as portas de escuta do container especificadas na execução, porém o EXPOSE no Dockerfile não faz o BIND com a porta do host fazendo a exposição, isso precisa ser feito ou em um Compose File ou no start do Container com o parâmetro "-p 80:80", ou seja, jamais coloque EXPOSE 80:80 assim no seu Dockerfile
• ENV: Variáveis de ambiente a serem enviadas para a imagem
• COPY: Copia os arquivos do diretório especificado do host para o diretório especificado dentro do container
• ADD: O ADD além de copiar também arquivos do local ele serve para enviar arquivos empacotados com “tar” na origem e automaticamente descompactar no destino e também tem a capacidade de baixar arquivos de uma URL, desde que não tenha autenticação
• ENTRYPOINT: É o ponto de entrada quando você iniciar o container, ou seja, geralmente definimos no ENTRYPOINT o comando ou script que chama o processo responsável pela execução do container e que manterá o container vivo.
• CMD: Geralmente é utilizado para prover argumentos para o ENTRYPOINT, quando você usa o CMD sem ENTRYPOINT o CMD é o que vale no start do container, quando você tem CMD e ENTRYPOINT no mesmo DockerFile, o que é colocado no CMD geralmente são parâmetros complementares para o ENTRYPOINT
• VOLUME: Instrução que fala qual volume será mapeado ou criado para o container
• USER: Nome de usuário (ou UID) e, opcionalmente, o grupo de usuários (ou GID) a serem usados ao executar a imagem e as instruções RUN, CMD e ENTRYPOINT que o seguem no Dockerfile.
• WORKDIR: Diretório à partir de onde os comandos ou as ações serão realizadas durante a contrução da imagem, para maior clareza e confiabilidade, você sempre deve usar caminhos absolutos para o seu WORKDIR.
• ARG: Define uma variável que os usuários podem passar no tempo de compilação para o construtor com o comando de compilação docker usando o sinalizador --build-arg =
• ONBUILD: Define algumas instruções que podem ser realizadas quando alguma determinada ação for executada, é basicamente como uma trigger.
• STOPSIGNAL: Define o sinal de chamada do sistema que será enviado para o contêiner para sair. Este sinal pode ser um número não assinado válido que coincide com uma posição na tabela syscall do kernel, por exemplo, 9 ou um nome de sinal no formato SIGNAME, por exemplo SIGKILL.
• HEALYHCHECK: A instrução HEALTHCHECK diz ao Docker como testar um container para verificar se ele ainda está funcionando. Isso pode detectar casos como um servidor web que está preso em um loop infinito e incapaz de lidar com novas conexões, mesmo que o processo do servidor ainda esteja em execução.
• SHELL: Serve para definir ou mudar no caso o SHELL padrão para a execução dos comandos, no linux o padrão é o ["/bin/sh", "-c"] e no Windows ["cmd", "/S", "/C"]

Exemplo de Dockerfile

# Use an official Python runtime as a parent image
FROM python:2.7-slim

# Set the working directory to /app
WORKDIR /app

# Copy the current directory contents into the container at /app
ADD . /app

# Install any needed packages specified in requirements.txt
RUN pip install --trusted-host pypi.python.org -r requirements.txt

# Make port 80 available to the world outside this container
EXPOSE 80

# Define environment variable
ENV NAME World

# Run app.py when the container launches
CMD ["python", "app.py"]

requirements.tx

Flask
Redis

app.py

from flask import Flask
from redis import Redis, RedisError
import os
import socket

# Connect to Redis
redis = Redis(host="redis", db=0, socket_connect_timeout=2, socket_timeout=2)

app = Flask(__name__)

@app.route("/")
def hello():
    try:
        visits = redis.incr("counter")
    except RedisError:
        visits = "<i>cannot connect to Redis, counter disabled</i>"

    html = "<h3>Hello {name}!</h3>" \
           "<b>Hostname:</b> {hostname}<br/>" \
           "<b>Visits:</b> {visits}"
    return html.format(name=os.getenv("NAME", "world"), hostname=socket.gethostname(), visits=visits)

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=80)

Criando sua imagem

O que arquivos que deveriam ter no diretório do seu projeto

$ ls
Dockerfile app.py requirements.txt

Gerando a imagem

docker build -t appython .

docker build

Listando minha imagens

$ docker image ls

REPOSITORY            TAG                 IMAGE ID
appython              latest              326387cea398

Executando container da sua aplicação

$ docker run -d -p 4000:80 appython

docker run

Esta rodando a nossa aplicação

Listando contêineres em execução

$ docker container ls
CONTAINER ID        IMAGE         COMMAND             CREATED
1fa4ab2cf395        appython      "python app.py"     28 seconds ago

Docker Contêiner

O Docker oferece três formas diferentes de montar dados em um container para um Docker Host: Volumes, bind mount, ou tmfs volumes

• Volumes: são armazenados em uma parte do sistema de arquivos do host que é gerenciado pelo docker (/var/lib/docker/volumes/ ) no linux. Os processos não Docker não devem modificar esta parte do sistema de arquivos.
• bind mounts: podem ser armazenadas em qualquer lugar do sistema host. Eles podem até ser importantes aruivos ou diretórios do sistema. Os processos não docker no host ou um contêiner docker podem modificá-los a qualquer momento.
• tmfs mounts: são armazenados somente na memória do sistema host e nunca são escritas no sistema de arquivos do host.

Os volumes têm várias vantagens sobre bind mounts:

• Os volumes são mas fáceis de fazer backup ou migrar do que os bind mounts.
• Você pode gerenciar volumes usando do comando Docker CLI ou API Docker.
• Os volumes funcionam em recipiente Linux e Windows.
• Os controladores de volumes permitem armazenar volumes em hosts remotos ou provedores de nuvem, criptografar o conteúdo do volumes ou adicionar outras funcionalidades.
• O conteúdo de um novo volume pode ser preenchido por um contêiner.

Usando Volumes

Originamente, o flag -v ou — volumes foi usado para contêineres independentes e o — mount foi usado para o serviço do swarm, à parte da versão 17.06, você também pode usar — mount para contêiner independente.

• Criando volume:

$ docker volume create [nome-do-volume]

• Lista volumes

$docker volume ls

• Inspecionar o volume

$ docker volume inspect [nome-do-volume]

• Removendo o volume

$ docker volume rm [nome-do-volume]

Quarta parte da series

Referências:

| Docker Documentation

docker run

Best practices for writing Dockerfiles