Category: Tutoriais

Tutorais de como implementar algo com Docker.

Kubernetes parte II

11 Comments

Olá pessoal,

Hoje vamos continuar a demonstração de como podemos utilizar Kubernetes para nos auxiliar na administração de containers. Para conseguirmos realizar todos os procedimento vamos criar uma estrutura com quatro servidores:

  • Node – Master   (CentOS7)
  • Node – Minion1 (CentOS7)
  • Node – Minion2 (CentOS7)
  • Node – Minion3 (CentOS7)

 

Agora vamos instalar alguns componentes em nosso servidor Master.

//Instalando o Kubernetes e o etcd (Serviço de descoberta)
yum install kubernetes etcd -y

// Vamos editar o conf do etcd para liberarmos as portas de acesso a esse serviço. Você vai ver que o arquivo de // conf possui diversas linhas comentadas, vamos tirar o comentário apenas dessas linhas:
vi /etc/etcd/etcd.conf
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"

//Agora vamos fazer a configuração da API do Kubernetes
vi /etc/kubernetes/apiserver
KUBE_API_ADDRESS="--address=0.0.0.0"
KUBE_API_PORT="--port=8080"
KUBELET_PORT="--kubelet_port=10250"
KUBE_ETCD_SERVERS="--etcd_servers=http://127.0.0.1:2379"
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
KUBE_ADMISSION_CONTROL="--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
KUBE_API_ARGS=""

//Depois de mexer nos conf da API do Kubernetes e do etcd, vamos dar um start neles agora

 systemctl restart etcd
 systemctl restart kube-apiserver
 systemctl restart kube-controller-manager
 systemctl kube-scheduler

etcdctl mk /atomic.io/network/config '{"Network":"172.17.0.0/16"}'

Agora nos servidores Minions vamos executar os seguintes comandos:

yum -y install flannel kubernetes

//Vamos editar o conf do flannel agora em /etc/sysconfig/flanneld
FLANNEL_ETCD="http://IPMASTER:2379"

//Editando o conf do Kubernetes para conectar na API do master. /etc/kubernetes/config
KUBE_MASTER="--master=http://IPMASTER:8080"

//Agora vamos editar o conf do serviço de cada minion, então em cada servidor você vai colocar o seu respectivo IP. /etc/kubernetes/kubelet
KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_PORT="--port=10250"
KUBELET_HOSTNAME="--hostname_override=IPMINION"
KUBELET_API_SERVER="--api_servers=http://IPMASTER:8080"
KUBELET_ARGS=""


systemctl restart kube-proxy 
systemctl restart kubelet
systemctl restart docker 
systemctl restart flanneld

Agora no server Master é só executar:

//Você receberá o status de nossos nó
kubectl get nodes

Por hoje era isso pessoal, em nosso próximo post vamos demonstrar como podemos criar aplicações altamente disponíveis dentro do nosso Kubernetes.

Espero ter ajudado, e já sabe, tendo dúvida entre em contato conosco ou deixe sua dúvida no fórum que o pessoal pode te ajudar :), quer nos ajudar? Divulgue o mundodocker.com.br e vamos conversando.

Abraço!

Referência: http://severalnines.com/blog/installing-kubernetes-cluster-minions-centos7-manage-pods-services

Supervisord – Gerenciando serviços

2 Comments

Eai gente, tudo tranquilo?

O LXC propriamente dito não foi desenvolvido para ter múltiplos serviços/processos em cada container, o ideal é que você segmente seu ambiente em diversos containers, cada um rodando um parte isoladamente. Mas Cristiano, eu realmente preciso ter 2, 3 serviços em um mesmo container, o que faço? Bom, se não tem jeito mesmo, você pode utilizar o supervisord para gerenciar seus processos dentro de um container, e garantir que eles iniciem juntamente com o container.

O supervisord para quem não conhece é um utilitário que serve para monitorar e reiniciar os serviços nele definidos quando esses serviços entram em um estado de falha, ele é escrito em python e é muito simples de se utilizar, ele possuí 2 comandos básicos:

  • supervisord: É o deamon propriamente dito, responsável por ler o arquivo de configuração e monitorar os serviços definidos;
  • supervisorctl: É um subutilitário que serve para poder reiniciar manualmente o serviço ou ainda verificar qual o status do serviço para o supervisord;

Vou mostrar como você pode utilizar o supervisord já com o container rodando, mas como você já viu nesse post, você pode converter todos esses comandos em um Dockerfile e dar um docker build e gerar um imagem pronta ;). Vamos lá:

1 – Instalando

c45cffcd9126:~# yum install python-setuptools -y
c45cffcd9126:~# easy_install pip
c45cffcd9126:~# pip install supervisor

2 – Configurando

c45cffcd9126:~# echo_supervisord_conf > supervisord.conf
c45cffcd9126:~# cp supervisord.conf /etc/supervisord.conf
c45cffcd9126:~# vi /etc/supervisord.conf

Agora basta você adicionar o bloco de comandos referente ao(s) serviço(s) que precisamos que sejam iniciados com o container, como por exemplo o ssh e o apache como definido abaixo:

[supervisord] 
nodaemon=false

[program:sshd] 
command=/usr/sbin/sshd -D 

[program:apache] 
command=/usr/sbin/httpd -DFOREGROUND -k start

Ah claro, não esquece de instalar esses serviços 😉

c45cffcd9126:~# yum install openssh-server httpd -y

Agora está no fim, crie um arquivo no / com nome de run.sh com o seguinte conteúdo

#!/bin/bash
/usr/bin/supervisord -c /etc/supervisord.conf
/bin/bash

Não esqueça da permissão de execução: chmod +x /run.sh

E está pronto o seu container, com o supervisord monitorando e mantendo no ar os serviços definidos, quer testar? Inicie o daemon: /usr/bin/supervisord -c /etc/supervisod.conf e verifique se os serviços que você definiu estão com status de running, para isso utilize:

c45cffcd9126:~# supervisorctl
apache RUNNING pid 160, uptime 0:00:03
sshd RUNNING pid 161, uptime 0:00:03
supervisor>

O supervisorctl possuir vários recursos, veja como você pode consultar:

supervisor> ?
default commands (type help <topic>):
=====================================
add exit open reload restart start tail
avail fg pid remove shutdown status update
clear maintail quit reread signal stop version
supervisor>

Através dele você pode parar, iniciar, atualizar entre muitas outras opções. Agora basta você gerar um imagem desse container:

docker commit containerid nomedaimagem

Feito isso você terá gerado a imagem do container, agora basta iniciar um novo container baseado nessa imagem:

docker run -d -p 80:80 -p 22:22 nomedaimagem /run.sh

E pronto, você terá iniciado 2 serviços diferentes dentro do mesmo container, e o melhor, eles reiniciarão sozinhos quando entrarem em failed state, legal não?

Espero ter ajudado, e já sabe, tendo dúvida entre em contato conosco ou deixe sua dúvida no fórum que o pessoal pode te ajudar :), quer nos ajudar? Divulgue o mundodocker.com.br e vamos conversando.

Abraço!

:

Docker – API Autenticada

Leave a comment

Oi Pessoal,

Uma das grandes vantagens em se utilizar o Docker em vez de LXC puro é a facilidade de se trabalhar utilizando uma API de integração, isso facilita e agiliza a vida tanto de programadores quanto do pessoal de operações. Alguns cuidados devem ser tomados é claro, entre eles em não expor a API de seu host Docker, pois nativamente não há um método de limitar o acesso. Existem soluções para isso? É claro, e hoje o mundodocker.com.br abordará um delas: Docker API com Basic Authentication.

Passo 1:

Primeiramente você deve expor a API do Docker apenas localhost, para isso você deverá editar o arquivo de configuração, no nosso exemplo (CentOS 7) é no /etc/sysconfig/docker, e deixe-o assim:

OPTIONS='-H tcp://127.0.0.1:2376 -H unix:///var/run/docker.sock'

Em seguida reinicie o serviço do Docker:

systemctl restart docker.service

Passo 2:

Agora precisamos instalar e configurar um proxy http (Nginx, Apache, etc), no nosso exemplo vamos utilizar o Nginx, para isso:

yum install nginx -y

Agora precisamos definir as credenciais de acesso, é simples, basta criar .htpasswd e fazer com que o proxy exija usuário e senha em uma determinada url, vamos lá:

htpasswd -c /etc/nginx/.htpasswd USUARIO

Ele solicitará a senha, digite-a duas vezes e está pronto seu arquivo de autenticação.

Agora vamos a configuração do proxy, para isso precisamos editar o arquivo: /etc/nginx/conf.d/default.conf e deixe-o da seguinte forma:

server {
 listen 2375 default_server;
 server_name localhost;
 location / {
 proxy_pass http://127.0.0.1:2376;
 auth_basic_user_file /etc/nginx/.htpasswd;
 auth_basic "Acesso restrito a API do Docker";
 }
}

O que falta? reiniciar o serviço do Nginx:

systemctl restart nginx.service

Testes

Depois de tudo configurado (se fosse não encontrar nenhum erro no caminho também 😉 ) basta você testar de uma forma bem simples: http://ipdoservidor:2375/info ele solicitará os dados informados anteriormente via htpasswd e retornará algumas informações do Docker e dos containers que está em execução neste host.

Você pode optar por outro método, que é o certificado SSL diretamente na API do Docker, isso garante que apenas clientes confiáveis tenham acesso ao host (pois deverão tem o certificado client configurado). E claro, você pode configurar para que o Nginx trabalhe sob SSL, isso garante que, além da autenticação com usuário e senha, você ainda tenha todos os seus dados trafegados de forma criptografada (esse sim é um ótimo método).

Por hoje era isso gente, gostaram? Ajudem divulgando o Blog por ai 😉

Abraços!

Portando aplicação para Docker

5 Comments

Oi Pessoal,

Para você que acompanha nosso blog, o www.mundodocker.com.br, hoje vamos mostrar um pouco mais de prática no Docker, vamos colocar em containers algumas aplicações e ver como é fácil ter seu ambiente totalmente portável. Para você que está começando com Docker, esse post será útil para entender e aprender como você pode começar, em casa mesmo, a mexer com Docker e fazer deploy de aplicações com ele. Já você que conhece Docker e já utiliza ele em seu ambiente, terá a oportunidade de pegar algumas dicas de como pode melhorar seu processo de deploy e criação de imagens.

Vamos lá:

 NodeJS

Vamos montar primeiro uma imagem de nossa aplicação, neste exemplo vamos utilizar o Framework Express do node. Primeiro crie um pasta, neste caso chamamos de app:

mkdir app

Crie dentro dessa pasta dois arquivos, package.json:

{
 "name": "app-node-mundodocker",
 "private": true,
 "version": "0.0.1",
 "description": "Teste App Node em Docker",
 "author": "MundoDocker <[email protected]>",
 "dependencies": {
 "express": "3.2.4"
 }
}

E index.js:

var express = require('express');

// Constants
var PORT = 8080;

// App
var app = express();
app.get('/', function (req, res) {
 res.send('Minha App Node\n');
});

app.listen(PORT);
console.log('Running on http://localhost:' + PORT);

Em seguida crie o arquivo Dockerfile:

FROM centos:centos6

# Habilita o repositório epel no CentOS
RUN yum install -y epel-release
# Instala o node e o npm
RUN yum install -y nodejs npm

# Instala as dependências 
COPY package.json /src/package.json
RUN cd /src; npm install

# Copia a app para a pasta src do container
COPY . /src

EXPOSE 8080
CMD ["node", "/src/index.js"]

Agora vamos criar a imagem:

docker build -t mundodocker/app-node-mundodocker .

Fácil né? Agora só criar o container e testar:

docker run -p 9090:8080 -d mundodocker/app-node-mundodocker

Se você acessar: http://seuip:9090 deve aparecer uma página como essa:

NodeApp

Rails

Agora vamos montar uma imagem utilizando uma aplicação em rails, primeiro vamos criar a pasta onde em seguida coloque nela os arquivos da aplicação e crie o Dockerfile:

FROM ruby:latest 
ENV HOME /home/rails/webapp 

# Instala as dependencias
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs 
WORKDIR $HOME 

# Instala as gems necessárias
ADD Gemfile* $HOME/ 
RUN bundle install 

# Adiciona os arquivos a pasta home 
ADD . $HOME 

# Executa o comando
CMD ["rails", "server", "--binding", "0.0.0.0”]

Vamos criar a imagem:

docker build -t mundodocker/app-rails-mundodocker .

Agora só criar o container e testar:

docker run -p 3000:3000 -d mundodocker/app-rails-mundodocker

Acesse http://seuip:3000 e você deverá ter um retorno desses:

RailsApp

Python

Para uma aplicação python vamos criar uma pasta chamado app e dentro dela criar um arquivo chamado app.py:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
 return 'Minha App em Python!\n'

if __name__ == "__main__":
 app.run(host="0.0.0.0", debug=True)

E também um Dockerfile:

FROM orchardup/python:2.7
RUN pip install Flask
ADD . /code
WORKDIR /code
CMD python app.py

Em seguida vamos gerar uma imagem desse ambiente:

docker build -t mundodocker/app-python-mundodocker .

Fácil né? Agora só criar o container e testar:

docker run -d -p 5000:5000 mundodocker/app-python-mundodocker

Se você acessar: http://seuip:5000 deve aparecer uma página como essa:

PythonApp

Baseado nesses exemplos você pode ir modificando e acrescentando o que for necessário para sua aplicação, não esquecendo que você pode criar links entre as aplicações, trazendo maior facilidade e segurança para seu ambiente.

Gostou? Nos ajude divulgando o Blog, grande Abraço!

Docker ToolBox

6 Comments

Oi Pessoal,

Você, sim você mesmo, que não tem grandes conhecimentos em Linux mas quer aprender Docker, criar seus containers e montar suas imagens, pois bem, esse post é pra você ;). Queremos mostrar como instalar e utilizar a ferramenta Docker ToolBox, que é um ótimo utilitário para subir seu ambiente Docker dentro de seu Windows ou Mac de forma fácil e rápida, montamos esse vídeo para lhe auxiliar, veja:

Basta você acessar: https://www.docker.com/docker-toolbox, fazer download da ferramenta e instalar como está ilustrado no vídeo. Ficou com dúvida ou dificuldade? Sem problema, deixa seu comentário ou ainda posta lá no nosso fórum: https://www.mundodocker.com.br/forum que vamos lhe ajudando.

Esperamos ter ajudado e nos ajude divulgando o Blog.

Link entre Containers – Parte 2

Leave a comment

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!

Rede no Docker 1.9

20 Comments

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!