PaaSTão difícil como parece ou tão fácil como
deve ser?
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
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
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.
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.
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.
12factor - I. CodebaseUm codebase com controle de versão, vários deploys
✓ Diferentes desenvolvedores e instâncias pode rodar diferentesversões do codebase.
12factor - II. DependenciesDeclarar e isolar dependências explicitamente
Ruby: "Gem Bundler + Gemfile" - bundle exec
Python: Pip - Virtualenv
C: Autoconf - static linking
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.
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
12factor - II. DependenciesDeclarar e isolar dependências explicitamente
✓ Positive side effect: tornar fácil a entrada de novosdesenvolvedores
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.
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.
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.
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;
12factor - III. ConfigArmazenar configurações no environment
✓ Agnóstico de linguagem e sistema operacional
12factor - III. ConfigArmazenar configurações no environment
Modelos: Grupos nomeados (também conhecidos como"environments") vs. Variáveis de ambiente
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
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
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.
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
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;
V. Build, release, runSeparar os estágios de build e execução
O codebase é transformado em deploy em três estágios:
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.
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
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.
V. Build, release, runSeparar os estágios de build e execução
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.
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
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
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
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
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.
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.
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
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
12factor - VIII. ConcurrencyEscale através do modelo de processos
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;
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".
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
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
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;
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.
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;
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
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
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.
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
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.
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;
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
Openruko
Thomas Buckley-Houston < >
-
Romain Philibert < >
-
Matt Freeman < >
-
https://github.com/openruko
github.com/tombh http://tombh.co.uk
github.com/Filirom1 http://philibert.romain.free.fr
github.com/nonuby http://blog.nonuby.com
Openruko - Arquitetura
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
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
Openruko - ArquiteturaDynohost -
Serviço desenvolvido em node.js + LXC, seu trabalho se divide emquatro partes:
openruko/dynohost
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;
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
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
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
Openruko - ArquiteturaMais componentes a serem desenvolvidos
Monitor e escalonador
Addons
Billing
Portal
Openruko - Live demo
Top Related