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!

AKS – Azure Kubernetes Service – Parte 2.

Continuando nossa série de posts sobre o AKS, hoje vamos entender como o AKS cria os recursos no Azure. Se você não viu o post anterior mostrando como podemos criar um cluster de maneira rápida e fácil dentro do Azure, segue o link abaixo:

AKS – Parte 1

Quando você executa a criação de um cluster de Kubernetes no Azure, automaticamente a Microsoft cria diversos componentes, hoje vamos entender que componentes são esses criados pelo Azure e como eles se relacionam com o cluster de Kubernetes.

Estrutura

Na criação de um cluster simples igual foi criado no post anterior a Microsoft irá automaticamente no Azure criar recursos dos tipos: Load Balancer, Resource Group, Node Pools.

Na imagem acima é possível ver que em Resource Groups existem dois recursos, o resource_aks foi criado anteriormente, porem o MC_resource_aks_aksmundodocker_eastus é criado automaticamente pelo Azure e nesse momento não podemos renomear esse resource, então ele vai adicionar o prefixo: MC_{NOME DO RESOURCE GROUP}_{NOME DO CLUSTER}_{REGIÃO}. Dentro desse Resource Group é onde ficam os objetos criados especificamente para o cluster. Dentro do resource_aks você irá visualizar apenas um recurso do tipo Kubernetes Service, como na imagem abaixo:

Ao clicar em MC_resource_aks_aksmundodocker_eastus você poderá ver os recursos criados, se você copiou e colocou o exemplo de criação do post anterior, você deve ver algo parecido com isto:

É possível ver os tipos de recursos: Public IP address, Network security group, Route table, Virtual machine scale set, Virtual network e Load balancer. Por padrão são esses os tipos de recursos criados para um cluster de AKS.

Public IP address

Quando se cria um cluster de AKS padrão o endereço IP padrão para o Load Balancer é um IP público, então automaticamente o Azure cria um recursos do tipo Public IP address dentro do Resource group.

Network security group

O Networ security group (NSG) é um componente do Azure no qual é possível criar as regras para tráfego nas interfaces de rede, definindo assim se habilita o tráfego para determinado endereço ou recurso ou se habilita o mesmo.

Route table

O Route table como o nome já sugere é um recurso do Azure para definir a tabela de roteamento de alguns componentes.

Virtual machine scale set

Para conseguir realizar o dimensionamento de máquinas de maneira automática o Azure cria para o cluster de AKS um recurso do tipo Virtual machine scale set que faz com que o grupo de máquinas pode aumentar ou diminuir conforme a demanda de uso ou o agendamento criado.

Virtual network

Todo o cluster de AKS precisa ser criado dentro de uma Virtual network (VNET) ela pode ser criada automaticamente no momento de criação do cluster (Igual a gente fez) ou pode ser criada anteriormente e depois informada no momento da criação do cluster.

Load balancer

Dentro do Kubernetes existem 3 tipos de services: NodePort, ClusterIP e Load balancer. Quando o tipo de service Load balancer é criado o Azure atribui 1 IP da sua subnet para esse service e configura no recurso Load balancer um encaminhamento para esse service. Nos próximos posts a gente vai entender melhor e ver como essas regras são criadas.

Não sabe o que é service? da uma olhada em o que é service?

OBS* Os recursos criados pelo AKS de maneira automática não devem ser modificados ou excluídos por outras contas a não ser pela própria Azure, pois qualquer modificação pode fazer com que o recurso pare de funcionar e a Azure não de suporte a eles.

Os recursos acima são os criados de maneira default em um cluster simples no AKS. Agora que você aprendeu como funciona a estrutura do AKS e quais são os componentes básicos do cluster nos próximos posts você vai aprender como é possível realizar o deploy das aplicações, fazer integrações, monitoramento e obter o melhor desempenho para as suas aplicações em produção.

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!

:

O que é dockerfile?

Olá!

Como mencionado neste post, o Docker possui alguns recursos que permitiram sua popularização pelo mundo a fora, além da API de integração, o Docker permite que possamos criar imagens a partir de um arquivo de definição, esse arquivo chama-se Dockerfile.

Vamos lá. Como explicado anteriormente em alguns posts, uma imagem nada mais é do que um ambiente totalmente encapsulado e pronto para ser replicado onde desejar. Podemos montar esse ambiente através de um container que esteja em execução (Exportando o mesmo), ou através da criação a partir do Dockerfile, que nada mais é do que um arquivo de definição onde é possível realizar ou preparar todo ambiente a partir de um script de execução. Em resumo, o Dockerfile é um arquivo texto com instruções, comandos e passos que você executaria manualmente, basicamente o Docker executa uma receita de bolo.

Através do comando docker build, o Docker realizar a execução desses passos e no final da execução ele encapsula cada layer gerada para dentro da imagem. Mas o Dockerfile deve seguir uma ordem ou formatação correta para que o build seja feito de forma certa, por exemplo, o formato do texto deve respeitar: INSTRUÇÃO argumento, onde INSTRUÇÃO é o comando que o build deve executar, e argumento são as instruções que deve fato serão feitas, por exemplo:

RUN yum update

Onde:

RUN: É a instrução;

yum update: Argumento que será executado.

Abaixo podemos visualizar todas as opções de instruções disponíveis:

  • FROM: Informa a partir de qual imagem será gerada a nova imagem, lembrando que em poucos casos (Veremos em posts futuros), uma imagem será gerada se um imagem base;
  • MAINTAINER: Campo opcional, que informa o nome do mantenedor da nova imagem;
  • RUN: Especifica que o argumento seguinte será executado, ou seja, realiza a execução de um comando;
  • CMD: Define um comando a ser executado quando um container baseado nessa imagem for iniciado, esse parâmetro pode ser sobrescrito caso o container seja iniciado utilizando alguma informação de comando, como: docker run -d imagem comando, neste caso o CMD da imagem será sobrescrito pelo comando informado;
  • LABEL: Adiciona metadados a uma imagem, informações adicionais que servirão para identificar versão, tipo de licença, ou host, lembrando que a cada nova instrução LABEL é criada uma nova layer, o Docker recomenda que você não use muitas LABEL. É possível realizar filtragens posteriormente utilizando essas LABEL.
  • EXPOSE: Expõem uma ou mais portas, isso quer dizer que o container quando iniciado poderá ser acessível através dessas portas;
  • ENV: Instrução que cria e atribui um valor para uma variável dentro da imagem, isso é útil para realizar a instalação de alguma aplicação ou configurar um ambiente inteiro.
  • ADD: Adiciona arquivos locais  ou que estejam em uma url, para dentro da imagem.
  • COPY: Copia arquivos ou diretórios locais para dentro da imagem.
  • ENTRYPOINT: Informa qual comando será executado quando um container for iniciado utilizando esta imagem, diferentemente do CMD, o ENTRYPOINT não é sobrescrito, isso quer dizer que este comando será sempre executado.
  • VOLUME: Mapeia um diretório do host para ser acessível pelo container;
  • USER: Define com qual usuário serão executadas as instruções durante a geração da imagem;
  • WORKDIR: Define qual será o diretório de trabalho (lugar onde serão copiados os arquivos, e criadas novas pastas);
  • ONBUILD: Define algumas instruções que podem ser realizadas quando alguma determinada ação for executada, é basicamente como uma trigger.

Veja abaixo um exemplo de Dockerfile completo:


# VERSION 0.1

FROM ubuntu
RUN echo foo > bar
# Saida parecida com ===> 907ad6c2736f

FROM ubuntu
RUN echo moo > oink
# Saida parecida com ===> 695d7793cbe4

EXPOSE 5900

# Você terá duas imagens, 907ad6c2736f com /bar, e 695d7793cbe4 com
# /oink.


Basta copiar esse código acima em um arquivo chamado Dockerfile e em seguir executar o comando: docker build -t minhaimagem . . E pronto, será criada uma imagem com o nome de minhaimagem, basta usa-la para o que precisar.

Nos próximos posts veremos como criar uma imagem mais complexa, iremos montar um ambiente completo para um site em WordPress, e aprendermos um pouco mais sobre outros recursos do docker build.

Fique atento, e tendo dúvidas já sabe, nos mande uma mensagem, 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!

Mundo Docker

Somos apaixonados por inovação, para nós quase tudo pode ser colocado em um Container, menos nossa criatividade. Acreditamos que compartilhar é a melhor forma de aprender, o conhecimento não deve ser aprisionado e sim distribuído, para que todos possamos aprender a cada dia mais e mais.

Quem compartilha no Mundo Docker?

https://br.linkedin.com/pub/cristiano-diedrich

Cristiano dos Santos Diedrich

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

https://br.linkedin.com/pub/cristhian-bicca

Cristhian Bicca

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

Quer trocar uma ideia com nós? É simples, mande e-mail para: [email protected].

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!

Docker multi-stage builds

Oi Pessoal,

Tivemos diversas novidades com o lançamento das versões 17.05 e 17.06 do Docker, que ocorreram nos últimos meses, nosso objetivo é trazer para vocês algumas dessas novidades, iniciaremos com o multi-stage builds, ou em português claro: construção em múltiplos estágios, vamos entender um pouco mais sobre esse conceito, como utiliza-lo e onde ele pode te ajudar no dia-a-dia.

Antes de mais nada, gostaríamos de nos desculpar pelo hiato na publicação de posts, mas garantimos que foi por alguns bons motivos

O que é?

O multi-stage build foi lançado na versão 17.05 e permite que um build possa ser reutilizado em diversas etapas da geração da imagem, deixando os Dockerfiles mais fáceis de ler e manter.

O estado da arte

Uma das coisas mais desafiadoras sobre a construção de imagens é manter o tamanho da imagem reduzido. Cada instrução no Dockerfile adiciona uma camada à imagem, e você precisa se lembrar de limpar todos os artefatos que não precisa antes de passar para a próxima camada. Para escrever um Dockerfile realmente eficiente, você tradicionalmente precisa empregar truques de shell e outra lógica para manter as camadas o mais pequenas possíveis e garantir que cada camada tenha os artefatos que ela precisa da camada anterior e nada mais.

Na verdade, era muito comum ter um Dockerfile para uso para o desenvolvimento (que continha tudo o que era necessário para construir sua aplicação), e outro para usar em produção, que só continha sua aplicação e exatamente o que era necessário para executá-la. Obviamente a manutenção de dois Dockerfiles não é o ideal.

Aqui está um exemplo de Dockerfile.build e Dockerfile exemplifica o caso acima:

Dockerfile.build:

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN go get -d -v golang.org/x/net/html 
  && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

Observe que este exemplo também comprime artificialmente dois comandos RUN juntando-os com o parâmetro “&&” do bash, para evitar criar uma camada adicional na imagem. Isso é propenso a falhas e difícil de manter. É fácil inserir outro comando e esquecer de continuar a linha usando este parâmetro , por exemplo.

Dockerfile:

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY app .
CMD ["./app"]  

Build.sh:

#!/bin/sh
echo "Building alexellis2/href-counter:build"

docker build --build-arg https_proxy=$https_proxy --build-arg http_proxy=$http_proxy   
    -t alexellis2/href-counter:build . -f Dockerfile.build
docker create --name extract alexellis2/href-counter:build 
docker cp extract:/go/src/github.com/alexellis/href-counter/app ./app 
docker rm -f extract 

echo "Building alexellis2/href-counter:latest" docker build --no-cache -t alexellis2/href-counter:latest . 
rm ./app

Quando você executa o script build.sh, ele cria a primeira imagem com o artefato, a partir da qual cria-se um container que é utilizado para copiar o artefato, em seguida, ele cria a segunda imagem copiando o artefato para essa segunda imagem. Ambas as imagens ocupam espaço em seu sistema e você ainda tem o artefato em seu disco local também.

O que melhorou

Com o multi-stage, você usa várias instruções FROM no seu Dockerfile, cada instrução FROM pode usar uma base diferente, e cada uma delas começa um novo estágio da compilação. Você pode copiar artefatos de um estágio para outro, deixando para trás tudo que você não quer na imagem final. Para mostrar como isso funciona, vamos adaptar o Dockerfile anterior para usar multi-stage:

Dockerfile:

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]  

Você só precisa do único Dockerfile, além de não precisar de um script de compilação separado, basta buildar sua imagem docker:

$ docker build -t alexellis2/href-counter:latest .

O resultado final é a mesma pequena imagem de produção que antes, com uma redução significativa na complexidade. Você não precisa criar nenhuma imagem intermediária e você não precisa extrair nenhum artefato para o seu sistema local.

Como funciona? A segunda instrução FROM inicia um novo estágio de compilação com a imagem base sendo alpine. A instrução “COPY –from=0”  copia apenas o artefato construído do estágio anterior para esta nova imagem, o Go SDK e quaisquer artefatos intermediários são deixados para trás e não são salvos na imagem final.

Deixando mais claro

Por padrão, as etapas não são nomeadas, e você referencia elas por seu número inteiro, começando por 0 na primeira instrução FROM. No entanto, você pode nomear seus estágios, adicionando a instrução “as <nome>” na mesma linha do FROM. O exemplo abaixo deixa mais claro isso e melhora a forma como manipulamos nossos builds nomeando as etapas e usando o nome na instrução COPY. Isso significa que, mesmo que as instruções no seu Dockerfile sejam reordenadas, a cópia do artefado não será interrompida.

FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]  

 

Ficou fácil né? Essa feature auxilia ainda mais as equipes no momento de administrar seus builds, pois centraliza e deixa mais transparente cada passo na geração dos pacotes/artefatos de uma aplicação.

Gostaríamos de agradecer ao @alexellisuk pela contribuição a comunidade com os exemplos utilizados acima. Esperamos ter ajudado, e como sempre, se tiver dúvidas avisa ai que vamos te ajudar.

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!

Iptables e Docker

Oi Gente!!

Iniciando 2019 e esse ano promete mudanças, em todos os aspectos, aqui no Blog também ;), esperamos que esse ano seja de grandes realizações, para todos nós.

Então, se você já trabalha com Docker, já deve ter passado por alguma situação onde as regras de iptables não são obedecidas, é, isso acontece :(.

Se você ainda não mexeu com Docker, recomendo este post aqui, que explica um pouco sobre o que é o Docker e como ele funciona, e te prepara pois o que mostraremos no post de hoje será bem útil para você.

O problema
Por padrão o Docker manipula regras no iptables, mas, por que ele faz isso? Porque quando você cria um container o Docker precisa criar algumas regras para encaminhamento de tráfego, isolamento, etc. É possível desabilitar esse comportamento, porém, você precisará garantir isso manualmente

Digamos que você tem seu iptables bonito, nele você libera apenas a porta 80 e 22, e bloqueia todo o resto, para isso é provável que você utilize as seguintes regras:

iptables -P INPUT DROP

iptables -A INPUT --dport 80 -j ACCEPT

iptables -A INPUT --dport 22 -j ACCEPT

Neste servidor você tem Docker rodando, e criou um container na porta 80 obviamente para responder as requisições que são feitas.

Ok, agora você teve a necessidade de criar outra container, este em outra porta, e neste container você terá o ambiente de homologação, como você já tem um container executando e utilizando a porta 80, você precisará criar na porta 8080, ok, sem problema, agora posso ir no meu iptables e liberar a porta 8080 APENAS para o meu ip, óbvio que funciona:

iptables -A INPUT -s 10.1.1.2 --dport 8080 -j ACCEPT

Não, não funciona. E a explicação para esse comportamento encontramos em um dos assuntos primordiais da existência de um Sysadmin Linux, o comportamento do iptables.

Para recapitularmos, o iptables é basicamente é um interpretador de regras gerando ações baseadas nessas regras. Dentro do iptables temos três tabelas, são elas: Filter, Nat e Mangle. A tabela mais utiliza de todas é a Filter, é nessa tabela que criamos nossas regras para bloqueio de portas/ips. Dentro dessa tabela encontramos outras três chains, são elas:

  • INPUT: Consultado para pacotes que chegam na própria máquina;
  • FORWARD: Consultado para pacotes que são redirecionados para outra interface de rede ou outra estação. Utilizada em mascaramento.
  • OUTPUT: Consultado para pacotes que saem da própria máquina;

Agora advinha em qual chain são criadas as regras do Docker? Sim, em uma chain de forward, isso por que o pacote não é destinado para o host e sim para a interface que o Docker cria. É importante saber disso, pois o fluxo dentro do iptables muda se o destino do pacote é local ou não.
Para ficar mais claro, dá uma olhada nessa imagem:
Isso quer dizer que aquele seu container que foi criado na porta 8080 ficará exposto, pois a regra de forward será executada antes daquela sua regra de input que bloqueia tudo ;). A chain utilizada neste caso chama-se DOCKER, e você pode visulizar as regras criadas utilizando o:

iptables -L -nv

“Oh, e agora quem poderá nos defender?”

A Solução

Até pouco tempo atrás havia basicamente uma solução, nem um pouco “elegante” de se resolver isso.

  • Desabilitar no daemon do Docker para ele não manipular de forma automatica essas regras, com isso você precisaria criar manualmente as regras;

Existiam outras formas? Sim, algumas mais complexas, outras mais baixo nível, mas de qualquer forma nada tão simples e muito menos fácil de se administrar, então, depois de vários pedidos e sugestões de solução no github do Docker, isso foi repensado e resolvido de uma forma mais inteligente.

Foi adicionado uma nova Chain, chamada DOCKER-USER, essa chain apesar de ser forward também, precede as chains utilizadas pelo Docker na criação de containers. Dessa forma, você pode utilizar ela para adicionar as suas regras personalizadas e garantir o bloqueio ou acesso aos containers.

Te lembra daquelas regra que não funcionava antes? Então, neste novo cenário, ficará dessa forma:

iptables -I DOCKER-USER -s 10.1.1.2 --dport 8080 -j ACCEPT

iptables -A DOCKER-USER --dport 8080 -j DROP

Bem mais simples do que manipular todas as regras do Docker manualmente, certo? Mas lembre-se, isso serve apenas para controlar o trafego externo aos containers, isso não é aplicado no contexto de INPUT, então tome cuidado achando que é nessa chain que deve ir todas as suas regras. Outro ponto positivo para essa abordagem é a simplicidade para automatizar, pois basta integrar essa mesma lógica em sua pipeline e você estará protegendo seus containers.

É possível ainda manter aquele seu script maroto de firewall, basta adicionar mais algumas regras liberando ou não o acesso a determinada porta (na qual quem responderá será um container).

Então era isso, se quiser saber mais, tirar alguma dúvida ou ainda ajudar, deixa ai nos comentários ou entre em contato por e-mail. Grande abraço e boa semana