Quando comecei a me interessar pelo tema Vagrant + Chef (cuja solução eu descrevi aqui), uma questão básica que eu quis responder desde o início era:

OK, eu consigo montar uma VM local e ter um ambiente de desenvolvimento / testes idêntico ao ambiente de produção. Mas como eu uso essas ferramentas para criar o meu ambiente de produção no AWS?

A versão 1.1 do Vagrant trouxe uma resposta parcial para o meu questionamento, ao criar o conceito de PROVIDER de virtualização, e permitir o uso de outros serviços além do VirtualBox. Entre eles, o uso de AWS. O Vagrant 1.2, lançado recentemente, parece permitir a gestão de diversas máquinas usando vagrant (coisa que acabo de descobrir, e que será objeto de nova pesquisa e novo post).

Vamos a mais uma receitinha de bolo. Sigam-me os bons:

• Execute o passo-a-passo descrito no post Vagrant + Chef;

• Crie uma conta no AWS, caso já não tenha uma (sempre é bom verificar…);

• Instale o plugin vagrant-aws:

  > vagrant plugin install vagrant-aws

• Adicione uma Dummy Box no vagrant, que será considerada como um box AWS. O jeito mais simples de fazer isso é utilizando a box criada por Mitchell Hashimoto:

  > vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

• Adicione um bloco novo no seu Vagrantfile, descrevendo e parametrizando a instância a ser criada no EC2:

    Vagrant.configure("2") do |config|
        config.vm.provider :aws do |aws|
            aws.access_key_id = "CHAVE DE ACESSO API AWS"
            aws.secret_access_key = "CHAVE SECRETA DE ACESSO API AWS"
            aws.keypair_name = "NOME DO PAR CHAVE/VALOR PARA ACESSO SSH"
            aws.ssh_private_key_path = "CAMINHO DO ARQUIVO CHAVE/VALOR PARA ACESSO SSH"
            aws.ami = "ami-3d4ff254"
            aws.ssh_username = "USERNAME"
            config.ssh.username = "USERNAME"
            aws.instance_type = "TIPO DE INSTANCIA. Ex: c1.medium"
            aws.security_groups = ["LISTA DE GRUPOS DE SEGURANCA",]
        end
    end

• Execute:

  > vagrant up --provider=aws

Seguindo este passo-a-passo, o resultado final será uma instancia do EC2 provisionada com seus scripts Chef. Caso tenha usado o script descrito no post anterior, você terá um servidor NGinx servindo um Hello World.

O plugins vagrant-ssh está disponível no github.

Estou como autor deste post, mas na verdade o autor deveria ser o nosso colega Thiago Ganzarolli, que é o real autor da apresentação sobre DevOps abaixo. Achei propício, tendo em vista o tema abordado no meu último post.

DevOps, NoOps...afinal que raios é isso? from Thiago Ganzarolli

Desenvolvedor de startup codifica, testa, publica, mantém infra, desenha telas, atende telefone e lava a louça do cafezinho no fim da tarde. E aí, o único jeito de se manter digno e produtivo é automatizar tudo o que puder ser automatizado, economizando tempo e erros bestas. Além do mais, em tempos de computação nas nuvens, hardware virou software e a melhor forma de tirar proveito desta flexibilidade é automatizando o processo de criação e configuração de suas máquinas. Assim, fica possível expandir, reduzir e substituir servidores com um ou dois cliques.

No SIGA, usamos intensivamente os serviços da Amazon AWS, temos alguns servidores rodando (e em alguns casos, este número varia automaGicamente conforme a necessidade), e apenas um coitado gerenciando tudo: eu. Me vi obrigado a procurar soluções, e o Fabric caiu como uma luva. Montei um script capaz de gerenciar minhas máquinas na Amazon (start, stop, reboot), os serviços disponíveis em cada, além de configuração inicial e atualização de código.

Tudo muito bom, tudo muito bem, cheguei ao limite desta solução, por vários motivos:

1. Totalmente amarrado à infra da Amazon;
2. Totalmente amarrado ao Ubuntu;
3. Desenvolvido de forma orgânica e sem muito planejamento. A portabilidade do script entre projetos melhorou muito, mas ainda é precária;

Procurando soluções, comecei a prestar mais atenção no Chef. E a coisa realmente começou a me interessar quando fui apresentado ao Vagrant. Resumindo muito cada ferramenta, o Chef é um sistema que automatiza a configuração de máquinas e instalação de pacotes, através de receitas (recipes), sendo capaz de lidar com sutilidades de diversos sistemas operacionais.

Chef provides a flexible model for reuse by enabling users to model infrastructure as code to easily and consistently configure and deploy infrastructure across any platform.

Já o Vagrant é um criador de máquinas virtuais, sendo capaz de gerar VMs do VirtualBox e VMWare a partir de um script.

Create a single file for your project to describe the type of machine you want, the software that needs to be installed, and the way you want to access the machine. Store this file with your project code.

Como você já deve ter adivinhado, o Vagrant usa o Chef para configurar e instalar pacotes em uma VM. Ambos permitem transformar a configuração de uma máquina em um simples script, que pode ser facilmente distribuido entre todos os desenvolvedores de um projeto (resolvendo outra dor de cabeça: ambientes heterogêneos. Quem nunca sofreu com isso que jogue a primeira pedra).

Resolvi por a mão na massa e montar setup básico para criar uma VM Ubuntu 12.04 com NGINX servindo uma página HELLO WORLD. Deu certo, e resolvi compartilhar este código com o mundo. Como este texto já está ficando longo, vou dar aqui apenas a receitinha de bolo pra executar o meu setup que, espero, poderá servir de ponto de partida para outros interessados no assunto.

Vamos lá:

1. Instale o VirtualBox, disponível em https://www.virtualbox.org/;

2. Instale Vagrant >= 1.1.X, disponivel no site http://vagrantup.com;

3. Instale ruby 1.9;

4. Instale chef:

   > gem install chef

5. Instale o plugin vagrant-omnibus. Ele garante que o Chef estará instalado na versão correta na VM:

   > vagrant plugin install vagrant-omnibus

6. Instale uma box do Ubuntu 12.04 no Vagrant :

   > vagrant box add precise64 http://dl.dropbox.com/u/1537815/precise64.box

   (caso prefira outro sabor de Linux, existe uma lista bastante grande de listadas em http://www.vagrantbox.es/)

7. Baixe o meu template de código no GitHub:

   > git clone git://github.com/mgalves/vagrant-chef-nginx.git

8. Entre no diretório vagrant-chef-nginx/chef_repo;

9. Rode o comando:

   > vagrant up

10. Acesse http://192.168.33.10/;

11. Hello World!

Quando comecei a utilizar sistemas de controle de versão distribuídos (ou DCVS), iniciei com o Mercurial, basicamente porque achei que a documentação era mais simples do que a qe o Git oferecia. No entanto, profissionalmente, Git se transformou no padrão (pelo menos na minha experiência), e tive que aprender a lidar com ele. Tendo compreendido os conceitos do Mercurial, a transição não foi difícil. Só havia uma coisa que eu sentia bastante falta, e agora não mais - o hg serve.

Basicamente este comando permite que outros se conectem ao seu repositório particular. Isto é bastante interessante quando você pareia com alguém em sua máquina, faz algumas mudanças que ainda não estão prontas para ser enviadas ao repositório central, e então precisa que estas mudanças estejam na máquina do seu par porque amanhã você não poderá vir ao escritório por exemplo. E isto só é possível porque o sistema é descentralizado, ou seja, qualquer repositório pode servir outro repositório.

As alternativas com o Git seria criar um patch e enviar ao seu parceiro, ou criar um branch no repositório central. Nestes momentos, sempre me lembrava com nostalgia do Mercurial. Mas agora descobri que é possível fazer algo similar com o Git:

git daemon –reuseaddr –base-path=. –export-all –verbose

Executando este comando em seu repositório local irá permitir que outros o acessem da mesma forma que fazemos usualmente com o repositório central. Basta que os interessados adicionem sua máquina com um repositório remoto ( git remote add ).

A fonte desta dica vem desta pergunta do StackOverflow.

Acredito que 99.9% dos desenvolvedores ja ouviram falar de progamaçao pareada, e certamente quase todos, consciente ou inconscientemente, ja fez uso desta pratica de desenvolvimento. Meu objetivo neste post nao e descrever esta tecnica, nem ensinar como aplica-la, mas sim relatar um pouco da minha experiencia “pareando”, e o que tenho aprendido com ela.

Minha experiencia real com programaçao pareada e muito pequena, e se concentra especialmente nas ultima seis semanas, quando iniciei em um novo projeto na empresa em que trabalho. Antes disto, minha experiencia se resumia ha algumas vezes em que entrava em um novo projeto em andamento, e pareava para facilitar a imersao no novo codigo e novo dominio, e ao que chamo de pareamento inconsciente, que e quando voce nao sabe mais o que fazer para resolver um problema, e pede ajuda a alguem (e vice-versa).

Dada esta limitada experiencia, a ideia que tinha desta pratica e de que era util para:

* facilitar a imersao em um projeto em andamento * auxiliar no aprendizado de desenvolvedores menos experientes * solucionar problemas que nao se consegue resolver sozinho

Eis que entao inicio neste novo projeto, em uma equipe pequena, e distribuida (2.2 desenvolvedores em Porto Alegre, 3 desenvolvedores em Boston, e 1 em Seatle), composta por desenvolvedores experientes. Alem disto, com expectativa de entregar a primeira versao do sistema em 3 meses. Dado este cenario, imaginava que parear nao seria de grande utilidade. Apenas no inicio, para realizar a imersao dos desenvolvedores de Porto Alegre no novo dominio (registros medicos eletronicos) e no framework utilizado (OpenMRS).

Mas durante este inicio de projeto, eis que me deparo com alguns desafios para os quais vi que a programaçao pareada tem se mostrado uma soluçao interessante.

O primeiro deles e manter as pessoas alinhadas com as atividades umas das outras: mesmo realizando stand-ups diarios, havia um certo desconforto, pois nao estavamos sendo capazes de comunicar bem a evoluçao das atividades que cada um estava realizando, especialmente entre as equipes em diferentes localidades. Ao dispendermos mais esforços no pareamento remoto (agradecimentos ao TeamViewer e ao Skype), este problema foi minimizado.

Outro problema, e que ha um certo desgaste em funçao de discussoes sobre arquitetura do sistema, abordagem a se seguir no desenvolvimento de uma estoria, entre outros. Estas discussoes acabam tomando tempo, e geram conflitos desnecessarios. Em uma certa estoria, apos uma serie de discussoes com um dos desenvolvedores sobre como implementar a estoria (que a principio eu desenvolveria com um terceiro), decidimos parear, e acabamos chegando a um consenso muito rapido sobre a implementaçao, tornando toda a discussao anterior inocua.

Em funçao desta experiencia pessoal, adiciono mais dois pontos a lista anterior de utilidades do pareamento:

* melhorar o alinhamento entre os membros da equipe quanto ao progresso das atividades * diminuir as discussoes “teoricas” sobre arquitetura e abordagens de implementaçao

Continuo nao acreditando que parear 100% e vantajoso. Mas quem sabe, se no futuro eu acabar participando de um projeto com pareamento em tempo integral, e possivel que eu enxergue vantagens que eu nao consigo enxergar hoje.

EC2, e máquinas virtuais na nuvem de modo geral, são extremamente convenientes. Uma pergunta que eu sempre me fazia, no entanto, era: e se por algum motivo eu perder o acesso SSH a uma instância? Afinal, não tenho acesso físico a essas máquinas, e no caso da Amazon, não tenho este tipo de suporte.

Bem, alguns dias atrás isto aconteceu e eu descobri finalmente o que acontece, e como se recuperar disto, sem arrancar os cabelos. Acho que é útil compartilhar com vocês.

Após atualização de alguns pacotes, minha instância precisava de um reboot. Depois de executar o comando, via o console do EC2 tudo parecia normal, mas a instância não estava acessível via SSH. Alguns minutos de desespero depois, reparei que o syslogé acessível pelo painel. De lá pude ver que o problema no boot era devido a uma entrada errada no fstab. Isto me deu a primeira ferramenta para resolver o problema: diagnóstico.

Já sabia o que eu deveria arrumar, mas como? Bem, neste caso eu estava usando instâncias com EBS Storage. Para quem não sabe, isso significa que existe um drive virtual independente e desacoplado de sua instância. Existe a opção de root storage para qualquer tamanho maior que o micro, mas você perde quaisquer dos seus dados armazenados nativamente na instância (salvo se você fizer um snapshot prévio, acredito). Portanto, este ‘tutorial’ só vale para o caso da EBS, mas com um pouco de criatividade e algum cuidado se resolveria o outro cenário.

Prosseguindo: feito o diagnóstico, parei a instância problemática, desacoplei o volume EBS dela e o acoplei como armazenagem secundária de uma máquina de homologação. Se você não tem outra máquina, pode criar uma instância micro apenas para esta tarefa e depois matá-la, mas lembre-se de que o volume a ser diagnosticado deve ser o secundário.

Efetuei o acesso nesta máquina, montei o volume (seguem os passos) e efetuei a mudança no fstab.

sudo mkdir /mnt/secondary_drive

sudo mount /dev/xvdf /mnt/secondary_drive

sudo vi /mnt/secondary_drive/etc/fstab

sudo umount /dev/xvdf

O passo final: desacoplar o volume secundário, reacoplar na instância problemática como volume principal e a reiniciar. Se tudo der certo, o acesso SSH terá retornado. Você pode conferir se tudo está funcionando no syslog e eventualmente repetir os passos. Mas como é um pouco demorado, diagnostique bem antes de  realizar os testes montando e desmontando volumes.

A partir de hoje existe. Segue um trecho do anúncio no blog do Bitbucket:

You’ve been asking for it, we’ve even joked about it – now it’s here (for real): for the one year anniversary of Bitbucket joining Atlassian, we are happy to announce Git support.

All your source, all in one-place

Whether you are using Hg or Git, you can now keep all of your code in one place with your preferred DVCS format. If you have existing code you would like to migrate, you can easily import your Git, Mercurial or Subversion source code. We have added a new importer for GitHub to our existing site importers which include SourceForge, Google Code and Codeplex.

Além disso, eles anunciam 350 novidades e bugfixes.

Mas daí você me pergunta: “Porque usar o Bitbucket para armazenar meus repositórios Git em vez de usar o tradicional GitHub?”

Bom, se você está desenvolvendo projetos Open Source, provavelmente o GitHub seja uma opção mais apropriada, já que ele se tornou referência. Muitas empresas pedem que candidatos adicionem o seu endereço GitHub nos currículos. Já BitBucket eu nunca vi.

Em compensação, se você está desenvolvendo projetos fechados, aí o Bitbucket é vantajoso. Em todos os planos, o número de repositórios privados é ilimitados. Na conta gratuíta, a limitação fica por conta do número de usuários: 5 no máximo, o que é mais do que suficiente para 99% das startups (o SIGA é uma delas). Já para empresas maiores, por 80 dólares por mês você tem direito ao plano UNLIMITED: repositórios ilimitados e usuários ilimitados! No GitHub o maior plano custa 200 dólares mensais, e dá direito a no máximo 125 repositórios privados.

Então desista já. Não perca tempo (como eu perdi algumas várias horas)!

Não funciona!

Fazendo uma rápida pesquisa na internet, descobrimos que o Twitter implementou um Javascript que impede a página de login de ser exibida caso esteja dentro de um iFrame (pode tentar, o resultado final será uma página em branco). O motivo: questões de segurança.

Portanto, ou exiba a página na janela principal do seu navegador, ou use um popup.

E tenho dito.

Pessoas tem idéias de produtos ou soluções para problemas todos os dias. Muitas destas idéias são de fato interessante. Algumas pessoas possuem o conhecimento necessário para fazer com que esta idéia se torne realidade. Quase ninguém tem a persistência e a força de vontade necessárias para colocar a idéia no ar.

Dos vários aspectos que me impressionaram e agradaram na minha curta passagem pelo Apontador, um que me agradou muito foi a concentração de pessoas boas que tinham projetos pessoais interessantes e funcionando, com pinta de sistema profissional. Corroborou mais uma das minhas teorias sobre empresas PONTOCOM: atraem pessoas diferentes, que gostam de criar e resolver problemas.

Eu gostaria de citar dois destes projetos, que eu usei e que realmente me ajudaram.

O primeiro é o Cruzalinhas, desenvolvido pelo Chester. Parafraseando o site, o Cruzalinhas permite que uma pessoa “saiba quais linhas de ônibus, trem ou metrô passam perto de um lugar em São Paulo”. A interface não poderia ser mais intuitiva: clique em um ponto do mapa da cidade, e veja todas as linhas de ônibus e metrô que passam por perto. Clique em um segundo ponto, e veja todas as linhas que podem potencialmente levá-lo de um lugar para o outro.

O segundo é o Encontre Seu Pacote, criado pelo Thiago Ganzarolli, colega de UNICAMP. O sistema permite rastrear os pacotes enviados por SEDEX em um mapa, por RSS ou via Direct Message do Twitter. O screencast deles, plagiado abaixo, explica melhor o funcionamento.

Este post pretende ser o primeiro de um grande movimento de retomada da atividade blogueira. Sim, porque bastou o Editor Chefe se distanciar um pouco, que quase nenhum post foi publicado neste espaço já consagrado pela crítica internacional.

Tenho vários assuntos que merecem uma notinha por aqui, todos eles diretamente ligados às minhas atividades dos últimos meses. Então, antes de mais nada, quero fazer um resumo de alguns fatos importantes.

Fato 0:

Virei pai do Rafael!

Fato 1:

Em setembro do ano passado, comecei a trabalhar no Apontador! Este era um movimento que eu já estava ensaiando há algum tempo: ter uma experiência em uma empresa .COM. Eu tinha algumas ideias pré-concebidas de como seria trabalhar em lugar como esses, boa parte devido ao imaginário coletivo ligado a empresas como Google.

O meu “relacionamento” com o Apontador começou de uma forma peculiar: antes de eu trabalhar para eles, eles eram meus “clientes”. Ou melhor: eram (e ainda são) usuários assíduos do Job4Dev. Isso me permitiu ter um primeiro contato com a cultura e o ambiente da empresa. E claro, me permitiu ter um bom contato com o RH. Um belo dia, decidi enviar meu currículo. E não é que deu certo?

Entrei no projeto da API Apontador, que na época estava sendo lançada. Quando entrei, assumi a bucha de desenvolvimento 100%. A equipe era formada por apenas duas pessoas: eu e o P.O, o Chester. Foi muito bom poder desenvolver um produto aberto, para usuário final, que seria utilizado por milhares de programadores por este mundão de meu Deus. Questões como qualidade, agilidade no processo, simplicidade de uso e real utilidade estavam constantemente na pauta do dia a dia. Não que não estivessem nos meus projetos anteriores. Mas sabemos como aplicações corporativas as vezes colocam essas coisas óbvias em segundo plano.

Tudo muito bem, tudo muito bom. Estava feliz, curtindo o ambiente e as pessoas com quem trabalhava. Mas aí veio o…

Fato 2:

Se eu fosse daqueles profissionais ultra organizados e meticulosos, e tivesse um plano de carreira bem definido, com metas e deadlines, eu diria que depois da experiência em empresas .COM, a minha meta seguinte seria virar empreendedor por completo. Ou seja: viver e trabalhar full time no meu próprio projeto. Mas sempre tinha aquelas questões secundárias como renda, contas a pagar (que aumentaram consideravelmente após o fato 0) e outras responsabilidades mundanas.

Haviam candidatos a projeto fulltime: Job4Dev e SigaSeuTime tinham potencial. E eu realmente estava acreditando que o SigaSeuTime era o que tinha mais chances de dar certo. Afinal, já tínhamos receita, uma base de usuários crescente, alguns clientes recorrentes…

E aí, um milagre aconteceu: o milagre do networking.

Meus sócios, pessoas de sucesso e com vários contatos interessantes, conheciam um cara. E esse cara tinha o hábito de investir em projetos em conjunto com um outro cara. Ambos os caras já tem o seu nome no hall da internet brasileira. E não é que eles gostaram do SigaSeuTime?  Foram alguns meses de negociações, até que a boa notícia veio: habemus recursos para manter uma equipe pequena, que me inclui, desenvolvendo e respirando o produto. \0/

Estamos em plenos trâmites burocráticos, mas eu já tomei o primeiro passo: saí do Apontador e estou dedicado. Realmente espero que este seja o marco inicial de um novo tipo de carreira e estilo de vida. Projetos não faltam, e o horizonte do Siga é bem promissor.

É isso.

Em breve, mais notícias.