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!

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 😉

Java em Docker

Olá pessoas, tudo bem?

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

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

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

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

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

Explicando.

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

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

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

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

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

$ docker build -t meujava:8 .

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

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

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

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

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

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

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

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

Por hoje era isso, no vemos ano que vem 😉

Grande abraço!

Cronjobs com Docker

Oi Pessoal,

Hoje vamos trazer para vocês um forma de resolver algo que é bem recorrente e comum em ambientes de produção, e que talvez acabe de tornando uma porta de entrada para o uso do Docker em maior escala. Dessa vez, você entenderá como é possível realizar o agendamento e execução de script utilizando a crontab dentro de containers Docker \o/.

Para quem ainda não sabe, dentro de ambiente like *unix é possível realizar o agendamento de scripts utilizando uma ferramenta chamada Crontab (para quem é do ambiente Microsoft, é o mesmo que o task scheduler, mas com mais poder 🙂 ), através dela você define o horário de execução para os scripts, usuário que será utilizado para a execução do mesmo, e claro, qual script deve ser executado. Pois bem, sabendo disso, é possível utilizar o Docker para que a execução desses scripts seja realizada dentro de containers.

Mas afinal, quais as vantagens disso?

Bem, a execução de script via crontab, pode gerar alguns desafios, principalmente se não há um controle rigoroso de quais scripts estão sendo agendados, dentre os desafios podemos destacar:

1 – Uso excessivo de recursos: Pode acontecer de algum script ter algum erro e fazer com que haja uso excessivo de recursos (memória, cpu) durante a sua execução, e acredite, isso é mais comum do que imagina. Existe formas de contornar isso, no entanto, nativamente não.

2 – Segurança na execução: Você pode definir qual usuário executará um determinado script, isso funciona muito bem dentro da crontab, no entanto, caso você não especifique, o usuário utilizado para a execução do script  será o mesmo que inicializou o serviço da cron, e geralmente este serviço inicializa com o usuário root, então…

Ok Cristiano, e como o Docker pode me ajudar?

Aeooooo mais um convertido, vamos ver como funciona na prática?

A primeira coisa que faremos é criar os diretório necessários, para isso, defina um diretório de trabalho, e nele crie uma pasta chamada “cron” e outra chamada “scripts”. Em seguida vamos buildar uma imagem Docker apenas com o que precisamos para realizar a execução dos scripts, como imagem base, vamos utilizar uma do NodeJS Alpine, lembrando que, neste caso nossa cron executará um script escrito em node, você deve adaptar a imagem de acordo com a sua necessidade (se seu script é em PHP, então a imagem deve ser PHP, e assim por diante) veja como ficou nosso Dockerfile:

FROM node:8-alpine
RUN apk update && apk add tzdata &&\ 
    cp /usr/share/zoneinfo/America/Sao_Paulo /etc/localtime &&\ 
    echo "America/Sao_Paulo" > /etc/timezone &&\ 
    apk del tzdata && rm -rf /var/cache/apk/*
CMD chown root:root /etc/crontabs/root && /usr/sbin/crond -f

Não preciso explicar este Dockerfile né, você já deve ter lido este post né? 😉 salve-o dentro da pasta “cron”.

Bem, agora precisamos montar o resto do ambiente, para este lab, vamos criar um arquivo chamado cron1 com o seguinte conteúdo:

0 7,19 * * * /usr/local/bin/node /home/mundodocker/hello.js >> /var/log/cronteste/hello.log 2>&1

Neste caso, o script será executado as 7h e as 19h todos os dias, salve-o dentro da pasta “cron” também.

Veja, que neste caso o script que deverá ser executado é o /home/mundodocker/hello.js que contém algo simples em node:

console.log("Hello world");

Salve-o dentro da pasta “scripts”.

Ok, agora estamos quase prontos, pelo menos, tudo que precisamos está pronto, se quisermos podemos utilizar essa estrutura, pois ai já contém tudo que é necessário, obvio que isso não basta, visto que a intenção é deixar tudo automatizado. Para isso, é necessário que você tenha o docker-compose instalado, com isso conseguimos automatizar 100% do ambiente. Como você já sabe, para utilizarmos o docker-compose, precisamos de um arquivo no formato yaml com as definições de nosso ambiente, veja como ficou nosso docker-compose.yml:

version: "3"
services:
    cron:
        build: cron
        container_name: cronteste
        volumes:
            - /var/log/cronteste:/var/log/cronteste
            - ./cron/cron1:/etc/crontabs/root
            - ./sripts:/home/mundodocker

Para validar, você pode executar o comando:

docker-compose up

Com isso ele fará o build da imagem e em seguida iniciará um container com esse agendamento. Além das opções acima, você pode por exemplo limitar os recursos desse container, inclusive definir um valor minimo para o mesmo. Outra possibilidade é iniciar este container com um usuário especifico, dessa forma você não terá problemas com aquela execução com usuário root 😉

Validou? Tudo certo? Agora vamos fazer com que esse mesmo comando seja executado na inicialização do servidor, visto que, ele ficará no somente enquanto o servidor estiver ligado, e obviamente os agendamentos serão perdidos, não queremos isso certo?

Pois bem, em sistema onde você tem o systemd (Ubuntu, RedHat, Fedora, CentOS) você deverá criar um novo service, para isso, crie dentro de: “/lib/systemd/system/” um arquivo com nome de: docker-cron.service com o seguinte conteúdo:

[Unit]
Description=Docker Cron
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/local/bin/docker-compose -f /home/mundodocker/docker-compose.yml up
ExecStop=/usr/local/bin/docker-compose -f /home/mundodocker/docker-compose.yml stop

[Install]
WantedBy=default.target

Criado o arquivo, basta fazer com que o systemctl releia o arquivo e adicione o serviço a sua base:

systemctl daemon-reload

Agora é simples, vamos adicionar este serviço ao startup do servidor:

systemctl enable docker-infra

Dessa forma você pode administrar da mesma forma que um serviço, ou seja, posso iniciar e parar esse agendamento a qualquer momento, e mesmo que o servidor seja reiniciado, o agendamento será persistido.

 

Ok, agora sim temos tudo 100% automático, não precisamos nos preocupar com mais nada, a não ser é claro em estender isso a  outros tipos de agendamento (se for este o seu caso é claro). Bom, por hora era isso, ficou com dúvida? Tem algo a contribuir? Por favor deixe nos comentários e vamos melhorando juntos 😉

 

Obrigado e grande abraço!

Traefik e Docker Swarm

Opa!

Acreditamos que um dos maiores desafios quando se trabalha com alguma tecnologia de cluster, é a forma como você vai disponibilizar o conteúdo para seu usuário/cliente, obviamente isso pode ser feito de diversas maneiras, e cada uma delas atender a uma necessidade e objetivo.

A intenção hoje é trazer à vocês uma forma simples de se disponibilizar conteúdo web (site, api, etc.) e que tem como backend o Docker Swarm, sim, hoje falaremos do Traefik, um poderoso proxy web dinâmico. Antes disso, temos que responder a seguinte dúvida: Por que diabos preciso de um proxy reverso dinâmico? Simples, por que as implementações atuais de Apache, Haproxy e Nginx foram desenvolvidas para serem estáticos, necessitando de intervenções para que as modificações sejam aplicadas. É claro que existem iniciativas que tratam isso, e são boas alternativas também, como é o caso do docker-flow-proxy e jwilder/nginx mas são presas ao que as tecnologias base oferecerem. No caso do traefik, a situação é bem diferente, ele é um proxy arquitetado e desenvolvimento para ser totalmente dinâmico e orientado a micro-serviços, além disso, ele suporta nativamente diversos tipos de backend, como é o caso do Docker Swarm, Kubernetes, Mesos, Docker apenas, Consul, dentre muitos outros.

Features

Algumas features/benefícios do Traefik, incluem:

  • Veloz.
  • Sem dependência, ele é um binário escrito em go.
  • Existe imagem oficial para Docker.
  • Fornece uma API Rest.
  • Reconfiguração sem a necessidade de reiniciar o processo.
  • Metricas (Rest, Prometheus, Datadog, Statd).
  • Web UI em AngularJS.
  • Suporte a Let’s Encrypt (Com renovação automática).
  • Alta disponibilidade em modo cluster (beta).

O Traefik foi desenvolvido para atender a demanda de requisições web, então ele pode ser utilizado para fazer o roteamento das conexões de um site ou api para o container ou serviço que foi criada para isso. A imagem abaixo é clássica, e explica bem esse comportamento:

Fonte: https://docs.traefik.io

Como pode ser visto, o traefik fica “ouvindo” as ações que ocorrem no orquestrador (independente de qual for) e baseado nessa ações se reconfigura para garantir o acesso ao serviço/container criado. Dessa forma basta você apontar as requisições web (seja http ou https) para o servidor onde o traefik está trabalhando.

Mãos a massa?

Em nosso lab, vamos montar esse ambiente utilizando o Docker Swarm como nosso orquestrador, para isso, tenha pelo menos três hosts, inicialize o Swarm em um deles, e em seguida adicione os demais ao cluster.

Feito isso, precisamos criar um rede do tipo overlay, que será utilizada pelo traefik para enviar o trafego web:

docker network create -d overlay net

Depois de inicializada a rede overlay, basta criar o serviço do traefik:

docker service create --name traefik --constraint 'node.role==manager' --publish 80:80 --publish 8080:8080 --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock --network net traefik:camembert --docker --docker.swarmmode --docker.domain=mundodocker --docker.watch --logLevel=DEBUG --web

Com este comando, será criado um serviço mapeando o socket do Docker para que o traefik possa monitorar o que acontece neste cluster, além disso são expostas as porta 80 (para acesso dos sites/apis) e 8080 (página administrativa do traefik), caso preciso da 443, basta adicionar a lista.

Ok, até agora o que fizemos foi criar o serviço do traefik no cluster para que monitore e se reconfigure baseado nos eventos do cluster. Agora precisamos criar nossos serviços web e ver se tudo funcionará como deveria. Vamos lá:

Blog:

Vamos criar agora uma nova aplicação web, que será responsável por um blog, o processo de criação é bem simples:

docker service create --name traefik --label 'traefik.port=80' --label traefik.frontend.rule="Host:blog.mundodocker.com.br;" --network net ghost

Criamos um serviço com nome de blog, utilizando uma imagem do WordPress e adicionamos na rede “net”, essa mesma rede onde o traefik está, agora vamos detalhar os novos parâmetros:

  • traefik.port = Porta onde a aplicação vai trabalhar, nos caso do wordpress, será na porta 80 mesmo.
  • traefik.frontend.rule = Qual será o virtual host que este serviço atende, com isso o traefik consegue definir que, quando chegar uma requisição para: blog.mundodocker.com.br, encaminhará as requisições para o serviço correto.

Agora basta apontar no DNS a entrada blog.mundodocker.com.br para o servidor do traefik e a mágica estará feita.

Site:

Para ver como é difícil, tudo que você precisa fazer é executar este comando:

docker service create --name site --label 'traefik.port=80' --label traefik.frontend.rule="Host:www.mundodocker.com.br;" --network net tutum/apache-php

Dessa vez criamos um novo serviço, na mesma rede, mas com alguns parâmetros diferentes, como é o caso do traefik.frontend.rule, onde especificamos um novo endereço, e claro a imagem que vamos utilizar, que agora é a tutum/apache-php.

URLs:

Outra feature muito legal do traefik é a possibilidade de redirecionar URLs para backends diferentes. O que isso quer dizer? Quer dizer que podemos enviar partes de uma aplicação para serviços diversos, por exemplo, na aplicação existe um /compras e um /categoria, podemos enviar essas URLs para serviços distintos, isso apenas informando o traefik, veja:

docker service create --name categoria --label 'traefik.port=3000' --label traefik.frontend.rule="Host:www.mundodocker.com.br; Path: /categoria/" --network net node

Note que agora temos um novo parâmetro, o “Path” onde especificamos qual URL este serviço vai atender, o resto é semelhante, informamos a porta e imagem que este serviço vai utilizar. Para criar um serviço especifico para outra URL, basta:

docker service create --name compras --label 'traefik.port=3000' --label traefik.frontend.rule="Host:www.mundodocker.com.br; Path: /compras/" --network -net node

E pronto, sua aplicação estará “quebrada” entre vários serviços, e o mais legal é que você não precisou editar um arquivo de configuração se quer. Além dessas facilidades, o traefik ainda disponibiliza uma interface para visualizar como está a saúde das url, em nosso lab você acessará pela porta 8080, e você visualizará algo assim:

Neste dashboard você poderá visualizar como estão configuradas as suas entradas no proxy. Na aba health você poderá visualizar como está o tempo de resposta das url e saber se está tudo certo com o trafego, veja:

Bonito né? E além de tudo, extremamente funcional 🙂 , em posts futuros veremos um pouco mais sobre como funciona a API do traefik, como configurar o let’s encrypt, e alguns outros pontos, por enquanto, como post introdutório, era isso que gostaria de trazer a vocês.

Esperemos que tenham gostado, qualquer dúvida/sugestão nos avise 😉

Grande abraço, até mais!

NodeJS com Docker na Umbler

Eai pessoal, blz?

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

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

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

Vamos detalhar o que foi apresentado.

Quem mesmo?

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

O caminho até aqui

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

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

OpenShift

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

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

Kubernetes

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

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

Docker Swarm

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

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

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

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

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

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

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

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

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

Docker 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!