12 factor app. Melhor com Docker

Aplicações 12 fatores
Melhor com Docker

wsilva/tom/boina
● Devops na GFG
● @_wsilva

Agenda
● O que é Docker?
● O que é 12 factor app?
● Os 12 fatores
● Como o Docker adere a cada fator

O que é Docker?
● Sistema de contêineres Linux

O que é Docker?
● Muito leve e rápido

O que é Docker?
● Muitas vantagens em relação à virtualização

O que é Docker?
● Build, Ship, Run anywhere

O que é Docker?
● Tem ferramentas para orquestração

O que é Docker?
● Tem ferramentas para clusterização

O que é Docker?
● Criado por Solomon Hykes

O que é Docker?
● Open Source

O que é Docker?
● Open Source
● http://www.docker.com

O que é 12 factor app?
● Metodologia para desenvolvimento de apps web e SAAS
(Software as a Service)

● Aplicável em qualquer linguagem de programação de alto
nível

nível
● Facilita portabilidade e escalabilidade

nível
● Criado por Adam Wiggins e outros colaboradores do Heroku

nível
● Foca em problemas sistêmicos comuns

nível
● Inspirado no "Patterns of Enterprise Application
Architecture" e no "Refactoring" de Martin Fowler

nível
● Inspirado no "Patterns of Enterprise Application
Architecture" e no "Refactoring" de Martin Fowler
● http://12factor.net

"Quando o relógio bate a uma,
todas as caveiras saem das
tumbas."
Tumbalacatumba tumba tá, tumbalacatumba tumba tá

I - Base de Código
● Repositório único por app (git, hg, svn, bazaar)

I - Base de Código
● + de um codebase é um sistema distribuído

I - Base de Código
● Mais apps num mesmo codebase é errado

I - Base de Código
● Vários deploys (dev1, dev2, dev3, staging, qa, integration, production)

I - Base de Código
● Vários deploys (dev1, dev2, dev3, staging, qa, integration, production)
Docker:
● Colocar Dockerfiles no repositório

I - Base de Código
1 cd 12factor
2 git init .
3 git add web-container/Dockerfile
4 git add wer-source/*
5 git commit -m "Iniciando os trabalhos"

"Quando o relógio bate as duas,
todas as caveiras pintam as
unhas."

II - Dependências
● Devem ser declaradas e isoladas

II - Dependências
● Devem estar presentes em um arquivo manifesto (composer.json,
requirements.txt, Gemfile)

II - Dependências
● Utilizar ferramentas de empacotamento (composer, pip, maven, bundle)

II - Dependências
● Dependencias de recursos de SO devem ser vendorizadas em um novo app

II - Dependências
● Mudanças são rapidamente detectadas na construção

II - Dependências
● Mudanças são rapidamente detectadas na construção
Docker
● Dependências ficam explícitas no Dockerfile
(FROM, ADD, COPY)

II - Dependências
1 FROM nginx:1.9.9
2 RUN apt-get update
3 && apt-get install -y -q --no-install-recommends
4 ca-certificates
5 wget
6 && apt-get clean
7 && rm -r /var/lib/apt/lists/*
8 RUN echo "daemon off;" >> /etc/nginx/nginx.conf
9 && sed -i 's/^http {/&n server_names_hash_bucket_size 128;
/g' /etc/nginx/nginx.conf

II - Dependências
1 ADD https://github.com/alanxz/rabbitmq-c/archive/v0.5.2.zip
/rabbitmq-c-0.5.2.zip
2 RUN unzip rabbitmq-c-0.5.2.zip
3 && cd rabbitmq-c-0.5.2
4 && autoreconf -i
5 && ./configure
6 && make
7 && make install
8 && pecl install amqp

II - Dependências
9 && echo "extension=amqp.so" > /etc/php5/mods-available/amqp.
ini
10 && cd /
11 && rm rabbitmq-c-0.5.2.zip
12 && rm -rf rabbitmq-c-0.5.2

"Quando o relógio bate as três,
todas as caveiras imitam chinês."

● Configurações devem ser armazenadas no ambiente
III - Configurações

● Configuração é tudo que varia conforme o deploy (dev, homolog, QA,
instâncias em produção)

● Informações de acesso a recursos (Servidores de Storage, Serviço de cache,
Acesso a banco de dados)

● Informações de acesso a recursos (Servidores de Storage, Serviço de cache,
Acesso a banco de dados)
Docker
● Ao construir e ao iniciar um container podemos definir
variáveis de ambiente

1 export TESTING="12 factor"

1 docker run -d --name web
2 --env TESTING="12 factor" nginx
3 docker run -d --name backend
4 --env-file ./env-file myimage/backend
5 docker run -d --name db
6 --env "MYSQL_ROOT_PASSWORD=senha"
7 --env "MYSQL_DATABASE=mydb" mysql

1 <?php
2
3 $var = getenv('TESTING');
4 echo $var; //12 factor

"Quando o relógio bate as quatro,
todas as caveiras tiram retrato."

IV - Serviços de Apoio
● Trate serviços de apoio como recursos anexados.

● São serviços consumidos via rede

● Exemplos: MySQL, Redis, Memcache, APIs, serviços de e-mail, Filas

● Por ser anexado podemos trocar o recurso caso apresente problemas

● Por ser anexado podemos trocar o recurso caso apresente problemas
Docker:
● Os serviços de apoio também podem ser outros containers

1 # docker-compose.yml
2 web:
3 image: account/webimage
4 ports:
5 - "80:80"
6 links:
7 - "redis:redis.dev"
8 - "mysql-write:mysql02.service-provider.com"
9 - "mysql-read:192.168.1.77"
10 redis:
11 image: redis:2.8
12 hostname: redis.dev
13 ports:

12 hostname: redis.dev
13 ports:
14 - "6379:6379"
15 entrypoint: ["redis-server"]
16 command: ["--appendonly", "yes"]

"Quando o relógio bate as cinco,
todas as caveiras apertam os
cintos."

V - Contruir, lançar e executar
● Separemos claramente os estágios de construção e execução

● Construção é a montagem do artefato e provisionamento de dependências

● Na construção que temos que detectar problemas (testes automatizados)

● Lançamento é combinação do artefato com a configuração do ambiente de
deploy

deploy
● Cada lançamento deve ter um identificador único (release)

deploy
● Cada lançamento deve ter um identificador único (release)
● Execução é a inicialização dos processos para fazer o app funcionar

Docker
● No Docker temos o mote: build, ship and run anywhere

1 docker build
2 -f Dockerfile-production
3 -t username/image
4 ./container/
5 docker push username/image
6 docker run -d username/images

"Quando o relógio bate as seis,
todas as caveiras jogam xadrez."

● Executar a aplicação com um ou mais processos
VI - Processos

● A aplicação não deve guardar estado
VI - Processos

● Dados devem ser persistidos e recuperados de serviços de apoio
VI - Processos

● Não devem ser daemon ou ter arquivo PID, deve trabalhar com o ambiente
(upstart)
VI - Processos

(upstart)
Docker
● Cada contêiner tem seu processo único
VI - Processos

VI - Processos
(upstart)
Docker
● Cada contêiner tem seu processo único
● Pode ser adicionado processos aos contêineres

VI - Processos
2 redis:
3 image: redis:2.8
4 ports:
5 - "6379:6379"

"Quando o relógio bate as sete,
todas as caveiras jogam
basquete."

● Exportar os serviços através do vínculo de portas
VII - Vínculo de portas

● Cada app deve escutar e receber as requisições em sua porta

Docker
● Cada container pode exportar uma porta e o vínculo é feito em uma porta do
host

Docker
● Cada container pode exportar uma porta e o vínculo é feito em uma porta do
host
● Podemos escolher qual porta do host será vinculada ao container

2 web:
3 image: username/webimage
4 ports:
5 - "80"
6 - "443"
7 - "8000:8000"

"Quando o relógio bate as oito,
todas as caveiras comem
biscoito."

● Escalar com base no processo usado como modelo
VIII - Concorrência

● Processos podem ser web ou workers

● Mais processos em paralelo, mais requisições são respondidas ou mais
rápido terminam processamentos em lote.

● Mais processos em paralelo, mais requisições são respondidas ou mais
rápido terminam processamentos em lote.
Docker
● Podemos escalar a quantidade de contêineres que executam uma tarefa.

1 docker-compose scale web=5 worker=3
2 docker-compose scale web=1 worker=1

"Quando o relógio bate as nove,
todas as caveiras se sacodem."

● Maximizar robustez
IX - Descartabilidade

● Inicialização rápida e desligamento normal e suave (gracefull shutdown)

● Processos do app são descartáveis

● Facilita escalonamento rápido e elástico

● Evitar desligamento repentino (crash)

Docker:
● Trocar uma configuração de um contêiner, subir novos e desligar os antigos

Docker:
● Trocar uma configuração de um contêiner, subir novos e desligar os antigos
● Em um Swarm quando um nó cai os containers são
reorganizados nos demais

1 docker run -d -P
2 --memory=512M
3 --name webserver
4 nginx
5 docker update --memory=1G webserver

"Quando o relógio bate as dez,
todas as caveiras comem
pastéis."

● Manter os ambientes mais similares (desenvolvimento, homologação,
produção)
X - Paridade Dev/Prod

produção)
● Minimizar a lacuna de tempo (deploy em horas ou minutos)

produção)
● Minimizar a lacuna de pessoal (devs codam, ops fazem deploy)

produção)
● Minimizar a lacuna de ferramentas (Dev com OSX, Nginx 1.2.1, PHP 7.0.3 e
MySQL 5.6 - Prod com Nginx 1.9, PHP 5.5.33 e Percona 5.6)

produção)
● Minimizar a lacuna de ferramentas (Dev com OSX, Nginx 1.2.1, PHP 7.0.3 e
MySQL 5.6 - Prod com Nginx 1.9, PHP 5.5.33 e Percona 5.6)
Docker:
● Os contêineres que rodam em dev tem as mesmas versões
das instâncias em produção

1 percona:
2 image: percona:5.6
3 ports:
4 - "3306:3306"
5 environment:
6 - "MYSQL_ROOT_PASSWORD=senha"
7 - "MYSQL_DATABASE=db"

8 rabbit:
9 image: rabbitmq:3-management
10 ports:
11 - "5672:5672"
12 - "15672:15672"
13 environment:
14 - "TERM=linux"
15 - "RABBITMQ_NODENAME=rabbit"
16 - "RABBITMQ_DEFAULT_PASS=senha"
17 - "RABBITMQ_DEFAULT_USER=admin"

18 redis:
19 image: redis:2.8
20 ports:
21 - "6379:6379"
24 memcached:
25 image: memcached:1.4
26 ports:
27 - "11211:11211"

"Quando o relógio bate as onze,
todas as caveiras sobem no
bonde."

● Logs como fluxo de eventos ordenados no tempo
XI - Logs

● O app escreve os eventos no fluxo stdout
XI - Logs

● Em dev os logs são consultados acessando os arquivos
XI - Logs

● Em homolog e produção são capturados em roteadores tipo fluent, logplex,
logstash
XI - Logs

● Em homolog e produção são capturados em roteadores tipo fluent, logplex,
logstash
● Busca e apresentação de logs com ferramentas tipo ELK (Elastic Search,
Logstash e Kibana)
XI - Logs

XI - Logs
Docker
● Containers tem drivers de log

XI - Logs
Docker
● Containers tem drivers de log
● Suporte a json-file, syslog, journald, gelf, fluentd, awslogs e splunk

XI - Logs
1 docker run
2 --log-driver=fluentd
3 --log-opt fluentd-address=localhost:24224
4 --log-opt tag=docker.{{.Name}}

"Quando o relógio bate as doze,
todas as caveiras fazem pose"

● Tarefas administrativas são como processos pontuais
XII - Processos Administrativos

● Mesmo codebase

● Mesmo codebase
● Executar em ambiente idêntico

● Mesmo codebase
● Migrações de banco

● Mesmo codebase
● Scripts de rotinas

● Mesmo codebase
Docker
● Técnica de conteinerização de comandos

● Mesmo codebase
Docker
● Técnica de conteinerização de comandos
● Adicionar processo ao contêiner com docker exec

1 # subindo o server
2 docker run --name db -d -P
3 --env "MYSQL_ROOT_PASSWORD=senha"
4 --env "MYSQL_DATABASE=banco"
5 percona

6 # rodando o client
7 docker run -it
8 --link db:db
9 --rm percona
10 sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -
11 P"$MYSQL_PORT_3306_TCP_PORT" -uroot -
p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'

https://joind.in/talk/91f92
https://speakerdeck.com/wsilva
Slides & Feedback

12 factor app. Melhor com Docker

Mais conteúdo relacionado

Mais procurados

Semelhante a 12 factor app. Melhor com Docker

Mais de Wellington Silva

12 factor app. Melhor com Docker