Category: Tutoriais

Supervisord – Gerenciando serviços

Eai gente, tudo tranquilo?

O LXC propriamente dito não foi desenvolvido para ter múltiplos serviços/processos em cada container, o ideal é que você segmente seu ambiente em diversos containers, cada um rodando um parte isoladamente. Mas Cristiano, eu realmente preciso ter 2, 3 serviços em um mesmo container, o que faço? Bom, se não tem jeito mesmo, você pode utilizar o supervisord para gerenciar seus processos dentro de um container, e garantir que eles iniciem juntamente com o container.

O supervisord para quem não conhece é um utilitário que serve para monitorar e reiniciar os serviços nele definidos quando esses serviços entram em um estado de falha, ele é escrito em python e é muito simples de se utilizar, ele possuí 2 comandos básicos:

  • supervisord: É o deamon propriamente dito, responsável por ler o arquivo de configuração e monitorar os serviços definidos;
  • supervisorctl: É um subutilitário que serve para poder reiniciar manualmente o serviço ou ainda verificar qual o status do serviço para o supervisord;

Vou mostrar como você pode utilizar o supervisord já com o container rodando, mas como você já viu nesse post, você pode converter todos esses comandos em um Dockerfile e dar um docker build e gerar um imagem pronta ;). Vamos lá:

1 – Instalando

c45cffcd9126:~# yum install python-setuptools -y
c45cffcd9126:~# easy_install pip
c45cffcd9126:~# pip install supervisor

2 – Configurando

c45cffcd9126:~# echo_supervisord_conf > supervisord.conf
c45cffcd9126:~# cp supervisord.conf /etc/supervisord.conf
c45cffcd9126:~# vi /etc/supervisord.conf

Agora basta você adicionar o bloco de comandos referente ao(s) serviço(s) que precisamos que sejam iniciados com o container, como por exemplo o ssh e o apache como definido abaixo:

[supervisord] 
nodaemon=false

[program:sshd] 
command=/usr/sbin/sshd -D 

[program:apache] 
command=/usr/sbin/httpd -DFOREGROUND -k start

Ah claro, não esquece de instalar esses serviços 

c45cffcd9126:~# yum install openssh-server httpd -y

Agora está no fim, crie um arquivo no / com nome de run.sh com o seguinte conteúdo

#!/bin/bash
/usr/bin/supervisord -c /etc/supervisord.conf
/bin/bash

Não esqueça da permissão de execução: chmod +x /run.sh

E está pronto o seu container, com o supervisord monitorando e mantendo no ar os serviços definidos, quer testar? Inicie o daemon: /usr/bin/supervisord -c /etc/supervisod.conf e verifique se os serviços que você definiu estão com status de running, para isso utilize:

c45cffcd9126:~# supervisorctl
apache RUNNING pid 160, uptime 0:00:03
sshd RUNNING pid 161, uptime 0:00:03
supervisor>

O supervisorctl possuir vários recursos, veja como você pode consultar:

supervisor> ?
default commands (type help <topic>):
=====================================
add exit open reload restart start tail
avail fg pid remove shutdown status update
clear maintail quit reread signal stop version
supervisor>

Através dele você pode parar, iniciar, atualizar entre muitas outras opções. Agora basta você gerar um imagem desse container:

docker commit containerid nomedaimagem

Feito isso você terá gerado a imagem do container, agora basta iniciar um novo container baseado nessa imagem:

docker run -d -p 80:80 -p 22:22 nomedaimagem /run.sh

E pronto, você terá iniciado 2 serviços diferentes dentro do mesmo container, e o melhor, eles reiniciarão sozinhos quando entrarem em failed state, legal não?

Espero ter ajudado, e já sabe, tendo dúvida entre em contato conosco ou deixe sua dúvida no fórum que o pessoal pode te ajudar :), quer nos ajudar? Divulgue o mundodocker.com.br e vamos conversando.

Abraço!

:

Docker Service

Oi Pessoal,

Hoje queremos trazer em detalhes para vocês uma das features implementadas no Docker 1.12 (que foi lançado no último dia 29), e que já mencionamos aqui, que é o Docker Service. Para quem ainda não leu o nosso post sobre as novidades do Docker 1.12, o Docker Service é uma feature que foi incorporada pela engine Docker em sua última versão e que permite ao administrador criar e administrar sua stack de serviço dentro de um cluster Swarm, sem precisar utilizar uma segunda ferramenta para isso. Ela é parte integrante de uma série de melhorias que permitiram ao Docker 1.12 ter a camada de orquestração nativa em sua engine.

Mas afinal, como isso me ajuda? Bem, nas versões anteriores do Docker, para você ter algum tipo de orquestração você teria que utilizar uma série de ferramentas, como por exemplo: Docker Swarm, Docker Compose isso sem falar, que, se você quisesse provisionar isso em larga escala mesmo, o recomendado era utilizar Kubernetes, Mesos ou alguma outra forma de orquestração mais adequada. Agora está tudo dentro da própria engine do Docker, o que permite você ter maior controle sob o que está utilizando, e claro, permite você manipular esse ambiente de forma mais simples.

Para serviço especificamente, foi adicionado o sub-comando: docker service, e dentro dele alguns itens, veja:

  1. docker service create: Possibilita a criação de sua stack de serviço, é ele o que você mais vai ver hoje ;)
  2. docker service inspect: Verifica as informações sobre seu serviço e retorna informações sobre parametro utilizados para inicialização do mesmo, imagem utilizada, etc.
  3. docker service ls: Lista todos os serviços que você tem criado, e lhe retorna informações sobre nome, quantidade de replicas, etc.
  4. docker service rm: Remove o serviço desejado do cluster
  5. docker service ps: 2° comando mais útil, retorna para você o status de cada container que atende um serviço, é muito parecido com o docker ps, com a diferença de lhe trazer apenas informações sobre os container que fazem parte de um serviço criado, você pode ainda utilizar filtros para ter um retorno mais simplificado.
  6. docker service scale: Com o scale é possível realizar o escalonamento de seu serviço, é possível você aumentar a quantidade de containers que atenderão o seu serviço.
  7. docker service update: Comando que lhe permite realizar modificações no serviço criado, através dele é possível modificar informações sobre quantidade de memória, cpu, dentre muitas outras coisas em seu serviço.

Tudo certo com a teoria? Então vamos a prática :), nosso problema: Queremos criar uma stack para nosso ElasticSearch, nosso objetivo é escalar esse ambiente quantas vezes eu quiser e atualiza-lo de forma consistente.

Primeiro temos que criar nosso service:

docker service create --replicas 1 --update-delay 10s --update-parallelism 1 --name elasticsearch elasticsearch

O que isso quer dizer? Vamos lá:

  • Replicas – Número de containers que eu quero criar nesse momento, deve ser no mínimo um (por motivos óbvios);
  • Update-delay – Quando for realizado uma procedimento de atualização do ambiente, qual será a cadência de atualização dos containers.
  • Update-parallelism – Quantidade de containers que desejamos atualizar por vez
  • Name – Nome do serviço e por último a imagem que vamos utilizar para esse serviço.

O retorno do comando será algo parecido com isso:

docker-service1

Certo, meu serviço está criado, como escalono ele agora? Fácil, olha o print

docker-service2

Note que para escalar, basta executar o comando: docker service scale $(seu-servico)=numero. Agora vamos atualizar o nosso ambiente, certo? Muito fácil, basta executar o comando: docker service update, com ele é possível modificar diversos atributos do serviço, como por exemplo: Portas publicadas, limites de recursos, número de replicas, imagem, politica de escalonamento, etc.

Em nosso exemplo vamos atualizar a imagem que nosso serviço utiliza, veja que quando criamos, a imagem utilizada era a elasticsearch:latest, agora queremos testar a última versão do elasticsearch, que está em alpha (no dia da criação desse post) que é a 5.0, para isso basta executar: docker service update –image elasticsearch:5.0 elasticsearch, veja o que aconteceu:

docker-service3

Veja que nosso serviço não foi atualizado de uma vez só, esse processo foi sendo realizado conforme os containers iam sendo atualizados, isso devido a nossa politica de update que definimos na criação do serviço. Com o update você pode realizar diversas ações, veja mais em: docker service update –help, ele lhe mostrará todas as opções disponíveis.

Como removemos um serviço? Bem, você já deve ter imaginado como: docker service rm nome_do_servico.

Ahh, você se lembra que falamos aqui que no Docker 1.12 era possível criar um serviço distribuído dentro Swarm e acessá-lo de qualquer lugar? Pois bem, quando você criar um serviço você pode especificar qual será a porta publica dele, no exemplo acima não utilizamos isso, mas você pode definir (através do parâmetro -p) que a porta 8080 seja a porta de seu serviço, com isso todo o trafego enviado para a porta 8080 nos ips de seus nós do cluster de Swarm será redirecionado para os containers que atendam esse serviço. Lembrando que para você criar um serviço distribuído é necessário ter um cluster de Swarm ativo.

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

Grande abraço!

 

Medindo Recursos

Oi Pessoal!
Hoje o post será um pouco mais curto, no vídeo abaixo explicamos como funciona e como o cAdvisor pode te ajudar a mensurar o uso de recursos de cada container, bem como o uso de recursos pelo host.

Ficou dúvida? Curiosidade? Deixe sua dúvida e vamos conversando, divulgue o mundodocker.com.br e nos ajude disseminando conhecimento!

Docker multi-stage builds

Oi Pessoal,

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

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

O que é?

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

O estado da arte

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

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

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

Dockerfile.build:

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

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

Dockerfile:

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

Build.sh:

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

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

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

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

O que melhorou

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

Dockerfile:

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

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

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

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

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

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

Deixando mais claro

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

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

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

 

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

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

Grande abraço!

Kubernetes parte II

Olá pessoal,

Hoje vamos continuar a demonstração de como podemos utilizar Kubernetes para nos auxiliar na administração de containers. Para conseguirmos realizar todos os procedimento vamos criar uma estrutura com quatro servidores:

  • Node – Master   (CentOS7)
  • Node – Minion1 (CentOS7)
  • Node – Minion2 (CentOS7)
  • Node – Minion3 (CentOS7)

 

Agora vamos instalar alguns componentes em nosso servidor Master.

//Instalando o Kubernetes e o etcd (Serviço de descoberta)
yum install kubernetes etcd -y

// Vamos editar o conf do etcd para liberarmos as portas de acesso a esse serviço. Você vai ver que o arquivo de // conf possui diversas linhas comentadas, vamos tirar o comentário apenas dessas linhas:
vi /etc/etcd/etcd.conf
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"

//Agora vamos fazer a configuração da API do Kubernetes
vi /etc/kubernetes/apiserver
KUBE_API_ADDRESS="--address=0.0.0.0"
KUBE_API_PORT="--port=8080"
KUBELET_PORT="--kubelet_port=10250"
KUBE_ETCD_SERVERS="--etcd_servers=http://127.0.0.1:2379"
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
KUBE_ADMISSION_CONTROL="--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
KUBE_API_ARGS=""

//Depois de mexer nos conf da API do Kubernetes e do etcd, vamos dar um start neles agora

 systemctl restart etcd
 systemctl restart kube-apiserver
 systemctl restart kube-controller-manager
 systemctl kube-scheduler

etcdctl mk /atomic.io/network/config '{"Network":"172.17.0.0/16"}'

Agora nos servidores Minions vamos executar os seguintes comandos:

yum -y install flannel kubernetes

//Vamos editar o conf do flannel agora em /etc/sysconfig/flanneld
FLANNEL_ETCD="http://IPMASTER:2379"

//Editando o conf do Kubernetes para conectar na API do master. /etc/kubernetes/config
KUBE_MASTER="--master=http://IPMASTER:8080"

//Agora vamos editar o conf do serviço de cada minion, então em cada servidor você vai colocar o seu respectivo IP. /etc/kubernetes/kubelet
KUBELET_ADDRESS="--address=0.0.0.0"
KUBELET_PORT="--port=10250"
KUBELET_HOSTNAME="--hostname_override=IPMINION"
KUBELET_API_SERVER="--api_servers=http://IPMASTER:8080"
KUBELET_ARGS=""


systemctl restart kube-proxy 
systemctl restart kubelet
systemctl restart docker 
systemctl restart flanneld

Agora no server Master é só executar:

//Você receberá o status de nossos nó
kubectl get nodes

Por hoje era isso pessoal, em nosso próximo post vamos demonstrar como podemos criar aplicações altamente disponíveis dentro do nosso Kubernetes.

Espero ter ajudado, e já sabe, tendo dúvida entre em contato conosco ou deixe sua dúvida no fórum que o pessoal pode te ajudar :), quer nos ajudar? Divulgue o mundodocker.com.br e vamos conversando.

Abraço!

Referência: http://severalnines.com/blog/installing-kubernetes-cluster-minions-centos7-manage-pods-services

Docker Machine

Olá!

Umas das ferramentas mais interessantes do ecossistema Docker, e que é mantido pela própria Docker é o Docker Machine, com ele é possível você fazer deploy de seu ambiente na infra-estrutura que desejar, você pode portar sua aplicação do seu notebook para AWS, Digital Ocean, ou o que for. Veja no vídeo um exemplo prático disso:

Você pode ainda integrar com Docker Compose, e automatizar ainda mais essas tarefas, legal né? Espero que tenham gostado, tendo dúvidas nos contatem, estamos dispostos a sanar todas as dúvidas.

Abraço!

Iptables e Docker

Oi Gente!!

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

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

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

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

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

iptables -P INPUT DROP

iptables -A INPUT --dport 80 -j ACCEPT

iptables -A INPUT --dport 22 -j ACCEPT

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

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

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

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

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

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

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

iptables -L -nv

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

A Solução

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

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

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

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

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

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

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

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

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

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

Auto Complete para Docker

Olá!

Hoje o post será um pouco diferente dos que geralmente publicamos, queremos mostrar para vocês como é possível utilizar a funcionalidade de auto complete do shell para os comandos Docker. Mas para que isso? Simples, facilidade e agilidade na execução de comandos, quem aqui nunca apertou o tab depois de digitar ‘./conf’? Então, você deve sentir falta dessa facilidade quando se utiliza os subcomandos do docker, certo? Queremos mostrar pra vocês como resolver isso.

Como você já viu aqui, existem diversos subcomandos do docker, e cada um possui diversos parâmetros que podem ser utilizados, com o docker –help você poderá visualizar as opções disponíveis.

Mas isso é chato algumas vezes, é mais fácil começar a digitar docker run --vol...[tab][tab]e deixar o autocomplete fazer o trabalho:

$ docker run --volume
--volume         --volume-driver  --volumes-from

#vamosinstalar?

No Mac OS X

O processo é simples, estando no Mac OS X temos que instalar o auto completion usando o brew:

$ brew install bash-completion

E em seguida adicionar as linhas em nosso arquivo de profile ($HOME/.bash_profile ou /Users//.bash_profile)

if [ -f $(brew --prefix)/etc/bash_completion ]; then
    . $(brew --prefix)/etc/bash_completion
fi

Você pode executar os seguintes comandos, que devem ser utilizados nesta sequência:

$ echo "if [ -f $(brew --prefix)/etc/bash_completion ]; then" | tee -a $HOME/.bash_profile
$ echo "    . $(brew --prefix)/etc/bash_completion" | tee -a $HOME/.bash_profile
$ echo "fi" | tee -a $HOME/.bash_profile

Atenção: Se não temos o homebrew instalado, veja em http://brew.sh/ mais informações de como instala-lo e utiliza-lo.

 
No Linux

No Linux, como sempre, é mais simples, basta instalar via gerenciador de pacotes da sua distribuição. Se for Debian like (Ubuntu, Mint, etc) usamos o apt-get:

$ sudo apt-get install bash-completion

Se for Red Hat like (RHEL, CentOS, Fedora, etc) então usamos yum:

$ sudo yum install bash-completion

Completion do Docker Engine

O arquivo está disponível em https://github.com/docker/docker/blob/master/contrib/completion/bash/docker portanto sempre que fizer uma atualização é recomendável que você baixe novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker.

Ao baixar devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux, se estivermos em um Mac OS X:  $(brew --prefix)/etc/bash_completion.d.

No Mac OS X
$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > $(brew --prefix)/etc/bash_completion.d/docker
No Linux
$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > /etc/bash_completion.d/docker

Completion do Docker Compose

De maneira similar o arquivo está disponível emhttps://github.com/docker/compose/blob/master/contrib/completion/bash/docker-compose . Reforçamos que sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker Compose.

Ao baixar também devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

No Mac OS X
$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > $(brew --prefix)/etc/bash_completion.d/docker-compose
No Linux
$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

Completion do Docker Machine

O processo é praticamente o mesmo porém o docker-machine possui 3 arquivos de auto complete. Os arquivos estão disponíveis em https://github.com/docker/machine/tree/master/contrib/completion/bash .

Como dito anteriormente devemos colocá-los na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

Como são mais arquivos recomendo utilizarmos um loop para baixarmos todos em sequência utilizando apenas um comando.

No Mac OS X
machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > `brew --prefix`/etc/bash_completion.d/$file
done
unset machineVersion
No Linux
machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > /etc/bash_completion.d/$file
done
unset machineVersion

Observe que:

  1. Se você utilizar alguma versão específica de uma dessas ferramentas basta baixar os arquivos da pasta correspondente.  Por exemplo o docker engine, da maneira que mostramos vamos pegar o arquivo que está na branch master, atualmente versão 1.12.1, para pegar na versão 1.11.0 por exemplo o arquivo fica em https://github.com/docker/docker/blob/v1.11.0/contrib/completion/bash/docker
  2. O Docker disponibiliza alguns arquivos de completion para outros shells. O Docker Engine disponibiliza bash, zsh, fish e powershell como podemos ver em https://github.com/docker/docker/tree/master/contrib/completion .
  3. O Docker Compose e o Docker Machine disponibilizam apenas para bash e zshcomo vemos nas urls https://github.com/docker/compose/tree/master/contrib/completion e https://github.com/docker/machine/tree/master/contrib/completion .

E era isso por hoje pessoal, agradecimento especial ao @wsilva pela dica. Já sabe, ajude divulgando o blog, e tendo dúvidas ou sugestões deixa ai nos comentários

Abraço!

Fonte: http://dumpscerebrais.com/2016/09/auto-complete-para-docker-engine-machine-e-compose/

Amazon EKS – Parte 1

Eai gente,

Bora falar de facilidades? Então, o objetivo deste post é trazer uma introdução ao uso da Amazon EKS (Elastic Kubernetes Service), vamos entender melhor o que é essa ferramenta e como você pode começar a “brincar” com ela de forma simples e rápida.

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

O que é o EKS

O Elastic Kubernetes Service nada mais é do que uma forma de você poder ter um cluster (ou mais) de Kubernetes sob demanda e sem a necessidade de administração dos managers (que para muitos é o mais complexo e oneroso dentro do Kubernetes), ou seja, a Amazon mais uma vez disponibiliza mais uma facilidade e tira um peso de quem precisa gerenciar o ambiente, é claro que isso gera outros pontos de atenção, como é o caso do vendor lockin, porém, se bem pensado, pode ser uma decisão que valha a pena.

Como Funciona

O objetivo da Amazon é disponibilizar para você uma infraestrutura completa, inclusive, no caso do EKS, tendo o gerenciamento dos manager sendo realizado pela própria Amazon. 

Fonte: https://aws.amazon.com/pt/eks/

Temos então basicamente três pontos principais nessa arquitetura:

     

Manager

Você não terá acesso a essa estrutura, toda a gerencia e configuração fica por conta da AWS mesmo, então, menos um ponto para se preocupar.

Workers:

São os nós do cluster onde você poderá executar todos os seus conteirners, ou seja, quando você instanciar um novo pod, ele será provisionado em um desses hosts.

Client:

Você precisa ter o binário do kubectl no host para poder geranciar o cluster, e ai que vem um ponto bem legal, você gerencia o cluster de forma transparente, da mesma forma como se fosse um Kubernetes on premise.

Mãos a obra?

A criação do master pode ser realizado utilizando a console da AWS mesmo, CloudFormation ou via CLI, o que veremos hoje será via CLI pois é o mais simples, para isso, você deve ter configurado em seu computador o awscli, para isso, siga os passos: https://docs.aws.amazon.com/pt_br/cli/latest/userguide/cli-chap-install.html, para resumir, se seu host for linux, siga a sequência:

Instale o Python 3:

apt-get/yum install python3

Baixe o pip para instalar o aws cli:

curl -O https://bootstrap.pypa.io/get-pip.py

Instale o pip:

python get-pip.py --user ou python3 get-pip.py --user

Adicione um novo caminho em seu path:

export PATH=~/.local/bin:$PATH
source ~/.bash_profile

Instale o AWS Cli:

pip3 install awscli --upgrade --user

Verifique a instalação:

aws version

Feito isso, você precisa configurar o cli para as credenciais da AWS, para isso, execute os passos:

aws configure

Informe os dados conforme for sendo lhe solicitado e pronto, basta seguir para o próximo passo.

Você precisará configurar o aws-iam-authenticator, para isso, siga:

curl -o aws-iam-authenticator 
https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.7/2019-03-27/bin/linux/amd64/aws-iam-authenticator
chmod +x ./aws-iam-authenticator
mkdir -p $HOME/bin && cp ./aws-iam-authenticator $HOME/bin/aws-iam-authenticator && export PATH=$HOME/bin:$PATH
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc

Além desses binários, você precisará também ter configurado no host o eksctl, então siga os passos abaixo:

Baixe o eks:

curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

mv /tmp/eksctl /usr/local/bin/

Verifique se o eksctl está ok:

eksctl version

Certo, agora você precisará baixar o client do Kubernetes, o kubectl, você pode seguir os passos:

curl -o kubectl.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/kubectl.sha256

chmod +x ./kubectl

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc

Feito, basta verificar se está ok, execute:

kubectl version --short --client

E agora José?

Agora bora subir esse cluster ai que o pessoal ta louco pra ver funcionando :).

Pra isso, você pode executar o eksctl da seguinte forma:

eksctl create cluster 

--name prod 

--version 1.13 

--nodegroup-name workers 

--node-type t3.medium 

--nodes 3 

--nodes-min 1 

--nodes-max 4 

--node-ami auto

Dessa forma o eksctl criará toda a escrutura necessária para o funcionando do cluster, desde VPC até regras de security group, esse novo cluster será formado com 3 instâncias t3.medium. O retono do comando será algo parecido com este:

[ℹ]  using region us-west-2
[ℹ]  setting availability zones to [us-west-2b us-west-2c us-west-2d] 
[ℹ]  subnets for us-west-2b - public:192.168.0.0/19 private:192.168.96.0/19 
[ℹ]  subnets for us-west-2c - public:192.168.32.0/19 private:192.168.128.0/19 
[ℹ]  subnets for us-west-2d - public:192.168.64.0/19 private:192.168.160.0/19 
[ℹ]  nodegroup "standard-workers" will use "ami-0923e4b35a30a5f53" [AmazonLinux2/1.12] 
[ℹ]  creating EKS cluster "prod" in "us-west-2" region 
[ℹ]  will create 2 separate CloudFormation stacks for cluster itself and the initial nodegroup 
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-west-2 --name=prod' 
[ℹ]  building cluster stack "eksctl-prod-cluster" 
[ℹ]  creating nodegroup stack "eksctl-prod-nodegroup-standard-workers" 
[✔]  all EKS cluster resource for "prod" had been created 
[✔]  saved kubeconfig as "/Users/ericn/.kube/config" 
[ℹ]  adding role "arn:aws:iam::111122223333:role/eksctl-prod-nodegroup-standard-wo-NodeInstanceRole-IJP4S12W3020" to auth ConfigMap 
[ℹ]  nodegroup "standard-workers" has 0 node(s) 
[ℹ]  waiting for at least 1 node(s) to become ready in "standard-workers" 
[ℹ]  nodegroup "standard-workers" has 2 node(s) 
[ℹ]  node "ip-192-168-22-17.us-west-2.compute.internal" is not ready 
[ℹ]  node "ip-192-168-32-184.us-west-2.compute.internal" is ready 
[ℹ]  kubectl command should work with "/Users/ericn/.kube/config", try 'kubectl get nodes' 
[✔]  EKS cluster "prod" in "us-west-2" region is ready

Ahh mas eu quero personalizar… Não se preocupe amigo, o eksctl permite você definir qual VPC vai usar, quais subnet, security group, imagem (desde que homologada pela AWS), chave, dentre outras opções.

Depois de criado o cluster, bem, agora ficou fácil, basta você administrar da mesma forma como se fosse um cluster de Kubernetes instalado ai, nas suas máquinas locais ;).

Valide se tudo está ok com o cluster executando os comandos para verificar os nós do cluster:

kubectl get nodes

Você pode visualizar se foi criado o serviço default também, para isso:

kubectl get svc

O retorno será algo parecido com este:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
svc/kubernetes   ClusterIP   10.100.0.1           443/TCP   1m

Legal, e agora?

Bem, agora a sua imaginação é limite, encare o EKS como um cluster normal, neste sentido, o deploy de suas apps seguirá o mesmo processo, e caso você queria, pode utilizar outras facilidades da AWS para agilizar a publicação, mas isso é conto para outro post.

Queremos ainda, falar sobre monitoramento no EKS, Logs, e claro, vamos criar e fazer deploy de alguns serviço neste cluster, vamos ver como ficam as questões de segurança, ingress de serviço, dentre outros pontos.

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

Criando um servidor web com docker

Olá!

Você está procurando uma forma de criar um ambiente web fácil e rápido? pois bem, hoje vamos mostrar como criar um ambiente web de maneira rápida e fácil. Nosso ambiente será constituído por 3 containers, sendo eles: Weave, HAProxy e Apache.

Com esse comando estamos criando o nosso container onde vamos colocar nosso apache

docker run -it --name apache centos /bin/bash

Agora já dentro do container 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 #Estamos utilizando a versão 7 do CentOS em nosso container.
rpm -ivh epel-release-7-5.noarch.rpm

yum install httpd -y
yum install php -y

/usr/sbin/httpd -DFOREGROUND -k start &

vi /var/www/html/index.html #Dentro do arquivo index.php vamos colocar o código abaixo:

<?php
 echo "Mundo Docker";
?>

Feito isso acima agora vamos pressionar CTRL + P + Q assim estamos saindo do container e voltando para o nosso Host. Vamos instalar agora o Weave para conseguir trabalhar com a parte de redes de uma maneira mais simples.


curl -L git.io/weave -o /usr/local/bin/weave
chmod a+x /usr/local/bin/weave

weave attach 192.168.0.2/24 apache #Estamos vinculando o ip 192.168.0.2/24 ao container apache através da rede Weave.

Agora vamos criar o container com o HAProxy.

docker run -it --name haproxy -p 80:80 centos /bin/bash

yum install wget -y
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm #Estamos utilizando a versão 7 do CentOS em nosso container.
rpm -ivh epel-release-7-5.noarch.rpm

yum install haproxy -y
echo "" > /etc/haproxy/haproxy.cfg
vi /etc/haproxy/haproxy.cfg

Copiar e colar dentro desse arquivo



global
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon



defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000

frontend localnodes
    bind *:80
    mode http
    default_backend nodes

backend nodes
    mode http
    balance roundrobin
    option forwardfor
    server web01 192.168.0.2:80 check

Agora vamos iniciar o HAProxy



/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg &

Feito isso acima agora vamos pressionar CTRL + P + Q para sair do container e vamos anexar um IP para esse container.


weave attach 192.168.0.1/24 haproxy

 

Após isso é só acessar http://seuip e você estará visualizando a sua página.

 

Por hoje era isso pessoal, em nossos próximos posts vamos mostrar como criar um ambiente web com alta disponibilidade, replicação de arquivos e muito mais. Então fique ligado e nos ajude a divulgar o mundodocker.com.br obrigado!.

Docker e Jenkins para build de aplicações

Olá pessoal,

Hoje queremos demonstrar para vocês como podemos utilizar Docker e Jenkins para o build de aplicações de forma rápida e fácil, primeiro vamos entender como é o ambiente de diversas empresas de TI hoje e você que estiver lendo este post possivelmente estará se identificando com isso.

Hoje diversas empresas utilizam a ferramenta Jenkins para build e deploy de aplicações, muitas vezes (Se não forem todas) essa maquina de Jenkins é compartilhada entre diversos times, Java, PHP, Python, Rails e NodeJS acabam utilizando. O que deixa essa máquina com ferramentas desnecessárias para as equipes, sobrecarregando o sistema e qualquer problema acaba parando todas as equipes.

Porém existem alguns casos mais organizados que a maquina onde irá ocorrer o build será uma máquina para cada equipe, o que torna o processo um pouco melhor, porém sempre que sair uma nova versões de softwares alguém precisa ficar atualizando essa máquina, o que pode acabar por muitas vezes impactando em prazos do projeto.

Então existe o que acreditamos que seja a melhor solução que seria a utilização de containers para o build de suas aplicações. mas porque usar containers?

  • Só dependências para aquela aplicação
  • Fácil manutenção
  • Ambiente de produção e local iguais.
  • Escabilidade

Então visto o porque que devemos utilizar containers para realizar o build, vamos mostrar como podemos utilizar essas duas ferramentas em sincronia.

Primeiramente vamos até as configurações do nosso repositório e clicar em “WebHooks & Services:4

Vamos até “Add Service” e adicionar o “Jenkins (Github Plugin)”
5
Agora em nosso servidor com Docker instalado, vamos iniciar o container que terá o Jenkins Master instalado.

############# SERVIDOR1 #################
docker run -p 8080:8080 -p 50000:50000 -d jenkins

Iniciado, agora vamos até o nosso browser e digitar http://ipserver:8080 e vamos fazer a configuração base do Jenkins.

1

Para pegar a senha você irá executar

docker exec idcontainer cat /var/jenkins_home/secrets/initialAdminPassword

Na pŕoxima página você pode escolher a opção de usar os plugins recomendados, então depois irá pedir para você criar um usuário.

2

Feito isso agora estamos na página inicial do jenkins.

3

Esse será nosso servidor de Jenkins Master que sera o responsável por avisar e mandar rodar alguns comandos no nosso servidor onde estará o Docker. Para isso, vamos acessar o servidor 2 e realizar a instalação do Jenkins:

############# SERVIDOR2 #################
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins -y
sudo yum install java -y 
sudo service jenkins start/stop/restart
sudo chkconfig jenkins on
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload
sudo yum install java-1.7.0-openjdk -y

Após realizar a instalação do servidor2, vamos até o nosso servidor de Jenkins Master e adicionar o outro nó nele, colocando o IP e a forma pela qual o agente fosse instalado: Para isso você deve ir até “Gerenciar Jenkins” >> “Gerenciar nós”

6

Após isso você irá clicar em novo nó, colocar o ip desse novo servidor e clicar na opção de “Permanent” e OK. Após isso irá aparecer algo parecido com a tela abaixo então, você tera que fazer download do slave.jar, ir até o outro servidor e executar o comando do java que é mostrado na imagem abaixo, porem com as suas configurações.

7

Feito isso, vamos até a tela da esquerda na opção de configurações e configurar parecido com a imagem abaixo: A parte mais importante dessa tela é a configuração do “rótulo” que é o apelido que vamos dar a esse servidor, e também o “uso” que estamos dizendo que vamos executar esse servidor apenas como jobs.

8

Agora vamos até a página inicial do nosso jenkins e então criar o nosso build. Vamos até “Novo Build”

9

Após selecionar “Novo Build” vamos até a opção de configuração:

10

Vamos colocar o nome do nosso servidor de slave na opção de “Restringe onde este projeto pode ser executado”

11

Abaixo vamos colocar o nosso caminho do “GitHub” e também de qual branch irá baixar o código.

12

Vamos marcar  a opção de “Build when a change is pushed to github” e também a opção de quanto em quanto tempo vamos ir consultar o nosso “SCM”.

14

Em nosso ultimo passo, vamos colocar os comandos que iremos executar em nosso servidor. Vamos criar uma imagem a partir do Dockerfile que está em nosso GitHub e após isso vamos iniciar o container com essa imagem.

15

Então por hoje era isso pessoal, espero que tenham gostado do post e gostaríamos que vocês interagissem através de comentários propondo novos posts e arquiteturas que vocês gostariam que a gente fizesse com Docker. Em breve teremos mais posts nesse estilo.

Obrigado!

Referências: https://docker.com/sites/default/files/RA_CI%20with%20Docker_08.25.2015.pdf

: https://jenkins.io/solutions/docker/

: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins

Docker Private Registry

Olá Pessoal!

Hoje o post será um pouco mais curto, isso por que queremos compartilhar com vocês alguns vídeos sobre as ferramentas que cercam o Docker, entre elas o Private Registry, que nada mais é do que um repositório privado de imagens.

Veja abaixo o vídeo que fala sobre isso, assine nosso canal no Youtube, ajude divulgando o mundodocker.com.br e fique por dentro das novidades!

 

Docker – API Autenticada

Oi Pessoal,

Uma das grandes vantagens em se utilizar o Docker em vez de LXC puro é a facilidade de se trabalhar utilizando uma API de integração, isso facilita e agiliza a vida tanto de programadores quanto do pessoal de operações. Alguns cuidados devem ser tomados é claro, entre eles em não expor a API de seu host Docker, pois nativamente não há um método de limitar o acesso. Existem soluções para isso? É claro, e hoje o mundodocker.com.br abordará um delas: Docker API com Basic Authentication.

Passo 1:

Primeiramente você deve expor a API do Docker apenas localhost, para isso você deverá editar o arquivo de configuração, no nosso exemplo (CentOS 7) é no /etc/sysconfig/docker, e deixe-o assim:

OPTIONS='-H tcp://127.0.0.1:2376 -H unix:///var/run/docker.sock'

Em seguida reinicie o serviço do Docker:

systemctl restart docker.service

Passo 2:

Agora precisamos instalar e configurar um proxy http (Nginx, Apache, etc), no nosso exemplo vamos utilizar o Nginx, para isso:

yum install nginx -y

Agora precisamos definir as credenciais de acesso, é simples, basta criar .htpasswd e fazer com que o proxy exija usuário e senha em uma determinada url, vamos lá:

htpasswd -c /etc/nginx/.htpasswd USUARIO

Ele solicitará a senha, digite-a duas vezes e está pronto seu arquivo de autenticação.

Agora vamos a configuração do proxy, para isso precisamos editar o arquivo: /etc/nginx/conf.d/default.conf e deixe-o da seguinte forma:

server {
 listen 2375 default_server;
 server_name localhost;
 location / {
 proxy_pass http://127.0.0.1:2376;
 auth_basic_user_file /etc/nginx/.htpasswd;
 auth_basic "Acesso restrito a API do Docker";
 }
}

O que falta? reiniciar o serviço do Nginx:

systemctl restart nginx.service

Testes

Depois de tudo configurado (se fosse não encontrar nenhum erro no caminho também ) basta você testar de uma forma bem simples: http://ipdoservidor:2375/info ele solicitará os dados informados anteriormente via htpasswd e retornará algumas informações do Docker e dos containers que está em execução neste host.

Você pode optar por outro método, que é o certificado SSL diretamente na API do Docker, isso garante que apenas clientes confiáveis tenham acesso ao host (pois deverão tem o certificado client configurado). E claro, você pode configurar para que o Nginx trabalhe sob SSL, isso garante que, além da autenticação com usuário e senha, você ainda tenha todos os seus dados trafegados de forma criptografada (esse sim é um ótimo método).

Por hoje era isso gente, gostaram? Ajudem divulgando o Blog por ai

Abraços!

Docker ToolBox

Oi Pessoal,

Você, sim você mesmo, que não tem grandes conhecimentos em Linux mas quer aprender Docker, criar seus containers e montar suas imagens, pois bem, esse post é pra você ;). Queremos mostrar como instalar e utilizar a ferramenta Docker ToolBox, que é um ótimo utilitário para subir seu ambiente Docker dentro de seu Windows ou Mac de forma fácil e rápida, montamos esse vídeo para lhe auxiliar, veja:

Basta você acessar: https://docker.com/docker-toolbox, fazer download da ferramenta e instalar como está ilustrado no vídeo. Ficou com dúvida ou dificuldade? Sem problema, deixa seu comentário ou ainda posta lá no nosso fórum: /forum que vamos lhe ajudando.

Esperamos ter ajudado e nos ajude divulgando o Blog.

Portando aplicação para Docker

Oi Pessoal,

Para você que acompanha nosso blog, o mundodocker.com.br, hoje vamos mostrar um pouco mais de prática no Docker, vamos colocar em containers algumas aplicações e ver como é fácil ter seu ambiente totalmente portável. Para você que está começando com Docker, esse post será útil para entender e aprender como você pode começar, em casa mesmo, a mexer com Docker e fazer deploy de aplicações com ele. Já você que conhece Docker e já utiliza ele em seu ambiente, terá a oportunidade de pegar algumas dicas de como pode melhorar seu processo de deploy e criação de imagens.

Vamos lá:

 NodeJS

Vamos montar primeiro uma imagem de nossa aplicação, neste exemplo vamos utilizar o Framework Express do node. Primeiro crie um pasta, neste caso chamamos de app:

mkdir app

Crie dentro dessa pasta dois arquivos, package.json:

{
 "name": "app-node-mundodocker",
 "private": true,
 "version": "0.0.1",
 "description": "Teste App Node em Docker",
 "author": "MundoDocker <[email protected]>",
 "dependencies": {
 "express": "3.2.4"
 }
}

E index.js:

var express = require('express');

// Constants
var PORT = 8080;

// App
var app = express();
app.get('/', function (req, res) {
 res.send('Minha App Noden');
});

app.listen(PORT);
console.log('Running on http://localhost:' + PORT);

Em seguida crie o arquivo Dockerfile:

FROM centos:centos6

# Habilita o repositório epel no CentOS
RUN yum install -y epel-release
# Instala o node e o npm
RUN yum install -y nodejs npm

# Instala as dependências 
COPY package.json /src/package.json
RUN cd /src; npm install

# Copia a app para a pasta src do container
COPY . /src

EXPOSE 8080
CMD ["node", "/src/index.js"]

Agora vamos criar a imagem:

docker build -t mundodocker/app-node-mundodocker .

Fácil né? Agora só criar o container e testar:

docker run -p 9090:8080 -d mundodocker/app-node-mundodocker

Se você acessar: http://seuip:9090 deve aparecer uma página como essa:

NodeApp

Rails

Agora vamos montar uma imagem utilizando uma aplicação em rails, primeiro vamos criar a pasta onde em seguida coloque nela os arquivos da aplicação e crie o Dockerfile:

FROM ruby:latest 
ENV HOME /home/rails/webapp 

# Instala as dependencias
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs 
WORKDIR $HOME 

# Instala as gems necessárias
ADD Gemfile* $HOME/ 
RUN bundle install 

# Adiciona os arquivos a pasta home 
ADD . $HOME 

# Executa o comando
CMD ["rails", "server", "--binding", "0.0.0.0”]

Vamos criar a imagem:

docker build -t mundodocker/app-rails-mundodocker .

Agora só criar o container e testar:

docker run -p 3000:3000 -d mundodocker/app-rails-mundodocker

Acesse http://seuip:3000 e você deverá ter um retorno desses:

RailsApp

Python

Para uma aplicação python vamos criar uma pasta chamado app e dentro dela criar um arquivo chamado app.py:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
 return 'Minha App em Python!n'

if __name__ == "__main__":
 app.run(host="0.0.0.0", debug=True)

E também um Dockerfile:

FROM orchardup/python:2.7
RUN pip install Flask
ADD . /code
WORKDIR /code
CMD python app.py

Em seguida vamos gerar uma imagem desse ambiente:

docker build -t mundodocker/app-python-mundodocker .

Fácil né? Agora só criar o container e testar:

docker run -d -p 5000:5000 mundodocker/app-python-mundodocker

Se você acessar: http://seuip:5000 deve aparecer uma página como essa:

PythonApp

Baseado nesses exemplos você pode ir modificando e acrescentando o que for necessário para sua aplicação, não esquecendo que você pode criar links entre as aplicações, trazendo maior facilidade e segurança para seu ambiente.

Gostou? Nos ajude divulgando o Blog, grande Abraço!

Escalando o MySQL com Docker e MaxScale

Oi Pessoal,

Não, hoje o post não é nosso :). Mas queremos divulgar um ótimo conteúdo criado por um de nossos parceiros, o MySQLBox, que é um dos maiores blogs sobre o SGBD MySQL e é mantido por um grande amigo nosso.

Então não deixe de ler o post: Escalando Mysql com Docker e Maxscale e veja como o Docker pode ajudar a escalar seu ambiente de banco de dados de forma fácil e rápida.

Grande abraço!

Link entre Containers – Parte 2

Olá!

Dando prosseguimento a primeira parte, vou trazer hoje como o Docker cria o tunelamento entre os containers para criar o Link. Como você viu aqui no Blog é possível criar um acesso seguro entre os containers sem a necessidade de expor portas tcp/udp tanto do host quanto do próprio container, para isso basta utilizar o parâmetro “link” e você vinculará dois containers. Mas como o Docker fazer com que esse acesso seja seguro e confiável? Basicamente de duas formas, são elas:

1 – Variáveis de ambiente:

O Docker cria diversas variáveis ​​de ambiente quando você cria um link entre os container. Docker, ele automaticamente as variáveis ​​de ambiente no container de destino com base nos parâmetros –link, ele também irá expor todas as variáveis ​​de ambiente provenientes do container de origem. Essas variáveis podem vir de:

  • Do comando ENV, utilizado na criação da imagem de origem via Dockerfile;
  • Das opções -e, –env e –env-file no comando docker run quando o container de origem é criado.

Essas variáveis ​​de ambiente possibilitam acessar programaticamente as informações do container de origem, ou seja podemos automatizar tarefas de deploy utilizando as variáveis carregadas de um container para o outro..

Aviso: É importante compreender que todas as variáveis ​​de ambiente provenientes de um container são disponibilizados para qualquer outro container que esteja ligado a ele. Isso poderia ter sérias implicações de segurança se dados sensíveis são armazenados nas variáveis de ambiente (como pode exemplo usuário e senha de banco de dados).

O Docker define um <alias>_NAME padrão como variável de ambiente para cada container de destino listado no parâmetro –link. Por exemplo, se um novo container chamado web está ligado a um container de banco de dados chamado db via –link db: webdb, então Docker cria uma variável WEBDB_NAME=/web/ webdb no container web.

Docker também define um conjunto de variáveis ​​de ambiente para cada porta exposta pelo container de origem. Cada variável tem um prefixo único no formulário:

<name>_PORT_<port>_<PROTOCOL>

Os componentes desses prefixos são:

  • O  alias <name> especificado no parâmetro –link (por exemplo, webdb);
  • A <port> exposta no container de origem;
  • O <protocol>, se é TCP ou UDP;

Docker usa este formato de prefixo para definir três variáveis ​​de ambiente distintas:

  • A variável prefix_ADDR contém o endereço IP a partir do URL, por exemplo WEBDB_PORT_5432_TCP_ADDR = 172.17.0.82.
  • A variável prefix_PORT contém apenas o número da porta, por exemplo WEBDB_PORT_5432_TCP_PORT = 5432.
  • A variável prefix_PROTO contém apenas o protocolo, por exemplo WEBDB_PORT_5432_TCP_PROTO = tcp.

Se o container expõe várias portas, uma variável de ambiente é definido para cada porta exposta. Isso significa, por exemplo, se um container expõe 4 portas o Docker cria 12 variáveis ​​de ambiente, 3 para cada porta.

Além disso, Docker cria uma variável de ambiente chamada <alias>_PORT. Esta variável contém do container de origem e a primeira porta exposta. A ‘primeira’ porta exposta é definida como a de menor número. Agora, considere essa variável: WEBDB_PORT=tcp: //172.17.0.82:5432, Se essa porta é usada para TCP e UDP, você deve especificar o protocolo tcp primeiro.

Agora na prática, vamos criar um container chamado site ligado a um container chamado db, veja o retorno do comando env dentro do container web:

    $ docker run --rm --name site --link db:db mundodocker/app env
    . . .
    DB_NAME=/site/db
    DB_PORT=tcp://172.17.0.5:5432
    DB_PORT_5432_TCP=tcp://172.17.0.5:5432
    DB_PORT_5432_TCP_PROTO=tcp
    DB_PORT_5432_TCP_PORT=5432
    DB_PORT_5432_TCP_ADDR=172.17.0.5
    . . .

Você pode ver que Docker criou uma série de variáveis ​​de ambiente com informações úteis sobre o container de origem ‘db‘. Cada variável é prefixado com DB_, que é preenchida a partir do alias especificado acima. Se o alias fosse db1, as variáveis ​​seriam prefixado com DB1_. Você pode usar essas variáveis ​​de ambiente para configurar suas aplicações para se conectar ao banco de dados no container db. A conexão será segura e privada; apenas o container site será capaz de falar com o container db.

Importante sobre variáveis ​​de ambiente Docker
Ao contrário de entradas de host no arquivo /etc/hosts, os endereços IP armazenados nas variáveis ​​de ambiente não são atualizados automaticamente se o container de origem é reiniciado. É recomendado a utilização das entradas de host em /etc/hosts para atualizar automaticamente o endereço IP de containers ligados.

As variáveis ​​de ambiente só são definidas para o primeiro processo no container. Alguns daemons, como sshd, limpará essas variáveis em uma nova conexão.

2 – Atualizando o arquivo / etc / hosts

Além das variáveis ​​de ambiente, o Docker adiciona uma entrada de host para o container de origem no arquivo /etc/hosts do container de destino. Veja como fica o /etc/hosts do container de destion:

$ docker run -t -i --rm --link db:sitedb mundodocker/app /bin/bash
root@aed84ee21bde:/opt/app# cat /etc/hosts
172.17.0.7  aed84ee21bde
. . .
172.17.0.5  sitedb 6e5cdeb2d300 db

Você pode ver duas entradas de host, a primeira é uma entrada para o container site que usa o Container ID como um nome de host. A segunda entrada utiliza o alias para referenciar o endereço IP do container db. Quer testar? Ótimo, do container que você acabou de criar (sitedb), você pode pingar os nomes definidos no link, por exemplo:

root@aed84ee21bde:/opt/app# ping db
PING webdb (172.17.0.5): 48 data bytes
56 bytes from 172.17.0.5: icmp_seq=0 ttl=64 time=0.267 ms
56 bytes from 172.17.0.5: icmp_seq=1 ttl=64 time=0.250 ms
56 bytes from 172.17.0.5: icmp_seq=2 ttl=64 time=0.256 ms

Você pode ver que o nome db responde ao ip do container onde está o seu banco de dados, que resolve para 172.17.0.5. Você pode usar essa entrada do host para configurar um aplicativo para fazer uso de seu container db.

Nota: É possível ligar vários container de destino em um único de origem. Por exemplo, você pode ter vários (com nomes diferentes) containers web conectados ao seu container db.

Se você reiniciar o container db, os containers ligados via /etc/hosts serão atualizados automaticamente com novo endereço IP do container de origem, permitindo que a comunicação continue.

Legal né? a partir disso é possível criar sistemas distribuídos de forma mais fácil, uma utilização bem importante é relacionado a criar link entre containers de aplicação e de volume, isso será tratado em posts futuros.

Estaremos ter ajudado, e tendo dúvidas nos avise, e claro ajude divulgando o Blog.

Abraço!

Cluster Mongo em Docker

Opa!

Hoje o post será mais prático, e queremos trazer para vocês uma forma de criar um cluster de MongoDB utilizando Docker. O próprio Docker tem um tutorial de como você pode criar a sua imagem de mongo e executá-lo dentro do Docker, para quem não viu ainda, segue o link. Para quem não conhece, MongoDB é um tipo de banco de dados orientado a documentos ou seja, utiliza o conceito de dados e documentos auto contidos e auto descritivos, e isso implica que o documento em si já define como ele deve ser apresentado e qual é o significado dos dados armazenados na sua estrutura.

O MongoDB também é chamado de banco de dados NoSql, mas isso é outro assunto . O que veremos neste artigo é como você pode montar um cluster de instâncias do mongo utilizando como backend containers Docker. Isso é possível pois o existe na “caixa” do mongo algumas formas de se construir um cluster, uma delas é utilizando o método de replica set, que consiste em ter instâncias  para onde a informação será replicada, e dessa forma garantir a persistência das informações, abaixo segue uma imagem ilustrativa de como isso funciona:

Dessa forma garantimos a persistência e tolerância a falha dos dados que estão sendo armazenados. Neste post mostraremos como utilizar essa abordagem, não entraremos em detalhes mais fundos do Mongo pois não é este o objetivo.

Vamos lá?

Antes de tudo, é recomendável que os servidores possam ser acessíveis via nome, caso não seja possível, você pode adicionar nos hosts os endereços para que isso seja temporariamente possível.

Em seguida precisamos criar o diretório no host onde será persistido os dados do banco:

$ mkdir /opt/mongo
$ mkdir /opt/mongo/data $ cd /opt/mongo

É importante lembrar que essas pastas devem estar criadas em todos os nós, para que dessa forma seja possível persistir os dados em todos os nós.

Agora você precisa gerar uma chave que será utilizada para realizar a sincronia entre as replicas, e garantir que os dados além de trafegar de forma segura, estejam replicados entre todos os nós, essa chave deve ser copiada para todos os nós também.

$ openssl rand -base64 741 > mongodb-keyfile $ chmod 600 mongodb-keyfile $ chown 999 mongodb-keyfile

Configurado este arquivo, precisamos subir um container para realizar algumas tarefas administrativas, para depois subir o cluster propriamente dito:

$ docker run --name mongo -v /opt/mongo/data:/data/db -v /opt/mongo:/opt/keyfile --hostname="node1" -p 27017:27017 -d mongo:2.6.5 --smallfiles

Vamos as configurações agora:

$ docker exec -it mongo /bin/bash
root@node1:/# mongo
> use admin
db.createUser( {
     user: "admin",
     pwd: "SENHA_DE_ADMIN",
     roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
   });

db.createUser( {
     user: "root",
     pwd: "SENHA_DE_ROOT",
     roles: [ { role: "root", db: "admin" } ]
   });
> exit
root@node1:/# exit

Remova o container para que possamos agora subir o ambiente todo:

$ docker stop mongo
$ docker rm mongo

Agora sim vamos subir o ambiente:

$ docker run --name mongo -v /etc/hosts:/etc/hosts -v /opt/mongo/data:/data/db -v /opt/mongo:/opt/keyfile --hostname="node1" --add-host node1.db:${node1} --add-host node2.db:${node2} --add-host node3.db:${node3} -p 27017:27017 -d mongo:2.6.5 --smallfiles --keyFile /opt/keyfile/mongodb-keyfile --replSet "rs0"

Acesse este container para inicializar o cluster:

$ docker exec -it mongo /bin/bash
root@node1:/# mongo
> use admin
> db.auth("root", "SENHA_DE_ROOT");
> rs.initiate()
{
         "info2" : "no configuration explicitly specified -- making one",
         "me" : "node1.db:27017",
         "info" : "Config now saved locally.  Should come online in about a minute.",
         "ok" : 1
}

> rs0:PRIMARY> rs.conf()
{
        "_id" : "rs0",
        "version" : 1,r
        "members" : [
              {
                  "_id" : 0,
                  "host" : "node1.db:27017"
              }
        ]
}

Nos demais nós, suba os containers da seguinte forma:

Servidor 2

$ docker run --name mongo -v /etc/hosts:/etc/hosts -v /opt/mongo/data:/data/db -v /opt/mongo:/opt/keyfile --hostname="node2" -p 27017:27017 -d mongo:2.6.5 --smallfiles --keyFile /opt/keyfile/mongodb-keyfile --replSet "rs0"

Servidor 3

$ docker run --name mongo -v /etc/hosts:/etc/hosts -v /opt/mongo/data:/data/db -v /opt/mongo:/opt/keyfile --hostname="node3" -p 27017:27017 -d mongo:2.6.5 --smallfiles --keyFile /opt/keyfile/mongodb-keyfile --replSet "rs0"

Volte até o servidor 1, acesse o container de mongo e execute os comandos:

$ docker exec -it mongo /bin/bash
root@node1:/# mongo
> use admin
> db.auth("root", "SENHA_DE_ROOT");
> rs0:PRIMARY> rs.add("node2.db") 
> rs0:PRIMARY> rs.add("node3.db") 
> rs0:PRIMARY> rs.status()

O status devem ser algo parecido com este retorno:

rs0:PRIMARY> rs.status()
{
 "set" : "rs0",
 "date" : ISODate("2017-05-16T15:43:30Z"),
 "myState" : 1,
 "members" : [
 {
 "_id" : 0,
 "name" : "node1:27017",
 "health" : 1,
 "state" : 1,
 "stateStr" : "PRIMARY",
 "uptime" : 578713,
 "optime" : Timestamp(1494371417, 1),
 "optimeDate" : ISODate("2017-05-09T23:10:17Z"),
 "electionTime" : Timestamp(1494371963, 1),
 "electionDate" : ISODate("2017-05-09T23:19:23Z"),
 "self" : true
 },
 {
 "_id" : 1,
 "name" : "node2.db:27017",
 "health" : 1,
 "state" : 2,
 "stateStr" : "SECONDARY",
 "uptime" : 577454,
 "optime" : Timestamp(1494371417, 1),
 "optimeDate" : ISODate("2017-05-09T23:10:17Z"),
 "lastHeartbeat" : ISODate("2017-05-16T15:43:29Z"),
 "lastHeartbeatRecv" : ISODate("2017-05-16T15:43:29Z"),
 "pingMs" : 0,
 "syncingTo" : "node1:27017"
 },
 {
 "_id" : 2,
 "name" : "node3.db:27017",
 "health" : 1,
 "state" : 2,
 "stateStr" : "SECONDARY",
 "uptime" : 577354,
 "optime" : Timestamp(1494371417, 1),
 "optimeDate" : ISODate("2017-05-09T23:10:17Z"),
 "lastHeartbeat" : ISODate("2017-05-16T15:43:29Z"),
 "lastHeartbeatRecv" : ISODate("2017-05-16T15:43:29Z"),
 "pingMs" : 0,
 "syncingTo" : "node1:27017"
 }
 ],
 "ok" : 1
}
rs0:PRIMARY>

Caso tenha ocorrido algum erro na sincronização das informações, você poderá visualizar através deste retorno, e claro terá informações para realizar a correção do caso. Existem muitas maneiras de realizar esse tipo de configuração de cluster, algumas mais complexas e outras mais simples, em nosso teste esta foi a forma onde tivemos mais objetividade e assertividade na configuração, baseado nessas informações você pode montar/adaptar os passos que atendem a sua demanda.

Um ponto muito importante nesse ambiente é a forma como ocorre a recuperação em caso de desastre, pois você pode parar o master (primário) e você poderá ver através do rs.status(); o comportamento do cluster elegendo um novo master, ou seja, dessa forma seu cluster ficará quase que 100% a prova de falhas ;).

Esperamos ter ajudado, e se tiver alguma dificuldade ou dúvida com relação a este ambiente por favor entre em contato conosco para que possamos ajudar o/. E como sempre, nos ajude divulgando o blog, isso é muito importante para nós.

Grande abraço!

Docker e .Net

Oi pessoal!

Rodar .Net em container? SIM!! é possível, e vamos mostrar hoje como você pode fazer esse ambiente funcionar e testar sua aplicação. Bem, antes de tudo você precisa entender todo o movimento que a Microsoft vem fazendo para que sua linguagem de programação torne-se cada vez mais utilizada pelos desenvolvedores, para isso eles repensaram tudo que já fizeram, e lançaram uma versão do .Net com features muito parecidas como as encontradas em node e ruby on rails, e a batizaram de ASP.NET Core. Conceitualmente o ASP.NET Core é uma plataforma open source de desenvolvimento leve e eficiente para aplicação escritas em .net, veja abaixo uma lista dos principais pontos do asp.net Core:

  • Suporte integrado para criação e utilização de pacotes NuGet;
  • Pipeline de request mais leve e modular;
  • Ambiente configurado para cloud;
  • Suporte a injeção de dependência;
  • Novas ferramentas que facilitam o desenvolvimento web;
  • Capacidade de hospedar o processo no IIS ou em um Self-Host;
  • Suporte para desenvolvimento de aplicação asp.net em Windows, Linux e Mac;
  • Open Source e com comunidade ativa;
  • Todos os pacotes do .Net no NuGet;
  • .Net Core construido com suporte a versionamento side-by-side;
  • Uma unica Stack para Web UI e Web APIs;

Por que a Microsoft vem tomando esse rumo? Simples, para atrair mais pessoas para o seu produto, tendo em vista que as principais linguagens, ou as que mais crescem tem nativas todas essas features, a melhor alternativa para a Microsoft foi mudar a abordagem e atrair pessoas para melhorar seu produto/serviço e claro, isso consolida ainda mais o Windows Azure, fazendo com o desenvolvimento e deploy de Apps em .net torne-se menos doloroso.

Vamos ver isso rodando em um container?

Simples, tendo o Docker instalado (em qualquer host, seja ele Windows, Linux ou Mac), execute:

docker run -it microsoft/dotnet:latest

Dentro do container, você deve criar sua aplicação, de forma parecida com o que ocorre com o ruby on rails, para isso o .net core disponibiliza um utilitário chamado: dotnet, veja:

mkdir app
cd app
dotnet new

O comando dotnet new criará toda a estrutura necessária para rodar uma aplicação hello world básica, ele criará um arquivo chamado project.json com o seguinte código:

{
 "version": "1.0.0-*",
 "compilationOptions": {
 "emitEntryPoint": true
 },
 "dependencies": {
 "Microsoft.NETCore.Runtime": "1.0.1-beta-*",
 "System.IO": "4.0.11-beta-*",
 "System.Console": "4.0.0-beta-*",
 "System.Runtime": "4.0.21-beta-*"
 },
 "frameworks": {
 "dnxcore50": { }
 }
}

Esse arquivo project.json contém as informações de dependência que sua aplicação precisará para rodar, é fundamental que você informe nesse aquivo todos os pacotes que necessita. Nessa mesma estrutura será criado um arquivo chamado Program.cs com este código:

using System;
namespace ConsoleApplication
{
 public class Program
 {
 public static void Main(string[] args)
 {
 Console.WriteLine("Hello World!");
 }
 }
}

Agora basta realizar a instalação das dependências:

dotnet restore

E pronto, sua aplicação estará pronta para rodar, basta executar o comando:

dotnet run

 Fácil certo? E é possível deixar ainda mais fácil, para isso, basta criar Dockerfile e gerar uma imagem com esse ambiente:

FROM microsoft/dotnet:latest
RUN mkdir /app
WORKDIR /app
RUN ["dotnet", "new"]
RUN ["dotnet", "restore"] 
ENTRYPOINT ["dotnet", "run"]

Agora crie a imagem: docker build -t myapp .

E crie um container baseado nessa nova imagem: docker run -d myapp , quer ver o que retornou nessa execução? docker logs iddocontainer, ele deverá retornar algo desse tipo: Hello World!.

É claro que você pode aprimorar esse ambiente, principalmente se quiser rodar uma aplicação web, mas esse ambiente básico já serve como inicio para seus testes ;).

Gostou? Então nos ajude divulgando o mundodocker.com.br, grande abraço!

Docker Overlay

Oi Pessoal,

Como vimos nesse post, é possível utilizar plugins diversos para resolver o desafio da rede, e mostramos nesse post um pouco da teoria de como usar o driver de overlay, hoje queremos mostrar isso na prática, e para isso, nada melhor do que colocar a mão na massa, certo?  Claro, mas antes precisamos entender um pouco de teoria, e lá vamos nós.

Se você estiver utilizando o Swarm, não é necessário configurar um serviço de chave-valor externo, pois o próprio Swarm faz o controle e persistência das informações de rede que você utiliza. E você deve ter cuidado, pois se quiser utilizar o Overlay com um serviço externo de chave-valor, o modo de cluster via Swarm fica impossibilitado.

Veja abaixo uma tabela com algumas informações relevantes sobre o funcionamento do Overlay:

Protocolo Porta Descrição
udp 4789 Data plane (VXLAN)
tcp/udp 7946 Control plane

Ou seja, você deve cuidar para que em seus firewalls essas portas estejam liberadas, caso contrario a comunicação entre os nós não ocorrerá, o que impossibilitará o funcionando do Overlay.

Veja abaixo os principais parâmetros que você deve ter atenção:

Opção Descrição 
--cluster-store=PROVIDER://URL
 Endereço do seu servidor/serviço de chave-valor 
--cluster-advertise=HOST_IP|HOST_IFACE:PORT
 IP ou interface do host que será utilizado para comunicação do cluster 
--cluster-store-opt=KEY-VALUE OPTIONS
 Configuração opicional, onde é possível definir regras de monitoramento dos hosts e validação TLS

Ok Cristiano, entendi tudo isso, mas como vamos testar, qual será o ambiente de laboratório que vamos seguir? Vamos lá, para exemplificar como será o ambiente que vamos montar, segue abaixo uma imagem onde ilustra o funcionamento do Docker com o serviço de chave-valor, todos os hosts consultam esse serviço para identificar quais redes existem e qual bloco/ip deve ser alocado por container. Veja:

Engine on each host

Vamos colocar a mão na massa?

Dependências/Configuração

Você deve ter um serviço de chave valor, no qual o Docker persistirá as informações de rede que você criar, em nosso lab utilizamos o Consul dentro de um container Docker, rodando em um server a parte dos que participarão do ambiente multi-host, para isso executamos:

[root@consul ~]# docker run -d  -p "8500:8500"  -h "consul"  progrium/consul -server -bootstrap

Dessa forma iniciamos um container com Consul, mapeando a porta 8500 do host para o container, ou seja, para ter acesso ao serviço do Consul basta acessar ip-do-host:8500. Agora vamos ao nosso ambiente de Docker.

Nos hosts de Docker (obviamente você já tem o Docker instalado, mas se quiser saber como instalar, veja esse post ) você precisará configurar o daemon para consultar o Consul e buscar as informações de rede, em nosso laboratório utilizamos o CentOS, com isso, o arquivo a ser modificado é o: /lib/systemd/system/docker.service, e deixamos da seguinte forma:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --cluster-advertise=eth0:2376 --cluster-store=consul://ip-do-consul:8500
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

Feito isso, basta reiniciar o serviço e seguirmos para o próximo passo.

Utilização/Testes

Agora que você já definiu um serviço de chave-valor a ser consultado, basta você criar a sua rede com o driver Overlay, para isso:

[root@docker01 ~]# docker network create --driver overlay rede1

Você pode definir ainda qual o bloco de ip que deseja para essa rede, caso não faça essa definição, o Docker associará um bloco automaticamente para você. Fácil certo? Basta testarmos, para isso vamos validar em todos os hosts se ambos estão visualizando a mesma rede, execute esse comando em qualquer outro host:

[root@docker01 ~]# docker network ls

Será retornando algo como isso:

NETWORK ID          NAME                DRIVER
64507d0be843f        rede1               overlay
d0bdae8fbe7bd        bridge              bridge
1c0eb8f68962d        none                null
3412c2496d0eb        host                host
697102a22e8d2        docker_gwbridge     bridge

 Vamos utilizar essa rede, crie os containers em pelo menos 2 hosts, informando essa nova rede, veja:

[root@docker01 ~]# docker run -it --net=rede1 centos /bin/bash

Agora basta pingar ou acessar os serviços entre os containers que estão nessa mesma rede.

Dessa forma você pode definir uma rede diferente por grupo de containers, e pode ainda isolar essas redes utilizando o método VXLAN, para isso deve passar como parâmetro na criação da rede o seguinte argumento: –opt “com.docker.network.driver.overlay.vxlanid_list=257″, esse parâmetro fará com que essa rede receba uma vlan, ou seja, todo o trafego direcionado a essa rede receberá uma identificação, impossibilitando que outros containers que não estejam nessa vlan tenha acesso a esse trafego. 

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

Grande abraço!

Docker Run – Avançado

Olá pessoal,

Hoje vamos falar um pouco mais sobre as opções que talvez muitas pessoas não conhecem sobre o Docker run e que podem ajudar você diariamente a subir suas aplicações com mais segurança e também com mais praticidade. A ideia por trás desse post não é mostrar como criar um container, mas sim quais as opções novas e que podemos utilizar em nosso dia a dia.

PID settings (–pid)

Por padrão todos os containers possuem o PID namespace habilitado. O Namespace PID remove o ponto de vista dos processos do sistema e permite ids de processos para ser utilizado. Em alguns casos você pode querer rodar alguma ferramenta de depuração em seu container para que ele consiga visualizar os processos do seu host, então basta iniciar o container com a opção de –pid ativado:

docker run -it --rm --pid=host imagem

É possível também utilizar o –pid para depurar as informações de outro container, para isso vamos iniciar a execução de um container com mongoDB e depois um container para realizar a depuração

docker run --name mongo -d mongodb 
docker run --it --pid=container:mongo imagem

–dns

Por padrão os containers irão compartilhar os mesmos servidores de DNS que estão sendo utilizados em seu host, então na hora de criação de cada container você pode utilizar o parâmetro –dns=”8.8.8.8″ por exemplo.

–add-host

O docker ja cria dentro de cada container em /etc/hosts o arquivo com algumas configurações de rede, como:

172.17.0.2 02ed3f564f1b
127.0.0.1 localhost
fe00::0 ip6-localnet

Porem é possivel na hora da criação do container você adicionar mais uma entrada dentro do arquivo de hosts para isso basta colocar a opção –add-host em seu “docker run”

 docker run -it --add-host entrada:ip -d centos

–security-opt

Nas versões mais recentes do Docker é possível você limitar para que os comandos que exigem privilégios dentro do Docker não sejam mais executado, como: su ou sudo para isso basta executar:

docker run --security-opt no-new-privileges -d centos

–restart

Utilizando essa opção é possível realizar a reinicialização de containers a partir de determinados evento, são esses: on-failure, always, unless-stopped.

  • On-failure: Reinicia somente se o status de saída do container por diferente de 0, é possível limitar o numero de tentativas de reinicialização. O docker irá esperar 100ms na primeira vez que tentar reiniciar o container, caso vá para segunda vez então irá esperar 200ms e depois 400ms e assim dependendo do número de tentativas.
 docker run --restart=on-failure:3 centos
  • Always: Sempre reinicie o container independentemente do status de saída. Na reinicialização do servidor, o container irá subir automaticamente após o serviço do docker ser startado.
 docker run --restart=always centos
  • Unless-Stopped: Inicialize o container independentemente do status de saída, porem na reinicialização do servidor ou do serviço do Docker o container não irá subir automaticamente;
 docker run --restart=unless-stopped centos

O status de saída exibido pelo Docker no docker run pode ser visto utilizando a seguinte opção:

 docker run redis; echo $?

Existem alguns números já conhecidos, 125 (Problema com o docker daemon), 126 (Comando não pode ser invocado), 127 (Comando não pode ser encontrado).

–isolation

Essa opção é útil quando você executar Docker no Windows essa opção define qual tecnologia ira ser usada para o isolamento do container, no caso do linux é default e no Windows temos: process e Hyper-v.

docker run -d --isolation process busybox top

–device

Um dia poderá aparecer a necessidade para que você anexe um disco a seu container, então com essa opção você pode anexar diretamente um disco a seu container:

docker run --device=/dev/sdb:/dev/xvdc -d centos

–rm

Por padrão quando você cria um container sem passar a opção de “–rm” quando esse container acaba parando por algum motivo, ele não é removido do Docker e também nem o seu volume. Porem caso você deseja que remova o container você poderá passar o parâmetro na hora da criação do container.

docker run -it -v /home/container:/home --rm -d centos

Nesse modo de criação de container, quando o container por algum motivo parar o docker irá excluir-lo e também apagar o volume junto. Para que NÃO APAGUE O VOLUME você deve criar um volume com a opção de docker volume create.... e na hora da criação desse container passar o nome do volume.

docker run -it --rm -v volume:/home -d centos

Então ta pessoal, por hoje era isso, espero que tenham gostado, em breve faremos posts mais focados no baixo nível do Docker para que você possa saber como todas as opções funcionam e como utiliza-las. Já sabe, nos ajude divulgando o blog

Link entre containers – Parte 1

Olá pessoal,

Hoje vou mostrar aqui no blog como podemos interligar containers sem precisar expor as portas do nosso host. Mapeamentos de portas não são a única maneira de conectar um container ao outro. Docker também tem um sistema de ligação que permite interligar vários containers juntos e enviar as informações de conexão de um para outro.

A importância de nomear

Para estabelecer os links, o Docker conta com os nomes dos container. Você já viu que cada container que você criar tem um nome criado automaticamente, mas você mesmo pode dar um nome ao container. Esta nomeação fornece duas funções úteis:

1 – Torna-se útil quando você precisa criar containers com funções especificas e precisa lembrar-se deles, por exemplo um container web, ou mysql, etc.

2 – Fica mais fácil fazer o link entre os containers, pois você não precisa decorar um nome que foi gerado aleatoriamente, basta você linkar seu container web com seu container mysql, por exemplo.

Você pode nomear seu recipiente usando o parâmetro –name, por exemplo:

$ docker run -d -P --name web training/webapp python app.py

Isso inicia um novo container e usa o parâmetro –name para nomea-lo como web. Você pode ver o nome do container utilizando o comando docker ps.

$ docker ps -l
CONTAINER ID  IMAGE                  COMMAND        CREATED       STATUS       PORTS                    NAMES
aed84ee21bde  training/webapp:latest python app.py  12 hours ago  Up 2 seconds 0.0.0.0:49154->5000/tcp  web

Você também pode usar docker inspect para retornar o nome do container.

Nota: Os nomes dos containers são únicos, então para reutilizar algum nome você deverá parar o container, remover e criar o container com o nome desejado.

Comunicação via Link

O Link permite que você trafegue informações entre os containers de forma segura, pois quem conhece um container conhece apenas o seu par definido no link. Quando você configurar um link, você cria um elo de ligação entre um container de origem e um container de destino. Para criar um link, você deve utilizar o parâmetro –link. Em primeiro lugar, deve-se criar um container que será origem de dados para outro container, desta vez vamos criar o container de banco de dados:

$ docker run -d --name db training/postgres

Isso criará um novo container chamado db a partir da imagem do postgres, que contém um banco de dados PostgreSQL.

Agora, você precisa excluir o container web criado anteriormente para que você possa substituí-lo por outro vinculado ao db:

$ docker rm -f web

Agora, crie um novo container chamado web e vincule com o seu container db.

$ docker run -d -P --name web --link db:db training/webapp python app.py

Isto irá ligar o novo container web com o container db criado anteriormente. O parâmetro –link fica da seguinte forma:

--link <nome ou id>:alias

Você pode ver que o container web agora está ligado ao container db, o que lhe permitirá coletar as informações do container db e claro do banco de dados que encontra-se lá.

Como pode notar, um link permite que um container de origem forneça informações sobre si próprio e de seus serviços a outro container de destino. No nosso exemplo, o destinatário web, pode acessar informações sobre o banco de dados de origem. Para fazer isto, o Docker cria um túnel seguro entre os container que não precisam expor as portas externamente, você deve ter notado que quando iniciamos o container db nós não usamos o parâmetro -P ou -p,  isso é uma grande vantagem em utilizar o link, nós não precisamos expor o container ou serviço, no nosso exemplo o banco de dados PostgreSQL, para toda a rede.

Na parte 2 desse tutorial veremos como o Docker cria esse túnel e permite a comunicação entre containers, fique atento as novidades aqui no Blog, e nos ajude divulgando o mundodocker.com.br

Abraço!

Kubernete parte III

Olá pessoal,

 

Depois de algum tempo sem falar sobre Kubernetes hoje vamos mostrar como podemos criar um ambiente altamente disponível de servidores web.

Conforme comentado nos posts anteriores, podemos criar um service Web e dentro desse service eu posso ter milhões de containers, onde o Kubernetes fará toda a parte de Balanceamento de carga com o que chamamos de Replication Controller.

Vamos criar então o Replication Controller:

 

vim web-rc.yml

apiVersion: v1
kind: ReplicationController 
metadata:
 name: web-controller
spec:
 replicas: 2
 selector:
   name: nginx
 template:
   metadata:
     labels:
       name: nginx
   spec:
     containers:
       - name: nginx
         image: nginx
         ports:
           - containerPort: 80

kind: É o tipo de objeto que o Kubernetes ira criar, nesse caso ele vai criar

Replicas: Quantos pods dessa imagem sempre deve existir, caso exista um número menor que o indicado, o Kubernetes irá criar outros pods até chegar ao número determinado em replicas.

 

Para criar o Replication Controller execute:

kubectl create -f web-rc.yml

 

Você poderá ver RC criado com o comando:

kubectl get replicationcontrollers

 

Agora vamos criar o Service que é aquele que faz com que o usuário consiga criar a aplicação:

 

vim web-service.yml

kind: Service
apiVersion: v1
metadata:
  name: web-service
spec:
  selector:
    name: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
kubectl create -f web-service.yml

Feito isso você pode executar o comando abaixo e verá que existe 2 pods de Nginx rodand:

kubectl get pods

Com tudo isso pronto você pode pegar e testar executando um curl no ip do seu servidor, no meu caso estou executando a partir do minion1, então vou acessar o minion2 e executar:

curl -qa http://seuip

E a página inicial do nginx será mostrada, você pode pegar e parar um pod e notará que o Kubernetes irá criar outro, pois no Replication Controller colocamos como 2 replicas.

Então tá pessoal por hoje era só, continue ligado em nosso canal e em breve estaremos fazendo um vídeo mostrando mais sobre o Kubernetes.

Rede no Docker

Oi pessoal!

Neste post vamos detalhar como o Docker trabalha com o ambiente multi-host, vamos trazer alguns exemplos práticos e vamos detalhar cada caso de uso. Boa leitura!

O que muda no Docker 1.9?

Bom, primeiramente o que existia até o Docker 1.8 continua, o que muda é que foram acrescentado alguns comandos, e como explicado neste post, na versão 1.9 a funcionalidade de rede do Docker é tratada como um plugin, sendo possível assim utilizar formas mais elaboradas de rede, sem a necessidade de modificação em sua aplicação. Abaixo uma listagem dos comandos adicionados:

  • docker network create
  • docker network connect
  • docker network ls
  • docker network rm
  • docker network disconnect
  • docker network inspect

Criando uma rede – Bridge

Quando você instala o Docker Engine, ele cria automaticamente uma interface local de comunicação, tanto para o host – container, quanto para container-container, chama-se docker0 , ela é uma interface virtual criada em modo bridge com a interface principal, isso faz com que seja possível o container se comunicar com a internet, geralmente é atribuído para essa interface é o ip: 172.21.0.1/16, e quando não definido, os containers terão um ip dessa rede.

Na versão 1.9 do Docker é possível criar basicamente dois tipos de rede: Bridge (forma tradicional, e acessível apenas de dentro do host) ou do tipo Overlay (que possibilita a comunicação entre outros hosts com Docker, possibilitando assim a criação de cluster de Docker). Abaixo você pode visualizar como é possível criar uma rede em modo Bridge:

$ docker network create minha-rede
cds4554wfedcsaafe564fef3648e8d9d181sase98d8ef8c7ed561e89d9
$ docker network inspect minha-rede
[
    {
        "Name": "minha-rede",
        "Id": "cds4554wfedcsaafe564fef3648e8d9d181sase98d8ef8c7ed561e89d9",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Config": [
                {}
            ]
        },
        "Containers": {},
        "Options": {}
    }
]

Claro que você pode criar uma rede especificando qual range de ip você deseja que seus containers utilizem, veja:

$ docker network create --driver=bridge --subnet=172.28.0.0/16 --ip-range=172.28.5.0/24 --gateway=172.28.5.254 br0
03449da9dc22133889c55b3497bcd821b83e64b20608a680ce6e5025bd491118
$ docker network inspect br0
[
 {
 "Name": "br0",
 "Id": "03449da9dc22133889c55b3497bcd821b83e64b20608a680ce6e5025bd491118",
 "Scope": "local",
 "Driver": "bridge",
 "IPAM": {
 "Driver": "default",
 "Config": [
 {
 "Subnet": "172.28.0.0/16",
 "IPRange": "172.28.5.0/24",
 "Gateway": "172.28.5.254"
 }
 ]
 },
 "Containers": {},
 "Options": {}
 }
]

Quando você criar o container basta especificar agora que deseja utilizar essa rede, com o comando abaixo é possível fazer isso:

$ docker run --net=br0 -itd --name=container3 busybox
b9b6cea6195c0b66133933364e806d14644f97625c2a7270170fa5b6e4984f22
$ docker network inspect br0
[
 {
 "Name": "br0",
 "Id": "03449da9dc22133889c55b3497bcd821b83e64b20608a680ce6e5025bd491118",
 "Scope": "local",
 "Driver": "bridge",
 "IPAM": {
 "Driver": "default",
 "Config": [
 {
 "Subnet": "172.28.0.0/16",
 "IPRange": "172.28.5.0/24",
 "Gateway": "172.28.5.254"
 }
 ]
 },
 "Containers": {
 "b9b6cea6195c0b66133933364e806d14644f97625c2a7270170fa5b6e4984f22": {
 "EndpointID": "32970bd2ebb403851b559f81ec9916ddd4f791d5a9c2f30a093a5c1626e7f089",
 "MacAddress": "02:42:ac:1c:05:01",
 "IPv4Address": "172.28.5.1/16",
 "IPv6Address": ""
 }
 },
 "Options": {}
 }
]

Legal não? Você pode criar uma arquitetura que possibilite você isolar determinados containers, e fazer com que eles não tenha acesso a internet por exemplo, isso é útil para containers que executam aplicação de apoio, como redis, mongo, etc.

Criando uma rede – Overlay

Note que no caso acima, como não foi definido parâmetros adicionais, o Docker criou uma rede em modo Bridge. Diferentemente do modo Bridge, o Overlay necessita que alguns requisitos sejam atendidos, dentre eles podemos destacar:

  • Acesso a um serviço de chave-valor distribuído, o Docker suporta Consul, Etcd ou ZooKeeper;
  • Um Cluster já montado com acesso a este serviço de chave-valor distribuído;
  • Daemon do Docker configurado corretamente em cada host do cluster.
  • Host com Kernel 3.16 ou superior.

As opções disponíveis para criação de uma rede Overlay são:

  • --cluster-store
  • --cluster-store-opt
  • --cluster-advertise

Também é uma boa ideia, embora não obrigatório, que você instale o Docker Swarm para gerenciar o cluster. O Swarm fornece o serviço de descoberta e gestão de servidor que pode te ajudar na implementação.

Quando você cria uma rede, o Docker Engine não sobrepõe a rede criada no momento da instalação. Você pode substituir esse padrão e especificar uma sub-rede diretamente usando a opção –subnet. Em uma rede em modo Bridge você pode criar apenas uma única sub-rede, uma rede Overlay suporta múltiplas sub-redes.

Além da opção --subnetwork, você também especificar os parametros --gateway, --ip-range e --aux-address. Veja como ficaria a criação da rede:

$ docker network create -d overlay
  --subnet=192.168.0.0/16 --subnet=192.170.0.0/16
  --gateway=192.168.0.100 --gateway=192.170.0.100
  --ip-range=192.168.1.0/24
  --aux-address a=192.168.1.5 --aux-address b=192.168.1.6
  --aux-address a=192.170.1.5 --aux-address b=192.170.1.6
  minha-rede-multihost

O único cuidado que você deve ter é não criar sub-redes conflitantes, isso causará um erro no momento da criação ou mau funcionando no ambiente que deseja montar.  Estando a rede criada, basta criar o container passando como parâmetro ao nome da rede, veja:

$ docker run -itd --net=minha-rede-multihost busybox

 

Nos próximos posts vamos trazer detalhadamente um ambiente com Overlay, desde a configuração dos pré-requisitos até a criação de containers em múltiplos hosts, quem sabe um vídeo .

Por hoje era isso, esperamos ter ajudado e tendo dúvidas nos avise para conversarmos, e claro, nos ajude divulgando o Blog!