{"id":681,"date":"2010-02-10T15:47:11","date_gmt":"2010-02-10T17:47:11","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=681"},"modified":"2010-04-16T16:01:38","modified_gmt":"2010-04-16T19:01:38","slug":"monitorando-o-delayed-job-com-bluepill-e-capistrano","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2010\/02\/monitorando-o-delayed-job-com-bluepill-e-capistrano\/","title":{"rendered":"Monitorando o Delayed Job com Bluepill e Capistrano"},"content":{"rendered":"

Ent\u00e3o voc\u00ea j\u00e1 fez a feliz escolha de tratar seu processamento em background com Delayed Job<\/a>, \u00f3timo! Mas como ter certeza que esse processamento vai continuar acontecendo enquanto voc\u00ea estiver dormindo? E se o o processo do Delayed Job cair, voc\u00ea vai acordar de madrugada e levant\u00e1-lo na m\u00e3o? Eu n\u00e3o faria isso, gosto do meu sono. Qual a solu\u00e7\u00e3o ent\u00e3o?<\/p>\n

N\u00e3o \u00e9 nenhuma novidade para n\u00f3s, rubyistas e railers, que existem solu\u00e7\u00f5es como o God<\/a> para fazerem o trabalho de monitoramento de processos. No entanto, existem outras solu\u00e7\u00f5es, como o Bluepill<\/a>. O Bluepill \u00e9 uma ferramenta de monitoramento de processos assim como o God, mas diferente dele, n\u00e3o tem memory leak<\/a>, segundo seus autores.<\/p>\n

Bem, como n\u00e3o quero acordar de madrugada para levantar meu processo do Delayed Job na m\u00e3o, e tamb\u00e9m n\u00e3o quero ficar restartando um processo do God por causa de memory leak, resolvi usar o Bluepill. Mas como uso o Bluepill para monitorar o Delayed Job?<\/p>\n

Para configurar o Bluepill para monitorar o Delayed Job, e usar o Capistrano para automatizar algumas tarefas, temos basicamente 4 passos:<\/p>\n

    \n
  1. Instalar e configurar o Delayed job<\/li>\n
  2. Instalar e configurar o Bluepill<\/li>\n
  3. Escrever a receita de capistrano para o Bluepill<\/li>\n
  4. Setar algumas coisas do arquivo \/etc\/sudoers<\/li>\n<\/ol>\n

    Vamos dar uma olhada em detalhes em cada passo.<\/p>\n

    Instala\u00e7\u00e3o e configura\u00e7\u00e3o do Delayed Job<\/h3>\n

    Instalar e configurar o Delayed Job \u00e9 super simples, basta ler o README<\/a> do projeto, que est\u00e1 bem claro. Recomendo tamb\u00e9m assistir ao RailsCast<\/a> sobre o Delayed Job. Foi de l\u00e1 que tirei a informa\u00e7\u00e3o de usar o fork do Delayed Job da Collective Idea ao inv\u00e9s da vers\u00e3o do reposit\u00f3rio original.<\/p>\n

    Instala\u00e7\u00e3o e configura\u00e7\u00e3o do Bluepill<\/h3>\n

    Instalar o Bluepill tamb\u00e9m n\u00e3o tem muito segredo, basta voc\u00ea ler o README<\/a> do projeto e seguir os passos que est\u00e3o descritos l\u00e1.<\/p>\n

    Na parte da configura\u00e7\u00e3o, voc\u00ea pode ver as op\u00e7\u00f5es tamb\u00e9m no README<\/a> do projeto. No meu caso, esse arquivo est\u00e1 em RAILS_ROOT\/config\/production.pill<\/code>.<\/p>\n

    Bluepill.application(\"my_app\") do |app|\r\n  app.process(\"delayed_job\") do |process|\r\n    process.working_dir = \"\/home\/deploy\/my_app\/current\"\r\n\r\n    process.start_grace_time    = 10.seconds\r\n    process.stop_grace_time     = 10.seconds\r\n    process.restart_grace_time  = 10.seconds\r\n\r\n    process.start_command = \"ruby script\/delayed_job -e production start\"\r\n    process.stop_command  = \"ruby script\/delayed_job -e production stop\"\r\n\r\n    process.pid_file = \"\/home\/deploy\/my_app\/shared\/pids\/delayed_job.pid\"\r\n    process.uid = \"deploy\"\r\n    process.gid = \"deploy\"\r\n  end\r\nend<\/pre>\n
    No entanto, eu tive um pequeno problema com a intera\u00e7\u00e3o do Bluepill e o Delayed Job. Ao passar a flag -e production<\/code> para o Delayed Job, ele n\u00e3o a estava interpretando direito. Voc\u00ea pode ver mais detalhes sobre isso numa issue<\/a> que abri no repo do Delayed Job.<\/p>\n
    A primeira solu\u00e7\u00e3o que pensei, foi usar RAILS_ENV=production ruby script\/delayed_job start<\/code>, no entanto por algum motivo que ainda desconhe\u00e7o, isso n\u00e3o funcionou.<\/p>\n
    A solu\u00e7\u00e3o que cheguei ent\u00e3o para resolver esse problema, foi modificar o arquivo que est\u00e1 em RAILS_ROOT\/script\/delayed_job<\/code> para o seguinte:<\/p>\n
    \r\n#!\/usr\/bin\/env ruby\r\n\r\n# TODO improve the line of code below\r\n# The line below is just a hack while we wait the delayed job guys answer the following issue\r\n# http:\/\/github.com\/collectiveidea\/delayed_job\/issues#issue\/38\r\nENV['RAILS_ENV'] ||= \"production\"\r\nrequire File.expand_path(File.join(File.dirname(__FILE__), '..', 'config', 'environment'))\r\nrequire 'delayed\/command'\r\nDelayed::Command.new(ARGV).daemonize<\/pre>\n
    Como a flag -e production<\/code> n\u00e3o estava sendo interpretada direito no Delayed Job, estou setando na m\u00e3o o RAILS_ENV<\/code> para production<\/code> (linha 6), portanto estou supondo que voc\u00ea s\u00f3 est\u00e1 usando o Bluepill para monitorar processos do Delayed Job em environment igual a production.<\/p>\n
    Receita do Capistrano para o Bluepill<\/h3>\n
    Para automatizar as tarefas de ligar e desligar o Bluepill, escrevi a seguinte receita de capistrano:<\/p>\n
    # deploy credentials\r\nset :user, \"deploy\"\r\nset :deploy_to, \"\/home\/deploy\/#{application}\"\r\nset :use_sudo, false\r\nset :rails_env, \"production\"\r\n\r\n# Bluepill related tasks\r\nafter \"deploy:update\", \"bluepill:quit\", \"bluepill:start\"\r\nnamespace :bluepill do\r\n  desc \"Stop processes that bluepill is monitoring and quit bluepill\"\r\n  task :quit, :roles => [:app] do\r\n    sudo \"bluepill stop\"\r\n    sudo \"bluepill quit\"\r\n  end\r\n\r\n  desc \"Load bluepill configuration and start it\"\r\n  task :start, :roles =>[:app] do\r\n    sudo \"bluepill load \/home\/deploy\/my_app\/current\/config\/production.pill\"\r\n  end\r\n\r\n  desc \"Prints bluepills monitored processes statuses\"\r\n  task :status, :roles => [:app] do\r\n    sudo \"bluepill status\"\r\n  end\r\nend<\/pre>\n
    Note que ao inv\u00e9s de usar o m\u00e9todo run<\/code><\/strong> do capistrano, estou usando o m\u00e9todo sudo<\/code><\/strong>. Isso porque o comando bluepill deve ser rodado como root. Isso nos leva para o pr\u00f3ximo t\u00f3pico.<\/p>\n
    \/etc\/sudoers<\/h3>\n
    J\u00e1 que eu preciso rodar o comando bluepill como root, vou ter que mudar o meu set :user, \"deploy\"<\/code> para set :user, \"root\"<\/code>? Acho melhor n\u00e3o, n\u00e3o gostamos de dar acesso root para qualquer coisa, mesmo para deployment. Ent\u00e3o, como fazer? Simples, basta editar seu arquivo de sudoers.<\/p>\n
    Para isso, voc\u00ea precisa usar o comando visudo<\/code> para abrir e editar o arquivo \/etc\/sudoers<\/code>. Uma vez com o arquivo aberto, adicione a seguinte linha no final do arquivo:<\/p>\n
    deploy ALL=(ALL) NOPASSWD: \/usr\/local\/bin\/bluepill<\/code><\/p>\n
    Pronto, agora o usu\u00e1rio deploy j\u00e1 pode fazer sudo bluepill<\/code> sem precisar de senha. Problema resolvido sem colocar a seguran\u00e7a da sua m\u00e1quina em risco. \ud83d\ude09<\/p>\n
    Depois de ter feito esses 4 passos, voc\u00ea est\u00e1 pronto para dormir a noite sem se preocupar com seu processo do Delayed Job. E quando quando quiser saber como est\u00e1 o status dos seus processos monitorados, basta usar a seguinte task do capistrano na sua m\u00e1quina local:<\/p>\n
    cap bluepill:status<\/code><\/p>\n
    E voc\u00ea? Quais solu\u00e7\u00f5es voc\u00ea usa para dormir em paz?<\/p>\n
    Update:<\/strong> Se voc\u00ea est\u00e1 tendo problemas em restartar o Bluepill com o capistrano, d\u00ea uma olhada aqui<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Ent\u00e3o voc\u00ea j\u00e1 fez a feliz escolha de tratar seu processamento em background com Delayed Job, \u00f3timo! Mas como ter certeza que esse processamento vai continuar acontecendo enquanto voc\u00ea estiver dormindo? E se o o processo do Delayed Job cair, voc\u00ea vai acordar de madrugada e levant\u00e1-lo na m\u00e3o? Eu n\u00e3o faria isso, gosto do … \u00bb<\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/681"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=681"}],"version-history":[{"count":41,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/681\/revisions"}],"predecessor-version":[{"id":879,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/681\/revisions\/879"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=681"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=681"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=681"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}