Tag: Docker Brasil

Docker Global Mentor Week – Até aqui

Oi Pessoal,

Gostaríamos de trazer hoje um apanhado geral do que foi o Docker Mentor Week esse ano. Quais as percepções dos participantes, conteúdo abordado, dentre muitas outras informações sobre esse grande evento sobre Docker.

Quem participou das edições no Rio de Janeiro, São Paulo, Goiânia e Gravataí, pôde ter a experiência de como é realizar um treinamento tão focado e ao mesmo tempo descontraído, podendo interagir com outros usuários de Docker que tiveram ou tem as mesmas dificuldades, dúvidas e soluções. Esse tipo de experiência reforça cada vez mais a ideia de comunidade aberta, onde todos são bem vindos e todos tem seu papel, sendo você um iniciante ou ainda alguém com uma bagagem maior de conhecimento nessa tecnologia.

Segundo Fernando Ike, um dos organizadores e mentors do evento em São Paulo, é possível descrever o evento como:
“Muito gratificante compartilhar um pouco da experiência com os outros e também aprender alguns truques novos sobre containers.”

Em todos os eventos notamos que o público era o mais variado possível, desde quem nunca tinha trabalhado com Docker, Devs, Ops, etc. E o mais interessante, e que ocorreu em quase todas as edições foi o caso do pessoal de desenvolvimento realizar trilhas de ops e vise-versa, o que acaba gerando ainda mais engajamento por ambas as partes.

Será que todo o mundo pensa da mesma forma?

Nós do MundoDocker não poderíamos ficar sem essa resposta, não é mesmo? ;). Para isso contamos com a ajuda do pessoal do Imasters, que estiveram presentes no evento que ocorreu em São Francisco, na Califórnia mesmo (Durante o DevTrip). O Matheus Moreira e o Romulo Scampini que participaram do DevTrip e foram até o evento na sede do Docker, resumiram a participação deles no evento como:

Romulo:
“Foi o meetup mais produtivo que já fui, pois normalmente em meetups só temos a apresentação de algum conteúdo, e levamos de lição de casa a prática do conhecimento obtido.
No Global Mentor Week, além de aprender pudemos colocar em prática todo o conhecimento obtido, e ainda tivemos o apoio de engenheiros especialistas.”

Matheus:
“Foi bem legal porque tinha um monte de mentores a nossa disposição pra tirar todas as duvidas que quissemos e ai adivinha os mentores eram os devs do core do Docker”.
#sortudos

Separamos algumas fotos dos eventos, em São Francisco.

Em São Paulo:

Fonte: https://meetup.com/Docker-Sao-Paulo/events/235267786/

Em Goiânia:

Estivemos presente no evento que ocorreu na sede da Umbler em Gravataí no último sábado (26/11), e claro que registramos tudo :). Foi uma experiência incrível participar como Mentors desse evento, nem tudo foi perfeito, mas a troca de conhecimento e networking foram demais, foi muito gratificante poder ajudar a comunidade e dar nossa contribuição para o esclarecimento de dúvidas e passagem de conhecimento. Vamos ver umas fotos?

Quer contribuir também? Então fique ligado nos meetup de Docker de sua cidade, não sabe onde tem? Comenta ai e vamos achar um o mais próximo de você.

Acabamos por aqui, e como sempre, nos ajude divulgando o blog

Grande abraço a todos!

Supervisord – Gerenciando serviços

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!

:

Ansible

Olá pessoal,

Hoje vamos falar sobre uma ferramenta que cada vez mais quem trabalha com Docker acaba utilizando que é o Ansible. A primeira vista muitas pessoas acham que ambas ferramentas fazem a mesma coisa, apresentando uma solução para gerenciamento de configurações através de meios diferentes. Na realidade a união das duas ferramentas torna o ambiente de implantações de softwares limpo, confiável e rápido.

Ansible

É uma ferramenta de automatização de tarefas semelhante a Puppet e Chef, porém muito mais poderosa e a queridinha do pessoal DevOps hoje. Com ela é possível fazer o deploy de aplicações, provisionando de servidores, automatizar tarefas, e outras funções.

O Ansible trabalha com arquivos YAML,  o principal arquivo de configuração é chamado de PLAYBOOK onde você coloca todas as tarefas que serão executadas “yum”,”mkdir”,”useradd” e no arquivo .ini você adiciona os servidores onde o Ansible irá executar esse PLAYBOOK. Cada Playbook possui roles que são as informações de provisionamento, após definir as roles você definirá em quais hosts essas roles serão executadas.

Dentro das roles existem as tasks, handlers, variaveis e templates:

       – Tasks: Tarefas de provisionamento que serão executadas

       – Handlers: Tarefas para manipular serviços e arquivos.

       – Templates: Arquivos para serem transformados em configurações dentro das máquinas.

       – Variaveis: Valores que são definidos para serem usados dentro das tasks, handlers e templates

O Ansible é uma ferramenta muito mais simples que seus concorrentes citados anteriormente, já que ele não precisa que seja instalado agents nos servidores na qual ele irá executar.

É possível utilizar Docker e Ansible em conjuntos para resolver duas situações: Implantação de Containers e Criação de Imagens.

Implantação de containers: É possível fazer toda a parte de orquestração, configuração e provisionamento com containers, sem precisar fazer a instalação de agents dentro dos containers

Criação de Imagens:

Exemplo de Playbook:

# Mysql service name for drupal application
mysqlservice: mysqld

# Mysql port for drupal application
mysql_port: 3306

# Database name for the drupal application
dbname: databasename

# Mysql Username for drupal application
dbuser: root

Exemplo de Configuração do arquivo do Ansible:

[defaults]
inventory = /etc/ansible/inventory
host_key_checking = False
priva_key_file = ~/.sh/id_rsa
callback_plugins   = /opt/ansible-plugins/callbacks
connection_plugins = /opt/ansible-plugins/connections

Então tá pessoal, hoje fizemos apenas uma pequena introdução ao Ansible, em nossos próximos posts estaremos trazendo algo como Jenkins, Travis e também faremos um grande post mostrando como podemos criar um ambiente com Docker, Jenkins e Ansible. Obrigado

Referência: http://docs.ansible.com/ansible/playbooks_intro.html e http://ibm.com/developerworks/br/cloud/library/cl-provision-docker-containers-ansible/

Docker Service

Oi Pessoal,

Hoje queremos trazer em detalhes para vocês uma das features implementadas no Docker 1.12 (que foi lançado no último dia 29), e que já mencionamos aqui, que é o Docker Service. Para quem ainda não leu o nosso post sobre as novidades do Docker 1.12, o Docker Service é uma feature que foi incorporada pela engine Docker em sua última versão e que permite ao administrador criar e administrar sua stack de serviço dentro de um cluster Swarm, sem precisar utilizar uma segunda ferramenta para isso. Ela é parte integrante de uma série de melhorias que permitiram ao Docker 1.12 ter a camada de orquestração nativa em sua engine.

Mas afinal, como isso me ajuda? Bem, nas versões anteriores do Docker, para você ter algum tipo de orquestração você teria que utilizar uma série de ferramentas, como por exemplo: Docker Swarm, Docker Compose isso sem falar, que, se você quisesse provisionar isso em larga escala mesmo, o recomendado era utilizar Kubernetes, Mesos ou alguma outra forma de orquestração mais adequada. Agora está tudo dentro da própria engine do Docker, o que permite você ter maior controle sob o que está utilizando, e claro, permite você manipular esse ambiente de forma mais simples.

Para serviço especificamente, foi adicionado o sub-comando: docker service, e dentro dele alguns itens, veja:

  1. docker service create: Possibilita a criação de sua stack de serviço, é ele o que você mais vai ver hoje ;)
  2. docker service inspect: Verifica as informações sobre seu serviço e retorna informações sobre parametro utilizados para inicialização do mesmo, imagem utilizada, etc.
  3. docker service ls: Lista todos os serviços que você tem criado, e lhe retorna informações sobre nome, quantidade de replicas, etc.
  4. docker service rm: Remove o serviço desejado do cluster
  5. docker service ps: 2° comando mais útil, retorna para você o status de cada container que atende um serviço, é muito parecido com o docker ps, com a diferença de lhe trazer apenas informações sobre os container que fazem parte de um serviço criado, você pode ainda utilizar filtros para ter um retorno mais simplificado.
  6. docker service scale: Com o scale é possível realizar o escalonamento de seu serviço, é possível você aumentar a quantidade de containers que atenderão o seu serviço.
  7. docker service update: Comando que lhe permite realizar modificações no serviço criado, através dele é possível modificar informações sobre quantidade de memória, cpu, dentre muitas outras coisas em seu serviço.

Tudo certo com a teoria? Então vamos a prática :), nosso problema: Queremos criar uma stack para nosso ElasticSearch, nosso objetivo é escalar esse ambiente quantas vezes eu quiser e atualiza-lo de forma consistente.

Primeiro temos que criar nosso service:

docker service create --replicas 1 --update-delay 10s --update-parallelism 1 --name elasticsearch elasticsearch

O que isso quer dizer? Vamos lá:

  • Replicas – Número de containers que eu quero criar nesse momento, deve ser no mínimo um (por motivos óbvios);
  • Update-delay – Quando for realizado uma procedimento de atualização do ambiente, qual será a cadência de atualização dos containers.
  • Update-parallelism – Quantidade de containers que desejamos atualizar por vez
  • Name – Nome do serviço e por último a imagem que vamos utilizar para esse serviço.

O retorno do comando será algo parecido com isso:

docker-service1

Certo, meu serviço está criado, como escalono ele agora? Fácil, olha o print

docker-service2

Note que para escalar, basta executar o comando: docker service scale $(seu-servico)=numero. Agora vamos atualizar o nosso ambiente, certo? Muito fácil, basta executar o comando: docker service update, com ele é possível modificar diversos atributos do serviço, como por exemplo: Portas publicadas, limites de recursos, número de replicas, imagem, politica de escalonamento, etc.

Em nosso exemplo vamos atualizar a imagem que nosso serviço utiliza, veja que quando criamos, a imagem utilizada era a elasticsearch:latest, agora queremos testar a última versão do elasticsearch, que está em alpha (no dia da criação desse post) que é a 5.0, para isso basta executar: docker service update –image elasticsearch:5.0 elasticsearch, veja o que aconteceu:

docker-service3

Veja que nosso serviço não foi atualizado de uma vez só, esse processo foi sendo realizado conforme os containers iam sendo atualizados, isso devido a nossa politica de update que definimos na criação do serviço. Com o update você pode realizar diversas ações, veja mais em: docker service update –help, ele lhe mostrará todas as opções disponíveis.

Como removemos um serviço? Bem, você já deve ter imaginado como: docker service rm nome_do_servico.

Ahh, você se lembra que falamos aqui que no Docker 1.12 era possível criar um serviço distribuído dentro Swarm e acessá-lo de qualquer lugar? Pois bem, quando você criar um serviço você pode especificar qual será a porta publica dele, no exemplo acima não utilizamos isso, mas você pode definir (através do parâmetro -p) que a porta 8080 seja a porta de seu serviço, com isso todo o trafego enviado para a porta 8080 nos ips de seus nós do cluster de Swarm será redirecionado para os containers que atendam esse serviço. Lembrando que para você criar um serviço distribuído é necessário ter um cluster de Swarm ativo.

Gostaram do post? Deixe seu feedback e novamente, nos ajudem divulgando o blog.

Grande abraço!

 

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!

Rancher – Painel para Docker

Olá,
O MundoDocker mostra hoje para vocês como funciona o Rancher, uma plataforma para deploy de sua infraestrutura Docker de forma fácil e controlada. O Rancher pode ser dividido em duas camadas: RancherOS, que é um sistema operacional minimalista (assim como o CoreOS) e a plataforma Rancher, vamos conhece-las mais:

RancheOS

O RancherOS, trás apenas as funções essenciais para o funcionamento do ambiente Docker, veja na imagem abaixo como é a arquitetura do RancherOS:

rancheroshowitworksFonte: http://docs.rancher.com/

O tamanho de uma imagem do RancherOS é de de 20MB, e possui tudo que é necessário para montar seu servidor para deploy de containers Docker. Como pode ser visto na imagem acima, o RancherOS é uma kernel base bem limitado, e toda a plataforma do Rancher é montada em cima de containers, sendo o init do sistema, chamado PID 1, é feito dentro de um container Docker, e os demais serviços (udev, dhcp, etc) são inicializados dentro de outros containers. Como você deve ter notado, no RancherOS o Docker faz o trabalho do sistema de inicialização (sysvinit ou systemd), comum em outros distribuições Linux.

Outro ponto interessante é que, como o RancherOS inicializa dentro de um container, o próprio serviço Docker a nível de usuário executa dentro um container Docker, ou seja, os containers de aplicação (que o usuário cria) são inicializados dentro do container de sistema, isso garante ainda mais isolamento e claro segurança, pois inclusive o sistema está encapsulado dentro de um container.

Rancher

Rancher é um software opensource que possibilita a criação de uma plataforma privada para criação de containers. Através dele é possível administrar todos os pontos de seu ambiente Docker, incluindo: orquestração, loadbalance, volumes e rede. E ainda é possível fazer a diferenciação entre usuários, ou seja, você pode criar um pool de recursos para seu desenvolvedor e ele mesmo poderá criar quantos containers quiser e puder, isso é muito útil para da liberdade e ainda assim garantir controle.

Um grande ponto positivo do Rancher, é você não ser obrigado a usar o RancherOS (claro que isso é muito recomendado), basta você subir seu servidor com Docker instalado e instalar tanto a plataforma quanto os agentes do Rancher dentro de containers.

Vamos a prática? Partimos do principio que você já tenha o Docker instalado, agora execute:

docker run -d --restart=always -p 8080:8080 rancher/server

Esse comando criará um containers com o servidor Rancher já pronto, feito isso basta acessar via web o ipdoservidor:8080, veja na imagem:

Rancher01

Veja que ele deixa em destaque a informação de que não foi configurado uma forma de acesso, para fazer isso vá até: Admin – Access Control, e habilite a forma que desejar, em nosso exemplo escolhemos Local, ou seja, utilizarei usuário criados dentro do Rancher mesmo, após isso crie seu primeiro usuário administrativo e salve, em seguida faça logout da plataforma e acesse: ipdoservidor:8080/login e acesse com os dados que você acabou de criar:

Rancher02

Depois de logado, clique em Add Host, para adicionar um host a ser manipulado pelo Rancher, lembre-se, você pode ou não adicionar o host onde está executando o servidor Rancher, se escolher adicionar ele deixe marcado a opção que vem e clique em Save, na próxima tela você pode escolher um dos provedores (Amazon, Digital Ocean, RackSpace, etc) para fazer deploy de seus hosts, como vamos adicionar o host local, clique me Custom, o Rancher lhe informará alguns dados que você deverá seguir, como por exemplo liberar porta no firewall e executar um comando para adicionar o Rancher Agent, veja:

Rancher03

Feito isso você verá que foi adicionado um host em seu dashboard. A partir de agora basta você criar os containers que desejar e claro fazer toda a definição de usuários, pool de recursos e o que mais for interessante para você.

Isso é o básico sobre o Rancher, mas o suficiente para você entender a ferramenta e dar o uso adequado a ela dentro do seu ambiente, em posts futuros falaremos mais sobre ela e traremos alguns exemplos práticos de uso do Rancher para deploy de container e automação de infraestrutura.

Esperamos ter ajudado, e nos ajude divulgando o MundoDocker. Abraço!

Docker no Windows 10

Oi pessoal!

Hoje o intuito é mostrar para vocês como instalar e utilizar o Docker for Windows no Windows 10 com apenas alguns cliques, com a ajuda do nosso amigo da Umbler, o Leo, estamos disponibilizando um vídeo com o passo-a-passo que deve ser seguido. Antes veja alguns requisitos que você precisa atender:

  1. Você deve ter o suporte a virtualização habilitado em seu computador;
  2. Seu Windows deve ser 64bits versão 1607 e build: 14393.0;
  3. Você deve habilitar o recurso do hyper-v;
  4. Baixe o Docker for Windows pelo link.

Basta você habilitar na Bios de seu computador o recurso de virtualização, para isso será necessário reiniciar seu computador. Em seguida habilite o recurso do hyper-v através do adicionar recursos do Windows (Painel de controle – programas – recursos do Windows). Execute o arquivo que você baixou lá do site do Docker e siga as instruções que aparecerem, logo em seguida aparecerá para você uma mensagem no canto inferior direito informando que o Docker está sendo iniciado, aguarde até a mensagem sair e pronto, o Docker estará instalado e configurado em seu computador.

Se você desejar, pode alterar as configurações dele pelo ícone que estará nos Ícones ocultos, por lá é possível parar e iniciar o serviço do Docker, assim como modificar o registry default, alterar configurações de rede, compartilhamento de volume, dentre outras opções.

Para usar é muito simples, abra o cmd e execute os comandos do Docker Cli, como se você estivesse em um terminal linux: docker ps -a, docker images, docker run xxx e assim por diante, note que a versão que ele instalará já é a 1.12 rc4, como você já viu nesse post, ela trás uma séria de melhorias e novas features, então bom divertimento :).

Esperamos que tenham gostado, e precisando nos enviem suas dúvidas para que possamos ajudar.

Grande abraço!

Medindo Recursos

Oi Pessoal!
Hoje o post será um pouco mais curto, no vídeo abaixo explicamos como funciona e como o cAdvisor pode te ajudar a mensurar o uso de recursos de cada container, bem como o uso de recursos pelo host.

Ficou dúvida? Curiosidade? Deixe sua dúvida e vamos conversando, divulgue o mundodocker.com.br e nos ajude disseminando conhecimento!

Persistindo dados -BTSync

Olá,

Hoje o mundodocker.com.br dará inicio a uma série de posts que tem por objetivo trazer soluções práticas para a persistência de dados no ambiente Docker.

Uma das premissas de se utilizar Docker é de que seu container é descartável, sim, isso pode parecer um tanto quanto radical, mas container em si foi desenvolvido para atender um processo durante um tempo determinado, e não para servir como um servidor virtual, nesse sentido, um cuidado que se deve ter é persistir os dados importantes de sua aplicação em um volume, ou até mesmo em um sistema de arquivo distribuído, dessa forma um container pode morrer, sem que sua aplicação morra junto.

Vamos ver nessa série, algumas alternativas para isso, e começamos com a mais simples delas: BTSync. Para quem não conhece o BTSync é uma ferramenta que utiliza o protocolo do Bittorrent para sincronismo de dados, através dele é possível sincronizar pastas e arquivos entre diferentes plataformas (desde que tenha o Sync instalado), de forma segura e rápida. No nosso exemplo vamos simular a sincronização de dados entre containers, dessa forma você pode fazer com que diversos containers tenha os dados de sua aplicação, garantindo assim maior disponibilidade. Mãos a obra então:

Como vocês já sabem, vamos criar um Dockerfile para gerarmos uma imagem e carrega-la para onde quisermos, esse é um bom exemplo:

FROM ubuntu:14.04

RUN apt-get update && apt-get install -y curl
RUN curl -o /usr/bin/btsync.tar.gz http://download-lb.utorrent.com/endpoint/btsync/os/linux-x64/track/stable; cd /usr/bin && tar -xzvf btsync.tar.gz && rm btsync.tar.gz
RUN mkdir -p /btsync/.sync; mkdir -p /var/run/btsync; mkdir -p /data

EXPOSE 8888
EXPOSE 55555

ADD start.sh /usr/bin/start.sh

RUN chmod +x /usr/bin/start.sh

VOLUME ["/data"]

ENTRYPOINT ["start.sh"]

 

Na mesma pasta onde está esse Dockerfile, crie um arquivo chamado: start.sh com o seguinte código:

#!/bin/bash
SECRET="${@}"
: ${SECRET:=`btsync --generate-secret`}

echo "Starting btsync with secret: $SECRET"

echo "{
 "device_name": "Sync Server",
 "listening_port": 55555,
 "storage_path": "/btsync/.sync",
 "pid_file": "/var/run/btsync/btsync.pid",
 "check_for_updates": false,
 "use_upnp": false,
 "download_limit": 0,
 "upload_limit": 0,
 "shared_folders": [
 {
 "secret": "$SECRET",
 "dir": "/data",
 "use_relay_server": true,
 "use_tracker": true,
 "use_dht": false,
 "search_lan": true,
 "use_sync_trash": false
 }
 ]
}" > /btsync/btsync.conf

btsync --config /btsync/btsync.conf --nodaemon

Explicando: Você pode definir, via arquivo de configuração, algumas variáveis para o btsync trabalhar, como por exemplo chave para estabelecer comunicação, diretório que será sincronizado e limites de transferência, é claro que em nosso teste não vamos definir algumas delas, apenas alterei o “dir” para que seja sincronizado o diretório /data, você pode definir qualquer um. Por padrão, a porta de comunicação é a 55555, você pode modificá-la sem problema, e não é necessário você mapear portas do host para o container ;).

Então, criado o Dockerfile e o start.sh, vamos gerar a imagem:

docker build -t bt_mundodocker .

Agora é simples, basta você iniciar o primeiro container:

docker run -d --name repl1 bt_mundodocker

Você deve capturar a chave gerada na inicialização desse container, ela será útil para quando você iniciar o segundo container, pois será a chave que permitirá estabilizar a conexão entre os peers do btsync:

docker logs repl1

A saída desse comando, será algo parecido com isso:

Starting btsync with secret: ANDHOU5F7NHNR3EBPFYBPFJJMKATGLBEK
[20160329 21:23:04.194] total physical memory 536870912 max disk cache 2097152
[20160329 21:23:04.195] My PeerID: 102D9BFD720DF686F77DD0BC7FE5FDC98C767930
[20160329 21:23:04.683] LC: license expired
[20160329 21:23:05.291] LC: license renewal

Basta você inicializar o segundo container, passando essa chave como parâmetro:

docker run -d --name repl2 bt_mundodocker ANDHOU5F7NHNR3EBPFYBPFJJMKATGLBEK

Veja agora o retorno do comando docker logs desse container:

Starting btsync with secret: ANDHOU5F7NHNR3EBPFYBPFJJMKATGLBEK
[20160329 21:27:07.480] total physical memory 536870912 max disk cache 2097152
[20160329 21:27:07.482] My PeerID: 1015FC44C961E6AB9B77AD3951437CC69C6D357A
[20160329 21:27:07.756] LC: license expired
[20160329 21:27:08.084] LC: license renewal
[20160329 21:27:08.090] PeerConnection[0x00007fe9bc001170] incoming connection from 172.17.0.42:57871
[20160329 21:27:08.143] PeerConnection[0x00007fe9bc001170] incoming connection from 172.17.0.42:57871
[20160329 21:27:09.260] PeerConnection[0x00007fe9bc20a1c0] incoming connection from 172.17.0.42:55555

Para testar, acesse os containers (docker exec -it repl1/repl2 /bin/bash), crie arquivos dentro da pasta /data e veja que eles serão sincronizados entre os containers, mesmo se você tiver mais de dois containers. Legal né? Todo o trafego entre os containers (mesmo os que não sejam locais) é criptografado, e apenas peers (containers) que iniciaram com a chave mencionada é que entram na replicação. Claro, nem tudo são flores, quanto maior a latência entre os containers, mais lento será essa replicação, então pense bem antes de sair utilizando ele para qualquer coisa

Fácil, simples e muito eficiente, essa foi a apresentação da primeira solução para persistência de dados entre os containers, fique atento aos próximos. Se gostou, ajude divulgando o Blog.

Grande Abraço!

Docker Universal Control Plane – Parte 1

Oi Pessoal,

Depois de um tempo nas postagens, hoje vamos iniciar os trabalhos aqui no https://mundodocker.com.br, trazendo para vocês uma das soluções que o Docker disponibilizou (ainda em fase beta) e que veio como resultado da aquisição da Tutum, que é o Docker Universal Control Plane. Entenda um pouco mais sobre as suas funcionalidades e objetivos neste primeiro post.

O Docker UCP, assim como algumas ferramentas que já apresentamos aqui (vide Rancher) é uma alternativa de painel para administração de sua infraestrutura de Docker, seja ela local ou na nuvem, a diferença entre essas ferramentas é basicamente a empresa que presta suporte e mantem a ferramenta, no caso da UCP a própria Docker. Em questão de funcionalidades tanto Rancher quanto UCP são bem parecidas, com a diferença novamente de que a UCP é 100% compatível com o Docker e suas ferramentas nativas, como por exemplo a Docker Swarm e Compose. Veja abaixo uma listagem das funcionalidades e benefícios da Docker UCP:

Solução voltada para empresas:

Um dos recursos que existe no UCP é a opção de integrar o método de autenticação em seu LDAP ou AD, isso é muito mais seguro e claro ajuda na organização e delegação de funções dentro do painel.

Gerenciamento nativo de seu ambiente Docker:

Como mencionei acima, o Docker UCP é desenvolvido pela própria Docker, isso garante 100% de compatibilidade entre todas as ferramentas que a Docker já disponibiliza e este painel, e claro, torna mais fácil a integração entre as diferentes ferramentas.

Administração simplificada:

Você pode gerenciar desde containers individuais até aplicações mais complexas que utilizam o Docker Compose, você pode de forma fácil criar um conjunto de rede ou volume e associar a sua aplicação/container apenas via interface web, sem a necessidade de acessar os servidores.

Resultado mais rápido:

O UCP permite você gerenciar e otimizar seu deploy de aplicação, você pode configurar todo seu ambiente, incluindo repositório de imagens e servidores em poucos cliques, isso é muito mais prático do que ficar configurando o ambiente via linha de comando e claro gera retorno muito mais rápido, o que no mundo DevOps isso é imprescindível.

 Agilidade e Controle:

Crie, gerencie e faça deploy de qualquer aplicação, em qualquer lugar, quando quiser, escale, distribua e altere quando for necessário sem perder o controle, esse é um dos pontos fundamentais do UCP, e uma das vantagens mais interessantes para os times de desenvolvimento e infra estrutura.

Escalável e disponível:

O Docker UCP foi desenhado e desenvolvido para ser altamente disponível e para que você possa escalar de forma fácil e rápida, para isso ele utiliza como engine de clusterização o Docker Swarm, que como já explicado aqui no blog, é extremamente leve e fácil de se administrar. Para garantir uma maior disponibilidade o Docker UCP pode ser integrado com algum serviço de entrega de chave-valor, como Consul, Etcd, dentre outros, isso na verdade é uma das premissas para se ter o Docker UCP rodando em seu ambiente, pois apenas utilizando um desses serviços é que se garante a disponibilidade da ferramenta.

Fique atento, em breve postaremos mais alguns posts sobre essa ferramenta, e quem sabe um vídeo ;).

Gostou? Nos 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://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!

WinDocks – Docker For Windows

Oi Pessoal,

No final do mês passado foi lançada uma StartUp com objetivo de criar uma forma de executar containers Windows utilizando como sistema base o Windows Server 2012, hoje compartilho com vocês um vídeo produzido pela equipe da WinDocks explicando como funciona a solução deles e como rodar um container com SqlServer e IIS, veja em:

https://youtube.com/watch?v=ZrLxiYy3ZZU

Agora em outubro eles pretendem lançar uma versão Beta ao público, isso fará com que a solução seja melhor avaliada e claro, melhorada.
É uma proposta bem interessante e tem muito a acrescentar no ecossistema Docker, ficamos no aguardo de novidades deles, e podem deixar que vou informando vocês por aqui. Quer ir mais afundo? Acesse: http://windocks.com/.

Grande Abraço!

Docker Compose

Oi pessoal,

Seguindo nossa série de posts sobre as ferramentas do ecossistema Docker, hoje veremos um pouco mais sobre o Docker Compose, uma ferramenta que agilizar no deploy de seu ambiente, utilizando uma forma simples, claro e padronizada.

O Docker Compose é uma ferramenta para a criação e execução de múltiplos containers de aplicação. Com o Compose, você usar um arquivo do tipo yaml para definir como será o ambiente de sua aplicação e usando um único comando você criará e iniciará todos os serviços definidos.

Compose é ótimo para desenvolvimento, testes e homologação, bem como para melhorar seu fluxo de integração continua. Por exemplo:

  • Em ambiente de desenvolvimento: Você pode utilizar ele para simular todo o ambiente de produção, ou seja, precisando de serviço redis, php, mysql? Basta definir isso em um arquivo .yml e quando você executar o docker-compose up, todo esse ambiente está disponível para você, todas as dependências que sua stack precisa estará configurada e disponível para uso. Isso sem contar que este ambiente poderá ser isolado, sem depender ou prejudicar o trabalho dos demais da equipe.
  • Automação de testes: Uma das premissas básicas para desenvolvimento e integração continua é ter uma base de testes automatizada, isso para garantir qualidade e agilidade na entrega de novas releases de sua aplicação. Pensando nisso, você pode utilizar o docker compose para criar sua própria suite de testes, e precisando apenas executar um docker-compose up para testar os 50, 100, 200 requisitos que você definiu.

Para utilizar o docker-compose você precisa ter em mente que será necessário seguir essas três etapas:

  1. Definir o ambiente necessário para sua aplicação utilizando um Dockerfile (que pode ser reproduzido em qualquer lugar que tenha Docker instalado);
  2. Definir no arquivo .yml  quais serviços são essenciais para sua aplicação e a relação entre elas.
  3. Executar o comando docker-compose up para que seu ambiente seja criado e configurado.

Fácil certo? Vamos praticar?

Instalação

Bem simples, basta executar o seguinte comando (caso Linux), se você estiver utilizando em Windows via Docker ToolBox você já terá disponível o docker-compose. Vamos lá:

curl -L https://github.com/docker/compose/releases/download/1.5.2/docker-compose-`uname -s`-`uname -m`
 > /usr/local/bin/docker-compose

Depois:

chmod +x /usr/local/bin/docker-compose

Compose eu escolho você

Vamos testar com um WordPress, é fácil:

  1. Criar um diretório de trabalho (mkdir /my-app);
  2. Faça download do WordPress: cd /my-app; curl https://wordpress.org/latest.tar.gz | tar -xvzf –
  3. Criar um arquivo Dockerfile com o seguinte código: 
    FROM orchardup/php5
ADD . /app
  4. Criar um arquivo my-app.yml com o código: 
    web:
  build: .
  command: php -S 0.0.0.0:8000 -t /my-app
  ports:
    - "80:8000"
  links:
    - db
  volumes:
    - .:/my-app
db:
  image: orchardup/mysql
  environment:
    MYSQL_DATABASE: wordpress
  5. Certifique-se de que seu wp-config esteja parecido com este: 
    <?php
define('DB_NAME', 'wordpress');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', "db:3306");
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

$table_prefix  = 'wp_';
define('WPLANG', '');
define('WP_DEBUG', false);

if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

require_once(ABSPATH . 'wp-settings.php');
  6. O que falta? docker-compose up no diretório onde você criou o Dockerfile e o  my-app.yml.

Agora é só acessar: http://ipdamaquina e prosseguir com a instalação do Woprdress normalmente, o que o Compose fez então? No passo 3 nós criamos um arquivo Dockerfile contendo a descrição da imagem que queremos criar e que será utilizada como base para o nosso ambiente, no passo 4 nós definimos qual era esse ambiente, veja que definimos 1 container para atender requisições web e 1 banco de dados, quando executamos o docker-compose up ele criará a imagem baseado no Dockerfile e criar os containers de serviços que definimos no my-app.yml. O mais legal, você pode quer escalar seu ambiente, ter mais containers web? docker-compose scale web=5 e o Compose criará e iniciará 5 containers do serviço web que definimos no my-app.yml.

Alguns dados importantes sobre o Docker Compose:

  • O Compose preserva todos os volumes atribuídos aos seus serviços, por exemplo, quando você executa o docker-compose up, se você já tiver algum outro container utilizando o volume informado, o Compose copiará o volume do container antigo para o novo container, sem perder nenhuma informação.
  • O Compose recriará apenas containers cujas configurações foras modificadas, caso contrário ele se baseará nas configurações que ele já tem armazenada em cache, isso é muito útil principalmente para provisionar e escalar seu ambiente de forma muito mais rápida.

Você ainda pode utilizar o Docker Compose juntamente com o Docker Machine e provisionar seu ambiente em qualquer lugar que precisar, isso é ainda mais útil para quem tem seu serviço de infraestrutura terceirizado com outros provedores (AWS, Digital Ocean, etc).

Gostou? Ótimo! nos ajude divulgando o MundoDocker, não gostou? Não tem problema, deixa seu feedback para que possamos melhorar cada vez mais

 

Abraço!

MundoDocker no DevOpsWeek

Oi Pessoal,

O Ano começou a todo vapor aqui para o MundoDocker, e hoje queremos convidar a todos para se inscreverem no DevOpsWeek, um dos maiores eventos sobre o assunto DevOps, Desenvolvimento/Infra ágil do Brasil.

Participaremos do evento com a apresentação: Deploy Integrado com Docker, é o assunto do momento, e o objetivo é tirar dúvidas e dar ideias de como o você pode usar Docker para automatizar suas rotinas, e claro acelerar seus processo de desenvolvimento.

Veja abaixo a chamada para o evento que gravamos, te liga:

Ficou interessado? Então te inscreve, o evento é online e gratuito!!! Acesse: http://devopsweek.com.br

 

Por hoje era isso, e fique atento pois teremos mais novidade aqui no Blog.

Grande abraço!

Troubleshooting e dicas de Docker

Olá pessoal,

Já faz mais de 1 ano que criamos esse blog e hoje resolvemos fazer um post referente a como solucionar algumas dificuldades e problemas que tivemos no começo, visto que trabalhamos a mais de 2 anos já com Docker, tivemos muitos problemas que queremos demonstrar para vocês.

Instalando a versão mais recente

A maioria das pessoas que acabam por usar Ubuntu, Centos, RedHat ou qualquer outra distribuição utiliza seus próprios comandos para realizar a instalação do Docker, com yum ou apt-get. Mas a forma de utilizar as versões mais recentes são essas:

Versão oficial para se utilizar em produção:

curl -sSL https://get.docker.com/ | sh

Versão que se encontra ainda em fase de testes:

curl -fsSL https://test.docker.com/ | sh

Versão alpha que está em constante desenvolvimento:

curl -fsSL https://experimental.docker.com/ | sh

 Como remover todos os containers parados:

docker rm $(docker ps -a -q)

 Sincronizar o relógio do host com o container:

Isso é um dos principais problemas que as pessoas acabam encontrando as vezes.

Para Centos (Na hora de criar o container mapeia o diretório do host com o do container)

docker run -v /etc/localtime:/etc/localtime:ro centos date

Para Ubuntu (Na hora da criar o container passa como variável o timezone(tz)

docker run -e "TZ=America/Salvador" ubuntu date

 Comunicação entre containers:

Por padrão no Docker a comunicação entre os containers na mesma rede é liberado através de IP interno. Mas caso você queira que os containers não se comuniquem diretamente basta mudar na hora da criação da rede colocar icc=false.

docker network create -o com.docker.network.bridge.enable_icc=false rede_isolada

Montando volumes com services:

Quando criamos um container simples com docker run, existe a opção do -v onde podemos passar como parâmetro o nosso volume, porém com a implementação do services no Docker 1.12 ficou um pouco mais complicado na hora de passar um volume para o serviço:

Como você pode ver na opção “type” temos o “bind” que seria um diretório em nosso host:

docker service create --mount type=bind,source=/diretoriohost,target=/diretoriocontainer imagem

E também temos a opção volume que é passado o volume que é criado com “docker volume create…..

docker service create --mount type=volume,source=meuvolume,target=/diretoriocontainer imagem

 Docker commit e volume:

O comando “docker commit” gera uma imagem do nosso container, porém ele NÃO vai armazenar os dados do volume que estão atrelados a aquele container. Então o docker commit não irá servir de backup para os seus dados que estão no volume.

Não rode containers com –privileged

Com a opção de –privileged o container consegue facilmente acessar diversas áreas do seu host na qual podem ser cruciais caso alguém ache alguma brecha de segurança em sua aplicação.

Um processo para cada container.

Não instale pacotes desnecessários em seus containers, se você quer ter um container para apache, só instale o apache nele. Quer ter o PHP também? então suba outro container.

Cuidado com as regras de IPTABLES

Como o Docker trabalha com toda a sua parte de redes através de iptables, é bem provável que se você fizer alguma manutenção em seu firewall e editar alguma regra errada, toda a sua estrutura de Docker pode parar de funcionar por algum problema.

Coloque o diretório do docker em outro disco:

O docker utiliza o caminho “/var/lib/docker” para colocar todos os seus arquivos de instalação e também toda a sua estrutura de containers, volumes e mais outros recursos que ele utiliza. Então não deixe esse diretório no mesmo disco do seu SO.

Gostaram do post? Deixe seu feedback e novamente, nos ajudem divulgando o blog.

Grande abraço!

Kubernetes parte II

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

Docker Machine

Olá!

Umas das ferramentas mais interessantes do ecossistema Docker, e que é mantido pela própria Docker é o Docker Machine, com ele é possível você fazer deploy de seu ambiente na infra-estrutura que desejar, você pode portar sua aplicação do seu notebook para AWS, Digital Ocean, ou o que for. Veja no vídeo um exemplo prático disso:

Você pode ainda integrar com Docker Compose, e automatizar ainda mais essas tarefas, legal né? Espero que tenham gostado, tendo dúvidas nos contatem, estamos dispostos a sanar todas as dúvidas.

Abraço!

E os Logs?

Oi Pessoal, tranquilo?

Uma das coisas que atormentam tanto a vida do pessoal de Dev quanto de Ops é saber o que está acontecendo com o seu ambiente. Como se resolve isso? Existem duas formas, que devem sempre trabalhar juntas, são elas: Monitoramento, para saber que vai dar problema antes do problema ocorrer :), e Gerencia de logs, para saber, depois de ocorrer algum problema, o que aconteceu com sua aplicação ou ambiente que ocasionou o comportamento inesperado.

Essa mesma abordagem deve ser utilizada quando se trabalha com containers também, para monitoria você já viu aqui e aqui algumas formas de como pode ser feito esse monitoramento. Para a gerencia de logs você deve pensar antes qual será a criticidade dessas informações para o debug de sua aplicação e resolução de algum imprevisto, outro ponto é: como preciso ou como gostaria de visualizar essas informações. Tendo resolvido essas duas questões você pode então optar:

  • Utilizar o comando docker logs: Com isso você terá as informações do que está sendo enviando para a console do container, ou seja,somente irá visualizar aquilo que estiver passando na console, você deve fazer com que sua aplicação envie as informações necessárias para a console do container. Caso sua aplicação salve o debug em arquivo de log você não conseguirá visualizar de forma fácil essa informação.
  • Utilizar plugins de log: Utilizando plugins você pode fazer com que qualquer log do container seja enviado para um serviço externo, isso garante que você poderá ter acesso a qualquer informação (seja do container ou app) de um único lugar.

O que vamos ver hoje é como você pode utilizar alguns dos plugins de logs mais conhecidos, isso é claro na prática

Fluentd

Um dos drivers de log mais fácil de se utilizar, com ele você pode enviar tanto o stderr quanto o stout para o serviço de logs externo, para isso basta você rodar:

docker run --log-driver=fluentd

É claro que você precisa passar alguns parâmetros, como por exemplo: “–log-opt fluentd-address=” onde você define qual será o destino de seus logs, geralmente será um host onde estará rodando o servidor Fluentd ou o endereço que esse serviço lhe fornecer. Por padrão a tag de busca será o id do container, com isso, quando você precisar consultar algum log deverá faze-lo pelo id do container que desejar.

Splunk

O Splunk é talvez uma das ferramentas para gerenciamento de log mais completo que se pode ter, e da mesma forma que o Fluentd, você precisa apenas definir esse driver como sendo de log:

docker run --log-driver=splunk

Você precisa definir algumas coisas antes, veja a lista:

  • splunk-token: Token utilizado para autenticação do container na API http;
  • splunk-url: Endereço do servidor de Splunk disponível, seja ele local ou na solução de cloud da Splunk;
  • splunk-source: Origem do log (se não definido ele coletará tudo);
  • splunk-sourcetype: Tipo do log (app, debug, etc);
  • splunk-index: Índice para os logs;
  • splunk-capath: Caminho do certificado;
  • splunk-caname: Nome para validação do certificado, por padrão ele pega pelo nome do splunk-url;
  • splunk-insecureskipverify: Desativa a verificação ssl para o seu host Splunk;
  • tag: Identificação do log na base, no caso do Docker você pode definir qualquer informação do container como tag, por exemplo: ID, Nome, Região, etc;
  • labels: Facilita a consulta do log posteriormente, você pode por exemplo consultar logs do container x que pertence a região Sul;
  • env: Pode classificar por Dev, Test, Prod etc.

Veja um exemplo prático:

docker run --log-driver=splunk --log-opt splunk-token=SEUTOKENAQUI --log-opt splunk-url=https://servidor-splunk:8088 --log-opt splunk-capath=/etc/cert/cacert.pem --log-opt splunk-caname=SplunkDefaultCert --log-opt tag="{{.Name}}/{{.FullID}}" --log-opt labels=location --log-opt env=TESTE --env "TESTE=false" --label location=sul nginx

AWS Logs

Claro que não poderia faltar a opção de enviar seus logs para o CloudWatch da AWS, e é o mais simples de se utilizar, por um motivo: Basta você ter conta na AWS e ativar o CloudWatch, não é necessário contratar um serviço cloud de terceiro ou subir um servidor de log local. Veja como você pode utiliza-lo:

docker run --log-driver=awslogs --log-opt awslogs-region=sa-east-1

Você deve definir para qual grupo de log deseja enviar os logs do container, e tenha cuidado pois dependendo do tipo de logs e quantidade, pode prejudicar a visualização do mesmo, então preste atenção no formato de log que estará enviando:

docker run --log-driver=awslogs --log-opt awslogs-region=sa-east-1 --log-opt awslogs-group=MeuGrupodeLog nginx

A autenticação é bem simples, você montar o seguinte volume: aws:~/.aws, dentro dessa pasta deve ter um arquivo chamado credentials com o seu AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, e AWS_SESSION_TOKEN Lembre-se que o usuário utilizado para isso deve ter no mínimo as seguintes permissões: logs:CreateLogStream e logs:PutLogEvents.

Espero ter ajudado, tenho alguma dúvida pode nos enviar por e-mail ou deixe nos comentários. E nos ajude divulgando o blog

Abraço!

Git e Docker

Fala pessoal,

Hoje vamos demonstrar como podemos utilizar Docker e Git dentro de nossos containers.

 

 

Legal não? Se gostou ajude-nos divulgando o mundodocker.com.br, abraço!

Entrevista com Jérôme Petazzoni

Oi Pessoal!

Hoje vamos reproduzir aqui uma entrevista concedida pelo Jérôme Petazzoni para o site: opensource.com. Para quem não o conhece, o Jérôme é um dos principais evangelistas Docker, esteve presente na QCon que ocorreu em agosto em São Paulo. A entrevista foi realizada por Sandeep Khuperkar que é um dos moderadores do site. Veja abaixo:

O que são containers? Quais tecnologias de containers existem e como o Docker é diferente delas?

De um ponto de vista mais abrangente, containers são máquinas virtuais mais leves. Você pode instalar qualquer coisa em um container, independente de  (e sem afetar!) outros containers em seu servidor. Cada container possuí sua própria camada de rede, processo (PID), sistema de arquivo, etc. A carga de trabalho é significantemente menor do que em VMs: containers iniciam mais rápido, requerem menos memória e espaço em disco. Isso por que, de um ponto de vista mais técnico, containers são processos regulares dentro do servidor, utilizando features do kernel como namespaces e cgroups para garantir isolamento. Iniciar um container é iniciar um processo UNIX normal; Criar um container  é apenas uma clonagem instantânea de um sistema de arquivos copy-on-write (Que hoje é extemamente barato, tanto em tempo de criação quanto em uso de espaço em disco).

O Docker é diferente das demais tecnologias, pois ele não é apenas uma engine para criação de containers, Docker é uma plataforma composta pela Docker Engine (para criar e executar containers), o Docker Hub (um repositório de armazenamento de imagens publicas, onde é possível o usuário criar e armazenar imagens customizadas), e ainda um vasto ecosistema de ferramentas como Docker Compose, Docker Machine, Docker Swarm, e muitas outras, todas girando em torno de um API pública e aberta.

De que forma o Docker diferente de outras tecnologias de hypervisor para virtualização?

Pode-se dizer que Docker é um “hypervisor para containers”, mas muitos não aprovarão esse metafora, uma vez que hypervisors geralmente gerenciam VMs, e Docker gerencia containers. Os detalhes técnicos são muito diferentes, quando um hypervisor inicia uma VM, ele cria hardware virtual, e aproveita instruções da CPU ou de recursos específicos, como VT-x, AMD-V. Quando Docker cria um container, ele aproveita recursos do kernel como namespaces e cgrups , sem depender de recursos de hardware específicos.

Por um lado os containers são mais portáteis, pois podem ser executados tanto em VMs quanto em servidores físicos, Por outro eles não são portáteis devido ao fato de serem atrelados ao kernel do servidor onde estão, isso quer dizer, por exemplo, que você não pode executar um container Windows dentro de um kernel Linux (exceto se o seu Linux conseguir executar binários do Windows).

O que você sugere para gerenciar armazenamento em containers Docker? Como é possível vincular dados com containers Docker?

Docker tem trabalha com o conceito de “volumes”, que são os diretórios compartilhados entre o container e seu servidor. Volumes são conceitualmente semelhante as “pastas compartilhadas” em máquinas virtuais, exceto elo fato de que eles não necessitam de qualquer configuração particular no container, e tem  zero de overhead, pois eles são implementados utilizando pontos montagens.

Quando você tem dados que encontram-se em um disco (seja disco local, ou um pool de RAID, ou algo montado através da rede, ou qualquer outra coisa) a opção mais fácil é montar esse disco no host, e em seguida, expô-lo ao container através de um “volume”.

Docker também tem (uma nova marca, ainda experimental) mecanismo de plug-in que permite que um container forneça armazenamento para outros containers. Isto significa que um container pode ser responsável pelo execução de um agente ou membro de uma rede Ceph, Gluster, ou qualquer outro cluster de armazenamento, e expor os dispositivos de bloco e os pontos de montagem para outros containers.

Como você faz para mover os dados de um container Docker para outro iniciado em outro servidor?

Exatamente como fizemos isso antes dos containers: armazenamento de rede, sistemas de arquivos distribuídos, a transferência de dados ou sincronização com rsync, unison, etc. Há, porém, duas vantagens ao usar containers: Em primeiro lugar, a nossa forma de acessar os dados são abstraídos do container, Se eu mudar, por exemplo, de DRBD para Ceph, meu container não precisa saber qual é a tecnologia utilizada, na verdade, o mesmo container será executado de forma idêntica em armazenamento local, ou em armazenamento distribuído. A outra vantagem vem desses novos plugins de armazenamento, eles vão fazer o acesso aos dados mais simples, separando corretamente o container de aplicação do container de armazenamento.

Como você pode garantir que as modificações de um container em execução são salva na criação de uma nova imagem?

Docker oferece chamadas de API para comparar um container com sua imagem original, e para criar uma nova imagem a partir de um container existente. Os comandos CLI para essas chamadas de API são “docker diff” e “docker commit”.

Como os containers Docker podem ajudar a criar soluções altamente disponíveis?

Quando você  cria um sistema altamente disponível, você geralmente passa um bom um tempo pensando em uma lista de coisas que devem ser feitas. Docker tornará algumas dessas etapas mais fácil, por exemplo, garantindo que você possa implantar novas versões de seu software nas máquinas de produção de forma mais ágil. O Docker não vai resolver problemas magicamento (o uso da magia na criação de sistemas é não é aprovado geralmente), mas ele vai tornar muitas das coisas mais fáceis, mais rápidas, mais confiáveis – da mesma forma do que usar um gerenciador de pacotes é geralmente mais conveniente do que a compilação de tudo, desde o código fonte.

Como você vê a crescente adoção do Docke em clientes empresariais e ambientes de produção?

De um modo geral, a visão é essa:: Docker inicia como uma ferramenta para desenvolvimento para consistência e repetição do ambiente, similar como o Hashicorp’s Vagrant faz. Então, gradualmente se forma CI/CD, onde ele ajuda a reduzir tempos de teste pela metade (ou até mais). Dai em diante ele é utilizado em testes de  pre-produção, onde o risco é menor. Eventualmente, uma vez que a equipe operacional ganhou experiência e confiança suficiente com o funcionamento do Docker, ele vai passa a atender todo o tráfego do ambiente de produção.

Legal não? Quer ver na íntegra? acesse: http://opensource.com/business/15/8/interview-jerome-petazzoni-docker-linuxcon

Fique atento e nos ajude divulgando do blog! Grande abraço.

Docker 1.10

Oi Pessoal,

Novidades no Docker, é claro que tem aqui no  mundodocker.com.br ;). Vamos trazer um apanhado do que há de novo na última versão da engine, assim como nas ferramentas do seu ecossistema. Vamos lá:

Docker Engine 1.10

  • Melhoramento na captura de eventos: A instrução docker events foi reformulada e teve uma melhoria significativa nos métodos utilizados, isso garante um tempo de resposta menor e mais precisão nos dados capturados.
  • Aperfeiçoamento no trabalho com imagens: Foram refatorados diversos trechos de código o que tornou o download e upload de imagens cerca de 3 vezes mais rápida, e garante um melhor controle em caso de falha do download.
  • Alteração de configuração online: Quando você seta os valores de limite (como cpu, memória, etc), tradicionalmente você precisaria reiniciar o container ou até mesmo recria-lo, agora na versão 1.10 você pode fazer essa alteração online, utilizando o comando: docker update.
  • Arquivo de configuração: Agora é possível redefinir alguns parâmetros e recarregar o docker sem a necessidade de reiniciar nada.
  • Sistema de arquivo temporário: A partir da versão 1.10 ficou mais fácil criar um ponto de montagem temporário, isso é muito útil quando você tem um container read-only mas sua aplicação precisa escrever em disco (log, sessão, etc), basta passar o parâmetro: –tmpfs no docker run.
  • Restrições de I/O de disco: É possível definir diversos parâmetros para restringir acesso a disco, entre eles: --device-read-bps, --device-write-bps, --device-read-iops, --device-write-iops, e --blkio-weight-device
  • Novo plugin de log: Agora é possível integrar o Splunk ao Docker para coleta dos logs.
  • Entre outras diversas correções de segurança e performance.

Docker Swarm 1.1

  • Reagendar containers quando um nó falhar: Essa é uma solução em fase de testes ainda, mas permite que o Swarm recrie o container em um nó que esteja disponível para atender, lembrando que esse é um recurso de teste, é possível que tenha alguns bug ainda.
  • Foram realizadas diversas melhorias para definição da ‘saúde’ do nó, isso garante um melhor gerenciamento dos recursos utilizados e claro possibilita criar um politica mais eficiente de deploy.

Docker Network

Na parte de rede do Docker foram feitas algumas melhorias significativas, algumas apenas ajustes e resolução de problemas encontrados na versão anterior, outras novidades mesmo, entre elas:

  • Rede Interna: Agora é possível criar uma rede para trafego interno (de entrada e saída), facilitando assim a sub-divisão das redes e facilita a organização topológica de seus ambiente.
  • IP personalizado: Você pode definir um ip personalizado independente da rede onde ele está criado, você não fica restrito ao range de ip de onde sua rede pertence.
  • Rede multi-host: Suporte todas as versões antigas do kernel (do 3.10 em diante), até a versão 1.9 você só poderia utilizar esse recursos em uma versão especifica do kernel.

Docker Compose, Machine e Registry: Tiveram algumas correções de bug e refatoração em seus códigos para que ficassem mais performáticos, mas nenhuma grande novidade, mas com certeza serão trabalhados para a próxima versão.

Espero que tenha ajudado, e não fique esperando, baixe e utilize essa última versão, para a comunidade isso é muito importante, quanto mais feedback melhor, e isso vale para o nosso blog também

Se gostou, ajuda divulgando o blog, grande abraço!

Auto Complete para Docker

Olá!

Hoje o post será um pouco diferente dos que geralmente publicamos, queremos mostrar para vocês como é possível utilizar a funcionalidade de auto complete do shell para os comandos Docker. Mas para que isso? Simples, facilidade e agilidade na execução de comandos, quem aqui nunca apertou o tab depois de digitar ‘./conf’? Então, você deve sentir falta dessa facilidade quando se utiliza os subcomandos do docker, certo? Queremos mostrar pra vocês como resolver isso.

Como você já viu aqui, existem diversos subcomandos do docker, e cada um possui diversos parâmetros que podem ser utilizados, com o docker –help você poderá visualizar as opções disponíveis.

Mas isso é chato algumas vezes, é mais fácil começar a digitar docker run --vol...[tab][tab]e deixar o autocomplete fazer o trabalho:

$ docker run --volume
--volume         --volume-driver  --volumes-from

#vamosinstalar?

No Mac OS X

O processo é simples, estando no Mac OS X temos que instalar o auto completion usando o brew:

$ brew install bash-completion

E em seguida adicionar as linhas em nosso arquivo de profile ($HOME/.bash_profile ou /Users//.bash_profile)

if [ -f $(brew --prefix)/etc/bash_completion ]; then
    . $(brew --prefix)/etc/bash_completion
fi

Você pode executar os seguintes comandos, que devem ser utilizados nesta sequência:

$ echo "if [ -f $(brew --prefix)/etc/bash_completion ]; then" | tee -a $HOME/.bash_profile
$ echo "    . $(brew --prefix)/etc/bash_completion" | tee -a $HOME/.bash_profile
$ echo "fi" | tee -a $HOME/.bash_profile

Atenção: Se não temos o homebrew instalado, veja em http://brew.sh/ mais informações de como instala-lo e utiliza-lo.

 
No Linux

No Linux, como sempre, é mais simples, basta instalar via gerenciador de pacotes da sua distribuição. Se for Debian like (Ubuntu, Mint, etc) usamos o apt-get:

$ sudo apt-get install bash-completion

Se for Red Hat like (RHEL, CentOS, Fedora, etc) então usamos yum:

$ sudo yum install bash-completion

Completion do Docker Engine

O arquivo está disponível em https://github.com/docker/docker/blob/master/contrib/completion/bash/docker portanto sempre que fizer uma atualização é recomendável que você baixe novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker.

Ao baixar devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux, se estivermos em um Mac OS X:  $(brew --prefix)/etc/bash_completion.d.

No Mac OS X
$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > $(brew --prefix)/etc/bash_completion.d/docker
No Linux
$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > /etc/bash_completion.d/docker

Completion do Docker Compose

De maneira similar o arquivo está disponível emhttps://github.com/docker/compose/blob/master/contrib/completion/bash/docker-compose . Reforçamos que sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker Compose.

Ao baixar também devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

No Mac OS X
$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > $(brew --prefix)/etc/bash_completion.d/docker-compose
No Linux
$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

Completion do Docker Machine

O processo é praticamente o mesmo porém o docker-machine possui 3 arquivos de auto complete. Os arquivos estão disponíveis em https://github.com/docker/machine/tree/master/contrib/completion/bash .

Como dito anteriormente devemos colocá-los na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

Como são mais arquivos recomendo utilizarmos um loop para baixarmos todos em sequência utilizando apenas um comando.

No Mac OS X
machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > `brew --prefix`/etc/bash_completion.d/$file
done
unset machineVersion
No Linux
machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > /etc/bash_completion.d/$file
done
unset machineVersion

Observe que:

  1. Se você utilizar alguma versão específica de uma dessas ferramentas basta baixar os arquivos da pasta correspondente.  Por exemplo o docker engine, da maneira que mostramos vamos pegar o arquivo que está na branch master, atualmente versão 1.12.1, para pegar na versão 1.11.0 por exemplo o arquivo fica em https://github.com/docker/docker/blob/v1.11.0/contrib/completion/bash/docker
  2. O Docker disponibiliza alguns arquivos de completion para outros shells. O Docker Engine disponibiliza bash, zsh, fish e powershell como podemos ver em https://github.com/docker/docker/tree/master/contrib/completion .
  3. O Docker Compose e o Docker Machine disponibilizam apenas para bash e zshcomo vemos nas urls https://github.com/docker/compose/tree/master/contrib/completion e https://github.com/docker/machine/tree/master/contrib/completion .

E era isso por hoje pessoal, agradecimento especial ao @wsilva pela dica. Já sabe, ajude divulgando o blog, e tendo dúvidas ou sugestões deixa ai nos comentários

Abraço!

Fonte: http://dumpscerebrais.com/2016/09/auto-complete-para-docker-engine-machine-e-compose/

Docker e Tutum

Oi pessoal,

Post rápido apenas para divulgar uma grande novidade: A Docker acaba de anunciar oficialmente a compra da Tutum, um serviço em Cloud para desenvolvedores e administradores de sistema onde é possível criar seu ambiente Docker. Essa é uma noticia muito boa pois fecha uma fase do Docker e inicia outra mais interessante ainda.

Na prática o que muda nesse momento é apenas o fato de que a partir de agora a Tutum tem o apoio da Docker Inc. para novas iniciativas, os clientes não serão afetadas por essa “fusão” por assim dizer. A forma como a Tutum faz o deploy e provisionamento da infra estrutura continuará exatamente igual, isso não muda. Outro ponto é que a partir de agora iniciará uma integração melhor do Docker Hub com a Tutum, isso fará com que os usuários tenham uma melhor experiência na integração de suas aplicações com a infra estrutura Docker utilizando a Tutum.

Muito legal não? Quer saber mais, veja o post no Blog do Docker:

http://blog.docker.com/2015/10/docker-acquires-tutum/

Docker – Device mapper

Olá pessoal,

No primeiro post da série falamos sobre AUFS e hoje vamos falar um pouco sobre Device Mapper.

Origem

No começo o Docker era suportado apenas em distribuições Ubuntu, Debian e usavam AUFS para o seu armazenamento. Depois de algum tempo o Docker começou a se popularizar e as pessoas começaram a querer utilizar Docker com RedHat, porêm o AUFS era suportado apenas em sistemas (Debian,Ubuntu).

Então os engenheiros da Redhat baseados no código do AUFS decidiram desenvolver uma tecnologia própria de armazenamento baseado no já existente “Device mapper”. Então os engenheiros da RedHat colaboraram com o “Docker inc” para contribuir com um novo driver de armazenamento para containers. Então o Docker foi reprojetado para fazer a conexão automática com o dispositivo de armazenamento baseado em Device Mapper.

Layers

O Device Mapper armazena cada imagem e container em seu disco virtual, esses discos virtuais são dispositivos do tipo Copy-on-Write no nível de bloco e não a nível de arquivo. Isso significa que ao invés do Device Mapper copiar todo um arquivo para o seu dispositivo, ele vai copiando por blocos o que o torna muito rápido comparado ao AUFS. No processo de criação de uma imagem com o Device Mapper é criado um pool e em cima desse pool é criado um dispositivo base que é a partir dele que as imagens são construídas, a partir dai temos as imagens base do Docker que a cada modificação vão criando camadas de snapshots a cima da camada anterior. Conforme a imagem abaixo:

https://docs.docker.com/engine/userguide/storagedriver/images/two_dm_container.jpg

Read

Quando um container deseja ler algum arquivo que está nas camadas anteriores o Device Mapper cria um ponteiro na camada do container referenciando a camada da imagem onde possui esses dados colocando transferindo esse bloco para a memória do container.

Write

Quando o Docker faz uma alteração no arquivo utilizando Device Mapper esse arquivo é copiado apenas o que sera modificado cada bloco de modificação copiado é de no máximo 64KB. Por exemplo na escrita de um arquivo de 40KB de novos dados para o container o Device Mapper aloca um único bloco de 64KB para o container, caso a escrita seja de um arquivo maior que 64KB então o Device Mapper aloca mais blocos para realizar essa gravação.

O Device Mapper já é padrão nas em algumas distribuições do linux como:

  • RedHat/Centos/Fedora
  • Ubuntu 12.04 e 14.04
  • Debian

Docker e Device Mapper

O Device Mapper atribui novos blocos para um container por meio de uma operação chamada “Allocate-on-Demand”, isso significa que cada vez que uma aplicação for gravar em algum lugar novo dentro do container, um ou mais blocos vazios dependendo do tamanho de gravação terão que ser localizados a partir do pool mapeado para esse container. Como os blocos são de 64KB então muitas gravações pequenas podem sofrer com problemas de performance, pois acaba causando lentidões nas operações. Com isso aplicações que gravam arquivos pequenos sequencialmente podem ter performance piores com Device Mapper do que com AUFS.

Legal né? Se gostou nos ajude divulgando o blog.

Grande abraço!