Uma configuração média que deve servir pra grande maioria das aplicações pequenas/médias de 8 reserved cloudlet de 768Mb e 1.2GHZ, 2 nodes sob balanceamento, com 256MB de Memcached, 1Gb e 1.6Ghz de PostgreSQL (sempre deixe seu banco maior que sua máquina Web) dá em torno de R$ 280 por mês, ou o equivalente a USD 96, que eu achei até competitivo com alternativas internacionais (sim, é controverso mas levar impostos em consideração).
Dicas de Configuração
Você pode fazer o deployment diretamente de um repositório Github ou subir de um zip. Depois disso você pode entrar em qualquer das máquinas diretamente via SSH. Esse passo será necessário pois não há outra forma de configurar ambiente (especificamente variáveis de ambiente que é o correto para configurações). Entre via SSH e configure um arquivo .env com seus dados de produção usando a gem dotenv-rails.
Uma coisa importante: se usar a configuração normal de banco de dados via config/database.yml vai ter problemas no caso do PostgreSQL pois parece que há diferença de versão entre o libpg nos nodes web com o PostgreSQL na máquina separada. Para bypassar isso, configure no arquivo .env uma variável chamada DATABASE_URL (que por padrão, bypassa o database.yml e conecta por TCP em vez de Unix Sockets). O formato dessa variável deve ser assim:
1 |
DATABASE_URL: 'postgres://[usuario]:[senha]@[host]:5432/[nome do banco]' |
Ao criar o servidor PostgreSQL você também deve receber um email com um link para o PHPPGAdmin que é uma interface web para configurar o banco, você pode entrar por lá e criar um novo usuário (não use o usuário 'webadmin', obviamente). Outra opção é entrar via SSH direto no servidor de banco e usar comandos normais como createuser ou createdb. Não esqueça de adicionar sua chave pública de SSH na aba de configurações da aplicação, é simples.
O deployment automaticamente via colocar os arquivos da sua aplicação no lugar correto e já vai executar o bundle install. Mas depois do deployment você ainda vai precisar entrar via SSH no node NGINX para executar tasks como rake db:migrate e rake assets:precompile. Se estiver usando Memcache (com Rack::Cache, por exemplo), às vezes talvez precise entrar via SSH para acessar o rails console para poder zerar o cache via Rails.cache.clear. No meu caso, mesmo depois do deployment dizer que já rodou o Bundler ainda precisei entrar no diretório da aplicação e rodar bundle install manualmente. Nada de mais, mas vale lembrar disso.
Obs: O Kemel me avisou depois que publiquei o post que o Jelastic (que parece que usa a estrutura do OpenShift por trás) suporta um arquivo rake_deploy justamente para adicionar configurações pós-deployment que podem ser executados automaticamente sem precisar entrar por SSH toda vez. Veja esta documentação.
Finalmente, se fez tudo certo, você já pode acessar sua aplicação pelo endereço [nome da app].jelasticlw.com. Daí você pode configurar a aplicação para aceitar um Custom Domain (domínio que você registrou) e no seu serviço de DNS (seja na própria Locaweb ou serviços como Zerigo, SimpleDNS) configurar o CNAME para apontar para o endereço Jelastic.
Não cheguei a testar mas o Jelastic também oferece opções como adicionar SSL e também Auto Scaling (escalabilidade horizontal), de tal maneira que se sua aplicação ultrapassar certas barreiras de consumo de CPU e/ou de Memória, ele automaticamente pode adicionar e remover nodes (você configura números máximos e mínimos de nodes). Assim você pode ficar despreocupado se seu site tiver picos inesperados de acesso e vai gastar apenas o que realmente precisa.
De pontos negativos, comparado ao que um PaaS de Ruby poderia ser, infelizmente ele não tem o conceito de buildpacks abertos, não tem como configurar um pipeline de deployment que já execute corretamente as Rake Tasks do Assets Precompile, Db:Migrate, etc. Não tem suporte a Procfile para subir o servidor de aplicação correto (recomendo já usar o Raptor direto). A escalabilidade vertical não ajuda tanto porque mesmo aumentando a capacidade da máquina, precisaríamos entrar via SSH para configurar a quantidade de worker processes de um Unicorn, por exemplo. E no meu teste, adicionar o balanceador de carga depois que já tinha um node deu problema (acho que precisa já deixar adicionar logo que cria a aplicação e não adicionar depois). Um último ponto importante: não há uma máquina para workers (background jobs), somente nodes web. Mesmo se precisar rodar cronjobs, ele vai rodar em concorrência com seu processo Web, o que é ruim para o tempo de resposta da aplicação web. Ainda não parei para ver se há outra forma (se alguém souber como, não deixe de colocar nos comentários).
De ponto positivo, a aplicação que coloquei no ar funcionou (Hurray!), teve alguns caveats que mencionei acima, mas o importante é que no final ele realmente funcionou. Ainda é cedo pra dizer o comportamento (foi meu primeiro teste), mas vamos ver o que teremos no futuro. O Jelastic continua em evolução: a própria adição do Raptor é um sinal disso, o que é muito positivo.
Conclusão
O Jelastic não é para completos iniciantes, para isso são planos de hospedagem compartilhada que já vem pré-configurados se você precisa subir um mero Wordpress ou Magento. Ele é para desenvolvedores com alguma experiência e que não deveriam estar responsabilizados pela infraestrutura do cliente. Configurar VPS não é difícil, mas a manutenção pode ser, especialmente se for necessário atualizar os recursos da máquina ou, principalmente, se for necessário configurar escalabilidade horizontal e recursos mais avançados como auto escalabilidade horizontal.
O custo do Jelastic é definitivamente maior que qualquer hospedagem compartilhada, porém é como comparar maçãs e bananas. Hospedagens compartilhadas são para coisas pequenas, de preferência sites completamente estáticos, que exigem quase nenhum processamento. Qualquer coisa maior que um pequeno blog vai sofrer. O único próximo passo que as hospedagens brasileiras ofereciam eram ou um Cloud Server (VPS) ou diretamente hardware bruto.
O Jelastic é o meio do caminho e da forma como está caminhando pode ser um ótimo meio do caminho que vale a pena ser explorado. O primeiro deployment pode ser meio doloroso até aprender o que é possível fazer, mas depois disso tudo fica menos complicado e definitivamente o custo-benefício entre manter um administrador de sistemas experiente full time na sua folha de pagamentos vai compensar algumas horas do seu desenvolvedor aprendendo a configurar a plataforma.
Num mundo onde ainda parece "normal" fazer deployment via FTP (protip: TOSCO!) e editar arquivos diretamente em produção, um produto como o Jelastic pode começar a ajudar a evangelizar conceitos mais corretos de deployment em produção.
Disclaimer: eu não sou da Locaweb e este post não é um marketing pago ou coisa do tipo. O Jelastic é um produto novo então muitos já devem ter enfrentado dores de cabeça. Se tiver experiências que possam ajudar outros desenvolvedores, não deixem de comentar abaixo.