A Busca Pelo Deploy Contínuo - Parte 3

Você está lendo a Parte 3 sobre "A Busca pelo deploy contínuo" eu recomendo você a começar pela Parte 1 e depois ler a Parte 2 se você já o fez, continue ;)

Agora um exemplo de arquitetura para facilitar o uso do deploy continuo usando um Load Balancer.

Você não precisa de applicances milionários para fazer isso o github, serve 2500 conexões TCP por SEGUNDO usando o ldirectord em uma máquina Xen com 128mb.

Com um Load Balance, você consegue testar funcionalidades novas no site para uma pequena porção dos usuários do site e usar os gráficos ( que você já tem lógico ) para ver se ela é boa ou não.

Como fazer isso? faça o deploy para apenas 1 das ‘n’ máquinas que você tem atrás do Load Balancer e redirecione, 5% ~ 10% das suas conexões dos seus usuários para essa máquina, o resto os gráficos que você preparou da sua aplicação irão te dizer ;)

Falando um pouco mais de arquitetura, e especificamente de Perl, eu gosto bastante de usar o Nginx + Starman a comunicação é feita via Unix Socket o Starman foi baseado no Unicorn do Ruby, ele funciona muito bem e…

“It’s a unix system I known this!” arquiteturas unix, forks, sockets e afins funcionam muito bem :)

O seu deploy consistiria em copiar os arquivos novos e mandar um sinal de reset para o pid do Starman:

{% codeblock %} $ kill -s USR2 1337 {% endcodeblock %}

Ele vai recarregar o código, e vai reiniciar todos os seus fork assim que eles forem ficando sem conexões ou seja para seus usuários a percepção de downtime será ZERO!

Abaixo uma conf de exemplo para se usar no Nginx para se conectar a um socket gerado pelo Starman:

{% gist 1126172 %}

Bom, basicamente é isso se tiver alguma duvida pergunte nos comentários :)

Bibliografia

Alguns slides foram copiados dessa palestra da etsy:

E outros foram copiados dessa palestra da AOE Media

Obrigado :) qualquer dúvida estou a disposição nos comentários.