Tag: Link entre containers

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
root@aed84ee21bde:/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:

root@aed84ee21bde:/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!

Cristiano Diedrich

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

www.mundodocker.com.br

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!

Cristhian Bicca

Trabalha em uma consultoria com foco em Plataforma como Serviço (PaaS), é especialista em Cloud Computing e Conteinerização, desenvolve todo dia uma nova maneira de resolver problemas e criar coisas novas.

www.mundodocker.com.br