Utilizando o Vagrant – parte 2

Vagrant-2

Só relembrando que na primeira parte o Vagrant foi instalado e que duas boxes, CentOS 7 e Ubuntu 14.04, foram deixadas disponíveis no cache. Isto já  permite subir máquinas virtuais com estes dois sistemas operacionais de forma quase instantânea mas é claro que ambas são imagens padronizadas e contendo “apenas” o  necessário. Logo é hora de customizá-las e também aproveitar para conhecer um pouco mais do “Vagrantfile” no processo.

O que está acontecendo?

Também na primeira parte eu disse que o “Vagrantfile” é o principal componente da ferramenta, que cada arquivo corresponde a um projeto e que antes de remover uma box é prudente executar um “vagrant destroy” etc.

Tudo bem, legal mas como consigo ter certeza da situação atual do projeto se ele executa as máquinas virtuais em modo headless?

Dentro do diretório do projeto faça:

$ vagrant status
Current machine states:

default                   not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.

No caso a máquina virtual não está em execução, se estivesse o resultado seria:

$ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

O Vagrant é “suficientemente legal” ao te informar como fazer para executar ou mesmo parar (ou interromper) a máquina virtual. Mas acontece que se você tem dois ou três projetos fica fácil entrar em cada diretório para saber o estado deles mas como fazer quando se tem muitos projetos?

$ vagrant global-status
id       name    provider   state    directory
------------------------------------------------------------------
7e1fa3d  default virtualbox paused   /home/giovanni/.../MongoDB
5c14b7c  default virtualbox poweroff /home/giovanni/.../virtualbox
ec248c6  default virtualbox running  /home/giovanni/.../Trusty64
 
The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"

E como ele gosta de explicar as coisas fica-se sabendo que é possível usar o identificador (o “id”) de cada projeto para iniciar (“vagrant up”), pausar (“vagrant suspend”), tirar da pausa (“vagrant resume”), interromper (“vagrant halt”) ou mesmo destruir (“vagrant destroy”) as máquinas virtuais.

Algo mais prático de que se fazer do que entrar individualmente em cada diretório e verificar o estado do projeto.

Vagrantfile

O arquivo criado por padrão a partir do “vagrant init” tem cerca de 70 linhas mas quase todas consistem de comentários com exemplos do que se pode ser feito na customização da máquina virtual do projeto.

Se deixarmos somente a parte funcional do “Vagrantfile” teremos isto aqui:

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"
end

Excetuando as duas primeiras linhas que servem para que EMACS e VI possam, respectivamente, compreender a sintaxe dele o resto do arquivo contém o mínimo necessário para que o Vagrant funcione corretamente, ou seja, ele identifica a versão do arquivo de configuração — o “.configure(2)” — o nome da box a ser utilizada.

O “Vagrantfile” funciona de modo bem parecido ao “Dockerfile” do Docker com ambos contendo parâmetros que servem para configurar a máquina virtual/contêiner, redirecionamento de conexões de rede, diretórios a compartilhar e até mesmo trecho de código a executar. Porém, como o Vagrant possui muito mais recursos que o Docker,  ele acaba tendo uma estrutura um pouco mais complexa.

Customizando o Vagrantfile

A ideia é criar um “Vagrantfile” customizado para produzir algo “pretensamente real”, isto é, uma máquina virtual para se testar aplicações escritas com o framework Express. Tudo bem, eu sei bem que é um exemplo “simples” (talvez até bobo) mas ainda assim ajuda a demonstrar o uso da ferramenta e com um pouco de paciência pode ser adaptado para outras demandas.

A primeira coisa a fazer, claro, é criar um projeto:

$ mkdir -p ~/Vagrant/express
$ cd ~/Vagrant/express

Como não pretendo usar o “Vagrantfile” gerado automaticamente dispensei a execução do “vagrant init” e criei manualmente o arquivo:

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"
  config.vm.box_check_update = true 
  config.vm.provider "virtualbox" do |vb|
    vb.customize ["modifyvm", :id, "--memory", "1024"]
    vb.customize ["modifyvm", :id, "--cpus", "2"]
  end
  config.vm.provision "shell", path: "./vagrant_express_setup.sh"
  config.vm.network "forwarded_port", guest: 3000, host: 8000
end

A linha em laranja informa ao Vagrant que ele deverá verificar e notificar atualizações na box — o padrão é não fazê-lo.

Aliás vale a pena citar duas coisas, a primeira é que uma box atualizada não significa necessariamente a atualização do sistema operacional instalado dentro dela e que ele não irá baixar a nova versão automaticamente, ele apenas informará o fato, ficando a seu critério fazer a atualização com “vagrant box update”.

O bloco em azul fará efeito apenas no caso do provedor ser o VirtualBox e cuida de realizar alterações na máquina virtual. Dentro dele, em verde, está o ajuste do tamanho da memória para 1024 MiB e , em roxo, a definição da quantidade de processadores — exatamente, o vb.customize[ … ] executará o VBoxManage! 🙂

Em vermelho está a parte mais importante e que cuidará da instalação do Express e suas dependências.

Provision é um recurso do Vagrant para se acrescentar “coisas” às máquinas virtuais, é invocado sempre que a máquina virtual é criada — o primeiro “vagrant up”, opcionalmente durante um “vagrant reload” e a qualquer instante usando “vagrant provision”.

É possível utilizar ferramentas como Ansible, Chef ou Puppet mas optei por usar um shell script convencional mesmo:

Como o programa rodará com o usuário ‘root’ é preciso explicitar com su os trechos onde a execução deve ser feita com o usuário local, o ‘vagrant’, daí minhas “barbeiragens”… 🙂

Basicamente ele instalará via APT o Node.js e também o npm (e com este instalará o Express). Já que tanto a Debian quanto o Ubuntu chamam o interpretador da linguagem de “nodejs” e alguns programas o chamam simplesmente de “node” eu aproveito para criar um link simbólico e assim evitar possíveis problemas.

Caso não exista, ele criará o diretório da aplicação (mas não destruirá uma aplicação já existente), baixará as dependências do Express e criará um pequeno programa para executar o servidor.

Por último, em magenta, crio o redirecionamento da porta 8000/tcp da máquina local para a porta 3000/tcp na máquina virtual — que é a porta padrão do Express. Daí é usar “vagrant up”, aguardar o processo finalizar e então usar “vagrant ssh -c /vagrant/run” para rodar a aplicação:

Vagrant-2_vagrant_ssh

Então acessá-la com seu navegador web predileto:

Vagrant-2_Express

Para interromper a execução da aplicação basta usar «Control»+«C». Só lembrando que neste caso será a aplicação escrita em Express que será interrompida e não a execução da máquina virtual, para esta basta usar “vagrant halt” ou mesmo um “vagrant destroy”.

Fechando a segunda parte

O interessante nesta abordagem é que usando somente dois arquivos (“Vagrantfile” e “vagrant_express_setup.sh”), que podem ser enviados tranquilamente por e-mail, é possível criar em qualquer lugar e a qualquer momento máquinas virtuais absolutamente idênticas — esta é a tal da idempotência em ação! 😀

Na próxima parte será a vez de fazer o mesmo, ou algo bem parecido, com o CentOS e também usar alguns outros recursos do Vagrant.

Anúncios

2 comentários sobre “Utilizando o Vagrant – parte 2

  1. Pingback: Utilizando o Vagrant, 2ª parte - Peguei do

  2. Pingback: Vagrant – parte 3 | giovannireisnunes

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s