Google Cloud SQL e Acesso ao Banco

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

Criando uma instância no Cloud SQL

Nós já estamos com nossa VM da aplicação configurada, os DNSs configurados e apontando para seus respectivos códigos, acessos SSH liberados e deploy com Git funcionando. Agora é chegada a hora de configurar nossa instância do Cloud SQL com um banco MySQL funcional.

Vamos abrir o menu do Console e escolher SQL. À princípio, teremos uma tela vazia, pois não temos nenhuma instância de SQL ativa, o que temos que fazer agora é só clicar em Criar instância.

Na tela que se segue, devemos escolher entre um dos dois engines de banco disponíveis, o MySQL ou o PostgreSQL. Vamos escolher o MySql por ser mais conhecido, mas se você já trabalhou ou trabalha com PostgreSql (como eu), o suporte ao banco está em versão beta na Cloud do Google e por conta disso, as instâncias dele são totalmente gratuitas, não importando o quento você use, mas só até o beta terminar (fique atento).

A próxima tela nos pergunta se queremos usar a versão do MySQL mais recente ou se queremos as versões da primeira geração do banco. A dica aqui é ter cautela, pois a segunda geração tem custos mais altos que a primeira geração, então vale a pena estudar esses valores pois o Cloud SQL é um dos poucos serviços do Cloud do Google que não tem limites mínimos gratuitos de uso, é pago desde o primeiro start da instância.

Depois dessa escolha, é a hora de configurar nossa instância. Nessa tela vamos dar um nome, definir a senha de ROOT do banco, escolher a região da instância (isso também impacta nos valores cobrados) além de mais algumas configurações mais avançadas.

Aqui só irei preencher o nome (ID) e a senha do ROOT.

A criação da instância leva alguns minutinhos, e logo você terá esta tela com as instâncias iniciadas no projeto, no nosso caso, só temos uma. Aqui, como na tela de instâncias do Comput Engine, o dado mais relevante é o IP do banco.

Clicando no nome da instância entramos na tela de gerenciamento. O local onde podemos criar o banco, usuários, fazer réplicas, configurar backups e mais algumas funções interessantes. Mas vamos começar configurando o nosso banco de dados.

Entrando na aba Bancos de dados, repare que só existem os bancos padrões do MySQL: information_schema, mysql e performance_schema. Vamos então criar o nosso banco clicando no botão Criar banco de dados.

O processo de criação é extremamente simples, basta dar um nome ao banco, escolher a codificação padrão e pronto. Chamei nosso banco de agenda.

Agora vamos na aba Usuários e vamos criar um novo usuário com acesso ao banco para não termos que usar o ROOT, o que seria uma falha de segurança. Basta clicar no botão Criar conta de usuário e na tela que se abre preencher o nome de usuário, a senha e definir se ele tem permissão de acessar de qualquer host.

Prontinho, foi ainda mais rápido e prático criar a instância de SQL com banco MySQL. Já podemos configurar agora a nossa aplicação para acessar o banco através do seu IP externo.

Atenção! O acesso ao Cloud SQL pela aplicação do mesmo projeto já está autorizada, porém nós desenvolvemos nossas aplicações localmente e só depois de tudo testado é que fazemos deploy para a nossa VM de produção. Para testar sua aplicação localmente e sua aplicação acessar o Cloud SQL, é preciso autorizar o seu IP externo (o que você recebe ao conectar sua máquina local à internet) para ter acesso. Eu uso frequentemente o site www.meuip.com.br para identificar qual IP externo eu estou usando no momento do desenvolvimento.

Para autorizar o acesso de um IP de fora do seu projeto, você deve clicar na aba Autorização, e em seguida em Adicionar rede. No fomulário que aparece, dê um nome a esta autorização e cole o seu IP que você consultou com o site meuip.com.br. Salve tudo e pronto. Em alguns minutos sua maquina local estará liberada para acessar a instância do Cloud SQL.

Caso você tenha problemas de conexão com o banco em sua aplicação, já na VM, as vezes é necessário adicionar o IP da VM à aba de Autorização também. Mas teste o acesso ao SQL à partir da VM antes de fazer esta configuração.

Conectando com nossa aplicação

Com nosso acesso local autorizado, já posso configurar a conexão com o Cloud SQL dentro da minha aplicação. Como estou usando o framework Sails.js para gerar minha API (para mais informações sobre o Sails.js, acesse https://sailsjs.com), devo configurar a minha conexão com o banco no arquivo config/connections.js, descomentando as linhas referentes à configuração com bancos MySql e preenchendo com os dados da minha instância:

Feita a conexão, vamos criar a tabela do evento. Será uma tabela simples que conterá tudo referente ao evento de TI cadastrado. Para criar a tabela, usei um cliente de MySql que tenho no computador, mas você pode usar qualquer cliente que queira, já que seu IP está liberado para acessar a instância. Pode até mesmo ser o cliente de linha de comando. O Sql para a criação da tabela é o seguinte:

Repare que alguns campos são obrigatórios e outros não. Isso porque no ato do cadastro do evento, pode ser que nem todos os dados estejam disponíveis e como vamos ter a possibilidade de editar o evento posteriormente, os dados faltantes podem ser adicionados mais tarde.

Criando o modelo no Sails.js

O bom do Sails.js é que ele é ótimo para criar APIs, e com ele muita coisa pode ser iniciada pela linha de comando. Por exemplo, acabei de criar a tabela evento e agora preciso criar o model e o controller para este recurso. Para isto basta eu digitar o seguinte comando com o terminal aberto na minha pasta do projeto (local):

sails generate api evento

Eu estou supondo que, ou você já conhece o Sails.js ou já teve a curiosidade de ir estudar sobre ele, e, obviamente, já tem ele instalado na sua maquina local, caso contrário o comando acima não irá funcionar. Você pode ter uma ideia do que é o Sails.js neste artigo que escrevi em meu blog pessoal:

Conhecendo o Sails.js

Com o comando executado com sucesso, agora temos mais dois arquivos no projeto, o api/controllers/EventoController.js e o api/models/Evento.js. Como na nossa tabela não criamos os dois campos que o Sails.js usa como padrão em seus modelos: createdAt e deletedAt, vamos editar o arquivo api/models/Evento.js e adicionar as linhas que definem que não precisamos destes campos, nosso modelo deve ficar assim:

Com isso feito, basta rodar o nosso servidor Node local:

node app.js

E tentar acessar a URL http://localhost:3003/evento (3003 foi a porta que eu defini em config/env/development.js e config/env/production.js como sendo a porta padrão para a aplicação Node). Se tudo estiver correndo bem, você verá a seguinte saída no seu browser:

[]

Testando a API

O Sails.js é tão legal que basta você usar um cliente REST (como o Postman) para testar sua API e ver que todos os verbos estão funcionando sem você ter escrito uma só linha de código:

POST http://localhost:3003/evento — cria um registro
GET http://localhost:3003/evento/1 — consulta um registro de ID = 1
GET http://localhost:3003/evento — consulta uma lista de registros
PUT http://localhost:3003/evento/1 — edita um registro de ID = 1
DELETE http://localhost:3003/evento/1 — exclui um registro de ID = 1

Que maravilha. Temos agora nossa API funcionando e rodando localmente. Como havíamos configurado nosso repositório remoto da VM, basta agora fazer um commit com estas alterações e empurrar para a VM com
git push deploy master

Configurando o Apache para direcionar a requisição para a porta 3003

Agora que temos a API básica configurada, precisamos direcionar as requisições que chegarem em http://api.trilhagooglecloud.ml na porta 80 para nosso servidor de API Node que está rodando na porta 3003 internamente na VM. Para isso vamos acessar nossa VM via SSH (via terminal local ou console web, tanto faz) e vamos editar o arquivo /etc/apache2/sites-available/api-trilha.conf para ficar parecido com este:

Agora definimos novas configurações no VirtualHost do Apache:

• ProxyPreserveHost: A diretiva é usada para que o nome do host desejado seja passado, no caso de vários nomes de host para uma única máquina
• ProxyRequests: Isso permite ou impede que o Apache funcione como um servidor proxy direto.
• ProxyPass: Esta diretiva permite que os servidores remotos sejam mapeados no espaço do servidor local. O servidor local não age como um proxy no sentido convencional, mas parece ser um espelho do servidor remoto. O servidor local geralmente é chamado de proxy reverso ou gateway
• ProxyPassReverse: Esta diretiva permite que o Apache ajude o URL nos cabeçalhos Location, Content-Locatione URInas respostas de redirecionamento HTTP. Isso é essencial quando Apache é usado como um proxy reverso (ou gateway)

Antes de reiniciarmos o Apache para que as alterações entrem em vigor, precisamos ativar o módulo de proxy com o seguinte comando sudo a2enmod proxye sudo a2enmod proxy_http, e agora sim vamos reiniciar o Apache sudo service apache2 reload e acessar o endereço api.seu_dominio_registrado/evento para ver se o Apache está redirecionando corretamente o tráfego para o serviço interno da VM na porta 3003.

Note que o cliente que está acessando a URL da API não precisa definir a porta como sendo 3003 (api.trilhagooglecloud.ml:3003/evento), porque agora quem cuida disso é o Apache e para nosso cliente esse redirecionamento é transparente. Além do mais, sequer liberamos a porta 3003 nos serviços de rede do Google Cloud Platform e, se você tentar acessar diretamente o URL acima com porta 3003 explícita, não terá acesso algum.

Executando o servidor Node/Sails automaticamente

O Apache já é iniciado automaticamente a cada reinicio do sistema, mas os serviços Node funcionam diferente. É preciso configurar manualmente o start da aplicação ou configurar uma ferramenta como o PM2 para se preocupar com isso.

Escolhi usar o PM2 por já ter experiencia com ele e por ele ser bem simples de configurar. Pra começar, vamos acessar a VM via SSH e instalar o PM2 globalmente:

npm i -g pm2

Caso tenha algum erro durante a instalação, execute novamente o comando, desta vez usando sudo. Depois de instalado, vamos configurá-lo:

pm2 startup

Este comando vai gerar uma linha de comando que devemos copiar e colar no terminal. Essa linha gerada é particular para cada servidor e serve para configurar o start automático do serviço, e é por isso que ela é gerada na hora. A linha se parece com essa (mas não copie esta aqui, gere a sua com o comando acima):

Feito isso, o PM2 está configurado para o startup. Agora vamos reconfigurar o arquivo /var/repos/api-trilha.git/hooks/post-receive para configurar que a cada novo deploy recebido, o sistema seja devidamente atualizado e reiniciado.

O arquivo post_receive nada mais é um script shell que é executado a cada push recebido no repositório, ele não serve só para fazer o checkout para a pasta www, nele pode ser colocado qualquer comando para ser executado em cada deploy, e é o que vamos fazer:

Vamos salvar o arquivo e em seguida empurrar uma nova versão da aplicação local via Git para o repositório da VM. A saída do comando git push deploy master deve ser algo parecido com isto:

O erro [PM2][ERROR] Process agenda-ti not found se deu por esta ser a primeira vez que executamos o comando pm2 stop agenda-ti e o serviço ainda não existia no PM2. Logo abaixo ele inicia o serviço, e ai sim ele passa a existir. Este é um erro que você só verá na primeira execução do script.

Pronto. Temos agora a nossa API configurada, acessando o Cloud SQL e servindo o endpoint /evento, com o gerenciador de serviços Node PM2 responsável por reiniciar o serviço a cada novo deploy, reinício da VM ou crash da aplicação.

Neste artigo aprendemos a criar e configurar uma instância do Cloud SQL, a liberar o acesso de IPs externos ao projeto, a configurar o acesso ao Cloud SQL à partir do Sails.js e a gerar os modelos e controllers para nossa API, a configurar o Apache para direcionar as requisições da porta 80 para nosso serviço interno na porta 3003, além de configurar o serviço PM2 para monitorar e manter online nosso servidor Node.