Google Cloud Launcher

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

Entendendo O Cloud Launcher

Alguns de nós já estamos acostumados a subir nossas VMs em alguns dos grandes players do mercado (Amazon, Linode, DigitalOcean, etc…) e configurá-la do jeito que a nossa aplicação precisa.

Então levantamos a VM, acessamos via SSH, instalamos o ambiente (Node, PHP, Ruby, Apache, Nginx, Redis, etc…), configuramos, startamos, etc. Mas muitas vezes fazer esse trabalho é chato e massante, e algumas vezes desnecessário, por não necessitar de uma configuração muito específica de determinada tecnologia.

Pois bem, no Google Cloud Platform nós temos a opção de usar o Cloud Launcher para iniciar uma stack pré-definida e pré-configurada economizando alguns bons minutos ou horas de trabalho. Não que as outras nuvens de serviços não tenham algo parecido, a Amazon tem o AWS Marketplace, o Linode tem os Scripts, e por ai vai… Mas o bom da Nuvem do Google é que lá tudo é muito mais fácil e amigável ao usuário.

Com o Cloud Launcher posso escolher criar uma instância inteira de uma VM com uma stack, ou um container com uma outra stack específica. Por exemplo, posso criar um container Docker com um ambiente configurado com Node para rodar minha aplicação e depois criar uma VM com o MongoDB configurado. Tudo isso sem ter de acessar via SSH uma máquina e configurar tudo na unha.

É claro que ainda vamos ter de entrar nestas instâncias e fazer os ajustes finos, mas essa é só a parte final da configuração.

Criando nossa instância

Ícone do Cloud Launcher no menu

Para essa série de artigos, vou precisar de apenas uma instância que rode o Node com o Git e o Apache ou o nginx.

Acessando o Cloud Launcher e fazendo uma busca por Node, no momento da escrita deste texto, haviam disponíveis 22 opções de máquinas virtuais com diversas configurações que incluíam o Node em sua stack.

Escolhi a opção de VM com Node fornecida pelo Google e conhecida como Google Click to Deploy. Entrando nos detalhes desta máquina podemos ver as configurações da VM e a stack que vem instalada e configurada com ela.

Note na sessão destacada na imagem que esta VM roda o sistema operacional Debian 9, o que é muito bom e eu particularmente gosto muito da facilidade do sistema de gerenciamento de pacotes, APT, do Debian, que me permitirá instalar com facilidade qualquer recurso adicional. Além disso, também vem instalado e configurado o Apache (queríamos o Apache ou nginx) e o Git. Ótimo, esta máquina serve perfeitamente para o projeto! Vamos instalá-la clicando no botão Lançar no Compute Engine

A tela que aparece em seguida é a tela de dimensionamento da VM. Aqui podemos provisionar a memória RAM, a quantidade de CPUs, o tipo de armazenamento e seu tamanho, além de fazer algumas pequenas configurações de rede.

Aqui vou deixar a maioria das opções como padrão e mudar somente o tamanho do disco de 10GB para 30GB e ativar o tráfego HTTPS. Isso porque futuramente pode ser que queiramos instalar um certificado SSL para o nosso domínio.

Levará alguns minutos (poucos) para a nossa VM ficar pronta e ativa. Assim que ela estiver pronta, veremos esta tela que nos dará informações importantes de como acessar e configurar alguns recursos da stack (essas informações variam muito de stack para stack). Podemos ver aqui um botão para abrir o site padrão instalado na VM (já que optamos por uma stack com Apache), um botão para fazer o acesso via SSH e, uma das informações mais importantes desta tela, o IP externo de acesso à esta VM.

E pronto, nossa VM está ativa a pré-configurada.

Configuração do IP externo

Por padrão, a VM que acabamos de criar vem com um IP temporário designado a ela. Isso funciona bem? Sim, funciona que é uma beleza, mas só até você ter de reiniciar sua instância. Se por alguma razão você precisar reiniciar a VM manualmente ou automaticamente por conta de uma manutenção, por exemplo, será atribuído um novo endereço IP externo à máquina, e isso pode ser um problema para o seu registro de DNS. Então vamos agora tornar este IP fixo, de forma simples e rápida.

Vamos acessar no menu do Console a opção Rede VPC > Endereços IP Externos. Assim que você carregar esta página, verá que já está listado o IP da VM que acabou de ser criada, e observe que a coluna Tipo indica que o IP é Temporário. Para alterar para fixo é só clicar na palavra temporário e um modal se abrirá pedindo para você dar um nome para este IP. Escolha o nome que quiser e uma descrição, caso queira especificar algum detalhe, e pronto. Ao clicar em Reservar o Google vai fazer justamente isso, vai reservar este IP para a sua VM, e a agora toda vez que você precisar reiniciar a máquina, ela retornará com o mesmo IP, mantendo assim suas configurações de DNS sempre operantes.

Mas preste atenção, o Google cobra por cada IP fixo reservado adicional uma taxa de uso. Temos direito a apenas um IP fixo gratuito por região da VM. Se você for reparar nas imagens anteriores, nossa VM com Node foi criada na região us-central1, isso significa que se neste projeto eu criar uma nova VM na mesma região (us-central1) e quiser que esta VM também tenha um IP fixo, então ai sim o Google vai me cobrar por este IP. Mas calma, o Google sempre avisa antes de fazer uma cobrança.

Configurando os domínios e sub-domínios

Agora que temos uma VM com um IP fixo reservado, vamos criar o direcionamento das requisições HTTP provenientes de www.trilhagooglecloud.ml e trilhagooglecloud.ml para nossa máquina virtual com o Apache rodando.

Entrando de novo no menu Serviços de rede > Cloud DNS e acessando a zona que criamos no artigo anterior, veremos que só temos até agora os registros de NS e SOA. Para criar um novo registro para esta zona, vamos acessar o botão Adicionar conjunto de registrios.

Na tela que se segue, basta preencher os dados do formulário com o Nome do DNS (prefixo do domínio, tudo que vem antes do seudominio.com.br) que queremos criar o registro, o Tipo (CNAME, A, TXT, MX, etc…) e o endereço IP externo para onde queremos que o trafego seja direcionado.

Para o domínio com www preenchemos assim:

Nome do DNS: www
Tipo: A
Enedereço IPv4: ip_da_sua_vm

Para o domínio sem www preenchemos assim:

Nome do DNS: deixar_em_branco
Tipo: A
Enedereço IPv4: ip_da_sua_vm

E pronto. Agora é esperar alguns minutos (até 10min) para esse novo registro se propagar e tentar acessar o domínio pelo nome www.trilhagooglecloud.ml para ver se o direcionamento está funcionando bem.

API é a melhor opção

Como foi dito na introdução do artigo, o objetivo é criar um sistema de agendamento de eventos e utilizar o Angular como frontend e o Node com o framework Sails.js como backend. Mas a ideia aqui é que ambos seja desacoplados um do outro, sendo o frontend um mero cliente que consumirá os dados de uma API no backend. Isso nos permite, futuramente, criar vários clintes de frontend para dispositivos diferentes sempre consumindo a mesma fonte de dados.

O ideal é que tivéssemos uma VM só pro frontend e uma VM só pro backend. E isso já vimos aqui que é muito fácil de configurar. Esses seriam os passos:

1 — Criar uma VM com Node ou outra stack de sua preferência (via Compute Engine ou Cloud Launcher)
2 — Reservar um IP externo para a VM
3 — Criar um registro na nossa zona de DNS apontando para essa VM
4 — Só isso!

Mas para não ficar muito dispendioso aqui, deixo esta configuração extra para vocês. O que vou fazer no nosso artigo é criar um registro na zona de DNS para api.trilhagooglecloud.ml e apontar para a mesma VM que apontei o frontend (nossa única VM criada) e lá na VM, via SSH, configurar o Apache para servir dois sites diferentes na mesma máquina.

A configuração do registro da zona ficaria assim:

Nome do DNS: api
Tipo: A
Endereço IPv4: o_mesmo_da_vm_anterior

Acessando a VM via SSH e configurando o Apache

Para acessar a VM, vamos primeiro usar o botão SSH que fica na própria página da instância. Basta acessar no menu do Console do Compute Engine > Instâncias de VMs e na lista de instâncias do projeto (só temos uma mesmo) clique no botão SSH. Uma janela no próprio browser com um cliente SSH será aberta. Achei isso uma mão na roda, pois assim posso dar manutenção às VMs mesmo não estando no meu computador de trabalho configurado.

Feito isso, é configuração padrão pra quem já trabalhou com Apache. Os arquivos de configuração dos sites do Apache estão na pasta /etc/apache2/sites-available. Fazendo uma listagem desta pasta podemos ver somente os dois sites defaults configurados, um para HTTP e outro para SSL (HTTPS).

Vamos desativar estes dois sites usando a ferramenta de configuração de linha de comando do Apache:

Depois disso temos que recarregar o Apache para que as novas configurações entrem em vigor:

Agora vamos criar, também com sudo, porque não temos permissão para escrever na pasta do Apache, dois outros arquivos de configurações de sites, o primeiro para o frontend:

E vamos digitar o seguinte conteúdo neste arquivo:

Depois criamos o segundo arquivo para o backend:

Com o conteúdo:

Basicamente estamos definindo dois VirtualHost no Apache, esses hosts virtuais são, para o servidor, sites independentes que deve ser tratados de forma separada. As configurações básicas para um VirtualHost funcionar são bem simples:

• ServerAdmin: o e-mail do administrador do servidor
• ServerName: o domínio (ou sub-domínio) que este host servirá
• ServerAlias: caso haja outro domínio que deve ser respondido pelo mesmo host, um exemplo disso é quando temos seusite.com e www.seusite.com
• DocumentRoot: A pasta onde estão os arquivos do site/sistema/aplicação que serão servidos pelo host

Para testar, vamos criar um arquivo index.html em cada pasta dessas citadas acima em DocumentRoot:

Feito isso, podemos ativar os sites com a ferramenta de linha de comando do Apache e reiniciar o serviço:

Se nada deu errado, agora temos dois sites independentes rodando na mesma VM com Apache. Acesse ambos para testar: www.seu_site e api.seu_site. Um deve exibir o texto www-trilha e o outro o texto api-trilha.

E por aqui terminamos mais um artigo desta série. Hoje aprendemos a criar uma instância de VM utilizando o Cloud Launcher, a configurar os DNSs para apontar o site para esta instância, a criar um subdomínio e também apontar para esta instância e por fim configuramos o Apache para servir estes sites independentemente.