Gomex: Lançamento da versão estável do livro “Docker Para Desenvolvedores”
1 de Novembro de 2016, 16:50 - sem comentários aindaÉ com grande prazer que anuncio a versão estável, também conhecida como 1.0, do livro “Docker para Desenvolvedores”. Para baixar acesse esse link:
https://leanpub.com/dockerparadesenvolvedores
Entenda como versão estável a reunião do conteúdo mínimo para entendimento do funcionamento básico do Docker para um desenvolvedor de código que nunca interagiu com essa tecnologia de virtualização usando container. Essa versão trata também sobre as melhores práticas para construção de imagens docker, através da utilização de exemplos e evolução de uma base de código simples usada para ilustrar cada boa prática.
O livro segue a filosofia do conhecimento livre, ou seja, ele está licenciado em Creative Commons e sua exigência é apenas para citar o autor do conteúdo, isso significa que você pode até mesmo comercializar o material sem me solicitar permissão. E eu queria muito saber que as pessoas estão fazendo bom uso dele.
A licença é muito mais que apenas explicitar sobre como se pode fazer uso do material. Meu interesse com ela é criar uma comunidade ao redor da construção desse conhecimento, ou seja, caso você encontre problemas no livro, não hesite em registrar um bug ou envie um patch/pull request caso tenha tempo/disposição para tal. Segue abaixo o repositório do livro:
https://github.com/gomex/docker-para-desenvolvedores
A grande vantagem de fazer um livro digital é a possibilidade de atualização contínua do material. Sendo assim a minha proposta é manter o livro atualizado a medida que o Docker for adicionando/modificando/removendo elementos.
Se você está ansioso pela versão impressa. Fiquem atentos que logo virei com novidades.
Mundo Docker: Docker – Device mapper
20 de Outubro de 2016, 15:17 - sem comentários aindaOlá 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:
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!
Mundo Docker: Docker – AUFS
13 de Outubro de 2016, 12:38 - sem comentários aindaOlá pessoal,
AUFS foi o primeiro controlador de armazenamento em uso com Docker, como beneficio tem uma história longa com Docker. É muito estável, tem grandes implementações no mundo real e possui forte apoio da comunidade, o AUFS possui diversas características que acabam o tornando uma boa escolha para uso com Docker. Entre elas estão:
- Tempo de inicialização do container rápido
- Uso eficiente de armazenamento
- Uso eficiente de memória
Apesar de ter uma ampla capacidade de caracteristicas com Docker, algumas distribuições não possuem suporte ao AUFS, pois ele não está incluído na linha principal do Kernel Linux, no caso do RHEL não é suporte AUFS.
Os tópicos seguintes demonstram algumas características do AUFS e como ele se relaciona com o Docker:
Layers de Imagens:
AUFS é um sistema de unificação de arquivos, isso quer dizer que ele leva vários diretórios em um único host linux, colocando um sobre o outro e fornece uma visão unificada desses arquivos para conseguir isso o AUFS usa uma união de montagem.
O AUFS driver de storage do Docker implementa Layers de imagens utilizando usando a união do sistema montado. Abaixo podemos ver um exemplo de Layers, onde para o cliente é apresentado a união de todas elas:
Utilizando arquivos:
O Docker utiliza a tecnologia de “AUFS CoW” para conseguir compartilhar a imagem e minimizar o uso de disco. Como o AUFS trabalha em nível de arquivos então todos os dados são copiados por inteiros para a camada superior mesmo que modificando uma pequena parte do arquivo, isso faz com que dependendo do tamanho de arquivo que será copiado acabe penalizando um pouco o desempenho do container, pois um arquivo muito grande demorará algum tempo para que seja copiado. Ou também a imagem possui uma grande quantidade de camadas e o arquivo que você deseja utilizar está na primeira camada da imagem.
A ordem de procura é de cima para baixo, então caso seja a primeira vez que o usuário irá utilizar aquele arquivo, então o Docker vai procurar esse arquivo nas suas camadas abaixo e copiar todo o seu conteúdo para a camada gravável do container. Porém o arquivo só é copiado na primeira vez, após isso o esse arquivo já está na ultima camada então todas as demais operações são rápidas.
Deletando arquivos:
O driver do AUFS exclui um arquivo de dentro do container colocando um arquivo whiteout na camada gravável do container. O arquivo whiteout obscurece a existência do arquivo nas camadas inferiores de imagem:
Você pode adicionar o driver AUFS no seu daemon docker editando o arquivo de conf do docker e adicionando:
DOCKER_OPTS="--storage-driver=aufs"
systemctl restart docker
Então ta pessoal esse é nosso primeiro post dessa série que vai mostrar para vocês os drivers de armazenamento nativos do Docker.
Mundo Docker: MundoDocker – Eventos
3 de Outubro de 2016, 15:59 - sem comentários aindaOi Pessoal,
Hoje o post é rápido, apenas para trazer a vocês nossa experiência no TcheLinux Caxias do Sul. Para quem nos acompanha nas rede sociais, ficou sabendo que iriamos participar de mais um edição do TcheLinux (um dos maiores eventos de tecnologia open source do Rio Grande do Sul), dessa vez em Caxias do Sul, na serra gaúcha.
O evento estava muito bem organizado, e o lugar não poderia ser melhor, com infraestrutura suficiente para atender os participantes, sem falar na localização. Com a ajuda de alguns amigos, conseguimos alguns registro fotográficos do evento, veja:
A nossa contribuição ao evento foi com uma palestra: Escalonando o mundo com Kubernetes, como o Google sobrevive. Essa apresentação teve como objetivo mostrar aos presentes como o Kubernetes funciona, como ele é utilizado dentro do Google e como você utiliza ele sem nem saber . Compartilhamos a apresentação em nosso Slideshare, para você, que não estava no evento, possa ver um pouco sobre o que levamos ao evento:
Gostaríamos de agradecer ao TcheLinux pela oportunidade e a Ftec que disponibilizou o local para o evento. Por hoje era isso, grande abraço! Ahhh e nos ajude divulgando o blog
Mundo Docker: Docker Overlay
28 de Setembro de 2016, 16:07 - sem comentários aindaOi Pessoal,
Como vimos nesse post, é possível utilizar plugins diversos para resolver o desafio da rede, e mostramos nesse post um pouco da teoria de como usar o driver de overlay, hoje queremos mostrar isso na prática, e para isso, nada melhor do que colocar a mão na massa, certo? Claro, mas antes precisamos entender um pouco de teoria, e lá vamos nós.
Se você estiver utilizando o Swarm, não é necessário configurar um serviço de chave-valor externo, pois o próprio Swarm faz o controle e persistência das informações de rede que você utiliza. E você deve ter cuidado, pois se quiser utilizar o Overlay com um serviço externo de chave-valor, o modo de cluster via Swarm fica impossibilitado.
Veja abaixo uma tabela com algumas informações relevantes sobre o funcionamento do Overlay:
Protocolo | Porta | Descrição |
---|---|---|
udp | 4789 | Data plane (VXLAN) |
tcp/udp | 7946 | Control plane |
Ou seja, você deve cuidar para que em seus firewalls essas portas estejam liberadas, caso contrario a comunicação entre os nós não ocorrerá, o que impossibilitará o funcionando do Overlay.
Veja abaixo os principais parâmetros que você deve ter atenção:
Opção | Descrição |
---|---|
--cluster-store=PROVIDER://URL |
Endereço do seu servidor/serviço de chave-valor |
--cluster-advertise=HOST_IP|HOST_IFACE:PORT |
IP ou interface do host que será utilizado para comunicação do cluster |
--cluster-store-opt=KEY-VALUE OPTIONS |
Configuração opicional, onde é possível definir regras de monitoramento dos hosts e validação TLS |
Ok Cristiano, entendi tudo isso, mas como vamos testar, qual será o ambiente de laboratório que vamos seguir? Vamos lá, para exemplificar como será o ambiente que vamos montar, segue abaixo uma imagem onde ilustra o funcionamento do Docker com o serviço de chave-valor, todos os hosts consultam esse serviço para identificar quais redes existem e qual bloco/ip deve ser alocado por container. Veja:
Vamos colocar a mão na massa?
Dependências/Configuração
Você deve ter um serviço de chave valor, no qual o Docker persistirá as informações de rede que você criar, em nosso lab utilizamos o Consul dentro de um container Docker, rodando em um server a parte dos que participarão do ambiente multi-host, para isso executamos:
[root@consul ~]# docker run -d -p "8500:8500" -h "consul" progrium/consul -server -bootstrap
Dessa forma iniciamos um container com Consul, mapeando a porta 8500 do host para o container, ou seja, para ter acesso ao serviço do Consul basta acessar ip-do-host:8500. Agora vamos ao nosso ambiente de Docker.
Nos hosts de Docker (obviamente você já tem o Docker instalado, mas se quiser saber como instalar, veja esse post ) você precisará configurar o daemon para consultar o Consul e buscar as informações de rede, em nosso laboratório utilizamos o CentOS, com isso, o arquivo a ser modificado é o: /lib/systemd/system/docker.service, e deixamos da seguinte forma:
[Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network.target [Service] Type=notify # the default is not to use systemd for cgroups because the delegate issues still # exists and systemd currently does not support the cgroup feature set required # for containers run by docker ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --cluster-advertise=eth0:2376 --cluster-store=consul://ip-do-consul:8500 ExecReload=/bin/kill -s HUP $MAINPID # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNOFILE=infinity LimitNPROC=infinity LimitCORE=infinity # Uncomment TasksMax if your systemd version supports it. # Only systemd 226 and above support this version. #TasksMax=infinity TimeoutStartSec=0 # set delegate yes so that systemd does not reset the cgroups of docker containers Delegate=yes # kill only the docker process, not all processes in the cgroup KillMode=process [Install] WantedBy=multi-user.target
Feito isso, basta reiniciar o serviço e seguirmos para o próximo passo.
Utilização/Testes
Agora que você já definiu um serviço de chave-valor a ser consultado, basta você criar a sua rede com o driver Overlay, para isso:
[root@docker01 ~]# docker network create --driver overlay rede1
Você pode definir ainda qual o bloco de ip que deseja para essa rede, caso não faça essa definição, o Docker associará um bloco automaticamente para você. Fácil certo? Basta testarmos, para isso vamos validar em todos os hosts se ambos estão visualizando a mesma rede, execute esse comando em qualquer outro host:
[root@docker01 ~]# docker network ls
Será retornando algo como isso:
NETWORK ID NAME DRIVER
64507d0be843f rede1 overlay
d0bdae8fbe7bd bridge bridge
1c0eb8f68962d none null
3412c2496d0eb host host
697102a22e8d2 docker_gwbridge bridge
Vamos utilizar essa rede, crie os containers em pelo menos 2 hosts, informando essa nova rede, veja:
[root@docker01 ~]# docker run -it --net=rede1 centos /bin/bash
Agora basta pingar ou acessar os serviços entre os containers que estão nessa mesma rede.
Dessa forma você pode definir uma rede diferente por grupo de containers, e pode ainda isolar essas redes utilizando o método VXLAN, para isso deve passar como parâmetro na criação da rede o seguinte argumento: –opt “com.docker.network.driver.overlay.vxlanid_list=257″, esse parâmetro fará com que essa rede receba uma vlan, ou seja, todo o trafego direcionado a essa rede receberá uma identificação, impossibilitando que outros containers que não estejam nessa vlan tenha acesso a esse trafego.
Legal né? Se gostou nos ajude divulgando o blog.
Grande abraço!