Quando comecei a tentar implantar nas laterais do Heroku, rapidamente encontrei um problema, pois minha configuração é um tanto delicada: tenho três processos, dois usam MRI, o outro JRuby. Em desenvolvimento, eu tinha um único Procfile que iniciava tudo. Houve interações complexas com Bundler e Rbenv. Tentar encaixar no Heroku levou um dia antes de desistir e iniciar uma instância EC2 … onde perdi outro dia. Configurar um sistema de produção é difícil quando você está acostumado com o fluxo git-push-deploy do Heroku.
Então eu divido tudo. Demorou surpreendentemente pouco tempo (apenas algumas horas) e a arquitetura é muito mais sólida. Eu uso submódulos git para compartilhar código com consequências interessantes. Você pode ver tudo no Github .
Cada um dos três processos tem seu próprio repo, que envia para sua própria instância do Heroku e é gerenciado separadamente . Isso leva a cenários de implantação um tanto complexos sempre que uma migração de banco de dados é necessária, mas fora isso é ótimo.
Os submódulos são retirados em um commit específico.
As únicas coisas neste núcleo lateral são modelos de banco de dados e definições de trabalho. Como os submódulos estão ‘congelados’, a lógica determina que devo atualizá-los em todos os repositórios afetados sempre que mudar algo. Acontece que isso não é totalmente verdade:
- Os clientes Sidekiq só precisam saber o nome dos trabalhadores (e talvez arity). Portanto, contanto que eu não adicione trabalhadores, só preciso atualizar o submódulo no trabalhador lado a lado (meu servidor Sidekiq), não nos outros.
- O relógio realmente dispara jobs do Sidekiq para tudo (exceto um). Portanto, ele nunca precisa saber sobre o banco de dados. Raramente atualizo o submódulo do relógio lateral.
Implantação com tempo de inatividade zero
Quando implanto uma nova versão do front-end da web, o trabalhador ainda está em execução e não é nem um pouco afetado. Melhor ainda, posso melhorar o trabalhador sem incorrer em tempo de inatividade visível para o usuário (web). Eu implanto o relógio muito raramente.
Meta-gerenciamento orientado a aplicativos
O relógio, é claro, executa ping em todos os três serviços regularmente para garantir que eles fiquem ativos (incluindo ele mesmo). Mas também reinicia o servidor Sidekiq a cada seis horas para mantê-lo atualizado. Da mesma forma, posso imaginar um serviço percebendo que algo está lento e solicitando que outro dinamômetro seja ligado … por dentro. Isso pode trazer dimensionamento automático granular avançado. Tudo muito meta!
Mais idiomas e versões
Atualmente, estou executando duas instâncias de MRI 1.9.3 e um JRuby 1.7.0.RC2 (ainda não atualizei.) Isso é bastante ruby, mas vendo como era fácil, estou pensando em dividir ainda mais funcionalidades e usar linguagens adequadas para tarefas específicas em vez de aplicar muitos conceitos diferentes na mesma base de código. A programação baseada em eventos, por exemplo, pode ser mais adequada para NodeJS.
Reestruturação
Esta abordagem modular torna possível a refatoração de alto nível: eu poderia trocar o DataMapper e usar outra solução progressivamente, mesmo enquanto modifico o esquema de uma tabela. Talvez mais ousado, eu provavelmente poderia tirar alguns serviços do Heroku inteiramente sem tempo de inatividade significativo.