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!

MundoDocker no DevOpsWeek

Oi Pessoal,

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

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

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

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

 

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

Grande abraço!

Troubleshooting e dicas de Docker

Olá pessoal,

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

Instalando a versão mais recente

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

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

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

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

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

Versão alpha que está em constante desenvolvimento:

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

 Como remover todos os containers parados:

docker rm $(docker ps -a -q)

 Sincronizar o relógio do host com o container:

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

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

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

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

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

 Comunicação entre containers:

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

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

Montando volumes com services:

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

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

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

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

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

 Docker commit e volume:

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

Não rode containers com –privileged

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

Um processo para cada container.

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

Cuidado com as regras de IPTABLES

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

Coloque o diretório do docker em outro disco:

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

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

Grande abraço!

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

Docker – Device mapper

Olá pessoal,

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

Origem

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

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

Layers

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

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

Read

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

Write

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

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

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

Docker e Device Mapper

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

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

Grande abraço!

 

Docker Global Mentor Week

Olá Pessoal!

Para quem não viu ainda, na quinzena final de novembro será realizado uma das maiores ações do Docker para treinamento e troca de experiência entre seus usuários, esse evento foi chamado de Docker Global Mentor Week.

Essa é uma ação coordenada diretamente pela equipe do Docker com a ajuda dos organizadores dos grupos de meetup docker pelo mundo, o objetivo é simples: Dar treinamento técnico de alto nível de maneira abrangente e uniforme, ou seja, o conteúdo abordado em Singapura, é o mesmo no México, na Inglaterra e claro aqui no Brasil :). SIM teremos esse evento ocorrendo aqui no Brasil também, vou deixar abaixo os links desses eventos para que você possa se inscrever.

Mas afinal, esse é apenas mais um encontro do grupo de Meetup? Sim e Não, sim porque os canais utilizados para divulgação desse evento são os grupos de meetup e não porque esse evento tem conteúdo definido pela equipe do Docker e é repassado através de seus Mentors, que são pessoas ativas na comunidade docker e que auxiliam na divulgação de conteúdo, disseminação da tecnologia e enriquecimento da comunidade local. Você encontrará em cada evento no mínimo 1 Mentor, então não deixe de tirar suas dúvidas com ele(s).

Ok Cristiano, gostei, mas e valor? Bom, isso é um problema, por ser um evento oficial realizado no mundo inteiro, o valor para realizar esse treinamento é……. ZERO, sim é evento totalmente de graça, e agora, qual a sua desculpa?

E o conteúdo?

A equipe do Docker definiu uma série de trilhas que podem ser abordadas durante o evento, é claro que todas é impossível de serem realizadas num período de 3 a 4 horas, então cada usuário defini o que deverá ver no evento, e os mentor auxiliaram na execução do treinamento e esclarecimento de dúvidas. Os conteúdos em si vão do básico (criação de containers, Dockerfile, etc) até o avançado (orquestração, serviços, rede, volume, etc).

Onde serão realizados aqui no Brasil?

Temos por enquanto, 4 eventos confirmados aqui no Brasil, são eles:

Docker Global Mentor Week – Goiania – 14/11

http://meetup.com/pt-BR/Docker-Goiania/events/234750966/?eventId=234750966

 

Docker Global Mentor Week – Rio de Janeiro  – 16/11

http://meetup.com/pt-BR/Docker-Rio-de-Janeiro/events/234784863/?eventId=234784863&chapter_analytics_code=UA-48368587-1

 

Docker Global Mentor Week – São Paulo – 19/11

https://meetup.com/pt-BR/Docker-Sao-Paulo/events/235267786/?eventId=235267786&chapter_analytics_code=UA-48368587-1

 

Docker Global Mentor Week – Porto Alegre – 26/11

http://meetup.com/pt-BR/Docker-Porto-Alegre/events/235451287/?eventId=235451287&chapter_analytics_code=UA-48368587-1

 

O MundoDocker estará presente? Claro! Vamos auxiliar o pessoal do grupo de Porto Alegre!

 

Era isso por hoje pessoal, ajude você também divulgando os eventos e claro o blog

 

Grande abraço!

Docker Stack e Deploy

Oi Pessoal,

Nós já conversamos sobre o Docker 1.13 aqui, agora vamos explorar um pouco mais sobre essa funcionalidade que saiu do modo experimental e tornou-se parte da engine estável do Docker, sim estamos falando do docker stack/deploy. Mas antes, recomendo fortemente você ler este post aqui sobre docker compose v3, ele é muito, mas muito importante mesmo para os exemplos que veremos neste post.

Agora com o Docker 1.13 é possível você portar suas aplicações do compose para o Swarm, e isso graças a funcionalidade de deploy disponível na engine. Seu funcionamento é bem simples, basta você informar na execução do comando o diretório de onde está o seu arquivo compose, e o nome da aplicação, se lembra que falei que era muito importante olhar esse post? Pois bem, não adianta você ter um compose escrito para a versão 2 e tentar utilizar aqui, será necessário você se altere para as novas regras da versão 3 para que seja possível a criação de sua stack pelo docker deploy. Mas digamos que você já tem seu arquivo pronto na versão 3, vamos pegar o exemplo do outro post, basta executar:

$ docker deploy --compose-file docker-compose.yml app

O retorno desse comando será

$ docker deploy --compose-file docker-compose.yml app
Creating network app_default
Creating service app_nginx
Creating service app_redis

Dessa forma foram criados uma rede e dois serviços, o mesmos definidos no arquivo compose. Para obter mais informações da stack, você pode executar os comandos:

$ docker stack ls
NAME SERVICES
app 2

Com o stack ls, será retornado todas as stacks que você criou, neste caso retornou apenas a “app” e informa também quantos serviços existem para essa stack, com este comando:

$ docker stack ps app
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
xb02xrua71db app_redis.1 redis:latest node1 Running Running 7 minutes ago
lm7k8obhncyl app_nginx.1 nginx:latest node1 Running Running 7 minutes ago
jh65f9scx0cq app_nginx.2 nginx:latest node1 Running Running 7 minutes ago

Você visualizará mais informações sobre a stack, como por exemplo o id de cada container, imagem utilizada, nome do container, nó onde está executando e claro o estado de cada container. Você pode ainda, executar o comando:

$ docker stack services app
ID NAME MODE REPLICAS IMAGE
g3i4f4erympf app_nginx replicated 2/2 nginx:latest
s11w093eraxz app_redis replicated 1/1 redis:latest

Para ter a visualização de sua stack no mesmo formato dos serviços (docker service ls).

O que fizemos até aqui foi portar uma stack do docker-compose para o cluster de swarm.

 

“Ahh mas como assim?”

Bom se você pegar esse mesmo arquivo de compose e executar: docker-compose up -d, ele funcionará também, sem erro, sua stack iniciará e ficará disponível para uso, MAS, não em cluster :), você continuará utilizando o docker-compose da mesma forma que antes, sem os benefícios do Swarm. Apenas com o docker deploy é que você poderá fazer o deploy e gerenciamento de sua stack dentro do cluster de swarm.

“Ok, entendido, mas como eu escalo agora a minha stack? Antes eu executava: docker-compose scale app=3, como faço isso com o docker stack?”, não se preocupe, você continuará tendo a possibilidade de escalar a sua stack, vamos lá: Já sabemos que o docker deploy criar todos os serviços necessários para a stack, certo? Pois bem, para escalar algum componente da sua stack, basta você escalar o serviço, da mesma forma como se você estivesse manipulando um serviço dentro do swarm, veja:

$ docker service ls
ID NAME MODE REPLICAS IMAGE
cnnabnpqkjvy app_redis replicated 1/1 redis:latest
pcn4urntqn8l app_nginx replicated 2/2 nginx:latest

Agora vamos escalar o serviço de nginx da minha stack app:

$ docker service scale app_nginx=4
app_nginx scaled to 4

E o resultado é:

$ docker service ls
ID NAME MODE REPLICAS IMAGE
cnnabnpqkjvy app_redis replicated 1/1 redis:latest
pcn4urntqn8l app_nginx replicated 4/4 nginx:latest

Ou seja, escalei apenas o nginx.

 

“Ok, muito bonito, mas como eu acesso a minha stack?”

Boa pergunta, mas é claro que há uma resposta, e é aqui que vem a parte mais legal ;).

Vamos voltar ao docker-compose.yml que usamos para criar essa stack, veja essas linhas:

nginx:
    image: nginx
    ports:
        - 80:80

Preste atenção no parâmetro: ports, ali você define em qual porta o serviço vai ouvir, neste caso, o nginx estará trabalhando na porta 80, ou seja, o serviço no cluster de swarm estará disponível para acesso através da porta 80, e todos os nós do cluster, quando receberem alguma requisição na porta 80 encaminharão para o container que atende este serviço (utilizando uma das funcionalidade do docker swarm que é a rede de serviço em mesh).
Quando escalamos um serviço, dizemos ao docker para adicionar mais containers para atender as requisições que estarão sendo feitas para o mesmo, ou seja, teremos diversos containers atendendo um único recurso que é o serviço, e o swarm se encarrega de distribuir os acessos para todos os containers.

 

“Ta bom, me convenceu, mas como removo tudo agora pra fazer direito?”

Muito fácil, da mesma forma que o docker service, basta você executar:

$ docker stack rm app
Removing service app_redis
Removing service app_nginx
Removing network app_default

E serão removidos todos os serviços, containers e rede que tenham sido criadas pela sua stack.

Interessante não? Esperamos que tenha sido útil, se ficou com dúvida nos avisa que ajudamos. Por hoje era isso, nos ajude divulgando o blog e fique atento, teremos mais novidades em breve ;).

Abraço!

 

Oito dicas sobre Docker

Oi Gente!

Sendo este o primeiro post com conteúdo sobre Docker para o ano de 2017, tivemos a ideia de trazer a vocês algumas dicas e informações que consideramos de muita importância. Para isso fizemos um com uma apresentação sobre essas dicas, explicando cada uma dela e contando um pouco sobre como elas resolvem ou ajudam em determinadas situações. Vamos ao vídeo?

 
Para você que não conseguiu ver o vídeo, disponibilizamos também a apresentação em nosso canal no slideshare, acompanhe:

 

Viu, não deixamos passar nada

Aguarde pois este ano teremos diversas novidades aqui no blog, garanto que vocês vão gostar.

 

Grande abraço!

Docker 1.13 – O que vem por ai

Eai gente!

Você que é leitor do blog já está acostumado a ver por aqui as principais novidades sobre o Docker e tecnologia associadas, e hoje não será diferente. Queremos trazer uma preview sobre as novas features que serão lançadas na versão 1.13 do Docker, como todos os sabem, o ciclo de desenvolvimento dentro do Docker é algo fora da curva, e a cada nova versão alguma novidade aparece, é possível acompanhar esse ritmo pelo próprio github deles.

Mas se você não quiser esperar a versão estável para brincar com as novidades, pode utilizar a versão experimental do Docker, que obviamente não é recomendado para se colocar em produção, mas que pode ser usada para lab sem problema. Para isso, basta você instalar o Docker com o seguinte comando: curl -sS https://experimental.docker.com | sh, com isso você terá acesso a engine com as modificações mais atuais mas em fase de desenvolvimento ainda.

Bom, chega de papo, vamos a uma pequenas lista das novidades do Docker 1.13:

 

Docker stack

Para quem usa docker-compose ou docker service sabe das diferenças entre essas duas “ferramentas”, e como de certa foram eles deveriam se complementar, não é mesmo? E Essa é uma situação que vinha sendo trabalhada pelos engenheiros do Docker a algum tempo, essa função intermediária vinha sendo testada através do comando docker stack que possibilita criar um serviço dentro do swarm baseado em uma estrutura do docker-compose, ou seja, você conseguirá portar para o cluster de swarm um serviço baseado no docker-compose, isso facilita em muito a administração de seu serviço e claro no deploy do mesmo, pois garante que o serviço esteja rodando independente do nó onde ele está.

Nas versões de teste você tinha que gerar um arquivo .dab (distributed application bundle ou pacote de aplicação distribuída) baseado em seu docker-compose.yml e depois sim você conseguiria fazer deploy dessa stack utilizando o docker. Agora no docker 1.13 isso não é mais necessário, basta você chamar o arquivo docker-compose.yml diretamente no deploy da stack, algo como isso:

# docker stack deploy --compose-file ./docker-compose.yml minhastack

Muito mais simples e rápido não?

 

Gerenciamento de senha

Ou gerenciamento de segredos, essa é uma função básica dentro de qualquer orquestrator, o Kubernetes já possuía esse conceito e aplicação á algum tempo já, e agora o docker também implementa essa funcionalidade.
Mas afinal, onde vou usar isso? Sua aplicação usa senha não usa? Seja para banco, API, etc, qualquer aplicação usa senha de acesso a algum serviço em algum momento, e com você faz hoje com Docker? Provavelmente via variável de ambiente ou compartilhando um arquivo com o container, existem outras formas, como ferramentas as a service de gerenciamento de identidade.

Agora no docker 1.13 você pode definir uma secret que pode ser utilizada pelo seu serviço dentro do swarm, exatamente da mesma forma que o Kubernetes usa. Para isso foram adicionados quatro comandos novos, são eles:

  • docker secret create
  • docker secret inspect
  • docker secret ls
  • docker secret rm

Veja um exemplo de como criar uma secret para ser utilizada dentro de seu serviço

# echo "123456" | docker secret create senha-banco

Agora um exemplo de como utilizar essa secret em seu serviço:

# docker service create --name app --secret senha-banco ubuntu

Dentro do container será criado um arquivo em /run/secrets/senha-banco com a informação da senha, isso é claro apenas dentro do container, sem precisar mapear nada do host para o container.

# docker exec -it app cat /run/secrets/senha-banco
123456

Um detalhe muito importante é: As secrets podem ser utilizadas apenas dentro de serviços, se você criar um container com o docker run, vão não poderá utilizar essa funcionalidade.

 

Novo parâmetro de rede no Swarm

Essa talvez seja uma das melhorias mais importante no core do docker, pois permite que você adicione uma rede do Swarm mesmo se o container for criado fora de um serviço, ou seja, criado da forma tradicional com o docker run.... Mas afinal, por que isso é importante? É importante porque agora é possível adicionar um container a mesma rede do serviço criado no Swarm, isso é muito útil para debugs ou até mesmo testes de ambiente.

E como fica agora então? Simples, veja:

# docker network create --driver overlay --attachable rede-plugavel

Com o comando acima nós criamos uma rede overlay do Swarm, e a diferença agora é o parâmetro –attachable, que permite que essa rede seja plugada em qualquer container criado, e no comando abaixo nós plugamos um container a essa rede:

# docker run --rm -it --net rede-plugavel centos ping google.com

 

Plugins

Finalmente alguns plugins que estavam sendo testados e aprimorados foram disponibilizados como estáveis dentro da engine do Docker. Dentre ele podemos destacar o Flocker e o Weave, que agora tem integração total com docker.

 

Docker Daemon –experimental

Até então para você poder utilizar comandos e opções em desenvolvimento/teste do docker, você teria que instalar a versão experimental ou test da engine, mas agora basta você iniciar o daemon do docker com a opção –experimental, com isso será habilitado em momento de execução as opções da versão experimental, veja:

 

Melhorias no docker service

Essas, na verdade, são algumas das melhorias que a comunidade pediu ao longo do meses, uma delas tem relação com o update da imagem no update do serviço, para quem não notou, quando um serviço é atualizado (até então) você precisava executar um update com alguns parâmetros a mais para poder atualizar o serviço com uma nova imagem, na nova versão esse processo pode ser feito passando o parâmetro –force junto, o docker service update já verificará se há uma versão mais recente da imagem e atualizará o serviço baseado nisso.

 

Novo parâmetro no docker service

Além das melhorias no docker service, foi acrescentado também um novo parâmetro. Hoje nós acessamos um serviço através da porta exposta do mesmo, que você pode definir com o parâmetro –publish, no docker 1.13 será possível você definir de forma mais detalhada essa regra, isso deve-se ao novo parâmetro –port, que, da mesma forma que o –mout, tem sintaxe parecida com csv, onde você define item=valor,item=valor… Veja um exemplo:

# docker service create --name servico_web --port mode=ingress,target=80,published=8080,protocol=tcp

Dessa forma você tem, de forma mais clara, as definições de porta do serviço.

 

Outras novidades

Dentre outras novidades do docker 1.13 podemos destacar ainda algumas que tem bastante relevância para quem o utiliza, como por exemplo:

  • Cache de Layer para o Build: Para que gera muitas imagens, sabe que esse era um problema a ser resolvido, exemplo: geramos um imagem agora com o docker build, caso tenha que modificar essa imagem todas as layers anteriores a alteração não eram buildadas novamente, o docker build usava o cache para elas. Agora digamos que mandamos essa imagem para outro host e queremos fazer outra modificação nela, o que ocorre? Exatamente, todas as layers são buildadas novamente, isso pelo fato do docker não ter naquele host o cache de build dessa imagem. Parece ser trivial, mas quando se quer ganhar tempo, não é. No docker 1.13 você pode especificar na hora do build de onde o docker poderá buscar o cache de build, como por exemplo:
    docker pull imagem:v1.0
    docker build --cache-from imagem:v1.0 -t imagem2:v1.1 .
    

    Dessa forma o build da nova imagem utilizará o cache da imagem original, compilando assim apenas as layers diferentes.

  • A instrução MAINTAINER  foi removida do Dockerfile, agora essa informação deve ser utilizada através de label;
  • Foi adicionado um novo comando, ainda experimental, que é o docker service logs para visualizar os logs do serviço e não do container em si.
  • Outra adição do docker service foi o parâmetro –rollback que tem por objetivo realizar o update do serviço através de uma versão anterior a atual;
  • Remoção de container velhos através do docker system (ainda não há mais informações sobre como esse comando funcionará para remoção de containers antigos, então ficamos ligados no lançamento)

 

Ok Cristiano, e quando será lançada? Não há uma data 100% definida, o que se sabe é que será lançada até inicio de Janeiro de 2017, então pode ser que seja lançada hoje mesmo . Pode haver mais modificações? Claro, sempre há e com certeza as novidades que trouxemos hoje serão melhor explicadas após o lançamento oficial, então o jeito é ficar ligado aqui no blog e claro no site do ofiical do docker.

 

Grande abraço!

 

 

Docker Overlay

Oi 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:

Engine on each host

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!

Java em Docker

Olá pessoas, tudo bem?

Estamos há algum tempo pensando em montar um conteúdo um pouco mais prático sobre algumas soluções e claro, dúvidas que nossos leitores tem. Pensando nisso, queremos trazer hoje algumas dicas de como você pode montar uma imagem para sua aplicação Java o/.

Bom, antes de tudo é válido reforçar que entender um Dockerfile é fundamental para quem tem interesse na criação não só de imagens para Java, mas para qualquer linguagem ou ainda aplicação. Mas por que? Por que ele te da o poder de criar o ambiente exatamente da forma que você quer e precisa, além é claro de servir como documentação do seu ambiente, pois tudo que você precisa estará dentro do Dockerfile, então, se você ainda não leu, por favor leia o post onde explicamos melhor ele ;).

Vamos começar pequeno, um passo por vez, em nosso lab, vamos criar no diretório corrente uma pasta chamada “app”, dentro dela vamos criar o Dockerfile com o seguinte conteúdo:

FROM phusion/baseimage:0.9.17
RUN echo "deb http://archive.ubuntu.com/ubuntu trusty main universe" > /etc/apt/sources.list
RUN apt-get -y update
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y -q python-software-properties software-properties-common
ENV JAVA_VER 8
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
RUN echo 'deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main' >> /etc/apt/sources.list && 
 echo 'deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main' >> /etc/apt/sources.list && 
 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C2518248EEA14886 && 
 apt-get update && 
 echo oracle-java${JAVA_VER}-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections && 
 apt-get install -y --force-yes --no-install-recommends oracle-java${JAVA_VER}-installer oracle-java${JAVA_VER}-set-default && 
 apt-get clean && 
 rm -rf /var/cache/oracle-jdk${JAVA_VER}-installer

RUN update-java-alternatives -s java-8-oracle
RUN echo "export JAVA_HOME=/usr/lib/jvm/java-8-oracle" >> ~/.bashrc
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
CMD ["/sbin/my_init"]

Explicando.

FROM – Começamos sempre a criação de uma imagem baseada em outra imagem, em nossos exemplos vamos pegar a “phusion/baseimage:0.9.17” e baseada nela montaremos todo o resto, incluindo o Java propriamente dito (lembramos que você não precisa criar tudo do zero, no Docker Hub existem imagens prontas com o SDK já instalado).

RUN – Utilizamos para executar os comandos que desejados na imagem, isso para a adição de repositório, instalação de pacotes, criação de arquivos, etc. Basicamente qualquer comando sh pode ser utilizado aqui.

ENV – Serve para definirmos algumas variáveis dentro da imagem, em nosso caso, definimos a versão do Java que queremos instalar, bem como o path “java_home” da instalação.

CMD – Comando de inicialização da imagem, aqui você define o comando que será utilizado para subir seu container e mante-lo em execução (caso seja necessário), em nosso exemplo definimos um comando fake, que não tem ação nenhuma.

Feito, precisamos buildar a imagem para posteriormente utiliza-lá, para gerar a imagem você deve executar o comando:

$ docker build -t meujava:8 .

Com isso, aparecerá na sua lista de imagens essa que você acabou de gerar, e baseada nela vamos subir uma aplicação muito simples. Então, no mesmo diretório onde você está, crie um arquivo chamado: Main.java com o seguinte conteúdo:

public class Main
{
 public static void main(String[] args) {
 System.out.println("Oi MundoDocker ;)");
 }
}

Ok, agora vamos testar a imagem, para isso basta apenas criar um container e mapear o diretório onde você está, dessa forma é possível compilar esse arquivo que acabamos de criar, veja:

$ docker run --rm -v $PWD:/app -w /app meujava:8 javac Main.java

Está pronto? Calma amiguinho, o que fizemos foi compilar nossa aplicação, veja que no mesmo diretório apareceu um novo arquivo chamado Main.java, esta é o arquivo compilado e pronto para a execução, vamos lá:

$ docker run --rm -v $PWD:/app -w /app meujava:8 java Main

Veja que o retorno será exatamente a mensagem que definimos no arquivo Main.java, sim, eu sei, é ma exemplo ridículo de simples, mas temos que começar por algo.

Sim, este é um exemplo bem simples, que serve como exemplo de como é possível executar uma aplicação Java dentro de containers Docker, é claro que essa é a base para que você mesmo possa evoluir e construir seu ambiente da forma a atender melhor a sua necessidade.

Por hoje era isso, no vemos ano que vem

Grande abraço!

Docker EE e CE

Oi Pessoal!

No último dia 02 de março, o Docker anunciou uma grande mudança em sua plataforma, lançando oficialmente a versão enterprise da engine de containers mais utilizada atualmente. Mas o que muda? Responderemos isso e mais algumas outras dúvidas neste post!

Esse movimento adotado pelo Docker em, dividir, as versões da sua engine é algo já esperado pela comunidade, e para alguns veio até tarde. Mas por que isso agora? Por um motivo simples, produto. O Docker vem já algum tempo sendo desenvolvido como uma plataforma, agregando a cada nova release alguma correção que resolve um problema ou uma feature que melhora algum aspecto da engine.

Agora temos claro as linhas de trabalho do Docker, e como serão realizadas as atualizações na plataforma. As entregas de novas features, correção de bug, etc, seguiram a mesma linha adotada por outras empresas, ou seja, correção de bug e fix mais frequentes do que novas features, com isso a comunidade não precisará aguardar tanto tempo para ter uma correção já na engine.

Para ficar mais claro, dá uma olhada nessa imagem:

Docker Enterprise Edition

Fonte: https://blog.docker.com/2017/03/docker-enterprise-edition

Como você pode notar, as entregas para a versão community serão mais frequentes, e serão baseadas em correções e fix, tendo uma cadência mensal. Já entregas que envolvem novas features ou mudanças significativas nas engine serão realizadas a cada três meses. Já a versão enterprise terá apenas entregas trimestrais, com correções e novas features (caso tenha é claro) e o suporte será de um ano, baseado na data de lançamento.

Mas por que essa agora?

Há algum tempo estamos divulgando, ensinando e ajudando diversos públicos ao uso do Docker, tendo em vista versatilidade dessa plataforma, é claro e obvio a necessidade de adaptação do modelo de negócio para atender esses públicos, por exemplo:

Note que são perfis diversos, com necessidades e expectativas diferentes, mas em algum momento complementares. A versão enterprise do Docker visa o público que não quer apenas brincar, mas sim colocar em produção e disponibilizar para cliente.

Na imagem acima temos um apanhado geral das diferenças e onde cada versão é aplicada. Isso quer dizer que não posso colocar o Docker CE em produção? Não, isso quer dizer que se você usar a versão enterprise terá mais facilidade, já com a versão community será possível mas você terá mais trabalho.

 

Mudou o nome?

Sim, a versão community será algo parecido com isso:

# docker -v
Docker version 17.03.0-ce, build 60ccb22

Não teremos mais a nomenclatura de 1.xx, teremos então: ano.mes com a distinção entre CE e EE.

 

Tem mais alguma coisa nova?

Sim!!! Você já deve ter visto no anuncio oficial, agora há uma forma de você certificar seu ambiente seguindo as diretrizes do Docker, está disponível a Docker Store, um hub para publcação de recursos oficialmente homologados pelo Docker. Com isso, se você desejar criar um plugin para o Docker, por exemplo, você pode, atendendo uma série de requisitos, ter este plugin homologado e com certificado do Docker, o que obviamente aumenta sua relevância para quem usa.

Mas o que o Docker quer com isso? Te lembra daquelas imagens ali de cima, onde eram ilustrados os diferentes públicos que o Docker atende? Pois bem, dessa forma o Docker provê um recurso oficial, homologado e com o selo de aprovação deles para plugins, imagens, S.O, etc., atendendo assim a uma necessidade do mundo enterprise: “É confiável? Quem mantém?” dentre outras questões que este publico levanta no momento de decidir entre tecnologias.

Resumo, sim, o Docker acaba de se dividir em Community e Enterprise, até onde as coisas legais estarão na versão community só Deus sabe, mas a tendência é que sempre tenhamos  com o que brincar. E claro, para quem não quer perder tempo fazendo tudo na mão, existe a enterprise, que facilita tudo o que é possível.

Ufa, agora sim acabou

Nos ajude divulgando o blog! Grande abraço!

 

NodeJS com Docker na Umbler

Eai pessoal, blz?

O post hoje será um pouco diferente, queremos trazer para vocês como a Umbler desenvolveu sua plataforma de NodeJS utilizando Docker. SIM, falaremos sobre o que deu certo e, claro, o que deu errado nesse caminho. O intuito é mostrar mais um case de sucesso e tudo que foi preciso para isso :).

A Umbler  já utiliza Docker há alguns anos (obviamente para aplicações/serviços internos) e isso ajudou no desenvolvimento de sua plataforma NodeJs. Mas até chegar à experiência ideal levou tempo, pesquisa, testes, prototipação e muita paciência.

Abaixo compartilhamos com vocês uma apresentação que foi realizada durante o Meetup de NodeJS em Porto Alegre no dia 11/07, onde mostramos aos participantes os detalhes dessa jornada:

Vamos detalhar o que foi apresentado.

Quem mesmo?

A Umbler é uma StartUp gaúcha de cloud hosting sob demanda, seu objetivo é facilitar cada vez mais a vida de quem cria a web, ou seja, as agências e desenvolvedores. Atualmente possui cerca de quarenta mil clientes e conta com setenta funcionários distribuídos pelo mundo.

O caminho até aqui

Como sempre, não existe uma solução mágica para todos os problemas, ou uma única solução infalível. Às vezes, temos que nos aventurar com o máximo de alternativas possíveis para ter certeza de que aquilo não nos atenderá ou, pelo menos, não nos atenderá naquele momento.

Foi assim que, depois de muito meses de testes e prototipação, foi possível observar algumas coisas e descobrir o porquê de algumas soluções não atenderem a demanda que a Umbler queria resolver. Entre as soluções testadas é possível destacar:

OpenShift

Plataforma pronta para criação de containers, baseada em Kubernetes. É uma plataforma que funciona muito bem, tem instalação relativamente fácil, possui gerenciamento centralizado e conta com integração com diversas outras ferramentas/soluções. Esta é uma ferramenta com muitos pontos positivos, pois atende aos mais variados problemas, mas que não se encaixou, até então, no que a Umbler precisava. Dos pontos negativos que se destacam são:Curva de aprendizagem: Openshift possui, além de kubernetes, uma série de outras soluções para que seja possível a criação e gerenciamento dos containers nela hospedado. Seu uso é simples e intuitivo, mas eventualmente algo daria manutenção, e aí estava um dos empecilhos. Além de saber tudo sobre Docker, Kubernetes, OpenVswitch, era obrigatório entender cada um dos demais componentes da plataforma, justamente para se antecipar a algum problema.

  • Restrições: Apesar de todas as facilidades, o OpenShift possui algumas restrições que, para as necessidades mapeadas, impossibilitaram o seu uso ou, pelo menos, gerariam mais demanda para adaptar a plataforma. O objetivo da Umbler é criar uma plataforma completa e fácil, com a menor quantidade de amarras possíveis, garantindo assim a melhor experiência dos usuários, infelizmente o Openshift tornaria isso mais complexo de ser realizado.
  • Inovação: Obviamente inovar é preciso, no mercado de tecnologia isso é além de bom, obrigatório, com as restrições que foram encontradas inovar utilizando o Openshift dependeria muito do que a plataforma teria a oferecer,  ou seja, a inovação do produto estaria presa a inovação da plataforma, restando pouco, ou quase nada de margem para adaptação.
  • Custo: Existem basicamente duas versões do Openshift, a Origin que é opensource e você pode utilizar para resolver seus desafios sozinho, e contar com o apoio da comunidade. Ou a versão enterprise, que garante suporte comercial à plataforma e atualizações dos softwares que a compõem. Independente da versão, o custo/benefício não compensava, pois mesmo com a versão opensource o tempo de resposta ou atualização para algo crítico era muito grande, tornando assim a versão “gratuita” não tão gratuita assim.

Kubernetes

Kubernetes é um orquestrador para containers totalmente opensource, e mantido por uma comunidade gigantesca. Tendo em vista o histórico de testes/prototipação com o Openshift, a segunda abordagem naturalmente seria algo mais voltado ao que já foi visto. Como a base do Openshift é Kubernetes, a ideia era utilizar o Kubernetes e adaptar o que fosse necessário para a plataforma. Simples não? Sim e não, vamos ver algumas restrições dele:

  • Curva de aprendizagem: Realmente, utilizando apenas o Kubernetes a quantidade de tecnologias que deveriam ser dominadas foi reduzida a apenas duas: Docker e Kubernetes. Mesmo assim, o tempo para aprender tudo e saber resolver tudo dessas tecnologias era elevado. Menor do que com Openshift, mas ainda assim algo que faria a plataforma levar mais tempo a ser finalizada.
  • Restrições: Depois de muita leitura, estudo e testes, foram encontradas ainda assim algumas restrições, a mais clássica delas é o Kubernetes não suportar as últimas versões do Docker, ou seja, sempre haveria um gap entre o que foi lançado de novidade pela engine do Docker e o que realmente está sendo utilizado.
  • Inovação: Como no caso da Openshift, o uso do Kubernetes resolveria diversos pontos da plataforma, mas ainda assim seria algo que poderia travar a inovação e adaptação da plataforma.

Docker Swarm

O Swarm é o método nativo de cluster na engine do Docker, a partir da versão 1.12 do Docker é possível utilizar esse recurso sem a necessidade de uma ferramenta ou solução de terceiros. Assim como no Kubernetes, com o Swarm é possível criar e gerenciar todos os serviços/containers do cluster. Com o Swarm foi possível resolver algumas das pendências das demais soluções, como por exemplo:

  • Curva de aprendizagem: Como já mencionado, a Umbler utiliza Docker há algum tempo, então já havia em casa mesmo o conhecimento prévio, bastando apenas a adaptação para o modo de cluster.
  • Custo: Existe a versão opensource e a versão enterprise do Docker, a grande diferença entre depender da comunidade Docker e comunidade Openshift é a velocidade na resolução de alguma issue ou até mesmo melhoria para a engine, isso facilita na tomada de decisão, sem contar no tamanho das comunidades
  • Inovação: Ainda há uma amarra quanto a tecnologia, no entanto, com o Swarm é possível criar/modificar a plataforma na mesma velocidade da engine de containers.

Existe algo em que o Swarm não atendeu? Sim, obviamente, e isso é natural, visto que não existe solução mágica para tudo. No entanto, foi possível adaptar algumas outras soluções para que fosse possível mitigar ou até mesmo sanar esses casos.

Sim, foi um processo longo, às vezes demorado, mas que rendeu bons frutos, seja de nível técnico (com o incremento de conhecimento para a equipe), ou de negócio, pois foi necessário o entendimento de todos quanto a necessidade real dos usuários, e, claro, a moldagem das ideias para atender essas necessidades. Desafios que foram sendo resolvidos durante a caminhada, é possível destacar:

  • Isolamento: Sim, containers são isolados, mas para isolar o tráfego entre os serviços, como faz? Esse foi um dos pontos onde se investiu algum tempo para encontrar a melhor resposta.
  • Inovar de forma responsável: A cada três meses é lançada uma nova versão do Docker, atualiza-se o ambiente a cada três meses? Usa-se as features novas já de cara? Este também foi motivo para algumas horas de conversa.
  • Complexidade: Não é porque foi utilizada uma tecnologia base que o ambiente não seria complexo. Quanto mais features para a plataforma, maior a complexidade para se atender essa demanda.
  • Simplificar: Como simplificar então? Como deixar tudo fácil de ser entendido, e, principalmente, replicável?
  • Deploy: De que forma o usuário vai utilizar a plataforma, como deve ser o melhor fluxo para colocar uma aplicação no ar com Docker? Às vezes a resposta certa não é a óbvia
  • Cobrança: Como quantificar o gasto de cada cliente, existe na “caixa” isso? Quanto cobrar, e mais importante, vamos cobrar?

Além de desafios, ficaram também diversos aprendizados, que não custa nada compartilhar, certo?

  • Pesquisa e Prototipação são fundamentais. Mesmo que tu saiba tudo na teoria, ás vezes um comportamento só é validado na prática, tentando fazer dar erro.
  • Perseverança é muito importante. Às vezes a solução mais fácil parecer ser a melhor, o que pode não se confirmar. Por isso é preciso cuidado, pois você estará fazendo algo não para você, e nem para seu colega, e sim para dezenas, centenas, milhares de pessoas. É nelas que você deve pensar.
  • Ouvir todos os interessados é fundamental. Seja seu cliente (aquele que já paga pelo serviço), seja seu usuário (aquele que apenas usa, mas não gasta), seja seu colega, seu chefe, e principalmente a comunidade, apenas ouça, processe, e aí sim pense em algo que faça sentido para todos.
  • Outro ponto interessante é separar o “que” precisa ser feito do “como” deve ser feito. Em alguns casos (muitos por sinal), quando recebemos um problema para resolver já saímos com a solução pronta, montada em nossa cabeça. Mas será que o problema é realmente o apresentado? Será que essa solução se encaixa realmente na resolução? Lembre-se: O que eu preciso fazer define como eu vou fazer, e não o contrário.
  • Admita, você não terá todas as respostas em uma única solução, isso é improvável. Mas você precisará estar aberto a isso, e, principalmente, você precisará saber lidar com isso.
  • Última, mas não menos importante dica: Entenda exatamente o que você está fazendo. Não apenas aceite e saia executando. Entenda! Isso fará o seu trabalho ter mais valor e você terá outra visão daquilo que está criando.

Esperamos que isso ajude vocês durante suas próprias jornadas. Para nós foi uma experiência bem divertida, além de enriquecedora, e é uma honra compartilhar com vocês, quer conhecer mais sobre o NodeJs na Umbler? Então acessa este link, tem tudo que você precisa saber

Como sempre, se ficou com dúvidas ou quer entender melhor, nos avise, e nos ajude divulgando o blog o/. Abraço!

Docker Secrets

Oi pessoal! 

Para o artigo de hoje, contamos com a ajuda de um grande amigo nosso, o Wellington F. Silva, que colocou em seu blog um texto muito bacana sobre o que é e como funcionam as secrets no Docker 1.13. No decorrer desse post entenderemos como essa nova funcionalidade trabalha, sua origem e claro, o impacto disso em nosso dia-a-dia, #vamoslá?

 

O que é o secret?

Quando estamos trabalhando em um projeto e precisamos passar informações sensíveis para o ambiente, tais como senhas, chaves privadas, tokens, chaves de APIs e afins sempre passamos pelo problema de não podermos deixar no controle de versão e devemos sempre utilizar uma maneira segura de trafegar esses segredos.

Muitas vezes acabamos trabalhando com variáveis de ambiente para guardar essas informações, o que não é recomendado por alguns motivos.

Diogo Monica que é um dos engenheiros de software da Docker mencionou em um comentário que variáveis de ambiente quebram o princípio de “least surprise” e podem levar a eventuais vazamentos de segredos já que estão acessíveis de várias maneiras, tais como linked containers, através do *docker inspect*, de processos filhos e até de arquivos de logs já que em caso de exceptions da aplicação muitos frameworks fazem o dump do contexto, inclusive o valor das variáveis de ambiente no arquivo de log.

 

Um pouco da história

Em Janeiro de 2015 houve uma proposta de adicionar o comando `docker vault` numa alusão ao Vault Project da Hashicorp para fazer a gerencia de segredos dentro do próprio Docker. Segue o link para a issue 10310 no GitHub. A discussão evoluiu e virou a issue 13490, onde trataram do roadmap para o atual Docker Secrets.

 

Como funciona?

O Docker Secrets funciona como um cofre onde você pode colocar coisas sensíveis lá e só que tem a chave do cofre consegue utilizar, no caso essa chave é designada aos nós dos serviços que a chave for atribuída.

 

Dicas

  • Só funciona no Swarm Mode onde toda a comunicação entre os nós é por padrão encriptada.
  • Se utiliza do algoritmo de RAFT para persistir o segredo de forma encriptada por todos os nós managers e distribuir aos containers que fizerem parte do serviço ao qual a chave for atribuída.

Segue diagrama da própria Docker:

Criando um secret

Podemos criar um secret de duas maneiras, usando o STDIN:

$ echo "ConteudoDoSecret" | docker secret create um-secret -

Ou lendo um arquivo:

$ docker secret create novo-secret $HOME/senhas.txt

 

Listando, removendo e demais opções

Para listar as secrets disponíveis:

$ docker secrets ls
  ID NAME CREATED UPDATED
  8ulrzh4i1kdlxeypgh8hx5imt um-secret 3 minutes ago 3 minutes ago
  n95fprwd2trpqnjooojmpsh6z novo-secret About an hour ago About an hour ago

Demais opções do que fazer com os secrets como remover, inspecionar, etc podem ser listadas com o help:

$ docker secret --help

 

Usando o secret criado

Podemos criar um serviço usando um secret criado com o comando:

$ docker service create --name demo --secret um-secret mysql:5.7

Podemos remover um secret de algum serviço existente

$ docker service update --secret-rm um-secret demo

Ou podemos adicionar um secret a algum service que esteja de pé:

$ docker service update --secret-add novo-secret demo

 

Quando atrelamos um secret a um service podemos então acessar qualquer um dos containers que estejam rodando nesse service no path /run/secrets. Dentro do container nesse path vai existir um arquivo plain text com o nome igual ao definido no nome do secret e com o conteúdo desejado, o secret em plain text. No nosso caso seria no path /run/secrets/novo-secret.

 

Bem legal não é? Ajude divulgando o blog, e fique ligado teremos muitas novidades em breve, então se não se inscreveu em nossa newsletter, inscreva-se ;). Até a próxima.

 

Fonte: http://dumpscerebrais.com/2017/02/como-trabalhar-com-secrets-no-docker-1-13-x/

Docker e Flannel

Oi Pessoal!

A intenção hoje é chamar a atenção para um dos recursos que está presente no Docker e que as vezes passa despercebido para muitos dos utilizadores dessa tecnologia, que é trabalhar com rede. Já vimos aqui no blog como trabalhar com Docker Network, mas com a ascensão do docker 1.12 ficou ainda mais fácil mudar a forma de como se utilizar rede, você pode integrar o Docker com diversos plugins e tecnologias de rede, hoje veremos como utilizar o Flannel para ser seu backend de rede.

Para quem não conhece, o Flannel é um projeto que foi inicialmente desenvolvido pela CoreOS, mas que atualmente é mantido, além da própria empresa, pela comunidade. Ele utiliza um serviço de chave-valor para persistir as informações sobre alocação de ip entre hosts e containers, por padrão ele utiliza o Etcd (que por coincidência é desenvolvido e mantido pela CoreOS também ), veja abaixo algumas das características do Flannel e a diferença em relação ao Docker Network:

                              Flannel              Docker Overlay Network
Modelo                        VxLAN ou UDP                            VxLAN
Isolamento de aplicação                        CIDR Schema                      CIDR Schema
Protocolos suportados                              Todos                            Todos
Serviço de nome                                Não                              Não
Requer backend externo                                Sim                              Sim
Tipo de encriptação                                TLS                              Não
 vNIC por Container                                Não                              Sim
Restrição de subnet por container                                Não                              Sim

Como podem notar o Flannel tem algumas vantagens e desvantagens em relação ao Docker Network, destacam-se a comunicação encriptada que ele provê e não ter a possibilidade de criar subnet diferente por cliente, ou seja, todos os containers fazem parte da mesma rede. Se você está pensando em utilizar Kubernetes, leve em consideração o Flannel, pois é um dos plugins mais utilizados com esse orquestrador. Vamos colocar a mão na massa?

Instalação e dependências

Servidor Etcd

Nosso exemplo foi baseado no Centos 7 64 bits, mas você pode utilizar em outro S.O sem problema. Vamos lá, primeiramente você deve habilitar o repositório Extras do CentOS, para isso edite o CentOS-Base.repo e coloque habilite-o, veja:

# CentOS-Base.repo
#
# The mirror system uses the connecting IP address of the client and the
# update status of each mirror to pick mirrors that are updated to and
# geographically close to the client. You should use this for CentOS updates
# unless you are manually picking other mirrors.
#
# If the mirrorlist= does not work for you, as a fall back you can try the
# remarked out baseurl= line instead.
#
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
enable=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Agora vamos instalar o backend do Flannel, que é o etcd (serviço de chave valor em memória), o etcd é utilizada para armazenar as informações sobre as redes que serão distribuídas entre os containers. Vamos lá:

[root@host-etcd ~]#  yum install etcd

Edite o /etc/etcd/etcd.conf alterando o ETCD_LISTEN_CLIENT_URLS, em nosso teste colocamos 0.0.0.0, ou seja, o etcd estará acessível através de qualquer ip do host, veja:

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"

Cuide para que a porta 2389 esteja liberado no firewall desse host. Agora vamos aproveitar que estamos no host de etcd e vamos já deixar configurado a rede que será utilizada pelos hosts de Docker. Para isso, crie um arquivo, em nosso lab: rede.json e adicione o seguinte código:

{
 "Network": "192.0.0.0/16",
 "SubnetLen": 22,
 "Backend": {
 "Type": "vxlan",
 "VNI": 1
 }
}

Onde:

  • Network – Bloco de rede que será distribuída para os containers;
  • SubnetLen – Tamanho do bloco alocada para cada host, ou seja, cada host receberá um /22 do bloco 192.0.0.0/16, isso que dizer que poderíamos ter até 1000 containers em 1 host.
  • Type – Tipo do canal que será utilizado, lembra que no Flannel você pode escolher em vxlan ou udp, pois bem, é aqui que você configura isso, por experiência própria, recomendamos utilizar vxlan, pois há menos overhead.

O que faço com isso agora? Importe no etcd ;), lembrando que o etcd trabalha com chave=valor, então execute:

[root@host-etcd ~]# etcdctl set /mundodocker/network/config < rede.json

Onde:

  • /mundodocker/network/config – chave
  • rede.json – valor

Agora vamos ver se essas informações foram persistidas no etcd:

[root@host-etcd ~]#etcdctl get /mundodocker/network/config
{
 "Network": "192.0.0.0/16",
 "SubnetLen": 22,
 "Backend": {
 "Type": "vxlan",
 "VNI": 1
 }
}

 

Servidores Docker

Não esqueça, em todos os hosts temos que ativar o repositório de extras do CentOS, da mesma forma que foi feita acima. Vamos as instalações das dependências, o docker é claro:

[root@host-docker01 ~]# curl -fsSL https://get.docker.com/ | sh

Agora o Flannel:

[root@host-docker01 ~]# yum install flannel -y

Vamos as configurações agora, começamos pelo Flannel, para isso, edite o arquivo: /etc/sysconfig/flanneld, modificando as linhas:

FLANNEL_ETCD = Servidor do Etcd.
FLANNEL_ETCD_KEY = Key definida no Etcd.

Veja como deve ficar:

[root@host-docker01 ~]# cat /etc/sysconfig/flanneld | grep -v ^#
FLANNEL_ETCD="http://host-etcd:2379"
FLANNEL_ETCD_KEY="/mundodocker/network"

Agora inicie o serviço do Flannel:

[root@host-docker01 ~]# systemctl enable flanneld
[root@host-docker01 ~]# systemctl start flanneld

Note que ele criará uma interface de rede chamada flannel.1, que será utilizada para comunicação entre os hosts. Note também que será criado um arquivo dentro de: /run/flannel/subnet.env com as informações sobre a rede que o host assumiu, esse arquivo será utilizado daqui a pouco.

Agora vamos configurar nosso serviço de Docker para utilizar a rede Flannel configurada anteriormente, para isso, edite o arquivo: /lib/systemd/system/docker.service adicionando a linha: EnvironmentFile=-/run/flannel/subnet.env e alterando a forma como o Docker será iniciado, veja como deve ficar:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket
Requires=docker.socket
 
[Service]
Type=notify
EnvironmentFile=-/run/flannel/subnet.env
ExecStart=/usr/bin/docker daemon -H fd:// $OPTIONS $DOCKER_STORAGE_OPTIONS --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity
TimeoutStartSec=0
 
[Install]
WantedBy=multi-user.target

Agora basta iniciar/reiniciar o serviço do Docker:

[root@host-docker01 ~]# systemctl enable docker.service
[root@host-docker01 ~]# systemctl start docker.service

Não esqueça de fazer isso em todos os hosts de Docker que você quer colocar nessa rede.

 

Vamos testar?

Basta você criar um container em cada host, em nosso teste criamos um baseado na imagem do CentOS:

Host 1:

[root@host-docker01 ~]# docker run -it centos /bin/bash

Host 2:

[root@host-docker02 ~]# docker run -it centos /bin/bash

Agora basta você pingar de um container para o outro, ou se quiser fazer um teste mais real, você pode instalar um banco de dados ou servidor web em um dos containers e tentar acessar via ip da rede Flannel pelo outro container. Como você deve ter notado esse processo é bem simples e resolve grandes problemas com rede no Docker, como por exemplo a comunicação entre multi-host.

Por hoje era isso, espero que tenha ajudado, e como sempre, nos ajude divulgando o blog

Abraço!