Primeiras aulas do curso Vagrant e Puppet: Criação e provisionamento de maquinas virtuais

Vagrant e Puppet: Criação e provisionamento de maquinas virtuais

Do hardware ao servidor web - Do hardware ao servidor web

Olá, meu nome é Guilherme!

Juntos, discutiremos sobre um sistema Java e como podemos inseri-lo em um ambiente de produção, de homologação, desenvolvimento e como replica-lo de diversas maneiras. Aprenderemos como criar o passo a passo de operações, colocar um sistema em produção, monitorá-lo e, por fim, automatizá-lo.

Agilidade é uma questão importante nos projetos atuais. Queremos adicionar mudanças em softwares o tempo inteiro e realizar diversos deployies. É claro, quanto mais deployies fazemos, maior o risco de erros. Então, temos de conseguir fazer análises temporais e replicar conteúdos.

Em um primeiro momento, achamos simples criar uma máquina nova: instalar o Linux, usar o apt-get e instalar o software de que você precisa. Depois, basta editar alguns arquivos de configuração utilizando VI. Por fim, fazemos uma cópia de alguns arquivos locais para um arquivo remoto com SCP. Essa é uma ideia bastante difundida.

Mas na prática há algumas complexidades: temos de conhecer exatamente o servidor do banco de dados usado, quais as configurações dele, a versão do Java, configurações no servidor de aplicação, do Servlet Conteiner. Precisamos saber, ainda, quais são os diretórios de uma máquina que são importantes para, por exemplo, se precisarmos realizar backups ao deletarmos uma máquina e criarmos outra. Quais são os usuários que eu tenho que criar? Quais são as portas que devo fechar e as portas que devo deixar abertas? Quais são os usuários, as senhas e as chaves que devo manter? Quais são os serviços que têm que rodar na minha máquina? Tudo isso deve estar contido no backup.

Todo o processo está sujeito a falhas, principalmente se é um ser humano que está o executando. O Mais importante é toda a vez que executarmos um deploy, ele se dê sem falhas e sempre da mesma forma, isto é, automatizado. Não devemos precisar de força humana para resolver problemas de provisioning.

Precisamos conseguir recriar uma máquina com agilidade caso aconteça algum problema que demande a destruição de uma máquina anterior, ou mesmo realizar atualizações de software com agilidade. Sabendo lidar com problemas de forma prática e rápida, conseguimos aproveitar projetos de um cliente para usar o mesmo modelo com clientes diferentes. Não podemos correr riscos ou perder tempo.

Neste curso, criaremos uma máquina nova para o desenvolvedor u para homologação e até mesmo criar uma máquina para produção no cloud. Instalaremos o Java, um servidor web, um banco de dados e configurar todos eles. Todo esse processo se dará de uma maneira automatizada, e não importa quantas vezes ele se repita, sempre teremos um mesmo modelo de máquina. Poderemos duplicar e recriar máquinas tranquilamente, esse é o processo de Devops.

O projeto em que trabalharemos é o Music Jungle.

Para criarmos uma máquia de produção ou homologação,precisamos primeiramente de um hardware. Para ter um hardware configurado, se eu for fazer uma máquina virtual dentro da minha máquina, eu posso usar diversos softwares. Por exemplo, o VirtualBox que permite que criemos máquinas virtuais dentro do meu sistema operacional. No futuro, usaremos uma máquina virtual em nossa própria máquina, que será executada na Amazon.

Com o hardware configurado, precisamos de um sistema operacional e neste projeto usaremos o Ubuntu. Legal, vou usar o Ubuntu. Eu quero instalar o Java, e o Tomcat, um servidor web dentro dessa máquina. Eu quero também ter um ip pra essa máquina, pra poder acessá-la via web. Tudo isso a gente vai conseguir fazer daqui a pouquinho.

Para criarmos nossa máquina virtual, usaremos Vagrant, que é capaz de criar e gerenciar essas máquinas virtuais através do VirtualBox, por exemplo.

O Vagrant será configurado na sua versão 2, e especificares que a que a imagem da máquina é Ubuntu, que por sua vez é chamado de hashicorp/precise32, de 32 bits.

Vagrant.configure("2") do |config|
    config.vm.box = "hashicorp/precise32"
end

Existem diversas imagens que podemos baixar na internet, mas podemos até mesmo criar nossa própria imagem padrão, em um sistema operacional já instalado e configurado. Ainda não baixamos essa imagem do sistema operacional, mas o Vagrant cuidará disso para nós.

Quando utilizamos config.vm.box = "hashicorp/precise32", signifca que todas as minhas máquinas virtuais dentro desse arquivo de configuração utilizarão o Ubuntu 32 bits. Criaremos uma máquina chamada web:

Vagrant.configure("2") do |config|
    config.vm.box = "hashicorp/precise32"

    config.vm.define :web do |web_config|
    end
end

Não realizamos nenhuma configuração, apenas definimo uma única nova máquina. Como é que eu executo esse Vagrant file no terminal? – isto é, eu criei um arquivo chamado Vagrant file, configurei o Vagrant para usar o Ubuntu 32, criar uma máquina virtual com o VirtualBox, que é o padrão dele – e então acionamos um vagrant up na linha de comando.

O vagrant up vai criar a máquina virtual, instalar o Ubuntu e baixar aquela imagem correspondente. Com o Ubuntu instalado, podemos fazer um SSH: vagrant ssh, então conseguimos nos conectar com máquina. O Vagrant está sendo executado, e se acionar os comandos ls, whoami, algo do gênero, perceberemos a lógica Ubuntu. O usuário padrão do vagrant ssh e é vagrant.

A próxima etapa é instalar o Tomcat. No ssh, escreveremos sudo apt-get update pra atualizar todos os pacotes do Ubuntu. Assim feito, escreveremos sudo apt-get install openjdk-7-jre tomcat7. Estou instalando tanto o jdk quanto o Tomcat, através de apt-get. Ao executarmos, notaremos que o Tomcat já está instalado, presente em /etc/init-d. Por meio do comando ps -ef | grep java, eu vejo que o Tomcat está rodando com o Java 7.

Contudo, precisamos de um ip, caso contrário não conseguiremos realizar testes, pediremos um ip Vagrant, solicitando uma configuração de rede. A rede será fechada (private_network). Para nossa máquina web teremos um ip fixo, que será: 192.168.50.10.

Vagrant.configure("2") do |config|
    config.vm.box = "hashicorp/precise32"
    config.vm.define :web do |web_config|
        web_config.vm.network "private_network", ip: "192.168.50.10"
    end
end

Estamos em uma rede com a nossa máquina e ela pode ser acessada. Contudo, a máquina já estava rodando e todo o hardware dela já foi inicializado, e não havia esse ip anteriormente. Então eu preciso reiniciar a máquina para que o VirtualBox possa configurar, com o auxílio do Vagrant, o ip dessa máquina. Para tanto, usaremos o comando vagrant reload.

O vagrant reload para a máquina e a reinicia já com as configurações que solicitamos. Em seguida, o Tomcat é inicializado, porque o pacote tomcat7 é automático. Dessa forma, poderemos acessar no navegador http://192.168.50.10:8080.

Mas todas as vezes que criarmos uma nova máquina, devemos fazer o processo sudo apt-get novamente? Temos que decorar tudo isso? Não podemos depender da memória humana para realizar uma configuração básica da máquina, isso deve ser executado automaticamente e não utilizar sempre a linha de comando.

O primeiro passo agora é automatizar o apt-get update e apt-get install openjdk-7-jre tomcat7.

Para isso, não é o Vagrant que vai nos ajudar. Quem vai configurar e provisionar o software necessário é o Puppet. Depois de destruir a minha máquina, usaremos o comando vagrant destroy e aí eu destruo completamente a minha máquina – acabou, a máquina virtual não existe mais no VirtualBox.

Criaremos um arquivo chamado web.pp. Esse arquivo web.pp vai dentro de um diretório chamado manifests. Lá dentro eu crio esse arquivo web.pp. Por que web.pp? “pp” de Puppet, “web” para ficar o mesmo nome da nossa máquina, pra gente saber que o web.pp é da máquina web.

Agoar, queremos executar o comandoapt-get update:

exec { "apt-update":
    command => "/usr/bin/apt-get update"
}

Daremos um nome para esse exec, será apt-update. Esse arquivo web.pp, quando ele for executado pelo Puppet, irá acionar o comando apt-get update para nós. Como executamos o Puppet? Devemos estar como root. Portanto: sudo puppet apply /vagrant/manifests/web.pp. Mas esse arquivo web.pp, eu criei na minha máquina, no meu host.

Onde temos vagrant file criaremos um diretório chamado manifests e, dentro desse diretório, web.pp. Como a nossa máquina virtua,l que está no vagrant ssh, acessa esse arquivo?

O Vagrant cria uma shared folderm um arquivo compartilhado entre a sua máquina, que é o host, e a máquina virtual. Esse diretório que está compartilhado é o diretório em que está o seu vagrant file. Então, se eu quero acessar o arquivo que está em manifests/web.pp, declaramos /vagrant/manifests/web.pp, por isso sudo puppet apply /vagrant/manifests/web.pp.

Quando acionamos o apply, eu vejo lá “Opa, qual que foi a mensagem que você deu aqui?” Você executou com sucesso o quê? O apt update. Repara que ele referencia para gente um nome: exec apt-update, e não o comando em si.

Já que eu salvei esse arquivo, os meus desenvolvedores, sempre que eles quiserem criar máquinas novas, basta que executem sudo apply que a máquina vai estar configurada, certo? Ainda não, falta instalar o openjdk e o Tomcat. Vamos instalá-los? Então, eu vou falar pro Puppet a instalação do package openjdk-7-jre etomcat7. Não só isso: gostaríamos também de ter certeza de que eles estão instalados: ensure => installed.

Antes de instalar os pacotes, queremos que o comando o comando Exec["apt-update"] tenha sido executado:

exec { "apt-update":
    command => "/usr/bin/apt-get update"
}
package { ["openjdk-7-jre", "tomcat7"]:
    ensure => installed,
    require => Exec["apt-update"]
}

Temos essas duas tarefas: a primeira:exec { "apt-update", e a segunda:package { ["openjdk-7-jre", "tomcat7"]. Para executar o arquivo escreveremos: sudo puppet apply /vagrant/manifests/web.pp.

Está tudo instalado. Toda vez que quisermos uma máquina nova, basta eu dar sudo puppet apply /vagrant/manifests/web.pp, e assim ela é criada e todo o software é instalado para nós, mas como podemos ter certeza disso?

No navegador acessaremos http://192.168.50.10:8080 e assim verificamos que o Tomcat está rodando. Mais adiante no curso, aprenderemos a instalar o banco de dados, como configurar sua aplicação e assim por diante.

Deployando uma aplicação web - Deployando uma aplicação web

Aprendemos a criar uma máquina do zero, colocar nela o Ubuntu, fazer o SSH e instala-la por meio deapt-get update, além dos pacotes de Java e Tomcat. Demos um IP para nossa máquina e acessamos o Tomcat via navegador, ele esta disponível na porta 8080, padrão do Tomcat. Conseguimos, ainda, instalar o Puppet para que, toda vez que eu o execute, ele faça o apt-get update e o install dos dois pacotes.

O próximo passo é pegar minha aplicação web e instalá-la no servidor. Em nosso máquina, as plicações são Java e possuem um arquivo formato .war, e esse arquivo será enviado para dentro do diretório webapps do meu Tomcat.

Temos uma aplicação baixada da internet de um projeto padrão do Vraptor chamado musicjungle. O arquivo .war deve ser copiado para o diretório onde temos os manifests. Dentro desse diretório, colocaremos o meu arquivo .war, o vraptor-musicjungle.war.

Agora que temos esse arquivo .war dentro do projeto, o que faremos é enviá-lo para o diretório do Tomcat. Para isso, precisaremos restartar o serviço, armazenado em /etc/init.d, onde ficam os serviços do Linux tradicionalmente.

Temos um serviço do Tomcat 7 chamado tomcat7 dentro do diretório, comunicaremos essa informação ao Puppet. Se tiver algum problema com o tomcat7, não adianta copiamos o arquivo .war pra dentro do diretório do Tomcat, pois não teremos execução de qualquer maneira.

Nós definimos anteriormente que o pacote Tomcat 7 deve estar instalado. Agora estamos dizendo que existe um serviço chamado tomcat7, e esse serviço tem que estar rodando, caso não esteja, o Puppet não continuará a execução:

service { "tomcat7":
    ensure => running,
    enable => true,
    hasstatus => true,
    hasrestart => true, 
    require => Package["tomcat7"]
}

O serviço tomcat7 deve estar ativo e sendo executado, portanto enable => true. Também podemos saber o status do service via hasstatus. E o hasrestart, disponibiliza a opção de "restart" ou "stop" para o serviço. Por padrão, os serviços que a gente tem para Linux possuem esses recursos.

O Puppet verificará se o serviço está sendo executado, e caso não, irá reiniciá-lo. Para o serviço tomcat7 estar rodando, primeiro temos de requerir (require) o pacote tomcat7.

Uma vez que o Puppet confirmou que serviço está operando normalmente, iremos copiar o arquivo .war. Para copiarmos esse arquivo, teremos de ir até o source isto é, o arquivo /vagrant/manifests/vraptor-musicjungle.war, e copiar para dentro do diretório webapps do Tomcat. Copiaremos o arquivo para /var/lib/tomcat7/webapps/vraptor-musicjungle.war.

file { "/var/lib/tomcat7/webapps/vraptor-musicjungle.war":
    source => "/vagrant/manifests/vraptor-musicjungle.war",
    owner => tomcat7,
    group => tomcat7,
    mode => 0644,
    require => Package["tomcat7"],
    notify => Service["tomcat7"]
}

Quando copiamos um arquivo no Linux, eu tenho que saber quem é o "dono" desse arquivo. Eu não queremos que o dono desse arquivo seja root, afinal o Puppet está sendo executado como root. Queremos executá-lo como usuário tomcat7.

Já existe um usuário tomcat7 na máquina, porque o pacote do Tomcat já fez tudo isso para gente. Então, simplesmente declaramos que o grupo e o usuário é o tomcat7. O modo de acesso a esse arquivo é 0644, de escrita,leitura, execução e assim por diante.

Depois de copiar esse arquivo, o Tomcat 7 deve ser reiniciado. É opcional – no caso do Tomcat, ele percebe que o arquivo war está lá – mas, para aprendermos como restartar o serviço, veremos passo a passo do procedimento.

Depois que o arquivo .war for instalado, solicitaremos que uma notificação para o serviço do Tomcat e, assim, ele ser reiniciado.

notify => Service["tomcat7"]

Estamos avisando para o Pupet que:

Quando ativamos o apply nesse script (sudo puppet apply /vagrant/manifests/web.pp) podemos conferir que de fato o arquivo foi copiado de um diretório para outro, e o Tomcat foi reiniciado.

Como o arquivo foi copiado para dentro do Tomcat, ele já deve estar disponível na web.No navegador, acessaremos http://192.168.50.10:8080/vraptor-musicjungle. O MusciJunlge estará sendo executado.

Agora, todas as vezes que acionarmos vagrant destroy ou vagrant up, executaremos o apply e teremos a máquina configurada com o Tomcat e com a nossa aplicação web.

Resumindo: na linha de comando, copiamos o arquivo .war para o projeto, definimos o serviço, copiamos o arquivo de um diretório para dentro do nosso webapps. Por fim, Definimos o grupo do usuário e reiniciaremos o serviço.

exec { "apt-update":
    command => "/usr/bin/apt-get update"
}

package { [openjdk-7-j re", "tomcat7"]:
    ensure => installed,
    require => Exec["apt-update"]
}

service {"tomcat7":
    ensure => running,
    enable => true,
    hasstatus => true,
    hasrestart => true,
    require => Package["tomcat7"]
}

file {"/var/lib/tomcat7/webapps/vraptor-musicjungle.war":
    source => "/vagrant/manifests/vraptor-musicjungle.wae",
    owner => tomcat7,
    group => tomcat7
    mode => 0644,
    require => Package["tomcat7"],
    notify => Service["tomcat7"]
}

Agora faremos um SSH pra máquina e apply do nosso Puppet. Assim, conseguimos acessar o Music Jungle no navegador. Conseguimos nos cadastrar já que está sendo usado um banco de dados padrão em memória.

Até este ponto, vimos dois passos importantes: como criar máquinas virtuais e configurar o hardware. Depois, instalar o software mínimo como o sistema operacional da máquina virtual usando sempre o vagrant.

O vagrant, junto com virtual box, cria a máquina virtual.Depois, usamos o Puppet pra instalar o software. Assim como o Puppet, existem diversos outras tecnologias que servem pra instalar os softwares que a gente precisa configurar e gerenciar a configuração desse nosso ambiente. Se quisermos, acionamos o vagrant reload para reiniciar a máquina, do mesmo modo podemos utilizar vegrant destroy para elimininá-la.

Se reiniciarmos a máquina, não conseguiremos nos logar com o mesmo usuário. Como foi dito, o Musuc Jungle utiliza por padrão um banco de dados em memória, e quando reiniciamos a máquina esses dados são perdidos.

Para desenvolvimento, banco de dados em memória funciona perfeitamente pela agilidade, mas em produção não é uma boa ideia. O ideal nesse caso é utilizarmos o MySQL, mas continuarmos usando o banco de memória quando estamos no processo de desenvolvimento, dessa forma temos dois tipos de ambientes que precisam ser configurados.

Provisionando um MySQL - Provisionando um MySQL

Temos uma máquina virtual que é executada no Ubuntu, instala o Java, instala o Tomcat, configura o Tomcat com a minha aplicação web. Coloco um ip na minha máquina e eu consigo acessar o navegador. Inclusive tem um banco de dados rolando em memória.

Em memória? Não era em memória que gostaríamos que isso ocorresse, certo? Pelo menos no meu ambiente de produção isso não é interessante, neste caso gostaríamos de utilizar o MySQL.

O primeiro passo é a gente instalar o MySQL e configurá-lo, certo? Então vamos fazer isso. Na nossa configuração, a gente vai criar um banco de dados pro nosso Music Jungle. Primeiro passo, criar o banco: instalar o banco, e criar o banco. Vamos lá?

Como é que eu crio o banco MySQL? Num ambiente Linux, é bem comum, no Ubuntu, que eu faça um apt-get: apt-get install mysql-server. E com isso ele instala o mysql-server pra mim.

Legal, o apt-get instalou o mysql-server? Instalou. Agora eu preciso criar o meu banco. Pra eu criar o meu banco, eu vou com o mysqladmin, passo o meu usuário, que é root, e dou um create + nome de banco de dados, musicjungle. Com isso, eu tenho um espaço onde eu posso criar minhas tabelas e tudo mais o que eu precisar. Então:

mysqladmin -uroot create musicjungle;

Com isso eu crio o meu banco de dados. São dois passos, aptget install do mysql-server e mysqladmin -uroot create musicjungle. Eu executo esses dois passos e ele instala o MySQL pra mim, cria o banco de dados e eu posso até testar. Eu dou um:

mysql -uroot musicjungle

Conseguimos acessar o banco de dados do Music Jungle.

Contudo, estamos aqui para automatizar o processo de criação das máquina e configuração dos ambientes. Não devemos fazer execuções manualmente, pois elas são mais frágeis e sujeita a erros, uma vez que o projeto pode passar por vários desenvolvedores.

Acessaremos o Puppet para realizar as configurações. Primeira coisa, lá onde a gente falava que a gente queria ter o package do openjdk e o package do tomcat instalado, manda instalar o mysql-server! Eu quero ter os 3 pacotes instalados. Manda instalar, ele que se vire, certo? Ele se vira.

Se eu tenho o package do mysql-server instalado, assim como no caso do Tomcat, o MySQL é aquele caso em que a gente está interessado em ter certeza de que ele está rodando. Eu preciso que ele esteja rodando. Então, o que é que eu vou definir? Um service.

O service, a gente já conhece. O service vai ter o nome de mysql. Ele depende, lá no final (require) do mysql-server, isso é, se ele nem conseguiu instalar o mysql-server, nem adianta tentar ver se o serviço está lá. O que mais? Quero ter certeza de que ele esteja rodando. Está rodando? Não está rodando? Está rodando ou não está rodando? Se não está rodando, nem continua, porque eu não instalei uma parte do meu serviço. O que mais, enable => true pra ter certeza de deixar ativo o serviço, hasstatus e hasrestart. Todos eles têm isso, o MySQL e o Tomcat, então eu não preciso me preocupar.


package { ["openjdk-7-jre", "tomcat7", "mysql-server"]:
    ensure => installed,
    require => Exec["apt-update"]
}

service { "mysql":
    ensure => running,
    enable => true,
    hasstatus => true,
    hasrestart => true,
    require => Package["mysql-server"]
}

Agora que eu tenho o MySQL rodando, isto é, se eu der um require no service mysql, eu tenho certeza de que ele está rodando. Agora o que eu quero fazer mesmo?

Criar o banco? Como é que eu crio o banco? mysqladmin etc. etc. Eu vou executar alguma coisa no bash, certo? Se eu vou executar – a gente já até viu, o primeiro de todos os comandos, exec. Eu quero executar um comando. Eu tenho que defini-lo.

exec, vou chamar isso de musicjungle (podia chamar de musicjungledatabase, createdatabase, o que a gente achar que faz sentido), lembre-se, é o nome da minha tarefa, esse é o nome do exec. O nome é musicjungle. Qual é o comando que eu vou executar mesmo? Lembra: o path inteiro, mysqladmin -uroot create musicjungle.

Mas o path inteiro, Guilherme, não está no diretório /usr/bin? Está no /usr/bin! Então, eu podia escrever /usr/bin/mysqladmin, ou eu posso separar no próximo atributo. path => “/usr/bin”.

E separando nesse próximo atributo, no path, quer dizer que esse comando vai ser executado dentro desse diretório. São duas maneiras, cada uma tem uma pequena diferença. Ou está executando dentro desse diretório, ou em outro diretório.


exec { "musicjungle":
    command => "mysqladmin -uroot create musicjungle",
    path => "/usr/bin",
    require => Service["mysql"]
}

Então, eu estou executando o mysqladmin -uroot create musicjungle depois de ter certeza de que o serviço está rodando perfeitamente. A gente está dando apt-get install, a gente está garantindo que o serviço está rodando, e a gente está rodando o mysqladmin pra criar o banco.

Lembra que eu já tinha dado, na minha máquina, o apt-get install? O que acontece se eu dou apt-get install duas vezes no mesmo pacote? Não faz nada! Já está instalado, não tem diferença. Mas o que acontece se eu crio o mesmo banco duas vezes? O que acontece se eu mandar o mysqladmin criar o mesmo banco duas vezes?

Se eu executo esse script agora, teremos um pequeno problema: o install do apt-get install ele nem tenta, porque já está instalado o MySQL. Não tenta instalar de novo. Mas ele fala o seguinte: criar o banco de dados deu erro. Por quê? Porque o MySQL reclama se o banco de dados já existe.

Eu gostaria de executar essa tarefa, executar a tarefa musicjungle (que é equivalente a mysqladmin -uroot create musicjungle) a não ser que o banco exista.

Como é que eu descubro se esse banco de dados já existe, mesmo? Se o banco de dados já existe é porque eu consigo me conectar a ele. Como é que eu me conecto? mysql -uroot musicjungle. Se esse comando for um sucesso, é porque o banco de dados já existe. Então, se esse comando for um sucesso, não cria de novo, não! Não tenta criar, não seja louco!

O que eu faço com esse nosso exec? Eu falo:


exec { "musicjungle":
    command => "mysqladmin -uroot create musicjungle",
    unless => "mysql -u root musicjungle",
    path => "/usr/bin",
    require => Service["mysql"]
}

O unless faz com que eu possa executar esse script diversas vezes e o resultado seja o mesmo. Se o banco já existe, deixa o banco lá. Se o banco não existe, ele cria. Não é que o resultado é bem o mesmo, mas eu posso executar esse script diversas vezes, sem ter um efeito colateral indesejado. Isso é o que a gente chama quando o script é idempotente. Eu posso executá-lo diversas vezes e eu vou ter o resultado que eu estou esperando ali no final, que é o banco de dados estar criado, não vai dar pau em nenhuma delas.

Agora, se eu executar o puppet apply, joinha. Ele nem chega a executar o create, porque ele tentou conectar com o banco, e o banco já existia. É claro, se o banco não existisse, e o MySQL não estivesse instalado, ele ia ter que fazer tudo isso.

Aí é um ponto interessante: não seja mão de vaca. A gente não precisa mais ser mão de vaca agora. Por que não? Porque, antes, pra você criar uma máquina de produção, ou uma máquina de aceitação, seja lá qual for a máquina que você queria criar, você tinha que executar um monte de comando na mão. Era trabalhoso. Agora não é mais. Você quer criar uma máquina igual a uma máquina de produção, uma máquina igual a uma máquina de homologação, é só você dar o vagrant up e você tem a sua virtual machine.

Agora você dá um sudo puppet apply e você já tem tudo instalado. Não é mais caro criar uma máquina virtual com um ambiente igual ao de produção. E depois a gente vai ver como jogar isso no cloud, claro, como jogar isso em outros lugares.

Não é mais caro criar essa máquina que nem a produção ou homologação. Então, não seja mão de vaca. O que você faz? Você faz um vagrant destroy, destrói tudo, e dá um vagrant up. E depois do vagrant up, dá um puppet apply. Aplica o seu script do Puppet, e você tem uma máquina igualzinha à outra. Não seja mais mão de vaca, você está com um problema, você testou umas coisas num ambiente igual ao de produção, aqui local, e viu que era isso que você queria ou não era isso que você queria, não tenha dó: destrua! vagrant destroy e vagrant up. Não tenha dó! Não seja mão de vaca. Quando você der um vagrant up e você der um puppet apply, o seu MySQL vai estar lá rodando, o seu Tomcat vai estar lá rodando.

De novo, não seja mão de vaca se você precisar de novo. Não seja mão de vaca, não economize vagrants destroys e vagrants ups. Porque a qualquer hora você tem um ambiente igual ao que você tinha antes. Esse é o poder do vagrant com o Puppet. Dei o destroy, dei o up, dei o apply do Puppet, e agora eu tenho uma máquina igualzinha a antes. Igualzinha à que eu tinha cinco minutos atrás.

Então, tãn dãn , o que eu faço? Acesso lá o Music Jungle, e eu tenho o meu serviço. Acesso-o, cadastro meu usuário e fico feliz e contente. Hum... Fico quase feliz e contente. Por quê? Porque quando eu chegar lá no meu MySQL, eu não estou ainda adicionando nada no meu MySQL. O MySQL até está lá, mas não tem nada na minha tabela do banco. Porque eu instalei o MySQL, é verdade, e eu vi o poder do vagrant up, do vagrant destroy e do puppet apply. Eu consigo criar a mesma máquina com todo o ambiente de configuração quantas vezes eu quiser. Mas eu ainda não falei pra minha aplicação web que é pra ela usar o MySQL.

De alguma maneira, eu tenho que fazer com que a minha aplicação web seja capaz de entender quando ela está em um ambiente de desenvolvimento, quando ela está em um ambiente de produção. E é isso que a gente vai fazer daqui a pouco.

Fazendo o código, o que é que a gente faz? Definir o pacote, criou o serviço do MySQL e falou:

Então eu vou lá e coloco um unless. Aí eu executo o puppet apply e ele funciona! Eu fico feliz e contente! Não sou mão de vaca! Não sou mão de vaca com vocês! vagrant destroy, vagrant up! Faço um ssh na minha máquina depois do vagrant up e dou um sudo puppet apply.

Quando eu dou um sudo puppet apply, ele instala tudo, tudo, tudo. Inclusive o banco. E aí eu posso dar um mysql -uroot e conecto no banco musicjungle. Ele está lá. Vou ao navegador, o navegador está lá. Consigo até me cadastrar. Só que, lembra, ele ainda não está usando o MySQL. Eu aprendi a adicionar novos pacotes, aprendi a executar qualquer tarefa, inclusive o unless, e aprendi o poder do vagrant destroy, do vagrant up e do puppet apply. Eu crio o mesmo ambiente quantas vezes eu quiser.

Agora... Como é que eu falo pra minha aplicação web que ela está num ambiente de desenvolvimento ou de produção? Como é que eu crio ambientes diferentes de configuração? Como é que eu crio configurações de ambientes diferentes? É o que a gente vai ver daqui a pouco. Primeiro, vamos lá pros exercícios!

Sobre o curso Vagrant e Puppet: Criação e provisionamento de maquinas virtuais

O curso Vagrant e Puppet: Criação e provisionamento de maquinas virtuais possui 72 minutos de vídeos, em um total de 56 atividades. Gostou? Conheça nossos outros cursos de Infraestrutura como Código em Infraestrutura, ou leia nossos artigos de Infraestrutura.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Infraestrutura como Código acessando integralmente esse e outros cursos, comece hoje!

  • 1112 cursos

    Cursos de programação, UX, agilidade, data science, transformação digital, mobile, front-end, marketing e infra.

  • Certificado de participação

    Certificado de que assistiu o curso e finalizou as atividades

  • App para Android e iPhone/iPad

    Estude até mesmo offline através das nossas apps Android e iOS em smartphones e tablets

  • Projeto avaliado pelos instrutores

    Projeto práticos para entrega e avaliação dos professores da Alura com certificado de aprovação diferenciado

  • Acesso à Alura Start

    Cursos de introdução a tecnologia através de games, apps e ciência

  • Acesso à Alura Língua

    Reforço online de inglês e espanhol para aprimorar seu conhecimento

Premium

  • 1112 cursos

    Cursos de programação, UX, agilidade, data science, transformação digital, mobile, front-end, marketing e infra.

  • Certificado de participação

    Certificado de que assistiu o curso e finalizou as atividades

  • App para Android e iPhone/iPad

    Estude até mesmo offline através das nossas apps Android e iOS em smartphones e tablets

  • Projeto avaliado pelos instrutores

    Projeto práticos para entrega e avaliação dos professores da Alura com certificado de aprovação diferenciado

  • Acesso à Alura Start

    Cursos de introdução a tecnologia através de games, apps e ciência

  • Acesso à Alura Língua

    Reforço online de inglês e espanhol para aprimorar seu conhecimento

12X
R$75
à vista R$900
Matricule-se

Premium Plus

  • 1112 cursos

    Cursos de programação, UX, agilidade, data science, transformação digital, mobile, front-end, marketing e infra.

  • Certificado de participação

    Certificado de que assistiu o curso e finalizou as atividades

  • App para Android e iPhone/iPad

    Estude até mesmo offline através das nossas apps Android e iOS em smartphones e tablets

  • Projeto avaliado pelos instrutores

    Projeto práticos para entrega e avaliação dos professores da Alura com certificado de aprovação diferenciado

  • Acesso à Alura Start

    Cursos de introdução a tecnologia através de games, apps e ciência

  • Acesso à Alura Língua

    Reforço online de inglês e espanhol para aprimorar seu conhecimento

12X
R$100
à vista R$1.200
Matricule-se

Max

  • 1112 cursos

    Cursos de programação, UX, agilidade, data science, transformação digital, mobile, front-end, marketing e infra.

  • Certificado de participação

    Certificado de que assistiu o curso e finalizou as atividades

  • App para Android e iPhone/iPad

    Estude até mesmo offline através das nossas apps Android e iOS em smartphones e tablets

  • Projeto avaliado pelos instrutores

    Projeto práticos para entrega e avaliação dos professores da Alura com certificado de aprovação diferenciado

  • Acesso à Alura Start

    Cursos de introdução a tecnologia através de games, apps e ciência

  • Acesso à Alura Língua

    Reforço online de inglês e espanhol para aprimorar seu conhecimento

12X
R$120
à vista R$1.440
Matricule-se
Procurando planos para empresas?
Acesso por 1 ano
Estude 24h/dia onde e quando quiser
Novos cursos toda semana