Aplicações 12 fatores, melhor com Docker

Globalcode – Open4education
Aplicações 12 fatores
Melhor com Docker
Wellington F. Silva

Wellington F. Silva
a.k.a.: wsilva/tom/boina
técnico em telecom,
programador, devops,
instrutor, escritor, pai
Atualmente na GFG

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

O que é Docker?

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 
tradicional

O que é Docker?
tradicional
OSS

O que é Docker?
tradicional
OSS
Diversas ferramentas de  
orquestração

O que é Docker?
tradicional
OSS
Diversas ferramentas de  
orquestração
Virtualização em nível de SO

Cupom de Desconto
TDC25
25% de desconto no site da
Novatec*
sem desculpas pra não
aprender Docker
*para qualquer título
O que é Docker?

Metodologia para desenvolvimento de  
webapps e SAAS

webapps e SAAS
Aplicável em qualquer linguagem de
programação de alto nível

webapps e SAAS
Facilita portabilidade e escalabilidade

webapps e SAAS
Criado por Adam Wiggins e outros  
colaboradores do Heroku

webapps e SAAS
Criado por Adam Wiggins e outros  
colaboradores do Heroku
Foca em portabilidade e escalabilidade

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
Tudo tem que estar no SCM (Source Control
Management)

I - Base de Código

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

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

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

I - Base de Código
Management)
Mais apps num mesmo codebase é errado
Vários deploys (dev1, dev2, dev3, staging, qa,
integration, production)

I - Base de Código
1 cd 12factor
2 git init .
3 git add web-container/Dockerfile
4 git add web-app/*
5 git commit -m "Iniciando os trabalhos"
6 git remote add origin git@github.com:usuario/
repo.git
7 git push -u origin master

I - Base de Código
E o Docker?

I - Base de Código
E o Docker?
Dockerfiles versionados

I - Base de Código
E o Docker?
Dockerfiles versionados
.dockerignore

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

II - Dependências
Devem ser declaradas explicitamente e isoladas

II - Dependências
1 <?php
2
3 require_once "monolog/src/Monolog/Logger.php";

II - Dependências
1 <?php
2
3 require_once "monolog/src/Monolog/Logger.php";
1 composer require monolog/monolog
2 composer install

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

II - Dependências
Utilizar ferramentas de automação (composer,
pip, maven, bundle)

II - Dependências
pip, maven, bundle)
Dependências de recursos de SO devem ser
vendorizadas em um novo app

II - Dependências
pip, maven, bundle)
Dependências de recursos de SO devem ser
vendorizadas em um novo app
Mudanças são rapidamente detectadas na
construção

II - Dependências
E 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

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

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

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

ambiente
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)

E o Docker?
Ao construir e ao iniciar contêineres devemos
definir os valores das variáveis de ambiente

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 export ENABLE_ENV_FILE="12 factor”
2 export DB_ROOT_PASS=“mutcha-porrada”
3 export DB_USER="maguila”
4 export DB_USER_PASS=“parabolicas-sta-rita”
5 export APP_PASS="w0rdpr355”

# arquivo docker-compose.yml
1 version: '2'
2 services:
3 db:
4 image: mysql:5.6
5 volumes:
6 - "./.data/db:/var/lib/mysql"
7 restart: always
8 environment:
9 MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASS}
10 MYSQL_DATABASE: wordpress
11 MYSQL_USER: ${DB_USER}
12 MYSQL_PASSWORD: ${DB_USER_PASS}

13 wordpress:
14 depends_on:
15 - db
16 image: wordpress:latest
17 links:
18 - db
19 ports:
20 - "8000:80"
21 restart: always
22 environment:
23 ENABLE_ENV_FILE: ${ENABLE_ENV_FILE}
24 WORDPRESS_DB_HOST: db:3306
25 WORDPRESS_DB_PASSWORD: ${APP_PASS}

1 <?php
2
3 /**
4 * Initialize main environment vars and load Yii 2
5 */
6 public static function init()
7 {
8 require('/var/www/vendor/autoload.php');
9
10 // Load .env file if enabled and if it exists
11 if (getenv('ENABLE_ENV_FILE') &&
file_exists(self::APP_DIR.'.env')) {
12 Dotenv::load(self::APP_DIR);
13 }

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

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

São serviços consumidos via rede

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

Exemplos: MySQL, Redis, Memcached, APIs,
serviços de e-mail, Filas
Por ser anexado e podemos trocar o recurso caso
apresente problemas

E o Docker?
No arquivo docker-compose.yml temos as
declarações dos serviços

E o Docker?
No arquivo docker-compose.yml temos as
declarações dos serviços
Os serviços de apoio também podem ser serviços
externos (SAAS) ou outros contêineres

1 version: '2'
2 services:
3 db:
4 image: mysql:5.6
5 volumes:
6 - "./.data/db:/var/lib/mysql"
7 restart: always
8 environment:
9 MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASS}
10 MYSQL_DATABASE: wordpress
11

12 wordpress:
13 depends_on:
14 - db
15 image: wordpress:latest
16 links:
17 - db
18 -
"redis1.bpnp.cfg.sae1.cache.amazonaws.com:cache-live"
19 ports:
20 - "8000:80"
21 restart: always
22 environment:
23 WORDPRESS_DB_HOST: db:3306
24 WORDPRESS_DB_PASSWORD: ${APP_PASS}

"Quando o relógio bate as cinco,
todas as caveiras apertam os cintos."
Tumbalacatumba tumba tá, tumbalacatumba tumba tá

V - Contruir, lançar e executar
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

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

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

E o Docker?
No Docker temos o slogan: "Build, ship and run
any app 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."

VI - Processos
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
Dados devem ser persistidos e recuperados de
serviços de apoio
Não devem ser daemon ou ter arquivo PID, deve
trabalhar com o ambiente (upstart)

VI - Processos
E no Docker?
Cada contêiner tem seu processo único

VI - Processos
E no Docker?
Cada contêiner tem seu processo único
Pode ser adicionado processos aos contêineres

VI - Processos
1 # docker-compose.yml
2 redis:
3 image: redis:2.8
4 ports:
5 - "6379:6379"
6 entrypoint: ["redis-server"]
7 command: ["--appendonly", "yes"]

VI - Processos
8 php:
9 image: php:7-fpm
10 links:
11 - “redis:redis.local"
12 ports:
13 - "9000:9000"
14 entrypoint: ["php-fpm"]

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

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

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

em sua porta
E no Docker?
Cada container pode exportar uma porta e o
vínculo é feito em uma porta do host

em sua porta
E no 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

1 # docker-compose.yml
2 web:
3 image: wfsilva/nginx-php7
4 ports:
5 - "80"
6 - "443"
7 - "172.16.0.10:8000:8000"

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

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

modelo
Processos podem ser web ou workers

modelo
Processos podem ser web ou workers
Mais processos em paralelo, mais requisições
são respondidas ou mais rápido terminam
processamentos em lote.

E no Docker?
Podemos escalar a quantidade de contêineres
que executam uma tarefa.

1 docker-compose scale web=34 worker=23
2 docker-compose scale web=1 worker=1

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

IX - Descartabilidade
Maximizar robustez

Maximizar robustez
Inicialização rápida e desligamento normal e
suave (gracefully shutdown)

Maximizar robustez
Processos do app são descartáveis

Maximizar robustez
Facilita escalonamento rápido e elástico

Maximizar robustez
Facilita escalonamento rápido e elástico
Evitar desligamento repentino (crash)

E no Docker?
Trocar uma configuração de um contêiner, subir
novos e desligar os antigos

E no 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 nós.

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."

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

Minimizar a lacuna de tempo (deploy em horas ou
minutos)

minutos)
Minimizar a lacuna de pessoal (devs codam, ops
fazem deploy)

minutos)
Minimizar a lacuna de pessoal (devs codam, ops
fazem deploy)
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)

E no 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"
22 entrypoint: ["redis-server"]
23 command: ["--appendonly", "yes"]
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."

XI - Logs
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
arquivos
Em homolog e produção são capturados em
roteadores tipo fluent, logplex, logstash

XI - Logs
arquivos
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
E o Docker?
Containers tem drivers de log

XI - Logs
E o 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"

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

pontuais
Tem que rodar no mesmo codebase

pontuais
Executar em ambiente idêntico

pontuais
Migrações de banco

pontuais
Migrações de banco
Scripts de rotinas

Docker
Técnica de conteinerização de comandos

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
12 -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'

1 # exemplo docker exec
2 docker exec -it phpcontainer /usr/bin/top

Concluindo
Não são regras, são sugestões de boas práticas

Concluindo
Os 12 fatores não farão sua aplicação melhor

Concluindo
Os 12 fatores vão trazer a facilidade de trabalhar
com sua aplicação em ambientes de cloud

Concluindo
Os 12 fatores vão trazer a facilidade de trabalhar
com sua aplicação em ambientes de cloud
Docker tem uma grande aderência aos 12 fatores

Slides & Feedback
https://joind.in/talk/0a473
https://speakerdeck.com/wsilva

Aplicações 12 fatores, melhor com Docker

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Aplicações 12 fatores, melhor com Docker

Semelhante a Aplicações 12 fatores, melhor com Docker (20)

Mais de Wellington Silva

Mais de Wellington Silva (16)

Aplicações 12 fatores, melhor com Docker