The twelve factor apps and openruko

68
12factor.net gh/openruko Éverton Ribeiro

description

Apresentação realizada no dia 13/04/2013, no 29º Guru-SP: gurusp.org/encontros/vigesimo-nono-encontro-do-guru-sp Versão original em js: https://github.com/nuxlli/12factor-openruko

Transcript of The twelve factor apps and openruko

Page 1: The twelve factor apps and openruko

12factor.netgh/openruko

Éverton Ribeiro

Page 2: The twelve factor apps and openruko

PaaSTão difícil como parece ou tão fácil como

deve ser?

Page 3: The twelve factor apps and openruko

The Twelve-Factor AppsMetodologia para construção de software-as-a-service

Define uma série de diretrizes e vocabulário padrão

Desenvolvedores / Engenheiros / Infra-estrutura

Page 4: The twelve factor apps and openruko

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

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

Page 5: The twelve factor apps and openruko

12factor - I. CodebaseUm 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.

Page 6: The twelve factor apps and openruko

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

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

✓ Separe seu código em bibliotecas.

Page 7: The twelve factor apps and openruko

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

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

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

Page 8: The twelve factor apps and openruko

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

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

Page 9: The twelve factor apps and openruko
Page 10: The twelve factor apps and openruko

12factor - II. DependenciesDeclarar e isolar dependências explicitamente

Ruby: "Gem Bundler + Gemfile" - bundle exec

Python: Pip - Virtualenv

C: Autoconf - static linking

Page 11: The twelve factor apps and openruko

12factor - II. DependenciesDeclarar e isolar dependências explicitamente

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

Page 12: The twelve factor apps and openruko

12factor - II. DependenciesDeclarar e isolar dependências explicitamente

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

Mesmo que um recurso esteja sempre presente na maior parte dossistemas, não existe garantia de que ele sempre vai estar presente

ou que sera compatível: vendorize

Page 13: The twelve factor apps and openruko

12factor - II. DependenciesDeclarar e isolar dependências explicitamente

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

Page 14: The twelve factor apps and openruko

12factor - III. ConfigArmazenar configurações no environment

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

Elas podem variar entre os environments (staging, production edeveloper) de uma mesma aplicação, o código não vai variar com a

mesma frequência.

Page 15: The twelve factor apps and openruko

12factor - III. ConfigArmazenar configurações no environment

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

comprometer a segurança.

Page 16: The twelve factor apps and openruko

12factor - III. ConfigArmazenar configurações no environment

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.

Page 17: The twelve factor apps and openruko

12factor - III. ConfigArmazenar configurações no environment

✓ Twelve-factor apps usam variáveis de ambiente para armazenarconfiguraçõ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;

Page 18: The twelve factor apps and openruko

12factor - III. ConfigArmazenar configurações no environment

✓ Agnóstico de linguagem e sistema operacional

Page 19: The twelve factor apps and openruko

12factor - III. ConfigArmazenar configurações no environment

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

Page 20: The twelve factor apps and openruko

12factor - IV. Backing ServicesTratar backing services como recursos conectados

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

Datastores: MySQL ou MongoDB

Messaging/Queueing: RabbitMQ ou Beanstalkd

SMTP: Postfix

Caching: Memcached ou Redis

Page 21: The twelve factor apps and openruko

12factor - IV. Backing ServicesTratar backing services como recursos conectados

Mas não somente serviços que em geral são resposabilidade do opsenginner, 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

Page 22: The twelve factor apps and openruko

12factor - IV. Backing ServicesTratar backing services como recursos conectados

✓ 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 dapor URL ou localizador/credencias adicionados ao config.

Page 23: The twelve factor apps and openruko

12factor - IV. Backing ServicesTratar backing services como recursos conectados

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

Page 24: The twelve factor apps and openruko

12factor - IV. Backing ServicesTratar backing services como recursos conectados

Cada backing service é um resource diferente. Por exemplo umMySQL é um resource, dois MySQLs (usados em redundância) são

qualificados como dois resources diferentes;

Page 25: The twelve factor apps and openruko
Page 26: The twelve factor apps and openruko

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

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

Page 27: The twelve factor apps and openruko

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

Build stage: É um processo de transformação, que transformacódigo do respositório em uma versão executável, nesta fase é feita

a busca pela versão especificada do código, vendorização dasdependências e compilação de assets.

Page 28: The twelve factor apps and openruko

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

Release stage: Nesta fase o produto da fase build é empacotadojuntamente com o as informações do config, um pacote pronto para

execução é criado

Page 29: The twelve factor apps and openruko

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

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

Page 30: The twelve factor apps and openruko

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

Page 31: The twelve factor apps and openruko

V. Build, release, runSeparar os estágios de build e 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.

Page 32: The twelve factor apps and openruko

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

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

Page 33: The twelve factor apps and openruko

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

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

$ python my_script.py

Page 34: The twelve factor apps and openruko

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

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

# Procfileweb: rack -s thinworker: resque work --queues=high,low

Page 35: The twelve factor apps and openruko

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

✘ Indiferente de ser simples ou complexo os processes não devemmanter estado e nem compartilhar nada por meio de persistência

em disco ou memória

Page 36: The twelve factor apps and openruko

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

✓ Memória e disco devem ser consideradas regiões de brief ousingle-transaction, qualquer outra informação que necessite

persistencia deve utilizar resources.

Page 37: The twelve factor apps and openruko

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

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

Page 38: The twelve factor apps and openruko

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

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

Page 39: The twelve factor apps and openruko

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

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

Page 40: The twelve factor apps and openruko

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

Page 41: The twelve factor apps and openruko

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

No Twelve-factor o processes é descartável, isso quer dizer que elepode 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;

Page 42: The twelve factor apps and openruko

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

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

Page 43: The twelve factor apps and openruko

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

O processo de graceful shutdown deve ocorrer normalmentequando o processo recebe um SIGTERM. Para processos http por

exemplo, ele deve parar de esperar por novas requisições, finalizaras requisições atuais, fechar todos os streams em andamento e

finalizar o processo

Page 44: The twelve factor apps and openruko

12factor - X. Dev/prod parityProcure tornar os ambientes de development, staging e

production o mais similar possível

✘ Esta deveria ser uma regra para qualquer processo dedesenvolvimento

Page 45: The twelve factor apps and openruko

12factor - X. Dev/prod parityProcure tornar os ambientes de development, staging e

production o mais similar possível

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;

Page 46: The twelve factor apps and openruko

12factor - X. Dev/prod parityProcure tornar os ambientes de development, staging e

production o mais similar possível

Twelve-factor apps são desenhadas para facilitar o processo decontinuous deployment o que ajuda a tornar o gap entre

desenvolvimento e produção muito menor.

Page 47: The twelve factor apps and openruko

12factor - X. Dev/prod parityProcure tornar os ambientes de development, staging e

production o mais similar possível

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;

Page 48: The twelve factor apps and openruko

12factor - X. Dev/prod parityProcure tornar os ambientes de development, staging e

production o mais similar possível

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

resolver.

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

environments

Page 49: The twelve factor apps and openruko

12factor - X. Dev/prod parityProcure tornar os ambientes de development, staging e

production o mais similar possível

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

Page 50: The twelve factor apps and openruko

12factor - XI. LogsTrate 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 dedesenvolvimento, em geral, logs são visualizados na forma destream na saída padrão, o desenvolvedor twelve-factor não se

preocupa em encaminhar ou armazenar este stream.

Page 51: The twelve factor apps and openruko

12factor - XI. LogsTrate logs como stream

✓ Porém como logs são importantes, o sistema de execução devese 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 emprocessamento e comunicação da máquina onde a aplicação esta

sendo executada

Page 52: The twelve factor apps and openruko

12factor - XI. LogsTrate logs como stream

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

Page 53: The twelve factor apps and openruko

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

processes

Além dos processo normais de execução das aplicações, muitasvezes 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;

Page 54: The twelve factor apps and openruko

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

processes

Para estes casos o desenvolvedor deve ser capaz de executar estastarefas nas mesmas condições dos environments de execução da

aplicação, incluindo rodar no mesmo release com as mesmasconfigs e protegido por dependency isolation

Page 55: The twelve factor apps and openruko

Openruko

Thomas Buckley-Houston < >

-

Romain Philibert < >

-

Matt Freeman < >

-

https://github.com/openruko

[email protected]

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

[email protected]

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

[email protected]

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

Page 56: The twelve factor apps and openruko
Page 57: The twelve factor apps and openruko

Openruko - Arquitetura

Page 58: The twelve factor apps and openruko
Page 59: The twelve factor apps and openruko

Openruko - ArquiteturaApi Server - 

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.

openruko/apiserver

Page 60: The twelve factor apps and openruko

Openruko - ArquiteturaGitmouth - 

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

Alternativas em desenvolvimento:

openruko/gitmouth

azukiapp/plowman

Filirom1/gogit

Page 61: The twelve factor apps and openruko

Openruko - ArquiteturaDynohost - 

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

openruko/dynohost

Page 62: The twelve factor apps and openruko

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;

Page 63: The twelve factor apps and openruko

Openruko - ArquiteturaRukorun - 

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

Dynohost

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

container

openruko/rukorun

Page 64: The twelve factor apps and openruko

Openruko - ArquiteturaHttprouting - 

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 postgresqlpara obter dados de resolução e dynos.

Alternativas:

openruko/httprouting

dotcloud/hipache

samalba/hipache-nginx

Page 65: The twelve factor apps and openruko

Openruko - ArquiteturaLogplex - 

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

openruko/logplex

Page 66: The twelve factor apps and openruko

Openruko - ArquiteturaMais componentes a serem desenvolvidos

Monitor e escalonador

Addons

Billing

Portal

Page 67: The twelve factor apps and openruko

Openruko - Live demo

Page 68: The twelve factor apps and openruko

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