Google Cloud Compute e Deploy com GIT

Google Cloud Platform na Prática

Introdução

Com esta série de artigos vou demonstrar como construir uma aplicação no Google Cloud Platform na prática. Mas digo na prática mesmo, não só na teoria e conceitos.

Aqui vamos criar um sistema de Agenda de Eventos de TI, uma agenda prática que servirá para que organizadores consultem as datas com eventos já marcados para assim marcar a data do seu evento sem conflitar com outros, evitando dividir o público.

Nesta série não abordarei o código da aplicação em si, pois o objetivo aqui é explicar sobre a infraestrutura disponível na nuvem do Google e como podemos usá-la. Quem sabe uma outra série de artigos derive desta, explicando a codificação da aplicação.

Agenda

Dividiremos os artigos da seguinte forma:

1- Parte 1: Introdução e Registro de domínio gratuito
2- Parte 2: Google Cloud Launcher
3- Parte 3: Google Cloud Compute e Deploy com GIT
4- Parte 4: Google Cloud SQL e Acesso ao Banco
5- Parte 5: Google Cloud Storage

As tecnologias de frontend e backend escolhidas para esta série serão:

• Angular
• NodeJs
• Sails.js
• MySql
• Apache 2
• Git

Configurando o Git para fazer o deploy dos arquivos

Vamos agora configurar os nossos repositórios Git para fazer deploy direto no servidor de forma prática e fácil.

Atenção! Obviamente fazer deploy direto no servidor de produção não deveria ser tão simples assim, antes do deploy deve ser feitos testes automatizados e o deploy só deve ocorrer depois de todos os testes passarem. Porém aqui não estamos focando em técnicas de desenvolvimento, código ou testes, estamos simplesmente configurando um deploy no servidor. Tome muito cuidado ao fazer isso no seu projeto.

Para começar, crie uma pasta /var/repos pelo terminal que está acessando o SSH (supondo que você ainda esta conectado à VM via SSH):

sudo mkdir /var/repos

Agora vamos criar uma pasta para cada site:

Use sudo para criar as pastas

Gosto de criar as pastas com o sufixo .git para ficar parecido com os repositórios do GitHub, que já são bem conhecidos.

Agora temos que entrar em cada um destes diretórios que criamos e vamos iniciar um repositório Git:

O que fiz aqui foi iniciar um repositório dentro de cada pasta. O parâmetro
— bare cria um repositório nulo, ideal para servir de servidor (são assim os repositórios do GitHub, BitBucket, GitLab, etc…) e o parâmetro — share torna o repositório acessível a outros usuários da VM, como os usuários do sistema.

Para configurar o deploy automático ao se fazer um push para este repositório, a mágica fica é feita nos arquivos de gatilho, ou hooks. Vamos entrar na pasta hooks de cada repositório e criar um arquivo chamado post-receive:

sudo nano /var/repos/www-trilha.git/hooks/post-receive

Com o seguinte conteúdo para o www:

Repare que estou usando o caminho sem o /dist que configurei no VirtualHost do Apache. Isso se dá porque no frontend estou planejando usar o Angular, e os arquivos de build com minha aplicação empacotada ficam justamente na pasta /dist. O Apache precisa saber disso, para só servir os aquivos empacotados, mas o checkout aqui no Git é do projeto todo, e isto inclui a pasta /dist dentro.

Este comando do post-receive define a GIT_WORK_TREE como sendo a pasta /var/www/html/www-trilha e é pra lá que ela manda a cópia dos aquivos que vieram com o push, e para evitar conflitos, o parâmetro -f (force) garante que tudo nesta pasta será substituído pelo novo conteúdo.

Por fim, precisamos dar permissão de execução para este arquivo recém-criado:

sudo chmod +x /var/repos/www-trilha.git/hooks/post-receive

Faremos o mesmo com o arquivo post-receive na pasta api-trilha.git, mudaremos apenas a GIT_WORK_TREE para apontar para a pasta /var/www/html/api-trilha e pronto. Temos nossos repositórios remotos e seus respectivos deploys configurados.

Chaves SSH

Para acessarmos o SSH à partir do nosso terminal do computador (sem usar o SSH oferecido pelo Cloud na web) e para conectar nosso projeto local ao nosso repositório Git remoto para deploy que acabamos de criar, precisamos adicionar a chave pública SSH da minha máquina local ao meu projeto do Google Cloud Platform. Faremos isso acessando o menu do Cloud Compute Engine > Metadados e na página que abre vamos escolher a aba Chaves SSH e clique no botão Editar

Em sua máquina local, digite o seguinte no terminal:

cat ~/.ssh/id_rsa.pub

Aparecerá na tela o conteúdo de sua chave pública. Com ela copiada, volte à tela de Metadados do Compute Engine clique em Adicionar Item e cole o conteúdo na caixa de texto. Salve e ponto.

Para testar se o acesso SSH agora está liberado à partir da sua máquina local, digite o seguinte em seu terminal local:

ssh [usuario-local]@[seu-dominio-registrado]

Onde [usuario-local] é o usuário que você usa pra logar em sua máquina local, no meu caso aqui em casa é walter, e [seu-dominio-registrado] é o domínio que você criou no FreeNom no primeiro artigo e depois vinculou o DNS ao seu projeto e etc e tal.

Se tudo correr bem você agora está conectado à sua VM via terminal de sua máquina local, parabéns! Vamos agora continuar as configurações.

Você reparou que todos estes comandos para criação dos repositórios Git foram dados usando o sudo? Isso porque estávamos usando o SSH do console da web, e esse usuário do SSH leva o mesmo nome da conta Google que você usou para cadastrar no Google Cloud Platform.

Quando eu estou conectado via SSH do Console na web, meu usuário no terminal parece como isto:

sys_sgcc@nodejs-1-vm;~$

Mas se conecto agora om meu SSH no terminal local, usando a chave pública que cadastrei no meu projeto, eu vejo isso:

walter@nodejs-1-vm:~$

E para conectar meu repositório local (com o código do meu projeto) ao repositório de deploy da VM, eu não posso usar o usuário do console sys_sgcc, tenho que usar meu usuário local. Como eu já testei o SSH local, a minha VM lá na nuvem já criou o meu usuário walter (lá), então agora preciso dar permissão pra esse meu usuário (walter), que é quem vai fazer os push no repositório da VM.

Complicado entender essa relação de permissões e usuários né? Mas é isso que faz os sistemas Unix serem tão superiores em relação à segurança. É complicado mas vale à pena.

Vamos lá. Conectado via SSH com meu usuário local (walter) em minha VM, vamos dar permissão:

Pronto, agora meu usuário do SSH local pode manipular os repositórios lá na VM. Vamos então vincular o repositório remoto da VM ao nosso repositório local que contém nosso código da aplicação. Vamos começar pelo frontend.

Se você já tem o seu projeto local com o seu código e um repositório Git iniciado, basta roda o seguinte comando:

git remote add deploy [usuario-local]@[seu-dominio-registrado]:/var/repos/www-trilha.git

No meu caso ficou:

git remote add deploy walter@trilhagooglecloud.ml:/var/repos/www-trilha.git

Estou chamando localmente este repositório de deploy pra ficar mais intuitivo. Para testar se a conexão está sendo feita corretamente, rode o comando git remote show deploye se nenhum erro de acesso ou permissão for exibido, está tudo pronto.

Mandar o meu código local para rodar na nossa VM agora é bem simples, basta fazer as alterações no código, fazer um commit local e depois empurrar pra VM com git push deploy mastere pronto!

Para o repositório da API você repetirá exatamente os mesmos passos, apenas trocando a linha do caminho do repositório:

git remote add deploy [usuario-local]@[seu-dominio-regitrado]:/var/repos/api-trilha.git

Agora já temos tudo pronto para enviar o código da aplicação de deixá-la no ar à todo vapor.

No artigo de hoje aprendemos a configurar repositórios Git remotos para usarmos para deploy da nossa aplicação, aprendemos a conectar nosso usuário local via SSH de nossa máquina local, e dar permissões ao nossos usuários e a vincular nosso repositório remoto com o nosso repositório local.