Note que o Vagrantfile vai buscar a variável de ambiente VAGRANT_SYNCED_FOLDER, não esqueça de colocar no seu .zshrc ou .bashrc apontando para o diretório onde você costuma clonar seus projetos. Ele será montado, via NFS, dentro do box Vagrant no diretório /vagrant.
Pronto, isso deve ser suficiente. Ao final você terá um ambiente de desenvolvimento com os seguintes componentes principais:
- RVM (receita 'user_install', onde você mesmo deve instalar os rubies que precisar manualmente)
- Oh-My-Zsh (isso não seria necessário, mas ZSH é tão bom que é melhor já ter pré-instalado)
- MySQL
- Postgresql
- MongoDB
- Redis 2
- Elasticsearch
- Node.js, Java 1.7, Git, Imagemagick
Acesse seu novo box com vagrant ssh, instale seu primeiro Ruby com rvm install ruby-2.1.2 e pronto!
Alguns Conceitos de Vagrant e Chef
Meu projetinho vagrant-railsbox por si só é estruturado como uma receita Chef. Ele tem um metadata.rb que funciona mais ou menos como uma "gemspec", se fosse uma Rubygem.
Para gerenciar as dependências, uso o Berkshelf, que funciona como se fosse um Bundler. Ao rodar berks install ele vai usar o arquivo Berksfile.lock (novamente, similar ao "Gemfile.lock" dos seus projetos Ruby). O arquivo Berksfile tem as definições de versão ou fonte, e no caso desta receita, puxa as dependências do metadata.rb. Leia mais sobre como usar Berkshelf com Vagrant neste post.
O arquivo Vagrantfile tem as configurações da receita. Na teoria eu deveria colocar as configurações que você encontra no bloco config.vm.provision :chef_solo no diretório attributes, que toda receita Chef tem, mas neste caso, como é muito específico ao Vagrant, deixei lá mesmo.
Note que estou usando um IP interno fixo com config.vm.network :private_network, ip: "192.168.50.4" em vez de usar a configuração com DHCP que seria , type: 'dhcp', porque acho que no VMWare Fusion (que eu uso) estava dando problema. Tente usar DHCP e veja se no seu caso funciona, senão mantenha fixo.
Como é máquina de desenvolvimento, a senha do usuário 'root' do MySQL é simplesmente 'root'. E a senha do usuário 'postgres' é simplesmente 'postgres', além de estar tudo como 'trust' no arquivo pg_hba.conf. Obviamente, estas configurações não devem ser mantidas assim se for subir em produção. Redis, Mongo e Elasticsearch, está tudo na configuração padrão e tudo sem proteção.
Para quem nunca usou Chef, o conceito é simples:
- procure por receitas no Chef Supermarket
- adicione no seu metadata.rb como depends 'git'
- adicione no seu recipes/default.rb como include_recipe 'git' ou o que a documentação da receita mandar
- configure o node['git'] no attributes/default.rb (ou, neste exemplo, no Vagrantfile), conforme a documentação
A receita é onde fica os comandos para instalar e configurar o que você precisa. Atributos são os valores customizáveis que variam de instalação para instalação. No diretório files costuma ficar templates ERB para arquivos de configuração, do tipo que você editaria em /etc. Em libraries ficam classes Ruby que organizam lógicas mais complexas que você quer estruturar para reusar.
Resources e Providers são conceitos mais complicados de explicar, e como a idéia deste post não é detalhar Chef, vamos apenas resumir dizendo que resources definem o estado de um sistema. Por exemplo, num cookbook de NGINX teríamos o pacote de instalação, o serviço e o arquivo de configuração. Providers são as ações que levam o sistema ao estado definido, como instalar o pacote propriamente dito, editar o arquivo de configuração e configurar o serviço. Se quiser saber mais sobre o assunto, leia este post e este outro.
A grande vantagem é você poder modificar este cookbook e incrementalmente instalar coisas novas no seu box com o comando vagrant provision. E também poder simplesmente recomeçar do zero, destruindo seu box com vagrant destroy e reiniciando com vagrant up --provision e chegar na mesma configuração final. É sempre bom pode começar do zero sem dores de cabeça.
Sobre montar seu próprio cookbook, a parte mais complicada é buscar os cookbooks que já existem, entender como eles funcionam, e isso requer ler as receitas, ler a documentação, entender dependências como ver que o oh-my-zsh depende o data_bag do cookbook 'user', por exemplo. Antes de sair montando tudo do zero, procure no supermarket e, obviamente, no Google, para buscar direto no Github.
Alguém tem mais dicas para melhorar este cookbook? Não deixe de comentar aqui ou mesmo mandar um Pull Request pra mim!