The twelve factor apps and openruko

1,072 views

Published on

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

Published in: Technology
3 Comments
7 Likes
Statistics
Notes
  • @nuxlli Obrigado pela resposta! Vou dar uma estudada mais sobre o PaaS, que me deixou bastante interessado e aos poucos vou ler mais a respeito do Apple Sandbox :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @wolcanus que bom que gostou :D

    No caso de um PaaS a persistência de variáveis entre servidores já faz parte do processo. Mas de fato isso é um pouco 'confuso' quando se esta trabalhando com deploy mais manual (como no caso de capistrano), mas de qualquer forma o melhor seria usar mesmo uma ferramenta de provisionamento como chef ou puppet, e garantir integridade entre as várias replicas.

    Logstash e Kibana (eu não conhecia esse, vlw), são boas ferramentas de processamento de log, mas elas diferenciam um pouco do conceito de tornar log um stream de informação, a coisa seria mais como um 'chat', onde os logs são enviados e vários serviços podem ler e processar esses logs, e ai sim entraria esses carinhas na equação.

    Sobre o Apple Sandbox, é uma 'feature' do mac os x bem interessante, confesso que para usar ela melhor gastaria muito, mas muito trabalho mesmo, de leitura e entendimento de como ela funciona, mas é uma coisa bacana.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Bem legal pluginho!

    Fiquei com algumas dúvidas:

    Em relação às configs da app: se armazenarmos em variáveis de ambiente (como uma das sugestões), como deve ocorrer a sincronização dos valores entre as instâncias da app em servidores separados? Puppet seria aplicável nesse caso?

    Sobre os logs, conhece LogStash (http://logstash.net/) e Kibana (http://kibana.org)? Essas ferramentas estariam de acordo com 'tratar logs como stream'?

    Ah, notei um erro de digitação na palavra 'expostos' no slide 38.

    Não conhecia o Apple Sandbox. Estou dando uma lida na documentação, obrigado pela referência no README do macbox.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,072
On SlideShare
0
From Embeds
0
Number of Embeds
167
Actions
Shares
0
Downloads
2
Comments
3
Likes
7
Embeds 0
No embeds

No notes for slide

The twelve factor apps and openruko

  1. 1. 12factor.netgh/openruko Éverton Ribeiro
  2. 2. PaaSTão difícil como parece ou tão fácil como deve ser?
  3. 3. The Twelve-Factor AppsMetodologia para construção de software-as-a-serviceDefine uma série de diretrizes e vocabulário padrãoDesenvolvedores / Engenheiros / Infra-estrutura
  4. 4. 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
  5. 5. 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.
  6. 6. 12factor - I. Codebase Um codebase com controle de versão, vários deploys✘ Multiplas apps compartilhando o mesmo codebase violam o princípio twelve-factor. ✓ Separe seu código em bibliotecas.
  7. 7. 12factor - I. Codebase Um 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 em cada instância.
  8. 8. 12factor - I. Codebase Um codebase com controle de versão, vários deploys✓ Diferentes desenvolvedores e instâncias pode rodar diferentes versões do codebase.
  9. 9. 12factor - II. Dependencies Declarar e isolar dependências explicitamente Ruby: "Gem Bundler + Gemfile" - bundle exec Python: Pip - Virtualenv C: Autoconf - static linking
  10. 10. 12factor - II. Dependencies Declarar 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.
  11. 11. 12factor - II. Dependencies Declarar e isolar dependências explicitamente✘ Nunca depender da existência implícita de todas as ferramentas do sistemaMesmo 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
  12. 12. 12factor - II. Dependencies Declarar e isolar dependências explicitamente ✓ Positive side effect: tornar fácil a entrada de novos desenvolvedores
  13. 13. 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 edeveloper) de uma mesma aplicação, o código não vai variar com a mesma frequência.
  14. 14. 12factor - III. Config Armazenar configurações no environmentMelhor 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.
  15. 15. 12factor - III. Config Armazenar configurações no environmentConfiguraçõ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.
  16. 16. 12factor - III. Config Armazenar configurações no environment✓ 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;
  17. 17. 12factor - III. Config Armazenar configurações no environment✓ Agnóstico de linguagem e sistema operacional
  18. 18. 12factor - III. Config Armazenar configurações no environmentModelos: Grupos nomeados (também conhecidos como "environments") vs. Variáveis de ambiente
  19. 19. 12factor - IV. Backing Services Tratar backing services como recursos conectadosQualquer 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
  20. 20. 12factor - IV. Backing Services Tratar backing services como recursos conectadosMas 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 APIs: Twitter, Google Maps ou Last.fm
  21. 21. 12factor - IV. Backing Services Tratar backing services como recursos conectados✓ Não é feita distinção entre backing services locais ou de terceirosUma vez que o resource foi anexado a aplicação, seu acesso se da por URL ou localizador/credencias adicionados ao config.
  22. 22. 12factor - IV. Backing Services Tratar backing services como recursos conectados✓ Facilitar o processo de troca entre versões de resources, sem a necessidade de alteração ou deploy de um novo código
  23. 23. 12factor - IV. Backing Services Tratar 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;
  24. 24. V. Build, release, run Separar os estágios de build e execuçãoO codebase é transformado em deploy em três estágios:
  25. 25. V. Build, release, run Separar 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 das dependências e compilação de assets.
  26. 26. V. Build, release, run Separar 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
  27. 27. V. Build, release, run Separar os estágios de build e execuçãoRun stage: também conhecido com runtime, nesta fase o pacote gerado no release é executado no ambiente de execução.
  28. 28. V. Build, release, runSeparar os estágios de build e execução
  29. 29. V. Build, release, run Separar os estágios de build e execuçãoTwelve-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.
  30. 30. V. Build, release, run Separar os estágios de build e execuçãoO processo de build é disparado pela ferramenta de deploy, quedeve ser capaz de, dentre outras coisas, executar processo derollback e atualização do códigoCada release deve ter um ID único, e uma vez criada não pode sermodificada;A fase de build tende a ser a fase mais complexa, em geral é ondeas falhas acontecem e são reportadas ao desenvolvedorimediatamente
  31. 31. 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: $pto m_citp yhn ysrp.y
  32. 32. 12factor - VI. ProcessesExecutar a aplicação como um ou mais processes sem estadoNa 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
  33. 33. 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
  34. 34. 12factor - VI. ProcessesExecutar a aplicação como um ou mais processes sem estado ✓ Memória e disco devem ser consideradas regiões de brief ou single-transaction, qualquer outra informação que necessite persistencia deve utilizar resources.
  35. 35. 12factor - VII. Port binding Exportar 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 http dando binding em uma porta e aguardar por requests nesta porta.
  36. 36. 12factor - VII. Port binding Exportar serviços via port bindingNão apenas serviços http devem ser espostos dessa forma, um serviço com ejabberd ou redis devem fazer o mesmo
  37. 37. 12factor - VII. Port binding Exportar serviços via port bindingObserve que um serviço assim exposto pode ser tornar um backing service para outras aplicações
  38. 38. 12factor - VIII. Concurrency Escale através do modelo de processos
  39. 39. 12factor - IX. DisposabilityMaximizar a robustez com fast startup e graceful shutdownNo 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;
  40. 40. 12factor - IX. Disposability Maximizar 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".
  41. 41. 12factor - IX. DisposabilityMaximizar a robustez com fast startup e graceful shutdown O processo de graceful shutdown deve ocorrer normalmente quando o processo recebe um SIGTERM. Para processos http porexemplo, ele deve parar de esperar por novas requisições, finalizar as requisições atuais, fechar todos os streams em andamento e finalizar o processo
  42. 42. 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 de desenvolvimento
  43. 43. 12factor - X. Dev/prod parity Procure 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, SQLitesobre OS X, e coloca em produção sobre: Apache, MySQL e Linux;
  44. 44. 12factor - X. Dev/prod parity Procure tornar os ambientes de development, staging e production o mais similar possívelTwelve-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.
  45. 45. 12factor - X. Dev/prod parity Procure 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 odeploy depois de algumas horas ou mesmo minutos;Gap pessoal: Quem desenvolve faz deploy, e pode observar comoo código se comportou em produção;Gap de ferramentas: mantendo o environment de produção edesenvolvimento tão semelhante possível;
  46. 46. 12factor - X. Dev/prod parity Procure tornar os ambientes de development, staging e production o mais similar 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
  47. 47. 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
  48. 48. 12factor - XI. Logs Trate logs como streamLogs 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.
  49. 49. 12factor - XI. Logs Trate 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
  50. 50. 12factor - XI. Logs Trate logs como streamBacking services para análise dos logs e geração de métricas podem ser adicionados para completar o processo.
  51. 51. 12factor - XII. Admin processTarefas de administração e manutenção devem ser on-off processesAlé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;
  52. 52. 12factor - XII. Admin process Tarefas de administração e manutenção devem ser on-off processesPara 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
  53. 53. 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
  54. 54. Openruko - Arquitetura
  55. 55. Openruko - Arquitetura Api Server -  openruko/apiserverComponente 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çãocom o desenvolvedor, que em geral é feita por meio daferramenta de CLI.API Privada: Por meio da qual todos os outros componentesinternos obtem informações sobre as fases de: build, release erun.
  56. 56. Openruko - Arquitetura 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
  57. 57. Openruko - Arquitetura Dynohost -  openruko/dynohostServiço desenvolvido em node.js + LXC, seu trabalho se divide em quatro partes:
  58. 58. Container constructor: Através de scripts bash constroi osarquivos de configuração e ponto de montagem / do containerLXC Wrapper: Uma vez com arquivos de configuração e o pontode montagem estabelecido, gerencia a execução dos containersLXC;Deploy: Antes de executar um container baixa o slug a serexecutado e monta este na pasta /app, e por fim starta ocontainer para execução do rukorunDyno gestor: Constroi um canal de comunicação com o container(dyno) por meio de sockets;
  59. 59. Openruko - Arquitetura 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
  60. 60. Openruko - Arquitetura Httprouting -  openruko/httproutingBalanceador 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
  61. 61. Openruko - Arquitetura Logplex -  openruko/logplex Syslog distribuído, este serviço desenvolvido em node.js é umasimplificação compatível do serviço de mesmo nome do heroku.
  62. 62. Openruko - Arquitetura Mais componentes a serem desenvolvidos Monitor e escalonador Addons Billing Portal
  63. 63. Openruko - Live demo
  64. 64. Perguntas?@nuxlli - https://github.com/nuxlli

×