Planeta Perl Brasil

Última atualização: 04/05/2012

December 03, 2011

Lorn

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:

1
$ kill -s USR2 1337

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:

upstream myapp_starman {
  server unix:/tmp/starman.sock fail_timeout=0;
}

server {
  listen 80;

  client_max_body_size 1024m;
  client_body_buffer_size 8k;
  proxy_read_timeout 300;

  ##
  # basic
  ##
  server_name www.localhost.com;
  root /home/user/MyApp/root;
  keepalive_timeout 0;

  ##
  # logging
  ##
  access_log /var/log/nginx/myapp.access combined;
  error_log /var/log/nginx/myapp.error;
  
  location /static {
        root  /home/user/MyApp/root/;
        autoindex on;
  }

  ##
  # proxy
  ##
  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_buffering off;
    if (!-f $request_filename) {
      proxy_pass http://myapp_starman;
    }
  }
}

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.

03/12/2011

December 02, 2011

Lorn

A Busca Pelo Deploy Contínuo - Parte 2

Você está lendo a Parte 2 sobre “A Busca pelo deploy contínuo” eu recomendo você a começar pela Parte 1 mas se já leu as duas partes, leia a Parte 3.

Agora que você já está convencido que precisa disso, ou não, vou começar a falar de algumas ferramentas/técnicas que você pode usar para te ajudar no processo:

  • SCM - Software Configuration Management

    Também conhecido como VCS ( Version Control System ), você precisa disso, se você não tem há algo muito errado e se você está usando Subversion, isso não é tão ruim, mas comece a usar git a partir de hoje, sério.

  • Testes

    Se você acha que teste é besteira, então deploy continuo é besteira para você também. É impossível ter um deploy contínuo confiável sem testes

  • Continuos Integration Software

    Esse tipo de software tem um papel simples, porem eficaz, ele fica fazendo “pooling” no seu SCM, a cada commit seu ele vai rodar o seu processo de “build” para ver se ele continua funcionando depois do código que você acabou de comitar, um processo de build pode conter:

    • Gerar pacotes
    • Verificar códigos/dependências
    • Testes Unitários
    • Testes de Integração
    • Testes de Segurança
    • Testes funcionais

    E caso algum teste tenha parado de funcionar, ele vai te enviar um email avisando que o build está quebrado.

    Eu uso e gosto bastante do Jenkins, conhecido antes como Hudson. Mas há muitos outros por ai, você só precisa escolher um.

  • Script de Deploy/Rollback para você começar, depois de ter todas essas coisas acima, você já pode a pensar em automatizar seu processo de deploy/rollback.

    • ./deploy.sh # faz o deploy
    • ./rollback.sh # faz o rollback do ultimo deploy

    Simples assim, mas tem que ser um script só que faz todo o trabalho, copiar arquivos, reinciar webserver etc

    Na Etsy quando o script ficou avançado eles evoluiram para um software web, que inclusive é opensource mais detalhes aqui: Deploynator Etsy

  • Puppet/Chef - eu não sei qual o nome dessa categoria de software, o que você faz com eles é escrever “receitas” de máquinas, imagine que a empresa está crescendo e você precisa montar 10 novos webservers que incluem:

    • Instalar SO
    • Configurar SO
    • Configurar Firewall
    • Configurar Webserver
    • Configurar seu sistema
    • Colocar ela no pool de webservers

    Tirando a instalação do Linux, todo o resto você pode automatizar com puppet ou chef você cria receitas nele dizendo como ele vai configurar seu Webserver, seu sistema e depois é só executar essa receita na máquina ele vai instalar o pacote e fazer todo o trabalho pra você.

    E você vai precisar fazer isso UMA vez para ‘n’ maquinas, e quando precisar mudar algo e só alterar na receita ele mantém as maquinas sincronizadas com sua receitas, nada de sair editando o mesmo arquivo em várias máquinas.

  • Monitoramento

    • Sistema Base/Nagios

      Você precisa monitorar o estado do seu sistema, vê se o Apache tá de pé se o disco tá cheio isso é bem comum, no minímo você já ouviu falar.

    • Seu negócio

      Você precisa também monitorar o seu negócio, você precisa saber que horas que acontecem mais vendas e precisa saber agora, nada de rodar aquela query no banco de dados faça gráfico de toda informação que você puder monitorar.

      Além desses gráficos ajudar o pessoal de Marketing/Vendas vai te ajudar quando entrar alguma funcionalidade nova no site, porque sempre tem um espertão na empresa, e muitas vezes esse espertão é o dono, que vai dizer:

      Acho que depois que você colocou aquela funcionalidade no site, o site está vendendo menos, estou com esse pressentimento.
      - Espertão

      A Etsy liberou recentemente a ferramente que eles fizeram para fazer gráficos, vale a pena dar uma olhada Measure Anything, Measure Everything eles contam bastante expêriencia deles com geração de gráfico para tudo, até para a quantidade de café na cozinha!

      Então tenha gráficos de tudo e mostre para ele no melhor sentido Opa chefe! tranquilo chefe!.

Continua ..

Você está lendo a Parte 2 sobre “A Busca pelo deploy contínuo” eu recomendo você a começar pela Parte 1 mas se já leu as duas partes, leia a Parte 3.

02/12/2011

A Busca Pelo Deploy Contínuo - Parte 1

Você está lendo a Parte 1 sobre “A Busca pelo deploy contínuo” esse post tem mais duas continuações: Parte 2 e Parte 3.

No dia 05/11 apresentei no YAPC::Brasil uma palestra com o nome “Em busca do deploy continuo” nesse post vou tentar descrever sobre tudo o que eu falei.

Como começar?

Infelizmente o principal problema do “Deploy Continuo” não é técnico e sim cultural, e mudança de cultura é muito mais difícil que mudança de Banco de Dados ou de Linguagem de Programação é enraizado nas fundações da empresa, esses são alguns exemplos culturais:

  • Falta de confiança

  • Processos complicado/complexos para tudo

Processo é uma reação à estupidez incorporada antes
- Clay Shirky

Em português claro, esse seria o famoso “vai que…” :

  • Vai que alguém faz uma alteração errada e o site fica fora do ar
  • Vai que alguém cria uma tabela nova e o site fica fora do ar.

Ainda bem que esse pessoal de processo não conhece o Efeito Borboleta se não eles iam criar coisas bem piores.

Em Startups esse tipo de coisa não acontece porque, geralmente, se tem pouco recurso e é necessário já pensar em Deploy/Integração continua desde o início, pois você precisa entregar valor para seu usuário para continuar vivo, você não tem uma receita fixa.

Então, se você for esperar a próxima madrugada para subir a funcionalidade que já está pronta, , fica dificil pivotear talvez essa funcionalidade não seja bem vista por seus usuários, eles entenderam errado, então é necessário não só coloca-la rápida em produção como tirar rápido também :)

Imagine demorar 48h para concluir esse fluxo todo, você pode perder usuários preciosos.

O github.com que é era uma startup e agora, mesmo depois de passar dos 40 funcionários, continua com as mesmas idéias de desenvolvimento baseado em software livre e deploy contínuo.

Caso você queira conhecer como funciona o processo de desenvolvimento/trabalho no github, eu recomendo a lida desse post do Zach Holman que é um dos funcionário mais antigos por lá e caso você não queira conhecer :)

Recentemente ele deu uma palestra falando um pouco mais sobre isso e como se usar o github como plataforma para esse processo ser aplicado em qualquer empresa.

Mas até agora, eu sou falei de empresinhas pequenas, por mais que elas ganhem algum dinheiro não tem um nome a zelar.

Quero ver isso funcionar em uma empresa grande!
- Cara de processo

Funciona, vou te dizer dois exemplos:

  • Amazon

  • Etsy

A Amazon chegou a divulgar em um apresentação na Velocity 2011 que faz um deploy a cada 11.6 segundos e você aí feliz por ter conseguido uma janela mais cedo para fazer seu deploy né?

A Etsy, não é muito famosa aqui no Brasil, e a conheci ela antes de me interessar sobre deploy continuo comprei um adesivo com uma frase de StarWars lá :) eles funcionam como um Mercado Livre para artesões e outras profissões “hand-made”.

Eles tem a bagatela de 1 bilhão de pageview por mês!

Caso você queira entender como funciona o deploy continuo na Etsy, e como era a vida deles antes do deploy continuo veja essa palestra:

Watch live streaming video from etsy at livestream.com

Tudo isso começou na Etsy, porque um ex-flickr foi contratado para ser o CTO lá e o flickr foi bem pioneiro nesse negócio de deploy contínuo, você pode ver um pouco mais sobre isso nessa outra palestra:

Continua ..

Você está lendo a Parte 1 sobre “A Busca pelo deploy contínuo” esse post tem mais duas continuações: Parte 2 e Parte 3.

02/12/2011

September 26, 2011

Lorn

Lá E Devolta Outra Vez

Depois de muito pensar, e a preguiça dominar, resolvi continuar no bom e velho wordpress até fiz o tão prometido blog em catalyst, mas a parte de design css/html e afins deu um trabalhinho e não está do jeito que eu quero e o wordpress tem tantos temas legais. Pelo menos aprendi bastante fazendo o blog, inclusive tem um branch ativo agora porque estou migrando a parte de persistencia para CouchDB.

Update: Mudei para o tumblr e meu blog agora fica no http://blog.lornlab.org

Update 2: Agora estou migrando para o Octopress

26/09/2011