Kubernetes – Namespaces

Fala galera, hoje vamos fazer mais um post referente a Kubernetes e vamos falar um pouco mais sobre Namespaces e como ele nos beneficia em nosso dia a dia. Para isso vamos entender um pouco mais o que é e como funciona o Namespace:

O Kubernetes diferente do Docker suporta com que a partir de um único cluster sejam criados diversos clusters virtuais dentro desse cluster e isso é chamado de Namespaces, possibilitando que seja possivel criar uma estrutura macro no qual futuramente possa ser dividia em vários namespaces. O Namespace foi projetado para suprir a demanda de equipes compostas pro diversos usuários e projetos nos quais cada equipe possui um ambiente diferente da outra equipe, fornecendo assim recursos dos quais facilitam muito o seu dia a dia como por exemplo a limitação de recursos que veremos mais a frente.

Para listar os namespaces atuais em um cluster de Kubernetes, basta executar

kubectl get namespaces

Por padrão já existem dois namespaces criados no Kubernetes são eles:

default: Onde todos os objetos que não possuem Namespace especificado são criados.

kube-system: Todos os objetos que o Kubernetes cria para gerenciar o cluster estão nesse Namespace.

Para criar um namespace você precisa criar um arquivo .yml como o abaixo:

apiVersion: v1
kind: Namespace
metadata:
  name: nomenamespace

kubectl -f arquivo.yml

Ou você também pode executar comando kubectl create namespace mundodocker

Quando o Kubernetes criar um serviço ele vai criar junto uma entrada DNS dentro do seu cluster e essa entrada DNS possui a seguinte nomeclatura: service-name.namespace-name.svc.cluster.local no qual pode ser utilizado pela sua aplicação para conectar em seu serviço, geralmente os Namespaces criados possuem nomeclaturas como: Produção, Homologação, Teste….

Para realizar a criação de um Pod dentro de um determinado Namespace é possível fazer executando:

kubectl --namespace=mundodocker run nginx --image=nginx


Limitação de recursos ou objetos.

Quando se utiliza um ambiente compartilhado, sempre existe uma preocupação com as questões de recursos, e dentro do Kubernetes existe a possibilidade de resolver isso utilizando “Resource Quota” que fornece uma limitação de recursos por Namespace, essa limitação pode ser desde limitação de Hardware (Memória,Cpu….) quanto há quantidade de objetis que podem ser criados por tipo dentro do Namespace. Quando o Kubernetes verifica se é possível criar um “Pod,Service,Replication Controller” dentro do Namespace, o Kubernetes verifica se existe alguma limitação de recursos no Namespace, caso exista o Kubernetes já notifica o usuário sobre não ser possível realizar a criação do componente desejado. Um exemplo de política de recursos que pode ser criado é o seguinte:

– Namespace Teste: Possui 20GB de memória e 20 Núcleos.
– Namespace Producao: Possui 40GB de memória e 20 Núcleos.

Porém se seu ambiente possuí um total de 50GB de memória, o Kubernetes irá alocar a memória o CPU para o componente que realizar o pedido primeiro, não tendo assim como colocar a prioridade para determinado Namespace. Além de fazer limitações de CPU e memória é possível também realizar a limitação de disco e também limitação de objetos.

Um exemplo de criação de “Resource quota” você pode ver abaixo:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: limitacao-recursos
spec:
  hard:
    pods: "10"
    limits.cpu: "10"
    limits.memory: 20Gi

Após criar o seu arquivo .yaml basta você executar kubectl create -f ./limitacao-recursos.yaml --namespace=teste e você terá criado o seu Resource Quota. Caso queira verificar se tudo ocorreu da forma certa, você pode executar kubectl get quota --namespace=teste e você irá visualizar o retorno bem parecido com esse:

NAME                    AGE
limitacao-recursos       5s

Também é possível verificar de uma forma mais detalhada sobre o seu Resource Quota utilizando kubectl describe quota limitacao-recursos --namespace=teste. Isso irá mostrar de forma detalhada como está configurado a sua quota.

Pessoal, nos próximos posts sobre Kubernetes vamos demonstrar na prática como é possível colocar algumas aplicações dentro do Kubernetes e como utilizamos os componentes mostrados até aqui na prática. Por hoje é isso, fique ligado em nossos próximos posts, um grande abraçõ e até a próxima.

 

 

 

 

 

 

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!

 

O que é Docker?

Olá!

Iniciamos agora uma série de posts técnicos que lhe ajudarão a entender o funcionamento do Docker, e como cada componente é utilizado dentro desta plataforma.

Primeiro temos que definir o que não é Docker. Docker não é um sistema de virtualização tradicional. Enquanto em um ambiente de virtualização tradicional nós temos um S.O. completo e isolado, dentro do Docker nós temos recursos isolados que utilizando bibliotecas de kernel em comum (entre host e container), isso é possível pois o Docker utiliza como backend o nosso conhecido LXC.

Abaixo podemos ver uma figura que ilustra essa diferença.

lxc-vm

 

Docker é uma plataforma Open Source escrito em Go, que é uma linguagem de programação de alto desempenho desenvolvida dentro do Google, que facilita a criação e administração de ambientes isolados.

Mas por que que o Docker é tão legal?

O Docker possibilita o empacotamento de uma aplicação ou ambiente inteiro dentro de um container, e a partir desse momento o ambiente inteiro torna-se portável para qualquer outro Host que contenha o Docker instalado.

Isso reduz drasticamente o tempo de deploy de alguma infraestrutura ou até mesmo aplicação, pois não há necessidade de ajustes de ambiente para o correto funcionamento do serviço, o ambiente é sempre o mesmo, configure-o uma vez e replique-o quantas vezes quiser.

Outra facilidade do Docker é poder criar suas imagens (containers prontos para deploy) a partir de arquivos de definição chamados Dockerfiles (veremos isso melhor em posts futuros).

Não podemos nos esquecer também de que o Docker utiliza como backend default o LXC, com isso é possível definir limitações de recursos por container (memória, cpu, I/O, etc.)

Para ficar um pouco mais claro, podemos ver na imagem abaixo a diferença em se utilizar o LXC puro e o Docker.

lxc_vs_docker

 

Como o Docker faz isso?

Como ele trabalha utilizando cliente e servidor (toda a comunicação entre o Docker Daemon e Docker client é realizada através de API), basta apenas que você tenha instalado o serviço do Docker em um lugar, e aponte em seu Docker Client para esse servidor. A plataforma do Docker em si utilizada alguns conjuntos de recursos, seja para a criação ou administração dos containers, entre esses conjuntos podemos destacar a biblioteca libcontainer, que é responsável pela comunicação entre o Docker Daemon e o backend utilizado, é ela a responsável pela criação do container, e é através dela que podemos setar os limites de recursos por container.

Podemos ver na imagem abaixo como é o Workflow dentro do Docker.

libcontainer intro

 

 

Ficou com dúvidas? Ótimo! nos mande suas dúvidas para que possamos conversar mais sobre essa tecnologia. E aguardem, nos próximos posts explicaremos melhor cada um dos componentes do Docker, e claro traremos algumas aplicações práticas dele

Até Mais!

 

O que é Container?

Olá Pessoal,

Este é nosso primeiro post aqui no Blog, antes de começar a falar sobre o que é Docker, Containers, DevOps e afins gostaríamos de agradecer a você que chegou até nós e agora está lendo um pouco sobre o que é esse mundo.

Você já deve ter ouvido falar em Containers ou no mínimo, Docker, bom o que é tudo isso afinal de onde veio essa história de container?

O projeto LXC (Linux Container) nasceu em agosto de 2008, no inicio, o site oficial trazia a seguinte frase: LXC, chroot com esteroides. O objetivo do projeto era ser uma alternativa a já consolidada tecnologia de chroot, sendo um meio termo entre máquina virtual e chroot, possibilitando a criação de um ambiente mais próximo possível de uma instalação Linux sem a necessidade de  um kernel separado.

Através do chroot é possível encapsular um sistema inteiro dentro de uma estrutura de diretório, fazendo com que o sistema hospede não acesse nada além daquilo que é definido dentro dessa arquitetura. Isso é muito útil pois elimina a sobrecarga de uma máquina virtual inteira para executar um processo ou serviço simples.

Voltando ao LXC, algumas das features do LXC são:

Kernel Namespaces:

Possibilita a abstração de processos dentro do kernel, isso quer dizer que um processo ou grupo de processo é isolado dentro do kernel, podendo visualizar os pontos de montagem, id de processos, id de usuário, hostname e fila de processo, isolados de outros processos ou grupo de processo.

Apparmor and SELinux:

Responsável por carregar politicas de acesso no host, isso quer dizer que são definidas regras de acesso a determinados arquivos/diretórios dentro do host, isso garante que em uma possível brecha de segurança, um container não consiga visualizar ou executar algo malicioso no host.

Seccomp policies:

Realiza uma filtragem das chamadas de sistema (syscall) e aceita ou não essa chamada. Como o host e container compartilham do mesmo kernel, é necessário algumas politicas especificas a nível de interface do kernel para que o hóspede não consiga escalar privilégios dentro do sistema host.

Chroots (pivot_root):

Responsável pelo mapeamento de diretórios e ponto de montagem do sistema container, é a chamada de sistema que cria a árvore de diretórios que o container terá acesso.

Kernel Capabilities:

Todos os sistema UNIX dividem os processos em duas grandes categorias, processo privilegiados  (sendo executados como root) e processos não privilegiados (executados com usuário comum), por padrão todo container executa comando não privilegiados, ou seja, um processo dentro de um container é executado como root dentro do host (mesmo que este esteja como root dentro do container). Sendo assim, a partir do kernel 2.2  foram inseridos dispositivos que possibilitam ao container executar de forma privilegiados alguns comandos, para esses dispositivos foi dado o nome de Capabilities ou CAP.

Cgroups:

Ou Control Groups, é responsável pelo controle de uso dos recursos por processo/grupo de processo, podendo assim executar diferentes containers com diferentes limites de uso (memória, cpu, I/O).

Devido a essas características é que chamamos de container todo sistema criado utilizando essa tecnologia, pois o sistema fica “enjaulado” dentro de uma caixa de recursos alocados exclusivamente para ele, e claro limitado a esses recursos. Abaixo há uma imagem ilustrando a diferença entre uma máquina virtual comum e um sistema em containers.

 

 

Ótimo, já sabemos um pouco sobre o que é e de onde vieram os containers, agora temos outras dúvidas:

O que é o docker afinal?

No que os containers podem me ajudar?

Ok, ok, vamos responder a essas e muitas outras dúvidas em nossos próximos posts, fiquem atentos e caso tenham dúvidas ou quiserem conversar um pouco mais sobre esse mundo, deixem suas mensagens!

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!

 

 

O que são capabilities

Olá!

Hoje vamos ver algumas features de segurança que pertencem não apenas ao Docker, mas sim ao LXC, são as capabilities.

Em sistemas Unix like, há basicamente duas categorias de processos: processos privilegiados, que executam com ID 0 (superusuário) e os não-privilegiados, que executam com ID maior que 0.

Basicamente os processos privilegiados ignoram todas as verificações de permissões de kernel, enquanto os processos não-privilegiados estão sujeitos a algumas checagens para sua correta execução, normalmente: UID efetivo (usuário dono do arquivo/binário, etc), GID efetivos (grupo dono do arquivo/binário, etc) ou lista de grupo suplementar (mais conhecidas como ACL’s – Access Control List).

Do kernel 2.2 em diante o Linux dividiu as formas tradicionais de privilégios associados ao superusuários em unidades diferentes, conhecidas como capacidades, que podem ser habilitadas e desabilitadas independentemente umas das outras. Essas capacidades são atribuídas por thread, ou seja, threads do mesmo processos podem ter suas capacidades de execução modificadas.

 No Docker é possível modificar essas capacidades, habilitando ou desabilitando conforma sua necessidade, vale lembrar que todo container executa de forma não privilegiada, ou seja, ele tem sua execução restrita, quando é adicionada uma capacidade a execução de um container, é dado o privilegio para que o mesmo possa executar alguma ação como root, isso pode ser um problema de segurança, dependendo do seu ambiente.

Vamos ver algumas capacidades que podem ser atribuídas a um container, e que são normalmente utilizadas:

CAP_SETPCAP Modifica capacidades de um processo
CAP_SYS_MODULE Insere ou remove módulos do kernel
CAP_SYS_RAWIO Modifica memória do Kernel
CAP_SYS_PACCT Configura quota de processo
CAP_SYS_NICE Modifica prioridade do processo
CAP_SYS_RESOURCE Sobrescreve os limites de recursos
CAP_SYS_TIME Modifica a hora de sistema
CAP_SYS_TTY_CONFIG Configura interface tty
CAP_AUDIT_WRITE Escreve logs de auditoria
CAP_AUDIT_CONTROL Configura auditoria dos subsistema
CAP_MAC_OVERRIDE Ignora politicas de MC do Kernel
CAP_MAC_ADMIN Configuração de MAC
CAP_SYSLOG Modifica o comportamento de logs
CAP_NET_ADMIN Configura funções de rede
CAP_SYS_ADMIN Possibilita execução totalmente privilegiada.

Agora, para habilitar alguma capacidade (ou CAP) no Docker, pode ser utilizado o parâmetro: –cap-add=NOMEDACAP, algo parecido com isso:

docker run --cap-add=NOMEDACAP -i -t --rm centos /bin/bash

Para remover alguma CAP basta adicionar o parâmetro –drop-cap, ficaria assim:

docker run --cap-add=ALL --cap-drop=NET_ADMIN -i -t --rm centos /bin/bash

Seguindo os parâmetros acima, todas as CAPs serão habilitadas para este container, menos a CAP NET_ADMIN, com isso todas as demais operações serão permitidas ao container, menos as operações de rede, como modificação de ip, configurações de rotas, etc.

Por hoje era isso, fiquem atentos para as novidades!

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 e Git parte 2

Olá pessoal, hoje estarei dando continuidade ao vídeo “Utilizando Git com Docker parte I” onde mostrei como poderíamos interagir com o Docker e Git. Nessa segunda parte vou mostrar como podemos criar uma imagem com o Git e Apache para fazermos deploy da nossa aplicação de uma forma rápida e fácil.

 

 

 

Bem legal né? Fique por dentro das novidades do Blog e nos ajude divulgando o mundodocker.com.br. Abraço!

Primeiros passos com Docker – Instalação

Olá pessoal,

Hoje vamos ver como damos o pontapé inicial com Docker, vamos começar com a instalação e depois algumas informações básicas sobre alguns comandos.

Usuários que tem o seu sistema baseado em Debian podem usar o apt-get ou o aptitude:

sudo apt-get update
sudo apt-get install docker.io

Usuários que tem o seu sistema baseado em RedHat podem usar o yum:

yum install docker

A versão de Docker que estou utilizando é a versão 1.6.2 que é a versão mais nova até hoje. Na instalação default de ambiente de Docker as configurações principais de seus contêineres ficam em /var/lib/docker aqui você pode encontrar o .json de todos os seus containers com suas respectivas configurações, em nossos próximos posts estaremos mostrando o que significa cada parâmetro e como podemos melhorar a performance de nosso ambiente. Agora vou mostrar para vocês os comandos que temos no Docker:

docker attach  – Acessar dentro do container e trabalhar a partir dele.
docker build   – A partir de instruções de um arquivo Dockerfile eu possa criar uma imagem.
docker commit  – Cria uma imagem a partir de um container.
docker cp      – Copia arquivos ou diretórios do container para o host.
docker create  – Cria um novo container.
docker diff    – Exibe as alterações feitas no filesystem do container.
docker events  – Exibe os eventos do container em tempo real.
docker exec    – Executa uma instrução dentro do container que está rodando sem precisar atachar nele.
docker export  – Exporta um container para um arquivo .tar.
docker history – Exibe o histórico de comandos que foram executados dentro do container.
docker images  – Lista as imagens disponíveis no host.
docker import  – Importa uma imagem .tar para o host.
docker info    – Exibe as informações sobre o host.
docker inspect – Exibe r o json com todas as configurações do container.
docker kill    – Da Poweroff no container.
docker load    – Carrega a imagem de um arquivo .tar.
docker login   – Registra ou faz o login em um servidor de registry.
docker logout  – Faz o logout de um servidor de registry.
docker logs    – Exibe os logs de um container.
docker port    – Abre uma porta do host e do container.
docker pause   – Pausa o container.
docker ps      – Lista todos os containers.
docker pull    – Faz o pull de uma imagem a partir de um servidor de registry.
docker push    – Faz o push de uma imagem a partir de um servidor de registry.
docker rename  – Renomeia um container existente.
docker restart – Restarta um container que está rodando ou parado.
docker rm      – Remove um ou mais containeres.
docker rmi     – Remove uma ou mais imagens.
docker run     – Executa um comando em um novo container.
docker save    – Salva a imagem em um arquivo .tar.
docker search  – Procura por uma imagem no Docker Hub.
docker start   – Inicia um container que esteja parado.
docker stats   – Exibe informações de uso de CPU, memória e rede.
docker stop    – Para um container que esteja rodando.
docker tag        – Coloca tag em uma imagem para o repositorio.
docker top        – Exibe os processos rodando em um container.
docker unpause – Inicia um container que está em pause.
docker version – Exibe as versões de API, Client e Server do host.
docker wait   – Aguarda o retorno da execução de um container para iniciar esse container.

Esses são todos os comandos que possuímos na versão 1.6.2 do Docker. Nos próximos posts estaremos mostrando como utilizar todos esses comandos e em qual momento devemos escolher entre um e outro.

Ficou com dúvida? Gostaria de saber mais? Algum feedback a nos dar? Deixe sua mensagem e vamos conversando.

Abraço!

MundoDocker – Eventos

Oi Pessoal,

Hoje o post é rápido, apenas para trazer a vocês nossa experiência no TcheLinux Caxias do Sul. Para quem nos acompanha nas rede sociais, ficou sabendo que iriamos participar de mais um edição do TcheLinux (um dos maiores eventos de tecnologia open source do Rio Grande do Sul), dessa vez em Caxias do Sul, na serra gaúcha.
O evento estava muito bem organizado, e o lugar não poderia ser melhor, com infraestrutura suficiente para atender os participantes, sem falar na localização. Com a ajuda de alguns amigos, conseguimos alguns registro fotográficos do evento, veja:

A nossa contribuição ao evento foi com uma palestra: Escalonando o mundo com Kubernetes, como o Google sobrevive. Essa apresentação teve como objetivo mostrar aos presentes como o Kubernetes funciona, como ele é utilizado dentro do Google e como você utiliza ele sem nem saber . Compartilhamos a apresentação em nosso Slideshare, para você, que não estava no evento, possa ver um pouco sobre o que levamos ao evento:

http://slideshare.net/MundoDocker/escalonando-o-mundo-com-kubernetes

Gostaríamos de agradecer ao TcheLinux pela oportunidade e a Ftec que disponibilizou o local para o evento. Por hoje era isso, grande abraço! Ahhh e nos ajude divulgando o blog

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!

 

SwarmKit

Oi Pessoal,

Hoje, você não pode pensar em utilizar Docker em produção em larga escala sem ter alguma forma de automação e orquestração dessa “coisa”, graças a comunidade e algumas empresas, temos ferramentas que podem nos auxiliar nessas tarefas, todas juntas ou em partes, é claro. Atualmente as ferramentas mais conhecidas para orquestração e scale em Docker são Kubernetes e Mesos, existem muitos projetos mantidos pela comunidade nesse sentido, mas nenhum deles com tanta representatividade quanto aos mencionados anteriormente. Para não ficar de fora desse mundo, a Docker vem trabalhando bastante em uma suite que atenda essa necessidade, e que futuramente seja incorporado ao Docker Data Center, o projeto chama-se Swarmkit, e hoje, aqui no MundoDocker, vamos ver um pouco mais sobre ele.

O Que é?

O Swarmkit é uma suite para escalonamento e orquestração para sistemas distribuídos, ele possui um sistema de descoberta de nós, agendamento de tarefas, e utiliza o raft-based consensus para coordenação do cluster.

O que tem de bom?

  • Como já mencionado, ele utiliza o raft-based consensus, isso garante uma melhor coordenação do cluster, eliminando assim o ponto único de falha.
  • Todo os nós do cluster Swarm conversam de forma segura, e para ajudar nisso o Swarmkit utiliza TLS para autenticação, autorização e transporte dos dados entre os nós.
  • Swarmkit foi projeto para ser simples, por isso ele é independente de base de dados externas, ou seja, tudo que você precisa para utiliza-lo já está nele.

Ele é composto basicamente de duas camadas: Worker e Manager nodes, para entender cada um:

Worker: Responsável por executar as tarefas utilizar um Executor, por padrão o Swarmkit vem com o Docker Container Executor, mas que pode ser trocado caso deseja.

Manager: Basicamente é o nó eleito pelo administrador para ser o ponto central de administração, lembrando que quanto você adiciona um nó no cluster de Swarm você define se esse nó será Manager ou não.

Como outras ferramentas, para o Swarmkit as tarefas são organizadas em serviços, e para esse serviço você define o que deseja fazer, por exemplo: Crie replicas desse serviço todo dia as 10h, ou: Atualize um container por vez baseado nessa nova imagem.

Features

  • Oquestração
  1. Estado desejado: O Swarmkit analise constantemente o cluster, garantindo que todos os serviços estejam de acordo com o pretendido pelo usuário, isso faz com que um serviço seja provisionado em outro nó caso algum falhe.
  2. Tipo de serviço: atualmente o Swarmkit suporta apenas 2 tipos: 1 – Replicas, onde você define quantas cópias daquele container deseja, e 2 – Global, onde você especifica o que deve ser executado em cada nó do cluster.
  3. Atualização: Você pode modificar a qualquer momento o estado de um serviço, seja para para-lo ou escala-lo, quando você atualiza um serviço, por padrão ele executa essa tarefa de atualização de uma vez só para todos os nós do cluster, mas você pode definir de outras duas formas essa atualização: 1 – Paralela, onde o administrador define quantas tarefas de atualização podem ser executadas por mês ou 2 – Delay, dessa forma o Swarmkit executará as tarefas de atualização de serviço de forma sequencial, ou seja, uma tarefa só será executada caso a anterior já tenha terminado.
  4. Politicas de restart: A camada de orquestração monitora o estado das tarefas e reage as falhas aplicando a regra definida pelo usuário, dentro dessas regras o administrador pode definir número máximo de tentativos de restart de um serviço, quanto tempo depois de uma falha esse serviço deve ser reiniciado, etc. Por padrão o Swarmkit reinicia o serviço dentro de outro nó disponível no cluster, isso garante que os serviços dos nós defeituosos sejam iniciados em outros nós o mais rápido possível.
  • Agendamento
  1. Recursos: O Swarmkit sabe, através das checagens constantes, como está a saúde de cada nó, com isso, quando um serviço precisa ser reiniciado ou realocado, por padrão essa tarefa será realizada no melhor nó do cluster;
  2. Restrições: O administrador pode limitar o reinicio de um serviço em determinados nós, isso pode ser feito através de labels, exemplo: node.labels.foo!=bar1
  • Gerenciamento de cluster
  1. State Store: Permite ter uma visão macro de todo o cluster, como suas informações ficam em memória, permite ao nó de gerenciamento tomar decisões de forma muito mais rápida e segura.
  2. Gerenciamento da topologia: O administrador pode alternar quais são os nós de gerenciamento e qual são os Workers através de chamadas de API ou CLI.
  3. Gerenciamento de nós: É possível definir um nó como pausado, por exemplo, com isso os serviços que estavam alocados neste nó serão iniciados nos demais nós, assim como a execução de novas tarefas permanece bloqueada.
  • Segurança
  1. TLS: Todos os nós se conversam através de TLS, e os nós de gerenciamento agem como autoridade certificadora de todos os demais nós, e são responsáveis pela emissão de certificados para os nós que entram no cluster.
  2. Politica de aceitação: O administrador pode aplicar regras de auto-aceitação, aceitação manual ou troca de chaves, isso claro na adição de novos nós ao cluster, por default o Swarmkit utiliza auto-aceitação.
  3. Troca de certificados: É possível definir a frequência com a qual serão alterados os certificados ssl utilizados para comunicação do cluster, por padrão o tempo é de 3 meses, mas pode-ser definir qualquer período maior que 30 minutos.

Vamos brincar?

Instalando

O Swarmkit foi desenvolvido em GO, então tenha todo o ambiente pré-configurado e claro, baixe os fontes para seu $GOPATH, você pode utilizar:

[root@docker1 ~]# go get github.com/docker/swarmkit/

Acesse o diretório, e execute:

[root@docker1 ~]# make binaries

Isso fará com que sejam instaladas as ferramentas para utilização do Swarmkit, em seguida você pode testar sua instalação:

[root@docker1 ~]# make setup
[root@docker1 ~]# make all

Agora adicione o swarmd e swarmctl ao seu $PATH e seja feliz utilizando ele, veja abaixo alguns exemplos.

Montando o Cluster

No primeiro nó, execute:

[root@docker1 ~]# swarmd -d /tmp/docker1 --listen-control-api /tmp/manager1/swarm.sock --hostname docker1

Nos demais nós, execute:

[root@docker2 ~]# swarmd -d /tmp/node-2 --hostname docker2 --join-addr 10.1.1.1:4242
[root@docker3 ~]# swarmd -d /tmp/node-3 --hostname docker3 --join-addr 10.1.1.1:4242

Você pode agora, utilizar outro host para administrar o cluster, no nosso exemplo utilizando o docker4, veja:

[root@docker4 ~]# export SWARM_SOCKET=/tmp/manager1/swarm.sock
[root@docker4 ~]# swarmctl node ls
ID             Name    Membership  Status  Availability  Manager status
--             ----    ----------  ------  ------------  --------------
6rj5b1zx4makm  docker1  ACCEPTED    READY   ACTIVE        REACHABLE *
91c04eb0s86k8  docker2  ACCEPTED    READY   ACTIVE        
nf6xx9hpf3s39  docker3  ACCEPTED    READY   ACTIVE        

Criando os serviços

Vamos começar devagar, veja como subir um ambiente em redis:

[root@docker4 ~]# swarmctl service create --name redis --image redis:3.0.5
6umyydpxwtzfs3ksgz0e

Listando os serviços:

[root@docker4 ~]# swarmctl service ls
ID                         Name   Image        Replicas
--                         ----   -----        ---------
6umyydpxwtzfs3ksgz0e      redis  redis:3.0.5  1

Inspecionando o serviço:

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicass         : 1
Template
 Container
  Image           : redis:3.0.5

Task ID                      Service    Instance    Image          Desired State    Last State               Node
-------                      -------    --------    -----          -------------    ----------               ----
6umyydpxwtzfs3ksgz0e         redis      1           redis:3.0.5    RUNNING          RUNNING Up About an hour    docker1

Atualizando serviço:

Conforme mencionado anteriormente, podemos atualizar o status de um serviço, no nosso exemplo vamos aumentar o número de replicas dele, veja:

[root@docker4 ~]# swarmctl service update redis --replicas 6
6umyydpxwtzfs3ksgz0e

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicas          : 6
Template
 Container
  Image           : redis:3.0.5

Task ID                      Service    Instance    Image          Desired State    Last State               Node
-------                      -------    --------    -----          -------------    ----------               ----
xaoyxbuwe13gsx9vbq4f         redis      1           redis:3.0.5    RUNNING          RUNNING Up About an hour     docker1
y8cu8nvl1ggh4sl0xxs4         redis      2           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker2
ksv9qbqc9wthkrfz0jak         redis      3           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker2
nnm9deh7t0op6rln3fwf         redis      4           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker1
4ya5eujwsuc6cr7xlnff         redis      5           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker3
9o4pmrz6q6pf9ufm59mk         redis      6           redis:3.0.5    RUNNING          RUNNING 10 seconds ago    docker3

Vamos atualizar a imagem do serviço?

[root@docker4 ~]# swarmctl service update redis --image redis:3.0.6
6umyydpxwtzfs3ksgz0e

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicas          : 6
Template
 Container
  Image           : redis:3.0.6

Task ID                      Service    Instance    Image          Desired State    Last State                Node
-------                      -------    --------    -----          -------------    ----------                ----
xaoyxbuwe13gsx9vbq4f         redis      1           redis:3.0.6    RUNNING          RUNNING 5 seconds ago    docker3
y8cu8nvl1ggh4sl0xxs4         redis      2           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker1
ksv9qbqc9wthkrfz0jak         redis      3           redis:3.0.6    RUNNING          RUNNING 5 seconds ago    docker2
nnm9deh7t0op6rln3fwf         redis      4           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker1
4ya5eujwsuc6cr7xlnff         redis      5           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker2
9o4pmrz6q6pf9ufm59mk         redis      6           redis:3.0.6    RUNNING          RUNNING 6 seconds ago    docker3

Por padrão todos os containers foram atualizados de uma única vez, isso tem suas vantagens e desvantagens, mas como explicado, você pode mudar essa execução para fazer em partes, veja:

[root@docker4 ~]# swarmctl service update redis --image redis:3.0.7 --update-parallelism 3 --update-delay 20s

Com isso, serão refeitos 3 containers por vez e entre eles terá um intervalo de 20 segundos.

Gerenciando nós

O Swarmkit monitora a saúde de cluster, e baseado nisso toma ações em cima dos serviços, você pode realizar ações manuais também, como por exemplo, retirar um nós do cluster, veja:

[root@docker4 ~]# swarmctl node drain docker1

[root@docker4 ~]# swarmctl node ls
ID             Name    Membership  Status  Availability  Manager status
--             ----    ----------  ------  ------------  --------------
6rj5b1zx4makm  docker1  ACCEPTED    READY   DRAIN         REACHABLE
91c04eb0s86k8  docker2  ACCEPTED    READY   ACTIVE        REACHABLE *
nf6xx9hpf3s39  docker3  ACCEPTED    READY   ACTIVE        REACHABLE

[root@docker4 ~]# swarmctl service inspect redis
ID                : 6umyydpxwtzfs3ksgz0e
Name              : redis
Replicas          : 6
Template
 Container
  Image           : redis:3.0.7

Task ID                      Service    Instance    Image          Desired State    Last State               Node
-------                      -------    --------    -----          -------------    ----------               ----
xaoyxbuwe13gsx9vbq4f         redis      1           redis:3.0.7    RUNNING          RUNNING 2 minute ago     docker2
y8cu8nvl1ggh4sl0xxs4         redis      2           redis:3.0.7    RUNNING          RUNNING 2 minute ago     docker3
ksv9qbqc9wthkrfz0jak         redis      3           redis:3.0.7    RUNNING          RUNNING 30 seconds ago    docker2
nnm9deh7t0op6rln3fwf         redis      4           redis:3.0.7    RUNNING          RUNNING 34 seconds ago    docker3
4ya5eujwsuc6cr7xlnff         redis      5           redis:3.0.7    RUNNING          RUNNING 28 minutes ago    docker2
9o4pmrz6q6pf9ufm59mk         redis      6           redis:3.0.7    RUNNING          RUNNING 29 seconds ago    docker3

O Swarmkit é uma ferramenta em desenvolvimento ainda, mas você pode utilizar ela em seus labs e entender um pouco melhor como pode trabalhar em cluster com Docker. Espero que tenham gostado, e nos ajude divulgando o blog

Abraço!

Criando uma imagem

Olá pessoal,

Anteriormente vimos o que era uma imagem e o que era um Dockerfile, agora vamos descobrir como criar uma imagem a partir da interação com um container. Vamos trabalhar da seguinte maneira:

Vamos criar uma imagem com apache com interação com o container.

Vamos começar criando o container com docker run -it centos /bin/bash agora que estamos dentro dele, vamos executar os seguintes comandos:

yum install wget -y
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
rpm -ivh epel-release-7-5.noarch.rpm

yum install httpd -y,

Instalamos o apache dentro do container, mas quando iniciarmos o container novamente, o serviço do apache não irá iniciar, pois o container não possui os serviços de inicialização então vamos usar um serviço chamado Supervisord que faz com que sempre que eu reiniciar o container eu possa já iniciar alguns serviços.

sudo yum install python-setuptools
sudo easy_install pip
sudo pip install supervisor
echo_supervisord_conf > supervisord.conf
sudo cp supervisord.conf /etc/supervisord.conf
sudo mkdir /etc/supervisord.d/
sudo vi /etc/supervisord.conf

Com o arquivo de configurações do supervisord aberto vamos alterar e adicionar algumas linhas:

Altere a linha que tenha

[include]
files =
[include]
files = /etc/supervisord.d/*.conf

Agora vamos criar o arquivo: vi /etc/rc.d/init.d/supervisord

Coloque esse código dentro do arquivo:

#!/bin/sh
#
# /etc/rc.d/init.d/supervisord
#
# Supervisor is a client/server system that
# allows its users to monitor and control a
# number of processes on UNIX-like operating
# systems.
#
# chkconfig: - 64 36
# description: Supervisor Server
# processname: supervisord

# Source init functions
. /etc/rc.d/init.d/functions

prog="supervisord"

prefix="/usr/"
exec_prefix="$"
prog_bin="${exec_prefix}/bin/supervisord"
PIDFILE="/var/run/$prog.pid"

start()
{
       echo -n $"Starting $prog: "
       daemon $prog_bin --pidfile $PIDFILE
       [ -f $PIDFILE ] && success $"$prog startup" || failure $"$prog startup"
       echo
}

stop()
{
       echo -n $"Shutting down $prog: "
       [ -f $PIDFILE ] && killproc $prog || success $"$prog shutdown"
       echo
}

case "$1" in

 start)
   start
 ;;

 stop)
   stop
 ;;

 status)
       status $prog
 ;;

 restart)
   stop
   start
 ;;

 *)
   echo "Usage: $0 {start|stop|restart|status}"
 ;;

esac
sudo chmod +x /etc/rc.d/init.d/supervisord
sudo chkconfig --add supervisord
sudo chkconfig supervisord on
supervisord

Agora já podemos adicionar nosso serviço até o supervisord. Abra novamente o arquivo: /etc/supervisord.conf
Adicione ao final do arquivo as seguintes linhas.

[program:httpd]
command=/usr/sbin/httpd -D FOREGROUND -k start
environment=APACHE_LOG_DIR=/var/log/httpd
redirect_stderr=true

Após isso vamos executar supervisorctl update e supervisorctl você poderá ver que foi adicionado o serviço httpd ao supervisord.
Vamos criar o arquivo vi /run.sh e dentro dele colocar as linhas seguintes:

#!/bin/bash
supervisord &
sleep 2

/bin/bash

chmod +x /run.sh

Agora vamos criar a imagem, pressione CTRL + P + Q . Agora estamos no console do Host, para criar a imagem vamos executar docker commit id_container nome_imagem. Agora é só colocar docker run -it nome_imagem /run.sh e você estará iniciando seu Servidor Web.

Obrigado pessoal, por hoje é isso.

Kubernetes – Iniciando com Pods

Olá pessoal,

Hoje quero fugir um pouco do tema “Docker” e quero mostrar para vocês um pouco mais de “Kubernetes”. Em dois posts anteriores mostrei como era complicada a instalação e configuração do Kubernetes caso não quizesse usar AWS ou Google Cloud. Com a comunidade sempre mostrando o quanto a instalação do Kubernetes era sempre trabalhosa, a partir da versão 1.4 foi criado o utilitario “kubeadm” que é utilizado para realizar a instalação de um cluster de Kubernetes de maneira rápida e fácil possibilitando assim uma maneira fácil de instalação e assim aderiando mais pessoas utilizando a ferramenta.

 

Passo 1 – Vamos iniciar agora a instalação do Kubernetes em alguns passos simples e depois vamos realizar algumas operações básicas para que você possa conhecer mais sobre essa ferramenta tão poderosa.

apt-get update && apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat < /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

 
apt-get update
# Install docker if you don't have it already.
apt-get install -y docker.io
apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Passo 2 – Parecido com a sintaxe do comando para iniciar um cluster com o “docker swarm” com o comando abaixo vamos estar iniciando o cluster com Kubernetes. Caso tenha 2 placas de redes em seu servidor você poderá especificar qual deseja utilizar com --api-advertise-addresses <ip-address> passando como parâmetro para o comando kubeadm init

Na saída do comando será possível visualizar, no final a instrução para você adicionar um outro nó ao seu cluster, para isso basta você repetir o passo 1 em seu outro nó e colar a saída do comando acima onde mostra:

kubeadm join --token=<token> <master-ip>

Após realizar os passos acima você estará com seu cluster de kubernetes quase pronto, porém ainda para que você possa fazer funcionar o seu cluster perfeitamente, você ainda precisa que seja instalado um plugin de rede para que o cluster de Kubernetes esteja a funcionar 100% para isso basta você executar:

kubectl apply -f https://git.io/weave-kube

Nesse caso o plugin escolhido foi o do Weave. Agora pronto estamos com nosso cluster de Kubernetes no ar e podemos começar a realizar as operações básicas em um cluster. Para isso vamos iniciar trabalhando com Pods.

Se você não sabe ainda os principais componentes do Docker, então você pode acompanhar um outro post nosso que fala sobre isso aqui. Então vamos por a mão na massa:

Com o comando kubectl é possivel fazer todas as operações que precisamos que sejam feitas em caso de lidarmos com containers. Então para listarmos os Pods que temos criados podemos executar o comando:

kubectl get pods 

Isso irá trazer os pods que foram criados no Namespace default. Namespaces são clusters virtuais dentro de um cluster físico, então eu posso ter dezenas de Namespaces em 1 cluster de kubernetes e em cada Namespace ter diversos Pods nos quais possuem total isolamento entre eles. Com namespace então eu posso limitar recursos como: CPU, Memória, Disco e Rede. Para que eu liste todos os Pods criados em todos os namespaces basta eu executar:

kubectl get pods --all-namespaces 

Para criar um Pod com uma imagem do Node.Js por exemplo você utiliza:

kubectl run --image=ghost --port=2368

Estou utilizando a porta 2368, pois é a que está com o EXPOSE no Dockerfile. Também é possivel criar 1 Pod com n container no caso você deve utilizar o parâmetro --replicas

kubectl run node --image=ghost --replicas=5 --port=2368

Nesse caso será criado os cinco containers no Docker porém apenas 1 Pod estará visivel no Kubernetes. Agora para que possamos acessar a nossa aplicação através do Browser devemos expor a porta 2368 para alguma porta do Host, o mesmo conceito do Docker, porém sintaticamente de uma forma diferente. Para isso utilizamos o comando:

kubectl expose deployment node --target-port=2368 --type=LoadBalancer

Com o comando acima estamos dizendo para o Kubernetes pegar alguma porta livre no host e redirecionar o tráfego para a porta 2368 dentro do container e que o tipo de envio seja um LoadBalancer entre as replicas que eu mandei criar, então no caso das 5 réplicas que foram criadas acima, cada requisição será enviada para uma replica diferente da outra.


Mais para frente entraremos mais a fundo no Kubernetes, mas agora quando executamos o comando kubectl expose o Kubernetes criou um service de forma abstrata, podemos agora de forma resumida dizer que um service tem o papel de Habilitar um endpoint para que o usuário consiga acessar a aplicação". Então se você executar o comando:

kubectl get services

Você irá ver algo parecido com isso:


NAME         CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
node         10.100.162.143        2368:31529/TCP   10s

Então a porta para que possamos acessar nossa aplicação será a porta 31529


Conforme criamos os primeiros posts sobre como criar containers, imagens e coisas mais simples com Docker, começaremos a fazer também com o Kubernetes, então vamos evoluir cada vez mais o conteúdo para que possa ser útil tanto para as pessoas que estão pensando em começar a usar, como também as que estão usando a um certo tempo.


Obrigado e fique ligado, pois em breve estaremos lançando novidades para os nossos leitores que estão se cadastrando em nossas Newsletter.

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 no Windows Server 2016

Olá Pessoal!

A Microsoft acaba de lançar o Windows Server 2016 Preview, que trará consigo o Docker Engine nativo, isso mesmo, a mesma engine utilizada dentro de distribuições Linux estará disponível no Windows Server. Quais benefícios isso trás?

 Flexibilização da infraestrutura, da mesma forma que no Linux, não será necessário instanciar uma VM ou máquina física para realizar deploy de uma aplicação.

Mais ferramentas para desenvolvedores, já existe um plugin para o Visual Studio, onde você poderá desenvolver sua aplicação e publica-la automaticamente dentro de um container, deu build foi pro ar!

Claro, isso não foi um trabalho fácil, houve um grande esforço por parte da Microsoft para que fosse possível integrar o Docker Engine ao Kernel do Windows e mesmo assim há algumas limitações, como por exemplo:  Não será possível, pelo menos não na versão preview, o uso de container Linux dentro Windows Server 2016, isso claro por motivos óbvios, pois o Kernel do host é bastante diferente do Kernel do container. Claro para testes ele pode ser utilizado sem problema.

OK, mas como ficou a arquitetura?

Bem parecido com o Docker no Linux, a Microsoft adicionou ao Kernel do Windows alguns recursos que possibilitam criar um ambiente isolado a nível de userspace, e uso limitado de recursos, na imagem abaixo podemos ter uma ideia de como ficou:

windows_docker

Fiquem atentos, nos próximos posts vamos colocar na prática o Docker no Windows Server 2016, continuem nos acompanhando aqui no blog, facebook ou nosso canal no youtube.

Referência:

Introducing the Technical Preview of Docker Engine for Windows Server 2016

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/

Prometheus e Docker

Fala pessoal, hoje vamos entrar em uma série de posts referentes a métricas, para quem está ligado no mundo da tecnologia, vem se falando há bastante tempo sobre SRE [ Ebook do Google ] (https://landing.google.com/sre/) um dos principais temas falado pelo pessoal do Google é em questões de métricas, pois são as métricas que nos fornecem uma visão geral referente a como está o nosso ambiente e nos proporciona a capacidade cada vez maior nossas equipes serem orientadas a dados: Data driven

Prometheus

Prometheus é um Kit de ferramentas de Monitoramento e Alertas Open Source que foi criada pela SoundCloud . Muitas empresas estão adotando o Prometheus para trabalhar com a questão de métricas de seus sistemas e aplicações. Em 2016 o Prometheus foi incorporado dentro da Cloud Native Computing Foundation sendo o segundo projeto hospedado após o Kubernetes.

Componentes

 Prometheus

Iniciando

Vamos monitorar o nosso servidor de Docker com o Prometheus, para isso vamos editar o arquivo daemon.json que já é criado por padrão em:

  • Linux /etc/docker/daemon.json
  • Windows C:ProgramDatadockerconfigdaemon.json

Dentro desse arquivo vamos adicionar as seguintes linhas:

{
    "metrics-addr" : "127.0.0.1:9000"
    "experimental" : true
}


Após a criação desse arquivo, ou edição dele, vamos precisar criar o arquivo de configuração do nosso Prometheus, para isso vamos criar o arquivo config.yml

global:
    scrape_interval: 15s
    evaluation_interval: 15s

  external_labels:
    monitor: 'codelab-monitor'

scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'docker'
         # metrics_path defaults to '/metrics'
         # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9323']


Com o conf criado vamos criar o serviço para começar a armazenar as métricas, para isso vamos executar:

docker service create --replicas 1 --name my-prometheus 
    --mount type=bind,source=/tmp/prometheus.yml,destination=/etc/prometheus/prometheus.yml 
    --publish published=9090,target=9090,protocol=tcp 
    prom/prometheus


  • –replicas=1 # Quantos containers de prometheus vamos ter
  • –mount # type = Tipo de mapeamento que iramos fazer, source = Caminho de origem para o arquivo de configuração, destination = Caminho de destino no container
  • –publish # publish = A porta que será exposta para o mundo, target = A porta que a gente configurou no config do prometheus, protocol = protocolo utilizado
  • prom/promtheus # Imagem utilizada.

Após isso basta abrir o seu browser e navegar até http://iphost:9090 e você terá acesso ao seu prometheus. Você pode ir até http://iphost:9000/targets/ onde você poderá ver as informações que configramos e verificar se está tudo ok com as coletas de nossas métricas.

Como podemos notar é meio complexo conseguirmos ver as informações referente ao nosso ambiente diretamente pelo Prometheus, então para facilitar esssa visão, vamos utilizar o Grafana como Dashboard, ja falamos dele em um post anterior: Grafana + Influx + Cadvisor

Para criar o container do Grafana vamos executar:

docker run -d --name=grafana -p 3000:3000 grafana/grafana

Passo 1 – Autenticação

feito isso vamos acessar http://localhost:3000 após o acesso será solicitado um username e password, por padrão o inicial é admin e admin, em seguida será solicitado um novo password, então basta colocar o seu novo password.

Passo 2 – Criação do Data Source

Agora vamos adicionar o nosso prometheus como Data Source, para que sejá possível realizarmos as consultas para preencher os nossos gráficos, para isso vamos clicar no icone conforme a imagem abaixo:

E vamos escolher a opção Data Source

Agora vamos ir até Add Data Source, onde vamos ter alguns campos que são padrões e outros que devem aparecer conforme o tipo de Data Source que será escolhido, nesse caso vamos utilizar o Prometheus.

  • url: http://localhost:9090
  • Access: Browser

Dessa vez vamos criar sem autenticação, então pode deixar as questões de AUTH em branco.

  • Marcar a opção: Skip TLS Verification (Insecure)

Após isso é só clicar em Save & Test.

Passo 3 – Criação dos Dashboards

Vá até a opção de New Dashboard dentro do Grafana e escolha a opção de “Graph”

Agora vamos editar o nosso Dashboard:

Agora a imaginação é sua, basta verificar no Prometheus quais os dados que você possui para poder fazer seus Dashboards.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!

Kubernetes – ConfigMap

Fala pessoal, estamos aqui novamente para continuar nossa série que fala sobre Kubernetes. Abaixo coloquei a lista de posts criados até o momento referente a Kubernetes, então se não tinha visto o ínicio é só clicar abaixo e ler cada um dos posts.

Conceitos de Kubernetes

Instalação e Configuração

Iniciando um servidor web

Entendendo Pods

Entendendo Services

Entendendo Namespaces

 

Então, o que é ConfigMap? É o desacoplamento dos artefatos de configuração do conteúdo da imagem para manter os aplicativos contidos em container. De forma simples podemos dizer que ConfigMap é um conjunto de pares de chave-valor para armazenamento de configurações, que ficará armazenado dentro de arquivos  que podem ser consumidos através de Pods ou Controllers,. Ele é muito parecido com Secrets, mas fornece um modo de se trabalhar com strings que não possuem dados confidências, como senhas, Chaves, Tokens e outros dados sigilosos.

Os arquivos de ConfigMap, podem ser tanto arquivos complexos que possuem poucas regras, como também arquivos no formato JSON complexos e cheio de regras. Podemos ver alguns exemplos abaixo de ConfigMaps tanto simples quanto complexos:
Podemos ver aqui um exemplo de criação de um ConfigMap através do client do Kubernetes “kubectl”

kubectl create configmap site --from-literal='url=mundodocker.com.br' Podemos ver 

Podemos ver aqui um outro exemplo que é um arquivo de configuração que a partir dele também podemos criar o nosso ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: mundodocker
  labels:
    name: mundodocker
  namespace: test
data:
  config: |-
    ---
    :url: mundodocker.com.br

Como foi visto acima existe 2 formas nas quais podemos criar o nosso ConfigMap, mas ahhh Bicca, como integramos isso com nosso Pod? Existem algumas formas para isso a primeira é que você pode colocar isso dentro do arquivo de criação do Pod, como mostro abaixo:


apiVersion: v1
kind: Pod
metadata:
  name: mundodocker
spec:
  containers:      
  - image: gcr.io/google_containers/busybox      
    name: container
    volumeMounts:
    - name: configmap
      mountPath: "/tmp"
  volumes:
  - name: configmap
    condigMap:
      name: site

 

Essa seria a forma de criação de um Pod com ConfigMap habilitado por exemplo, esses são exemplos simples de arquivos que mostram como funciona o uso de ConfigMaps.

ALGUMAS DICAS:

  • Lembre-se que para que seja possível criar o seu Pod com ConfigMap, você precisa primeiro criar o ConfigMap ou coloca-lo como opcional, pois caso contrario o Pod não irá ser iniciado por causa que o ConfigMap ainda não foi criado.
  • ConfigMap estão dentro de Namespaces, então apenas Pods do mesmo Namespace podem acessa-los
  • Podem ser consumidos de 3 formas: Argumentos, Variaveis de ambiente e Arquivos em volumes. Essa quantidade de modos faz com que ConfigMap se enquadre em grandes partes das aplicações.

 

Pessoal, vamos continuar criando posts para explicar alguns componentes do Kubernetes e em breve vamos colocar mais conteúdos para demonstrar como é possível utilizar Kubernetes em produção com exemplos de uso no dia-a-dia, fique ligado que em breve estaremos com muitas novidades em nosso site e também.

Docker e Project Atomic

Olá pessoal,

Com o passar dos anos as tecnologias vem evoluindo cada vez mais rápido, surgem novos conceitos porém muitos morrem e poucos acabam se tornando tendência. No passado muito se falou sobre “Máquinas Virtuais” muitas empresas apareceram no mercado de virtualização porém apenas algumas se destacaram que é o caso de Microsoft, VMWare e Oracle.

Agora chega a hora da tendência de containers (Sim, LXC existe há um grande tempo já) que cada vez mais vem se popularizando e com isso surgem diversas empresas no mercado oferecendo integrações, plataformas, contentores e entre outros produtos. Com essa gama de ofertas decidi realizar uma série mostrando as empresas que acreditamos que serão as grandes donas do mercado de containers nos próximos anos.

O ProjectAtomic: É um sistema operacional desenvolvido pela RedHat, foi projetado para a execução de aplicações em containers docker. O Project Atomic depende de vários projetos de código aberto as várias distribuições Linux específicas. A comunidade Atomic vai trabalhar para o desenvolvimento do projeto atômico de forma inclusiva, contribuindo para os projetos upstream relacionados, resolvendo problemas de integração nas diversas distribuições sendo usado e desenvolver as ferramentas de gestão específicas necessárias para atualizações de gestão e de sistema. As principais ferramentas utilizadas foram:

– Docker – Implementação dos aplicativos

– Kubernetes – Orquestração

– rpm-ostree – Atualizações

– systemd – Gerencia de serviços

O Project Atomic possui uma ferramenta Web chamada Cockpit para realizar o gerenciamento de containers e hosts, com o Cockpit você pode:

– Visualizar os recursos utilizado pelos containers.

– Limitar recursos dos containers.

– Iniciar, parar, salvar e realizar o commit dos containers.

– Executar e excluir imagens.

– Administrar o host.

– Configurar serviços no host e outras funcionalidades.
cockpit-screenshot

Exemplo de imagem do Cockpit

Aqui possui o link para o download da imagem do sistema operacional http://projectatomic.io/download/

Por hoje era isso, espero que tenham gostado e tendo dúvidas nos avisem, e claro ajudem divulgando o https://mundodocker.com.br

Abraço!

AKS – Azure Kubernetes Service – Parte 1

Olá pessoal,

Para aqueles que nâo conseguiram realizar a implantaçâo do EKS (Elastic Kubernetes Service) que o Cristiano comentou no post anterior, pois a sua empresa está usando o Azure por exemplo,
hoje vamos falar a respeito do AKS (Azure Kubernetes Services) quem sabe você convence o seu chefe a pelo menos realizar uma POC? emmmm

Ahhh, mas antes você sabe o que é Kubernetes? Caso ainda não esteja familiarizado recomendo que leias os posts que fizemos sobre o assunto ? Segue os links:

Kubernetes Parte 1

Kubernetes Parte 2

Kubernetes Parte 3

AKS

O AKS é um serviço de Kubernetes gerenciado pelo Azure que abstrai a instalaçâo, configuraçâo e boa parte do gerenciamento de um cluster de Kubernetes. Quando você cria um AKS o mesmo já disponibiliza uma interface onde é possível ver o status atual de seu cluster, containers e ainda por cima nâo cobra valor algum pelos servidores Master do cluster, apenas pelos Workers.
Com toda essa facilidade não tem porque você criar uma estrutura de máquinas virtuais e depois realizar a instalação do Kubernetes, sendo que você irá precisar de pessoas para administrar ou automatizar essa instalação.

Prós:

  • Integração de RBAC simples com o Azure Active Diretory (É possível definir pessoas e grupos do AD que podem acessar diretamente o seu cluster de Kubernetes)
  • Integração com o Azure Disks (É só dizer qual tipo de disco seu Pod vai usar que automaticamente o disco é criado no Azure)
  • Azure CNI (Definir uma subnet especifica já criada e colocar IPs válidos nos Pods para realizar alguma integração com algum recurso do Azure)
  • Escalar automaticamente (Deixe configurado para aumentar a quantidade de nós quando chegar em x% de CPU)
  • Integração com Log Analytics (Enviar os logs dos containers diretamente para o Log Analytics e gerar Dashboards e alertas a partir dele)

Contras:

  • Caso queira fazer alguma configuração especifica nos Managers nâo é possível.
  • Não é possível mudar a engine de containers (Usam Docker).

Hands On

Partiu? vamos ver como é fácil realizar a instalaçâo e configuraçâo de um AKS?

Para isso existem duas maneiras, caso vocês utilizem Windows, é possível realizar a instalação do az-cli ou via Powershell realizar a instalação do módulo Powershell para o Azure. Para Linux deve ser feita a instalaçâo do az-cli

Windows

  • https://docs.microsoft.com/pt-br/cli/azure/install-azure-cli-windows?view=azure-cli-latest

Linux

  • Debian/Ubuntu
    • https://docs.microsoft.com/pt-br/cli/azure/install-azure-cli-apt?view=azure-cli-latest
  • RedHat/Centos
    • https://docs.microsoft.com/pt-br/cli/azure/install-azure-cli-yum?view=azure-cli-latest

Feito a instalação do az-cli, você deve realizar o login no azure para isso vamos executar:

az login

Após executar o comando irá aparecer na tela uma URL para você acessar e se autentica no portal do Azure, após realizar essa autenticação o az-cli estará pronto para uso.

Para realizar a criação do AKS vamos utilizar o comando az aks create esse comando possuí apenas 2 parâmetros obrigatórios são eles:

--name: Nome do cluster de AKS.
--resource-group: Grupo de recursos onde o cluster será criado.

Porém vamos utilizar outros parâmetros para ver o que mais a gente pode definir, então vamos utilizar mais os seguintes parâmetros:

--max-pods: Máximo de pods por worker.
--disable-rbac: Desabilita RBAC.
--node-count: Quantidade de Workers iniciais
--zones: Zona de disponibilidade do Azure
--nodepool-name: Nome do pool de máquinas para o AKS
--max-count: Quantidade máxima de Workers que podem ser criadas.

Para realizar a criação do cluster de AKS basta executar

az aks create --name aksmundodocker --resource-group resource_aks --max-pods 100 --disable-rbac --node-count 2 --zones 1 --nodepool-name aks --min-count 1  --max-count 3 --location eastus --enable-cluster-autoscaler

A criação deve demorar algo em torno de 7 minutos, após a criação do cluster basta você executar.

az aks get-credentials --name aksmundodocker --resource-group aks 

Com isso você já tem acesso ao seu cluster de AKS e pode começar a trabalhar nele. Para validar você pode executar o kubectl para testar a comunicação com o cluster:

kubectl get nodes

Eai, curtiu? Então manda para alguém que talvez tenha interesse, e claro, fique a vontade para conversamos ?
Grande Abraço!

Filesystem no Docker

Olá pessoal!

Para você que está começando a ler nossos posts agora, sugiro que leia antes esseesse link que explicam o que é o Docker e como ele funciona. Hoje nós abordaremos um dos assuntos mais importantes dentro do Docker: O Filesystem.

O sistema de arquivos do Docker é chamado de layered, ou seja, é um sistema de arquivo em camadas, o que isso quer dizer?

Um sistema de arquivo comum, possui basicamente duas camadas:

bootfs: Onde ficam o sistema de Boot do sistema e o Kernel.

rootfs: Inclui o sistema de arquivo do sistema, incluindo a arquitetura de diretório, em sistemas unix-like: /dev, /proc, /bin, /etc, /lib, /usr, e /tmp assim como os arquivos de configuração e binários do sistema.

Quando o sistema é iniciado ele carrega o rootfs primeiramente em modo somente leitura, verifica sua integridade e em seguida remonta-o como leitura/escrita e assim fica disponível para o usuário/aplicação.

No Docker temos essa arquitetura também, mas com um diferencial, a camada de escrita que o processo/aplicação visualiza não é o mesmo rootfs base, e sim uma camada de abstração do rootfs, isso é o que faz com que um container torne-se portável, pois as modificações realizadas não são aplicadas ao sistema origem do container, e sim na camada a qual o sistema visualiza.

Para ficar mais claro, veja na figura abaixo como é um sistema tradicional:

    docker-filesystems-generic1

 

Agora veja como é o filesystem no docker:

 

docker-filesystems-multiroot

 

 

Como podem notar o bootfs em vez de ser único por sistema/container, é compartilhado entre eles, mas o rootfs é isolado por camadas, ou seja, o que deve ser em comum entre o host e container é compartilhado via AUFS, que monta uma camada de leitura/escrita em cima do filesystem em somente leitura, isso garante que modificações feitas dentro do container não afetem o sistema de arquivos do host.

A imagem abaixo ilustra melhor como funciona essas camadas:

docker-filesystems-busyboxrw

Um detalhe nessa arquitetura é que a cada modificação e commit do container é gerada uma nova camada, ou seja, digamos que eu inicie um container a partir de uma imagem do Debian, e instale o serviço apache dentro desse container, quando eu for transformar esse container em uma imagem, essa imagem possuirá a primeira camada que é do sistema Debian, e uma camada adicional que refere-se a instalação do serviço apache. Na imagen abaixo podemos visualizar melhor esse ambiente.

 

docker-filesystems-multilayer-update

Lembrando que uma imagem pode ser utilizada diversas vezes, ou seja, há compartilhamento da imagem entre os containers, mas os containers depois de iniciados são isolados uns dos outros, na imagem abaixo podemos visualizar essa arquitetura.docker-filesystem

Como podemos notar, há o compartilhamento das camadas inferiores, pois elas fazem parte da imagem que originou o container, e a camada de escrita, que faz parte do container rodando, é isolada para cada container.

Por hoje é isso, veremos em breve um pouco mais sobre filesystem no Docker, e algumas outras questões relacionadas a essa arquitetura. Ficou com dúvida? Gostaria de saber mais? Algum feedback a nos dar? Deixe sua mensagem e vamos conversando.

Abraço!

Utilizando API com Docker

Olá pessoal!

Hoje vamos mostrar como realizar as operações mais básicas do Docker através da API dele. Vamos ver como iniciar, parar, criar, excluir e coletar informações de containers através da API. Estarei utilizando a distribuição CentOS 7 em meu host onde vou criar os containers.

– Como habilito a API?

vim /etc/systemd/system/docker.service 

//Vamos alterar a linha que contém ExecStart=/usr/local/bin/docker -d -H fd:// por essa

ExecStart=/usr/local/bin/docker -d -H fd:// -H 0.0.0.0:4243

service docker restart

Agora estamos com nossa API habilitada e escutando na porta 4243.

– Iniciar

curl -X POST http://IPHost:4243/containers/IDContainer/start

– Parar

curl -X POST http://IPHost:4243/containers/IDContainer/stop

– Excluir

curl -X DELETE http://IPHost:4243/containers/IDContainer

– Criar

curl -X POST -H "Content-Type: application/json" http://IpHost:4243/containers/create -d '{
"Hostname":"",
   "User":"",
   "Memory":0,
   "MemorySwap":0,
   "AttachStdin":false,
   "AttachStdout":true,
   "AttachStderr":true,
   "PortSpecs":null,
   "Privileged":false,
   "Tty":false,
   "OpenStdin":false,
   "StdinOnce":false,
   "Env":null,
   "Dns":null,
   "Image":"busybox",
   "WorkingDir":""
}'

– Renomear

curl -X GET http://IPHost:4243/containers/IDContainer/rename?name=novo_nome

– Exibir containers que estão iniciado

curl -X GET http://IPHost:4243/containers/json

– Exibir todos os containers

curl -X GET http://IPHost:4243/containers/json?all=1

– Top

curl -X GET http://IPHost:4243/containers/IDContainer/top

– Stats

curl -X GET http://IPHost:4243/containers/IDContainer/stats

– Images

curl -X GET http://IPHost:4243/images/json?all=0

Por hoje era isso, fiquem atentos para as novidades e ajude divulgando o mundodocker.com.br!

Cluster de Docker Swarm com Ansible

Fala pessoal, faz tempo que não criamos conteúdo para o site, foram alguns meses de conversa sobre o futuro do blog. E a partir de hoje vamos iniciar os nossos posts de 2018, o Mundo Docker por mais que contenha a palavra “Docker” em seu nome não é um blog que contenha só posts referentes a essa tecnologia, mas sim as tecnologias mais usadas no momento. No decorrer desse ano vamos falar de muita coisa que está sendo usada hoje em dia.

Então para nosso primeiro post do ano vamos mostrar como é possível realizar a configuração de um cluster de Docker Swarm com 3 managers e 1 Worker utilizando Ansible. para quem ainda não possui familiaridade com as nomenclaturas do Docker, Manager é o papel responsável por gerenciar o cluster de Docker Swarm, já o Worker é o responsável por hospedar os containers.

Mas o que é o Ansible? Basicamente é uma ferramenta de automatização de tarefas que é muito utilizada para provisionamento e configuração de servidores, muito semelhante a Chef e Puppet. Você pode ver mais detalhes dela em nosso outro post que detalha mais sobre o ansible:

Ansible

Para esse post vamos utilizar 5 máquinas virtuais, das quais:
3 Ubuntu 16.04 que serão utilizados como Managers
1 Ubuntu 16.04 que será utilizado como Worker
1 Ubuntu 16.04 que estará com o Ansible instalado

Nosso principal objetivo é realizar a configuração de nossos servidores de forma declarativa através do Ansible e disparar os Playbooks de configuração de nossos servidores.

Vamos iniciar fazendo a instalação do Ansible em nosso servidor que será o responsável por conectar nos outros 4 servidores. Como o Ansible conecta através de ssh nas máquinas então não é preciso realizar a instalação de agentes nas máquinas de destino, o único requisito é ter o acesso ssh liberado para a máquina que irá executar o Ansible. No momento da criação desse post a versão mais recente do Ansible é a 2.5 então vamos utilizar essa versão. Na máquina que estamos utilizando para servir como Ansible você irá executar os seguintes comandos:

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

Após a execução desses comandos você estará com o Ansible instalado em sua máquina, o Ansible cria o diretório /etc/ansible/ dentro deste diretório temos o arquivo ansible.cfg que é o responsável por gerenciar algumas configurações como métodos de conexões, portas, protocolo, entre outras configurações. Alguns exemplos de configurações que muitas vezes são alteradas no ansible.cfg:

remote_port = 22
sudo_user = root
host_key_checking = False
# SSH timeout
timeout = 10

Esse foi um exemplo simples de alteração, você pode acessar o arquivo e verificar todas as opções de mudança. Vamos continuar então realizando a nossa configuração. Vamos criar o diretório que irá conter as nossas configurações para os servidores:

mkdir /home/exemplopost
mkdir /home/exemplopost/roles
mkdir /home/exemplopost/group_vars
cd /home/exemplopost
touch /home/exemplopost/hosts
touch /home/exemplopost/main.yml

Esses são os diretórios base que utilizamos em um projeto com Ansible, essa é uma nomenclatura padrão com quem trabalha com ansible. Dentro de “Roles” é onde vamos colocar os nossos “Playbooks” responsáveis pela configuração dos servidores onde segmentamos por funcionalidades, “group_vars” é onde colocamos os nossos templates de variáveis que utilizamos dentro dos nossos Playbooks. Ainda temos os arquivos “hosts” onde estão as informações dos servidores que vamos conectar e também o arquivo “main.yml” que é o início da execução do nosso Ansible, onde estará descrito as Roles que serão executadas e quais os hosts que serão usados. Então vamos iniciar adicionando os nossos hosts no arquivo hosts.

vim /home/exemplopost/hosts

[docker_swarm_manager]
MANAGER1 ansible_ssh_host=10.10.10.2 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
MANAGER2 ansible_ssh_host=10.10.10.3 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
MANAGER3 ansible_ssh_host=10.10.10.4 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
[docker_swarm_worker]
WORKER1 ansible_ssh_host=10.10.10.5 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost

Esse é o conteúdo do nosso arquivo de hosts, dentro deles temos dois grupos de máquinas, um que chamamos de “docker_swarm_manager” e “docker_swarm_worker” com a criação de grupos conseguimos definir que determinado grupo irá executar Roles X e outro grupo irá executar Roles Y, visto que nesse caso Managers e Workers possuem diferentes configurações. Vamos criar uma hierarquia de diretórios e arquivos conforme a imagem abaixo:

Vamos agora editar o arquivo /home/exemplopost/roles/docker/tasks/main.yml:


---
  - name: Realizando apt-get update
    apt:
     update_cache: yes
  - name: Modificando hostname
    shell: hostname {{ inventory_hostname }}

  - name: Instalando a versão mais recente do Docker
    shell: curl -sS https://get.docker.com | sh

  - name: Reiniciar serviço do Docker
    systemd:
     state: restarted
     enabled: yes
     daemon_reload: yes
     name: docker

Com isso temos todos os passos que são comuns em todos os servidores de Manager e Worker. Agora vamos realizar a configuração dos Managers: Abra o arquivo /home/exemplopost/roles/manager/tasks/main.yml:


---
  - name: Verifica se o Docker Swarm está habilitado
    shell: docker info
    changed_when: False
    register: docker_info

  - name: Cria o cluster no primeiro servidor
    shell: docker swarm init --advertise-addr {{ docker_swarm_manager_ip }}:{{ docker_swarm_manager_port }}
    when: "docker_info.stdout.find('Swarm: active') == -1 and inventory_hostname == groups['docker_swarm_manager'][0]"

  - name: Armazena o token de manager
    shell: docker swarm join-token -q manager
    changed_when: False
    register: docker_manager_token
    delegate_to: "{{ groups['docker_swarm_manager'][0] }}"
    when: "docker_info.stdout.find('Swarm: active') == -1"
 
  - name: Adiciona os outros swarms Managers no cluster.
    shell: docker swarm join --token "{{ docker_manager_token.stdout }}" {{ docker_swarm_manager_ip}}:{{ docker_swarm_manager_port }} 
    changed_when: False
    when: "docker_info.stdout.find('Swarm: active') == -1
     and docker_info.stdout.find('Swarm: pending') == -1
     and 'docker_swarm_manager' in group_names
     and inventory_hostname != groups['docker_swarm_manager'][0]"

 

Após criar o cluster e adicionar os servidores de Managers, vamos adicionar o nosso Worker para isso vamos editar /home/exemplopost/roles/worker/tasks/main.yml:


---
  - name: Verifica se o Docker Swarm está habilitado.
    shell: docker info
    changed_when: False
    register: docker_info

  - name: Pega o token do worker.
    shell: docker swarm join-token -q worker
    changed_when: False
    register: docker_worker_token
    delegate_to: "{{ groups['docker_swarm_manager'][0] }}"
    when: "docker_info.stdout.find('Swarm: active') == -1"

  - name: Adiciona o servidor de Worker no cluster.
    shell: docker swarm join --token "{{ docker_worker_token.stdout }}" {{ docker_swarm_manager_ip}}:{{ docker_swarm_manager_port }}
    changed_when: False
    when: "docker_info.stdout.find('Swarm: active') == -1
           and docker_info.stdout.find('Swarm: pending') == -1"

Os playbooks acima são os responsáveis pela criação do cluster de Docker Swarm. Agora vamos criar as variáveis que serão utilizadas.

/home/exemplopost/group_vars/all


---
  docker_swarm_manager_ip: "10.10.10.2"
  docker_swarm_manager_port: "2377"

Vamos agora definir o nosso arquivo main para chamar as roles a serem executadas. Para isso vamos criar o arquivo em /home/exemplopost/main.yml


---
 - name: Configurando Managers
   hosts: docker_swarm_manager

   roles:
     - docker
     - manager

 - name: Configurando Workers
   hosts: docker_swarm_worker
   roles:
    - docker
    - worker

Agora sim, criamos todos os arquivos necessários para rodar o nosso playbook, após fazer isso basta você executar o comando:

 ansible-playbook -i hosts main.yml

.
Feito isso temos o nosso cluster de Docker Swarm configurado e funcionando. Fizemos uma configuração simples que funciona muito bem para um ambiente de teste.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!