Wellington Silva: Docker, do Básico a Orquestração e Clusterização - 6. Swarm
30 de Junho de 2015, 3:00 - sem comentários aindaNessa série de artigos estamos abordando tópicos para uma boa utilização do Docker.
O docker-swarm é uma ferramenta que nos possibilita através do docker-machine (que vimos no último artigo) juntar vários hosts de docker montando um como se fosse um grande cluster onde podemos rodar nossos containers com nossas aplicações dentro.
Neste momento você deve estar perguntando: “Mas wsilva, que exemplo de aplicação precisa que eu monte um cluster em ambiente de desenvolvimento?” A resposta que sempre me vem a cabeça é nenhuma aplicação. Esse cluster é vantajoso quando precisamos que nossa aplicação permaneça disponível mesmo quanto um fornecedor de infraestrutura de TI estejá indisponível. “Como assim wsilva?”
Imagine que toda sua infraestrutura está baseada nas soluções de cloud da Amazon e toda ela fique fora do ar, muito improvável né, ok. Então imagine que você queira simplesmente baixar seu custo utilizando o provedor de serviços mais barato em um determinado período. Com o swarm essas tarefas ficam simples.
No exemplo que veremos a seguir vamos levantar VMs locais mas podemos fazer o mesmo exercício com VMs em provedores distintos, AWS, Azure, DigitalOcean, Hackspace, etc, etc, etc.
Hands On
Pegando toke no Dockerhub
Como estou usando MacOSX primeiro subi a VM usando o docker machine e exportei as variáveis para que consiga acessar o serviço do docker. Se vc estiver no Linux basta pegar o token do docker hub diretamente com o comando docker run swarm create. Apenas anote o token gerado, pois com ele que amarramos todos as VMs que vamos criar.
Criandos o nó central
Aqui chamo o VM principal de abelha-rainha:
Criando outros nós
Aqui criamos 2 nós que chamamos de abelhas operárias, o comando é o mesmo só não temos a flag de –swarm-master:
Quarto passo: Rodar uma aplicação no enxame
Aqui nós apontamos nossas variáveis do Docker para o nó mestre do enxame, digamos que para a abelha rainha. Subimos uma instância de redis em um dos containers e escalamos ele para rodar 4 instâncias no total. Quando escalamos percebemos que cada instância do redis foi distribuida e executada nas abelhas-operarias e também na abelha rainha.
Podemos perceber com o comando docker ps que a abelha operária 1 ficou executando o redis 1 e o redis 4 e as demais abelhas rodando redis 2 e 3, também notamos os ips e as portas onde são executados, na abelha operária 1 por exemplo podemos ver que 2 portas (32769 e 32768) são mapeadas para dentro dos containers ao contrário das demais abelhas com apenas uma porta mapeada.
Concluindo
Com o Docker Swarm podemos montar e comunicar diversas VMs rodando Docker e permitir uma alta disponibilidade de nossas aplicações. Esse exemplo rodamos em VMs num ambiente local. Porém mudando o driver do docker machine (docker-machine create opção -d) podemos criar nossas VMs na AWS, DigitalOcean, Azure, e outras.
O mundo docker está evoluindo muito e bem rápido, é bom acompanhar as novidades sempre no blog deles e nos meet ups das comunidades, quando comecei escrever esse artigo foi antes do DockerCon 2015 e na versão 0.2 do docker-machine e do docker-swarm. Hoje já estamos na 0.3 de ambos. Uma boa novidade do swarm é a integração com serviços de descuberta e gerenciamento de containers como Mesos e Marathon que apresentadas na conference. Vale dar uma olhada quando eles liberarem todos os videos da Dockercon 2015.
Aqui encerramos a série do básico a orquestração de containers, mas testarei novas ferramentas e customizações no mundo Docker.
Té +
Gomex: Será que esse modelo de containers é um Hype?
12 de Junho de 2015, 1:34 - sem comentários aindaNa informática tudo as vezes parece muito fluído. Coisas nascem rapidamente e morrem as vezes na mesma velocidade. Algumas tecnologias que prometem muito e as vezes se percebe que grande parte é uma grande obra de marketing ou algo parecido.
Quando a ideia de trabalhar com containers me foi apresentada, através do uso do Docker, e como as pessoas já estavam eufóricas fora do Brasil sobre esse assunto, me deixou um pouco com a antena ligada, que talvez fosse esse mais hype da nossa área. Sendo assim fui pesquisar com certo receio.
Ao testar pela primeira vez seu uso, percebi que tinha grande potencial, que tecnicamente a ideia é muito boa e toda cadeia de serviço que vem embutido no modelo faz muito sentido para a nova cultura DevOps que vem se desenhando há certo tempo.
Talvez você não confie nas minhas previsões, pois sou somente um soteropolitano comedor de acarajé 
Talvez as notícias abaixo deixem você mais convencido:
Containers and Microservices Force VMware To Ship A Linux Distribution
Veja que estamos falando da grande VMWare, que é dona de uma enorme fatia de mercado.
Intel takes on CoreOS with its own container-based Linux
A Intel não me parece ser uma empresa que aposta em hypes 
E criar sua própria distribuição GNU/Linux para atender essa demanda de mercado quer dizer muita coisa pra mim.
Google gets a jump on Microsoft and Amazon with Container Engine
Nem preciso falar do tamanho da Google, não é? Sei que ela acaba testando muita coisa, e uma parte acaba por ser Hype mesmo (Google Glass?), mas ela usar como serviço indica bastante coisa pra mim.
Microsoft Unveils New Container Technologies for the Next Generation Cloud
Assim como a Google, a Microsoft está apostando nesse modelo para seu serviço e vale lembrar que de todas essas empresas, a MS é a empresa mais conservadora, ou seja, se até mesmo a MS está apostando nisso, quem pode duvidar desse sucesso?
Gomex: Troubleshooting Docker
8 de Junho de 2015, 1:36 - sem comentários aindaO Docker é uma solução muito recente e talvez por isso que tenha tão pouca documentação sobre coisas não triviais. Com base nisso, farei um pequeno resumo dos passos que pode seguir para analisar seu ambiente para encontrar a causa raiz em caso do problema.
Parâmetro PS
Como o básico, temos o comando “docker ps” ele nos mostra o estado dos containers. Ele por padrão (sem parâmetros) mostra quais estão em execução, mas com os parâmetro -a ele mostra todos os containers, incluindo os que não estão em execução:
Os containers que tiverem a informação “Exited” na coluna “STATUS” não estão mais em execução e o número que aparece entre parentes é o código de saída do processo, ou seja, qualquer coisa diferente de “0” indica um problema.
Log
Você pode analisar o log também. O Docker por padrão envia logs via syslog, ou seja, acesse o arquivo de log geral do seu GNU/Linux, que no caso do Debian é o “/var/log/syslog”:
# tail -f /var/log/syslog | grep -i “docker”
Logs
Diferente de apenas analisar o log do host docker, você pode ver o resultado do comando executando no container. Isso pode ser muito útil para entender a saída de erro, que normalmente não aparece no log do syslog:
# docker logs <container ID>
No meu caso abaixo, ficou fácil:
Stats
Caso você suspeite de uso irresponsável dos recursos, pode usar o parâmetro “stats” do docker. Com o comando abaixo listará todos os containers e seus respectivos usos do recurso do host:
docker ps -q | xargs docker stats
Sysdig
Não conhece Sysdig? Veja esse vídeo.
Caso esteja usando Debian, será necessário instalar o pacote mais novo. Você pode fazer tudo com o comando abaixo:
# wget http://ftp.us.debian.org/debian/pool/main/s/sysdig/sysdig_0.1.99-1_amd64.deb ; wget http://ftp.us.debian.org/debian/pool/main/s/sysdig/sysdig-dkms_0.1.99-1_all.deb ; dpkg -i sysdig*
Depois será necessário reiniciar o módulo do sysdig:
# rmmod sysdig-probe; modprobe sysdig-probe
Processamento
Para analisar o alto consumo de processador é simples. Use o comando abaixo:
# sudo sysdig -pc -c topprocs_cpu
O parâmetro “-pc” adiciona o contexto de containers, ou seja, é o mesmo comando padrão de processamento do sysdig, porém com o adendo sobre containers.
Veja o retorno desse comando:
Eu executei um grep recursivo no container “trusting_mayer” apenas para efeito de teste. E veja nosso container como o processo que mais consome processador.
Rede
É possível saber quem são os maiores utilizadores de recurso de redes com o comando abaixo:
# sysdig -pc -c topprocs_net
Veja o retorno:
Resumindo. Uso de rede não é o problema aqui, certo?
Caso tenha interesse em saber quais as conexões abertas nesse momento, use o comando abaixo:
# sysdig -pc -c topconns
Veja o retorno:
Interessado em ir um pouco mais fundo nessa analise? Que tal ver os dados que trafegam nessas conexões?
# sysdig -A -cecho_fds container.name=tender_elion and fd.port=80
No lugar de “tender_elion” coloque o nome do seu container e o mesmo para a porta.
Veja o retorno:
Como podemos ver, é apenas o apt-get instalando pacotes.
Disco
E se o problema for algo relacionado a uso do disco?
Com o comando abaixo é possível ter uma pista:
# sysdig -pc -c topprocs_file
Veja o retorno:
Podemos ver que tem alguém ali consumindo bastante disco.
E se eu quiser mais informação sobre quais são os arquivos maiores e afins?
# sysdig -pc -c topfiles_bytes
Veja o retorno:
Agora temos mais informações.
Segurança
Suspeitou de algum problema de segurança? Analise todos os comandos executados, tanto no host, como no container com o comando abaixo:
# sysdig -pc -c spy_users
Veja o retorno:
Mais logs
Quer analisar todos os logs em apenas um tela? Simples assim:
# sysdig -pc -cspy_logs
Veja o retorno:
Muito dado, certo? Quer ver os logs de um container em específico?
# sysdig -pc -cspy_logs container.name=condescending_einstein
Lembre-se de mudar o nome do container.
Veja o retorno:
Com todo esses dados, acho que agora sua analise da causa raiz do problema fique mais fácil.
Referência
https://sysdig.com/let-light-sysdig-adds-container-visibility/
http://www.sysdig.org/wiki/
Gomex: Docker – Compose (Vídeo)
2 de Junho de 2015, 1:25 - sem comentários aindaSeguindo a série de vídeos sobre Docker, com esse vídeo você verá o que é Docker Compose e como usá-lo.
Gomex: Segurança no Docker
1 de Junho de 2015, 2:40 - sem comentários aindaQuando pensamos sobre segurança no Docker, é importante relembrar que a exploração de uma falha nesse ambiente podem ter efeitos catastróficos. Ainda mais quando é algo automatizado.
A ideia é ter certeza que o ambiente e o processo executado é o mais seguro possível.
Nem tudo é tão seguro quanto parece!
Vou apresentar algumas configurações iniciais que podem ser analisadas para tornar seu ambiente ainda mais seguro.
Restrição de acesso
No que tange a isolamento, o Docker tem muito a acrescentar e esse ponto não se limita ao fato das aplicações estarem separadas a nível de disco e processo. Podemos sair da dicotomia “root e não root”, pois entre um usuário sem permissão e o usuário root existe todo um gradiente de permissões que podem, e devem, ser analisadas e removidas caso não seja necessária.
Desde o kernel 2.2, as permissões foram divididas e chamadas de “capabilities”, que no docker podem ser “ligadas” ou “desligadas” por container. Isso permite que o ambiente tenha “a menor permissão necessária”, que é quase um mantra na área de segurança.
Para conhecer a lista de capabilities, segue o seguinte link.
No Docker, caso você não especifique nada sobre adicionar ou remover capabilities, a lista abaixo será aplicada no container:
- CHOWN
- DAC_OVERRIDE
- FSETID
- FOWNER
- MKNOD
- NET_RAW
- SETGID
- SETUID
- SETFCAP
- SETPCAP
- NET_BIND_SERVICE
- SYS_CHROOT
- KILL
- AUDIT_WRITE
Caso deseje remover permissão MKNOD, por exemplo, use o seguinte comando:
# docker run –cap-drop=MKNOD …
Caso deseja adicionar, LEASE por exemplo, use o seguinte comando:
# docker run –cap-add=LEASE …
Restrição de sistema de arquivo
Quando um container é instanciado é criado um novo ponto de montagem com arquivo da imagem usada para esse novo ambiente.
Esse espaço de disco da imagem é montado como somente leitura e assim uma camada superior é criada para receber as modificações que ocorrerem desde então. Caso queira aplicar essas modificações na imagem, pode usar o parâmetro “commit” para tal ação.
As modificações podem ser armazenadas em tags diferentes e assim se tornaria mais fácil fazer “rollback” das modificações, caso seja necessário. Pra usar tag é muito simples:
# docker tag <número ou nome da tag> <nome da imagem>
Multi Level Security
Com o Docker é possível manipular configurações do “MCS labels” para evitar que um container acesse indevidamente dados de outro container, por uma questão de má configuração ou exploração de alguma vulnerabilidade. Podemos aplicar um label a um processo baseado no nível de informação que você deseja que ele tenha acesso.
docker run -d –security-opt label:level:TopSecret httpd
Quer aprender um pouco mais sobre MLS? Leia aqui.
Outras medidas de segurança “fora” do Docker
As versões modernas do Kernel Linux podem ser complementadas com variadas ferramentas de segurança adicionais, tal como TOMOYO, AppArmor, SELinux e GRSEC, que podem funcionar perfeitamente com Docker, algumas inclusive já tem templates de configuração específicos para containers.
Você pode definir políticas customizadas de segurança com essas ferramentas. Basta ler seus respectivos manuais.
Referências:
https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf
https://docs.docker.com/reference/run/#runtime-privilege-linux-capabilities-and-lxc-configuration
https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go
http://docs.docker.com/articles/security/
