PaaS Tão difícil quanto parece ou tão fácil quanto deve ser

12factor.net
gh/openruko
Éverton Ribeiro

PaaS
Tão difícil como parece ou tão fácil como
deve ser?

The Twelve-Factor Apps
Metodologia para construção de software-as-a-service
Define uma série de diretrizes e vocabulário padrão
Desenvolvedores / Engenheiros / Infra-estrutura

The Twelve-Factor Apps
Write by Adam Wiggins - CTO e Co-Founder do Heroku

Disponível para contribuição no github:
https://github.com/adamwiggins/12factor

12factor - I. Codebase
Um codebase com controle de versão, vários deploys

✘ Múltiplos codebase não é uma app, é um sistema distribuído.

✓ Cada componente de um sistema distribuído pode,
individualmente, cumprir twelve-factor.


✘ Multiplas apps compartilhando o mesmo codebase violam o
princípio twelve-factor.

✓ Separe seu código em bibliotecas.


Deploy: instância de uma aplicação.

Mesmo codebase ao longo dos deploys, mas diferentes versões em
cada instância.


✓ Diferentes desenvolvedores e instâncias pode rodar diferentes
versões do codebase.

12factor - II. Dependencies
Declarar e isolar dependências explicitamente

Ruby: "Gem Bundler + Gemfile" - bundle exec
Python: Pip - Virtualenv
C: Autoconf - static linking


✘ Declaração e isolamento de dependências devem ser utilizas de
forma conjunta, apenas o uso de uma não satisfaz twelve-factor.


✘ Nunca depender da existência implícita de todas as ferramentas
do sistema

Mesmo que um recurso esteja sempre presente na maior parte dos
sistemas, não existe garantia de que ele sempre vai estar presente
ou que sera compatível: vendorize


✓ Positive side effect: tornar fácil a entrada de novos
desenvolvedores

12factor - III. Config
Armazenar configurações no environment

✘ Configurações nunca devem estar armazenadas na forma de
constantes no código. Isso viola o twelve-factor

Elas podem variar entre os environments (staging, production e
developer) de uma mesma aplicação, o código não vai variar com a
mesma frequência.


Melhor forma de saber se esta seguindo essa premissa é se o código
da aplicação poderia ser tornar publico a qualquer momento, sem
comprometer a segurança.


Configurações internas da aplicação não são consideradas "config",
"config/routes.rb" ou código xml de ORM são exemplos de
configuração interna.


✓ Twelve-factor apps usam variáveis de ambiente para armazenar
configurações:

Fácil de alterar entre ambientes;
Há poucas chances das configurações irem parar no codebase;
Não é preciso nenhum sistema adicional de configuração;


✓ Agnóstico de linguagem e sistema operacional


Modelos: Grupos nomeados (também conhecidos como
"environments") vs. Variáveis de ambiente

12factor - IV. Backing Services
Tratar backing services como recursos conectados

Qualquer que seja o backing service consumido via rede e faça
parte da operação normal do sistema, exemplos:

Datastores: MySQL ou MongoDB
Messaging/Queueing: RabbitMQ ou Beanstalkd
SMTP: Postfix
Caching: Memcached ou Redis


Mas não somente serviços que em geral são resposabilidade do ops
enginner, também fazem parte serviços de terceiros:

SMTP services: Postmark ou Sendgrid
Metrics-gathering services: New Relic ou Loggly
Binary asset services: Amazon S3 ou Azure Store
API's: Twitter, Google Maps ou Last.fm


✓ Não é feita distinção entre backing services locais ou de terceiros

Uma vez que o resource foi anexado a aplicação, seu acesso se da
por URL ou localizador/credencias adicionados ao config.


✓ Facilitar o processo de troca entre versões de resources, sem a
necessidade de alteração ou deploy de um novo código


Cada backing service é um resource diferente. Por exemplo um
MySQL é um resource, dois MySQLs (usados em redundância) são
qualificados como dois resources diferentes;

V. Build, release, run
Separar os estágios de build e execução

O codebase é transformado em deploy em três estágios:


Build stage: É um processo de transformação, que transforma
código do respositório em uma versão executável, nesta fase é feita
a busca pela versão especificada do código, vendorização das
dependências e compilação de assets.


Release stage: Nesta fase o produto da fase build é empacotado
juntamente com o as informações do config, um pacote pronto para
execução é criado


Run stage: também conhecido com runtime, nesta fase o pacote
gerado no release é executado no ambiente de execução.


Twelve-factor define uma separação estrita entre as fases: build,
release e run. Por exemplo: não é possível alterar o código da
aplicação na fase de runtime.


O processo de build é disparado pela ferramenta de deploy, que
deve ser capaz de, dentre outras coisas, executar processo de
rollback e atualização do código
Cada release deve ter um ID único, e uma vez criada não pode ser
modificada;
A fase de build tende a ser a fase mais complexa, em geral é onde
as falhas acontecem e são reportadas ao desenvolvedor
imediatamente

12factor - VI. Processes
Executar a aplicação como um ou mais processes sem estado

No caso mais simples o código é um script autônomo, como em:

$pto m_citp
yhn ysrp.y


Na outra extremidade temos aplicações em produção que podem
rodar diversos processes ao mesmo tempo, como em:

#Pofl
rcie
wb rc - ti
e: ak s hn
wre:rsu wr -qee=ihlw
okr eqe ok -uushg,o


✘ Indiferente de ser simples ou complexo os processes não devem
manter estado e nem compartilhar nada por meio de persistência
em disco ou memória


✓ Memória e disco devem ser consideradas regiões de brief ou
single-transaction, qualquer outra informação que necessite
persistencia deve utilizar resources.

12factor - VII. Port binding
Exportar serviços via port binding

Nenhum webserver é injetado no environment de execução, as
aplicações devem ser auto-contidas, elas devem expor o serviço http
dando binding em uma porta e aguardar por requests nesta porta.


Não apenas serviços http devem ser espostos dessa forma, um
serviço com ejabberd ou redis devem fazer o mesmo


Observe que um serviço assim exposto pode ser tornar um backing
service para outras aplicações

12factor - VIII. Concurrency
Escale através do modelo de processos

12factor - IX. Disposability
Maximizar a robustez com fast startup e graceful shutdown

No Twelve-factor o processes é descartável, isso quer dizer que ele
pode ser parado e startado a qualquer momento.

Isso permite:

Facilidade ao escalar a aplicação;
Rapidez no processo de deploy do código e mudança das
configurações;
E um robusto processo de deploy em produção;


Ter fast startup agiliza o processo de execução da aplicação,
tornando a rápidamente disponível e facilita o processo de mover a
aplicação de máquina "física".


O processo de graceful shutdown deve ocorrer normalmente
quando o processo recebe um SIGTERM. Para processos http por
exemplo, ele deve parar de esperar por novas requisições, finalizar
as requisições atuais, fechar todos os streams em andamento e
finalizar o processo

12factor - X. Dev/prod parity
Procure tornar os ambientes de development, staging e
production o mais similar possível

✘ Esta deveria ser uma regra para qualquer processo de
desenvolvimento


Evite os gaps:

Gap de time: Desenvolver código por dias, semanas ou até
mesmo por meses só depois para por em produção;
Gap pessoal: Desenvolvedor coda, ops enginners fazem deploy;
Gap de ferramentas: Desenvolve localmente com Nginx, SQLite
sobre OS X, e coloca em produção sobre: Apache, MySQL e Linux;


Twelve-factor apps são desenhadas para facilitar o processo de
continuous deployment o que ajuda a tornar o gap entre
desenvolvimento e produção muito menor.


Como os gaps são evitados:

Gap de time: Após desenvolver um código o dev pode fazer o
deploy depois de algumas horas ou mesmo minutos;
Gap pessoal: Quem desenvolve faz deploy, e pode observar como
o código se comportou em produção;
Gap de ferramentas: mantendo o environment de produção e
desenvolvimento tão semelhante possível;


✘ Divergências entre backing services talvez sejam um dos
principais pivos de problemas, e um dos mais complicados de
resolver.

✓ Porém o desenvolvedor twelve-factor resiste ao máximo utilizar
diferentes backing services para a mesma função entre os
environments


Utilize ferramentas de isolamento e provisionamento:

http://www.vagrantup.com
http://www.docker.io/
https://github.com/nuxlli/macbox
http://www.opscode.com/chef/
https://puppetlabs.com

12factor - XI. Logs
Trate logs como stream

Logs são uma parte muito importe de uma aplicação, porém é
comum o redirecionamento e amazenamento dos mesmos em
arquivos.

✘ Isso não deve acontecer, assim como no ambiente de
desenvolvimento, em geral, logs são visualizados na forma de
stream na saída padrão, o desenvolvedor twelve-factor não se
preocupa em encaminhar ou armazenar este stream.

12factor - XI. Logs

✓ Porém como logs são importantes, o sistema de execução deve
se preocupar em capturar e encaminhar os logs para algum serviço
que o desenvolvedor possa consultar depois.

Esse processo deve ser o menos impactante possível, seja em
processamento e comunicação da máquina onde a aplicação esta
sendo executada

12factor - XI. Logs

Backing services para análise dos logs e geração de métricas podem
ser adicionados para completar o processo.

12factor - XII. Admin process
Tarefas de administração e manutenção devem ser on-off
processes

Além dos processo normais de execução das aplicações, muitas
vezes o desenvolvedor pode precisar executar tarefas de
manutenção e administração, como:

Rodar migrações de banco de dados;
Acessar um console para execução de códigos aleatórios;
Rodar algum script de correção de dados;

12factor - XII. Admin process
Tarefas de administração e manutenção devem ser on-off
processes

Para estes casos o desenvolvedor deve ser capaz de executar estas
tarefas nas mesmas condições dos environments de execução da
aplicação, incluindo rodar no mesmo release com as mesmas
configs e protegido por dependency isolation

Openruko
https://github.com/openruko

Thomas Buckley-Houston < tom@tombh.co.uk >

github.com/tombh - http://tombh.co.uk

Romain Philibert < romain.philibert@gmail.com >

github.com/Filirom1 - http://philibert.romain.free.fr

Matt Freeman < matt@nonuby.com >

github.com/nonuby - http://blog.nonuby.com

Openruko - Arquitetura
Api Server - openruko/apiserver

Componente central do Openruko, feito em node.js + postgresql,
seu trabalho é divido em duas partes:

API Pública (heroku compatível): Responsável por toda interação
com o desenvolvedor, que em geral é feita por meio da
ferramenta de CLI.
API Privada: Por meio da qual todos os outros componentes
internos obtem informações sobre as fases de: build, release e
run.

Gitmouth - openruko/gitmouth

Desenvolvido em python com auxilio da biblioteca twisted, é
responsável pelo balanceamento de carga das chamadas ssh/git.

Alternativas em desenvolvimento:

azukiapp/plowman
Filirom1/gogit

Dynohost - openruko/dynohost

Serviço desenvolvido em node.js + LXC, seu trabalho se divide em
quatro partes:

Container constructor: Através de scripts bash constroi os
arquivos de configuração e ponto de montagem / do container
LXC Wrapper: Uma vez com arquivos de configuração e o ponto
de montagem estabelecido, gerencia a execução dos containers
LXC;
Deploy: Antes de executar um container baixa o slug a ser
executado e monta este na pasta /app, e por fim starta o
container para execução do rukorun
Dyno gestor: Constroi um canal de comunicação com o container
(dyno) por meio de sockets;

Rukorun - openruko/rukorun

Feito em node.js, esse é um simples script que faz a ponte do
container com o mundo, através de sockets estabelecidos pelo
Dynohost

É atráves deste script que aplicação e inicializada pelo dynohost, ou
mesmo coisas como um console podem ser estabelecidas com o
container

Httprouting - openruko/httprouting

Balanceador de carga para chamadas http, desenvolvido em node.js
é o responsável por tratar todas as chamadas http vindas com
destino as aplicações em execução no openruko.

Atualmente suporta websockets, e se conecta direto ao postgresql
para obter dados de resolução e dynos.

Alternativas:

dotcloud/hipache
samalba/hipache-nginx

Logplex - openruko/logplex

Syslog distribuído, este serviço desenvolvido em node.js é uma
simplificação compatível do serviço de mesmo nome do heroku.

Mais componentes a serem desenvolvidos

Monitor e escalonador
Addons
Billing
Portal

Perguntas?
@nuxlli - https://github.com/nuxlli

PaaS Tão difícil quanto parece ou tão fácil quanto deve ser

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à PaaS Tão difícil quanto parece ou tão fácil quanto deve ser

Similaire à PaaS Tão difícil quanto parece ou tão fácil quanto deve ser (20)

PaaS Tão difícil quanto parece ou tão fácil quanto deve ser