Link entre Containers – Parte 2

Olá!

Dando prosseguimento a primeira parte, vou trazer hoje como o Docker cria o tunelamento entre os containers para criar o Link. Como você viu aqui no Blog é possível criar um acesso seguro entre os containers sem a necessidade de expor portas tcp/udp tanto do host quanto do próprio container, para isso basta utilizar o parâmetro “link” e você vinculará dois containers. Mas como o Docker fazer com que esse acesso seja seguro e confiável? Basicamente de duas formas, são elas:

1 – Variáveis de ambiente:

O Docker cria diversas variáveis ​​de ambiente quando você cria um link entre os container. Docker, ele automaticamente as variáveis ​​de ambiente no container de destino com base nos parâmetros –link, ele também irá expor todas as variáveis ​​de ambiente provenientes do container de origem. Essas variáveis podem vir de:

  • Do comando ENV, utilizado na criação da imagem de origem via Dockerfile;
  • Das opções -e, –env e –env-file no comando docker run quando o container de origem é criado.

Essas variáveis ​​de ambiente possibilitam acessar programaticamente as informações do container de origem, ou seja podemos automatizar tarefas de deploy utilizando as variáveis carregadas de um container para o outro..

Aviso: É importante compreender que todas as variáveis ​​de ambiente provenientes de um container são disponibilizados para qualquer outro container que esteja ligado a ele. Isso poderia ter sérias implicações de segurança se dados sensíveis são armazenados nas variáveis de ambiente (como pode exemplo usuário e senha de banco de dados).

O Docker define um <alias>_NAME padrão como variável de ambiente para cada container de destino listado no parâmetro –link. Por exemplo, se um novo container chamado web está ligado a um container de banco de dados chamado db via –link db: webdb, então Docker cria uma variável WEBDB_NAME=/web/ webdb no container web.

Docker também define um conjunto de variáveis ​​de ambiente para cada porta exposta pelo container de origem. Cada variável tem um prefixo único no formulário:

<name>_PORT_<port>_<PROTOCOL>

Os componentes desses prefixos são:

  • O  alias <name> especificado no parâmetro –link (por exemplo, webdb);
  • A <port> exposta no container de origem;
  • O <protocol>, se é TCP ou UDP;

Docker usa este formato de prefixo para definir três variáveis ​​de ambiente distintas:

  • A variável prefix_ADDR contém o endereço IP a partir do URL, por exemplo WEBDB_PORT_5432_TCP_ADDR = 172.17.0.82.
  • A variável prefix_PORT contém apenas o número da porta, por exemplo WEBDB_PORT_5432_TCP_PORT = 5432.
  • A variável prefix_PROTO contém apenas o protocolo, por exemplo WEBDB_PORT_5432_TCP_PROTO = tcp.

Se o container expõe várias portas, uma variável de ambiente é definido para cada porta exposta. Isso significa, por exemplo, se um container expõe 4 portas o Docker cria 12 variáveis ​​de ambiente, 3 para cada porta.

Além disso, Docker cria uma variável de ambiente chamada <alias>_PORT. Esta variável contém do container de origem e a primeira porta exposta. A ‘primeira’ porta exposta é definida como a de menor número. Agora, considere essa variável: WEBDB_PORT=tcp: //172.17.0.82:5432, Se essa porta é usada para TCP e UDP, você deve especificar o protocolo tcp primeiro.

Agora na prática, vamos criar um container chamado site ligado a um container chamado db, veja o retorno do comando env dentro do container web:

    $ docker run --rm --name site --link db:db mundodocker/app env
    . . .
    DB_NAME=/site/db
    DB_PORT=tcp://172.17.0.5:5432
    DB_PORT_5432_TCP=tcp://172.17.0.5:5432
    DB_PORT_5432_TCP_PROTO=tcp
    DB_PORT_5432_TCP_PORT=5432
    DB_PORT_5432_TCP_ADDR=172.17.0.5
    . . .

Você pode ver que Docker criou uma série de variáveis ​​de ambiente com informações úteis sobre o container de origem ‘db‘. Cada variável é prefixado com DB_, que é preenchida a partir do alias especificado acima. Se o alias fosse db1, as variáveis ​​seriam prefixado com DB1_. Você pode usar essas variáveis ​​de ambiente para configurar suas aplicações para se conectar ao banco de dados no container db. A conexão será segura e privada; apenas o container site será capaz de falar com o container db.

Importante sobre variáveis ​​de ambiente Docker
Ao contrário de entradas de host no arquivo /etc/hosts, os endereços IP armazenados nas variáveis ​​de ambiente não são atualizados automaticamente se o container de origem é reiniciado. É recomendado a utilização das entradas de host em /etc/hosts para atualizar automaticamente o endereço IP de containers ligados.

As variáveis ​​de ambiente só são definidas para o primeiro processo no container. Alguns daemons, como sshd, limpará essas variáveis em uma nova conexão.

2 – Atualizando o arquivo / etc / hosts

Além das variáveis ​​de ambiente, o Docker adiciona uma entrada de host para o container de origem no arquivo /etc/hosts do container de destino. Veja como fica o /etc/hosts do container de destion:

$ docker run -t -i --rm --link db:sitedb mundodocker/app /bin/bash
[email protected]:/opt/app# cat /etc/hosts
172.17.0.7  aed84ee21bde
. . .
172.17.0.5  sitedb 6e5cdeb2d300 db

Você pode ver duas entradas de host, a primeira é uma entrada para o container site que usa o Container ID como um nome de host. A segunda entrada utiliza o alias para referenciar o endereço IP do container db. Quer testar? Ótimo, do container que você acabou de criar (sitedb), você pode pingar os nomes definidos no link, por exemplo:

[email protected]:/opt/app# ping db
PING webdb (172.17.0.5): 48 data bytes
56 bytes from 172.17.0.5: icmp_seq=0 ttl=64 time=0.267 ms
56 bytes from 172.17.0.5: icmp_seq=1 ttl=64 time=0.250 ms
56 bytes from 172.17.0.5: icmp_seq=2 ttl=64 time=0.256 ms

Você pode ver que o nome db responde ao ip do container onde está o seu banco de dados, que resolve para 172.17.0.5. Você pode usar essa entrada do host para configurar um aplicativo para fazer uso de seu container db.

Nota: É possível ligar vários container de destino em um único de origem. Por exemplo, você pode ter vários (com nomes diferentes) containers web conectados ao seu container db.

Se você reiniciar o container db, os containers ligados via /etc/hosts serão atualizados automaticamente com novo endereço IP do container de origem, permitindo que a comunicação continue.

Legal né? a partir disso é possível criar sistemas distribuídos de forma mais fácil, uma utilização bem importante é relacionado a criar link entre containers de aplicação e de volume, isso será tratado em posts futuros.

Estaremos ter ajudado, e tendo dúvidas nos avise, e claro ajude divulgando o Blog.

Abraço!

MundoDocker no DevWeek – POA

Oi Pessoal,

Ontem participamos de um evento realizado pela iMasters, o DeveloperWeek, e na edição de Porto Alegre fomos convidados a fazer uma apresentação sobre Docker, e claro nós fomos :), queremos neste post compartilhar com vocês o conteúdo que apresentamos, assim como o vídeo demonstrando na prática como o Docker pode auxiliar as equipes de DevOps. veja:

                                                                                                                                                                     

No final do evento recebemos um presente do pessoal da iMasters pela contribuição 🙂

DevWeek

E fica o convite para o segundo MeetUp sobre Docker em Porto Alegre: http://www.meetup.com/Docker-Porto-Alegre e claro para o TcheLinux POA: http://poa.tchelinux.org, estaremos em ambos os eventos 😉

Fique atendo as novidades, e nos ajude divulgando o Blog.

Abraço!

Rede no Docker 1.9

Oi pessoal!

Neste post vamos detalhar como o Docker trabalha com o ambiente multi-host, vamos trazer alguns exemplos práticos e vamos detalhar cada caso de uso. Boa leitura!

O que muda no Docker 1.9?

Bom, primeiramente o que existia até o Docker 1.8 continua, o que muda é que foram acrescentado alguns comandos, e como explicado neste post, na versão 1.9 a funcionalidade de rede do Docker é tratada como um plugin, sendo possível assim utilizar formas mais elaboradas de rede, sem a necessidade de modificação em sua aplicação. Abaixo uma listagem dos comandos adicionados:

  • docker network create
  • docker network connect
  • docker network ls
  • docker network rm
  • docker network disconnect
  • docker network inspect

Criando uma rede – Bridge

Quando você instala o Docker Engine, ele cria automaticamente uma interface local de comunicação, tanto para o host – container, quanto para container-container, chama-se docker0 , ela é uma interface virtual criada em modo bridge com a interface principal, isso faz com que seja possível o container se comunicar com a internet, geralmente é atribuído para essa interface é o ip: 172.21.0.1/16, e quando não definido, os containers terão um ip dessa rede.

Na versão 1.9 do Docker é possível criar basicamente dois tipos de rede: Bridge (forma tradicional, e acessível apenas de dentro do host) ou do tipo Overlay (que possibilita a comunicação entre outros hosts com Docker, possibilitando assim a criação de cluster de Docker). Abaixo você pode visualizar como é possível criar uma rede em modo Bridge:

$ docker network create minha-rede
cds4554wfedcsaafe564fef3648e8d9d181sase98d8ef8c7ed561e89d9
$ docker network inspect minha-rede
[
    {
        "Name": "minha-rede",
        "Id": "cds4554wfedcsaafe564fef3648e8d9d181sase98d8ef8c7ed561e89d9",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Config": [
                {}
            ]
        },
        "Containers": {},
        "Options": {}
    }
]

Claro que você pode criar uma rede especificando qual range de ip você deseja que seus containers utilizem, veja:

$ docker network create --driver=bridge --subnet=172.28.0.0/16 --ip-range=172.28.5.0/24 --gateway=172.28.5.254 br0
03449da9dc22133889c55b3497bcd821b83e64b20608a680ce6e5025bd491118
$ docker network inspect br0
[
 {
 "Name": "br0",
 "Id": "03449da9dc22133889c55b3497bcd821b83e64b20608a680ce6e5025bd491118",
 "Scope": "local",
 "Driver": "bridge",
 "IPAM": {
 "Driver": "default",
 "Config": [
 {
 "Subnet": "172.28.0.0/16",
 "IPRange": "172.28.5.0/24",
 "Gateway": "172.28.5.254"
 }
 ]
 },
 "Containers": {},
 "Options": {}
 }
]

Quando você criar o container basta especificar agora que deseja utilizar essa rede, com o comando abaixo é possível fazer isso:

$ docker run --net=br0 -itd --name=container3 busybox
b9b6cea6195c0b66133933364e806d14644f97625c2a7270170fa5b6e4984f22
$ docker network inspect br0
[
 {
 "Name": "br0",
 "Id": "03449da9dc22133889c55b3497bcd821b83e64b20608a680ce6e5025bd491118",
 "Scope": "local",
 "Driver": "bridge",
 "IPAM": {
 "Driver": "default",
 "Config": [
 {
 "Subnet": "172.28.0.0/16",
 "IPRange": "172.28.5.0/24",
 "Gateway": "172.28.5.254"
 }
 ]
 },
 "Containers": {
 "b9b6cea6195c0b66133933364e806d14644f97625c2a7270170fa5b6e4984f22": {
 "EndpointID": "32970bd2ebb403851b559f81ec9916ddd4f791d5a9c2f30a093a5c1626e7f089",
 "MacAddress": "02:42:ac:1c:05:01",
 "IPv4Address": "172.28.5.1/16",
 "IPv6Address": ""
 }
 },
 "Options": {}
 }
]

Legal não? Você pode criar uma arquitetura que possibilite você isolar determinados containers, e fazer com que eles não tenha acesso a internet por exemplo, isso é útil para containers que executam aplicação de apoio, como redis, mongo, etc.

Criando uma rede – Overlay

Note que no caso acima, como não foi definido parâmetros adicionais, o Docker criou uma rede em modo Bridge. Diferentemente do modo Bridge, o Overlay necessita que alguns requisitos sejam atendidos, dentre eles podemos destacar:

  • Acesso a um serviço de chave-valor distribuído, o Docker suporta Consul, Etcd ou ZooKeeper;
  • Um Cluster já montado com acesso a este serviço de chave-valor distribuído;
  • Daemon do Docker configurado corretamente em cada host do cluster.
  • Host com Kernel 3.16 ou superior.

As opções disponíveis para criação de uma rede Overlay são:

  • --cluster-store
  • --cluster-store-opt
  • --cluster-advertise

Também é uma boa ideia, embora não obrigatório, que você instale o Docker Swarm para gerenciar o cluster. O Swarm fornece o serviço de descoberta e gestão de servidor que pode te ajudar na implementação.

Quando você cria uma rede, o Docker Engine não sobrepõe a rede criada no momento da instalação. Você pode substituir esse padrão e especificar uma sub-rede diretamente usando a opção –subnet. Em uma rede em modo Bridge você pode criar apenas uma única sub-rede, uma rede Overlay suporta múltiplas sub-redes.

Além da opção --subnetwork, você também especificar os parametros --gateway, --ip-range e --aux-address. Veja como ficaria a criação da rede:

$ docker network create -d overlay
  --subnet=192.168.0.0/16 --subnet=192.170.0.0/16
  --gateway=192.168.0.100 --gateway=192.170.0.100
  --ip-range=192.168.1.0/24
  --aux-address a=192.168.1.5 --aux-address b=192.168.1.6
  --aux-address a=192.170.1.5 --aux-address b=192.170.1.6
  minha-rede-multihost

O único cuidado que você deve ter é não criar sub-redes conflitantes, isso causará um erro no momento da criação ou mau funcionando no ambiente que deseja montar.  Estando a rede criada, basta criar o container passando como parâmetro ao nome da rede, veja:

$ docker run -itd --net=minha-rede-multihost busybox

 

Nos próximos posts vamos trazer detalhadamente um ambiente com Overlay, desde a configuração dos pré-requisitos até a criação de containers em múltiplos hosts, quem sabe um vídeo 😉 .

Por hoje era isso, esperamos ter ajudado e tendo dúvidas nos avise para conversarmos, e claro, nos ajude divulgando o Blog!

Docker 1.9

Olá pessoal,

Estou aqui hoje para divulgar as novas funcionalidades da versão 1.9 do Docker. Abaixo segue algumas de suas novas funções e como isso pode te ajudar.

Multi-host Networking

A funcionalidade de rede multi-host estava em fase experimental desde junho desse ano, agora ela foi lançada como versão estável dentro da engine do Docker, isso é muito útil principalmente se você está pensando em ter diversos hosts de Docker interligados, e claro criar cluster de Docker, pois ele possibilita a criação de redes virtuais entre os hosts. Outro beneficio é que agora a rede é como um plugin adicional do Docker, isso faz com que seja possível trocar o plugin de rede sem precisar mudar algo em sua aplicação ou ambiente, ou seja, não há tanto retrabalho.

Persistent Storage

Nessa nova versão a engine do Docker foi desenhada para trabalhar melhor com os plugins de volume, ou seja, agora além de ser mais fácil trabalhar com volumes, ainda os plugins que existiam foram adicionados como oficiais. Outro beneficio é que agora é possível integrar essas plugins de volumes com o Swarm, deixando ainda mais fácil a administração de um Cluster. Plugins oficiais: Blockbridge, Ceph, ClusterHQ, EMC e Portworx, explicaremos cada um melhor nos próximos posts.

Docker Swarm 1.0

Com as melhorias trazidas com a rede e storage persistente, agora o Swarm ficou ainda mais eficiente, além de algumas correções de bug essa nova versão permite que você crie Cluster de Docker e escale seus containers de forma ainda mais eficiente, em testes realizados pelo pessoal de engenharia do Docker foi possível 30.000 containers em 1.000 nós sem dificuldade alguma.

Docker Engine 1.9

Além das melhorias já apresentadas, a engine do Docker traz ainda:

  • Variáveis em tempo de compilação no Dockerfile: Agora é possível setar variáveis (ou na tradução livre: argumentos), apenas no momento geração da imagem via Dockerfile, isso é muito útil caso você tenha alguma restrição para construir sua imagem (proxy local por exemplo).
  • Pull de imagem concorrente: Até a versão 1.8 do Docker, quando você baixava duas imagens que tem layer iguais, uma das imagens (geralmente a mais recente que você mandou baixar) ficava presa aguardando o término da outra, na versão 1.9 isso foi melhorado e agora você poderá baixar as duas simultaneamente, a diferença é que uma não esperará pela finalização da outra.
  • Sinais de parada: No Dockerfile agora é possível adicionar a instrução: STOPSIGNAL, fazendo com que seja possível personalizar o final de parada enviado para seu aplicativo quando o container for parado.
  • AWS CloudWatch logging driver: Se você tiver sua infra na AWS é possível integrar o CloudWatch com seus containers para ter relatório e monitoramento dos logs de seus containers.
  • Métricas de I/O de disco: Agora comando stats retornará também informações sobre o uso de I/O de disco de cada container.

Docker Compose 1.5

Principais novidade no Compose 1.5:

  • Suporte a Windows: Foi adicionado ao Docker Toolbox Windows, isso agiliza bastante o desenvolvimento e permite você rodar os mesmos comandos do Windows no Mac e vice-versa.
  • Variáveis de ambiente Compose: Agora você pode fazer qualquer coisa em seu arquivo Compose em tempo de execução utilizando variávies de ambiente.
  • Melhor suporte para múltiplos ambientes: Você define qual será seu ambiente base a partir de um único arquivo e em arquivos adicionais acrescenta as definições e mapeamentos de produção, desenvolvimento, QA, e afins.
  • Integração com rede: Isso é experimental ainda, mas possibilidade que você faça deploy via compose em um cluster de Docker, ou ainda possa definir seu cluster através do Compose.
  • Validação de arquivo: Agora o Compose validará seu arquivo de definição e lhe trará mensagens melhoradas com relação a análise em caso de erro

Docker Toolbox

Com o Docker Toolbox é possível você montar seu ambiente de desenvolvimento independente do S.O utilizando, basta você instala-lo, ele trará todas as ferramentas citadas acima empacotadas em um único instalador.  Ele ainda permite que você se conecte com algum provedor de externo. Você ainda pode escrever seu próprio driver para ele.

Docker Registry 2.2

Novidades dessa nova versão do Registry:

  • Suporte ao Google Storage: Agora é possível você armazenar suas imagens no Google Storage Plataform;
  • Modo somente leitura: Se você quer manter a consistência de seu repositório em momentos de manutenção, basta colocá-lo em modo somente leitura e os usuários poderão apenas ler as imagens, sem permissão para acrescentar novas
  • Arquivo configurável de HealthCheck: Se você quer desativar um repositório sem afetar outras ferramentas que dependem dele, você pode adicionar um arquivo para invalidade as consultas e download das imagens contidas nele.
  • Cabeçalhos de resposta HTTP configuráveis: Agora é possível você personalizar os cabeçalhos resposta HTTP do registro, isso é útil para melhorar a segurança do repositório ou até mesmo personalizar para o seu ambiente.

Ufa! bastante coisa não? Imaginem o que virá na 2.0 :). Espero ter ajudado e nos ajude divulgando o Blog.

Abraço!

Docker exec

Olá pessoal,

Hoje vamos demonstrar no mundodocker como podemos executar comandos dentro de nossos containers, sem precisarmos acessar o console deles.

O Docker disponibiliza um comando chamado docker exec que possibilita que seja possivel ser executado qualquer comando sem que seja preciso estar no console do container. O docker exec executara apenas se o container estiver running, caso contrario retonará uma mensagem de erro.

Exemplos:

Criando container com a imagem do centos

docker run -it -d centos /bin/bash

Criando diretório dentro do container

docker exec id_container ou nome_container mkdir /tmp/mundodocker.com.br

Agora podemos criar um arquivo dentro desse diretório

docker exec id_container ou nome_container touch /tmp/mundodocker.com.br/mundodocker.txt

Podemos acessar o container e verificar o arquivo lá dentro

docker attach id_container ou nome_container

ls /tmp/mundodocker

Ou poderiamos verificar via docker exec também

docker exec id_container ou nome_container ls /tmp/mundodocker.com.br

O docker exec é ótimo para quem tem uma imagem base e para cada container criado precisa editar poucos arquivos, você apenas usa o sed nos arquivos e pronto.

Obrigado pessoal por hoje era isso, espero ter mostrado um pouco do que podemos fazer com o Docker exec.

Espero ter ajudado e se gostou ajude divulgando o mundodocker.com.br, abraço!

Docker Swarm

Oi Pessoal,

Hoje queremos trazer para vocês mais uma das ferramentas que o Docker disponibiliza em seu ecossistema, chegou a hora de conhecermos o Docker Swarm. O Docker Swarm é uma ferramenta nativa do Docker que permite a criação de clusters de Docker, ou seja, podemos fazer com que diversos hosts de Docker estejam dentro do mesmo pool de recursos, facilitando assim o deploy de containers. É possível por exemplo criar um container sem necessariamente saber em qual host ele está, pois o Swarm disponibilidade uma API de integração, onde é possível realizar grande parte das atividades administrativas de um container. Quer ver na prática?

Requisitos:

  • Estar com a versão 1.6+ do Docker
  • Abrir a API do Docker para o Swarm Manager

 

Mãos a obra:

1 – Baixando a imagem oficial:

$ docker pull swarm

2 – Criando o cluster:

$ docker run --rm swarm create 
4765653423fdecsdfe875954a6e2h78ed # 

 

O retorno desse comando será o ID do Cluster, armazena essa informação pois será importante nas próximas etapas.

3 – Adicionando nós ao cluster:

$ docker run -d swarm join --addr=<node_ip:2375> token://4765653423fdecsdfe875954a6e2h78ed

4 – Configurando o Manager:

$ docker run -d -p <porta_manager>:2375 swarm manage token://4765653423fdecsdfe875954a6e2h78ed

Lembrando que <porta_manager> será a porta que você utilizará para se comunicar com o Swarm Manager, responsável pela administração do cluster, a arquitetura ficará da forma como a imagem abaixo:

5 – Verificando o Cluster:

$ docker -H tcp://ip:porta_manager> info

O retorno será algo parecido com isso:

Containers: 0 
Nodes: 3 
agent-2: 172.31.0.1:2375 
  └ Containers: 0 
  └ Reserved CPUs: 0 / 1 
  └ Reserved Memory: 0 B / 514.5 MiB 
agent-1: 172.31.0.2:2375 
  └ Containers: 0 
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 514.5 MiB 
agent-0: 172.31.0.3:2375 
  └ Containers: 0 
  └ Reserved CPUs: 0 / 1 
  └ Reserved Memory: 0 B / 514.5 MiB

Você pode enfrentar alguma dificuldade relacionada a TLS, principalmente se estiver apenas testando, para resolver isso basta executar: unset DOCKER_TLS_VERIFY, com isso não será verificado se os hosts possuem acesso via TLS ativado.

Para administrar seu cluster (criar containers, etc) basta utilizar o IP e Porta do Swarm Manage, dessa forma:

$ docker -H tcp://<manager_ip:manager_port> info 
$ docker -H tcp://<manager_ip:manager_port> run ... 
$ docker -H tcp://<manager_ip:manager_port> ps 

Para listar os nós que fazem parte do cluster, bata utilizar o comando abaixo:

$ docker run --rm swarm list token://4765653423fdecsdfe875954a6e2h78ed
172.31.0.1:2375 
172.31.0.2:2375 
172.31.0.3:2375

 

É claro que isso é apenas o início, tendo o cluster montado é possível criar filtros de identificação por tipo de serviço, isso é muito útil para criar containers com o mesmo tipo de serviço em um mesmo local sem a necessidade de saber onde. Mas isso é história para um próximo post 😉

Fique atento as novidades do Blog, e ajude divulgando o mundodocker.com.br.

Abraço!

 

Link entre containers – Parte 1

Olá pessoal,

Hoje vou mostrar aqui no blog como podemos interligar containers sem precisar expor as portas do nosso host. Mapeamentos de portas não são a única maneira de conectar um container ao outro. Docker também tem um sistema de ligação que permite interligar vários containers juntos e enviar as informações de conexão de um para outro.

A importância de nomear

Para estabelecer os links, o Docker conta com os nomes dos container. Você já viu que cada container que você criar tem um nome criado automaticamente, mas você mesmo pode dar um nome ao container. Esta nomeação fornece duas funções úteis:

1 – Torna-se útil quando você precisa criar containers com funções especificas e precisa lembrar-se deles, por exemplo um container web, ou mysql, etc.

2 – Fica mais fácil fazer o link entre os containers, pois você não precisa decorar um nome que foi gerado aleatoriamente, basta você linkar seu container web com seu container mysql, por exemplo.

Você pode nomear seu recipiente usando o parâmetro –name, por exemplo:

$ docker run -d -P --name web training/webapp python app.py

Isso inicia um novo container e usa o parâmetro –name para nomea-lo como web. Você pode ver o nome do container utilizando o comando docker ps.

$ docker ps -l
CONTAINER ID  IMAGE                  COMMAND        CREATED       STATUS       PORTS                    NAMES
aed84ee21bde  training/webapp:latest python app.py  12 hours ago  Up 2 seconds 0.0.0.0:49154->5000/tcp  web

Você também pode usar docker inspect para retornar o nome do container.

Nota: Os nomes dos containers são únicos, então para reutilizar algum nome você deverá parar o container, remover e criar o container com o nome desejado.

Comunicação via Link

O Link permite que você trafegue informações entre os containers de forma segura, pois quem conhece um container conhece apenas o seu par definido no link. Quando você configurar um link, você cria um elo de ligação entre um container de origem e um container de destino. Para criar um link, você deve utilizar o parâmetro –link. Em primeiro lugar, deve-se criar um container que será origem de dados para outro container, desta vez vamos criar o container de banco de dados:

$ docker run -d --name db training/postgres

Isso criará um novo container chamado db a partir da imagem do postgres, que contém um banco de dados PostgreSQL.

Agora, você precisa excluir o container web criado anteriormente para que você possa substituí-lo por outro vinculado ao db:

$ docker rm -f web

Agora, crie um novo container chamado web e vincule com o seu container db.

$ docker run -d -P --name web --link db:db training/webapp python app.py

Isto irá ligar o novo container web com o container db criado anteriormente. O parâmetro –link fica da seguinte forma:

--link <nome ou id>:alias

Você pode ver que o container web agora está ligado ao container db, o que lhe permitirá coletar as informações do container db e claro do banco de dados que encontra-se lá.

Como pode notar, um link permite que um container de origem forneça informações sobre si próprio e de seus serviços a outro container de destino. No nosso exemplo, o destinatário web, pode acessar informações sobre o banco de dados de origem. Para fazer isto, o Docker cria um túnel seguro entre os container que não precisam expor as portas externamente, você deve ter notado que quando iniciamos o container db nós não usamos o parâmetro -P ou -p,  isso é uma grande vantagem em utilizar o link, nós não precisamos expor o container ou serviço, no nosso exemplo o banco de dados PostgreSQL, para toda a rede.

Na parte 2 desse tutorial veremos como o Docker cria esse túnel e permite a comunicação entre containers, fique atento as novidades aqui no Blog, e nos ajude divulgando o mundodocker.com.br 😉

Abraço!