Google Cloud Compute Engine: escalabilidade e alta disponibilidade

Provisionando uma aplicação - Introdução

Tem pensado em migrar sua aplicação para dentro da nuvem do Google, mas fica preocupado em amanhã ou depois ter que escalar, criar uma redundância, ou até mesmo implementar uma alta disponibilidade? Essa é a ideia desse curso. Vamos percorrer alguns serviços dentro da plataforma do Google Cloud, enquanto construímos nossa aplicação de forma escalável e com alta disponibilidade. Vamos aprender um pouco mais sobre computação em nuvem, a parte de histórias e de load balance para que possamos distribuir nossa aplicação de forma profissional.

Eu sou o Ricardo Merces e vou te acompanhar em mais este curso.

Provisionando uma aplicação - Diagrama da solução

Para começarmos, vamos falar um pouco da aplicação, o que você vai precisar. Como vai funcionar nosso curso? A ideia é que levemos nossa aplicação para dentro da nuvem do Google, como disse na apresentação.

Como vamos fazer isso? O que você vai precisar? Você tem que já ter uma conta no Google Cloud. Se você tiver algum problema em criar a conta, que é só preencher o cadastro, tem um curso já na plataforma que faz a publicação de uma app lá dentro do Google Cloud. Você pode ver a parte de criação de conta, que é bem simples.

Feita essa parte, é legal entender o que vamos fazer. Eu separei uma mini apresentação para separar em camadas nossa aplicação. Ela é dividida em dois segmentos separados em serviços para rodar na Google Cloud. A primeira parte é uma instância virtual, uma máquina virtual que vai abrigar nosso servidor web, nossa parte do front end. Os dados vão estar todos localizados no cloud storage. Tenho então meu site e o conteúdo do meu site abrigado no cloud storage.

Vamos começar nessa configuração. Já tem uma coisa aqui bem legal. A atualização do nosso site vai ser direta pela publicação do conteúdo. O desenvolvedor faz as alterações, publica no storage e já tem uma rotina para atualizar nosso front end. Já colocando alguns conceitos de DevOps e tudo mais para automatizar o dia a dia do nosso site.

Começamos de forma simples e vamos evoluir. Qual a diferença? Depois de construirmos a primeira forma, a primeira camada, vamos evoluindo até chegar à configuração mostrada. É uma configuração que consegue escalar a máquina conforme o uso. Conforme a necessidade das alocações do recurso, temos como crescer nossa instância. Somado a isso, vamos ter um load balancing na frente para garantir a alta disponibilidade do nosso site.

No finalzinho, então, é nessa configuração que vamos chegar, que é a app escalável e também com alta disponibilidade.

Vamos começar a trabalhar, voltando para o cenário número um, que é provisionar nossa instância e a parte de storage. O primeiro passo é entrar no cloud.google.com e fazer o login na nossa conta.

Carregada a página, vamos ver o sumário. Para todo mundo partir do mesmo ponto, vou nos projetos e vou criar um novo. O nome vai ser site-rmedeslabs. Você pode escolher o seu. E vamos criar.

Projeto criado, tudo zerado para começarmos. Vamos precisar agora provisionar nossa instância que vai receber o front end da nossa aplicação. Clico no menu. O recurso que vamos utilizar está na compute engine, que tem as opções de máquina virtual, disco.

Uma dica: vê o pin que aparece? Se você clicar nele, a opção já vai lá para cima e facilita a organização.

Vamos trabalhar. Vamos criar nossa instância. A primeira vez em que você utiliza isso, pode ser que ele demore. É só aguardar uns minutinhos. Qual vai ser o setup da nossa instância? Vamos começar com uma única máquina abrigando front end e os dados provisionados no cloud storage, que é outro serviço.

O nome da máquina está como instance-1. Vou deixar assim mesmo. O tipo de máquina é o perfil de máquina que queremos, a região. É legal sempre dar uma olhada, ainda mais para quem está começando. Talvez você tenha já experiência em outro provider, como por exemplo o AWS. Você que já tem experiência vai reparar que até os nomes são parecidos.

Resumindo: tenho região e zona. Região é o ponto, o datacenter onde ele está localizado. E as zonas são divisões, isolamentos dentro desse datacenter. Eu tenho um datacenter e tenho a parte A, B, e C, ou conforme ele der o nome da zona. Se der problema no B, você ainda tem o A e o C, se der problema no B e no C, você ainda tem o A. Ou seja, ele tem redundância dentro de cada região. Aqui, então, temos uma região com três redundâncias.

Busque no Google por Google cloud region map para facilitar o entendimento. No globo, temos os datacenters. Estamos na Carolina do Sul, que é o padrão. Temos em Virginia, Montreal, Los Angeles. Dentro delas, os números representam as zonas. Ou seja, tem três opções ali dentro que são independentes entre si. Em termos de redundância, se você depois quiser comparar com o mapa do AWS, você vai ver que é bem parecido.

Então, é só você escolher um datacenter mais próximo do seu cliente. Se seu cliente está no Brasil, hospedar em Tóquio pode não ser uma boa ideia. Você escolhe o datacenter e adequa sua aplicação para ter a menor latência possível.

Eu vou manter o default. Agora, no tipo de máquina, vou escolher a micro, que é uma CPU compartilhada. Uma coisa legal é que quando você seleciona a máquina do lado ele já te dá a estimativa de valor, assim você não tem surpresas depois.

Como aqui é só para efeito de aprendizado, você não precisa começar com uma máquina maior. Essa micro está ótima.

Depois, temos o disco de boot. Ele nada mais é do que o sistema que vai rodar. No Google Cloud, por default, vem um Debian 9. Vou usar esse mesmo.

O que vamos mudar agora? Vamos selecionar o permitir tráfego HTTP e HTTPS. Ele vai criar duas regras no firewall para mim. Preciso colocar mais alguma coisa? Por enquanto, não. Vamos fazendo os ajustes conforme necessário.

Vou criar minha máquina. É bem rápido o processo. Temos a máquina criada, um IP de acesso externo para fazermos a conexão. No próximo vídeo vamos conectar na máquina e começar a fazer a configuração do nosso Apache.

Provisionando uma aplicação - Provisionando a máquina virtual

A máquina está provisionada. Temos um recurso dentro do console de conectar via SSH. Abrindo nosso cliente SSH – esse client web é um quebra-galho. Minha dica é não se acostumar a usar isso. Use numa emergência. Quando você usa muitas vezes o processo ele vai te mostrar até uma mensagem dizendo que você pode reduzir o tempo drasticamente utilizando um cliente local, que é muito mais fácil e mais rápido. Mas para começarmos a ideia é essa.

O que precisamos fazer? sudo apt-get update. Vamos atualizar nossa máquina. Depois: sudo apt-get install apache-2. Ele vai fazer a instalação do apache. Tudo instalado, tem mais um ponto importante para verificarmos.

No Debian, o apache roda com usuário www. É legal fazermos isso: cd /var/www, depois: ls -l. Nosso conteúdo vai ficar no HTML, que é o default. Não vamos alterar isso. Uma boa prática, até para facilitar o manuseio do conteúdo que vamos fazer é mudar: chown -R www-data:www-data html/

Vamos testar a máquina. Vou clicar no link, vai abrir uma nova janela. Cuidado, porque a pessoa pode ter uma desilusão no início por não funcionar. Não é isso. Ele abre https. É http que quero testar, porque é como acabei de instalar o apache.

Assim já provisionamos a máquina. Com o Apache instalado, já com essa configuração do diretório. Mas aí você pode perguntar se não tem um jeito mais fácil de provisionar a máquina com o Apache, já com tudo pronto? E tem. Essa é a ideia de DevOps, para automatizarmos nossos processos.

Vou criar uma outra instância. Vamos fazer o comparativo de quanto tempo demora desse jeito. Nós vamos escolher o mesmo tipo de máquina e vamos clicar no management. Estou no gerenciamento. Vou começar criando nosso script de inicialização. Vou definir qual o shell que vou utilizar no startup script: #/bin/bash. Essa automação é reunir o que fizemos passo a passo em um só lugar.

O primeiro comando: apt-get update. Depois: apt-get install apache2 -y. A diferença é que quando trabalhamos com script temos alguns recursos que precisam ser utilizados. O -y serve para ele não perguntar. Lembra quando instalamos o apache e ele perguntou várias coisas default? Com o -y já digo que ele não precisa perguntar.

Outra coisa é que não tem o sudo na frente, porque na inicialização da máquina ele já está fazendo isso com usuário privilegiado. Já está fazendo com o root, e o root não precisa ter sudo na frente.

Fizemos então essa linha. Depois, o que fizemos foi: chown www-data:www-data /var/www/html. Estou mudando o dono e o grupo do /var/www/html. Além disso, vamos colocar um complemento. Vou criar uma página com um html teste. Só para incluir um item a mais.

Rodando isso e fazendo o teste, tudo funciona. Isso sim é uma forma de provisionar um recurso muito mais inteligente. E a evolução disso ainda veremos dentro do curso, que é gerar uma imagem. Você pode ter uma imagem em um template, precisar criar dez servidores web. Use uma imagem, um script desse de inicialização, e veja como fica mais fácil.

Na sequência, vamos passar para o ssh local e fazer algumas modificações.

Sobre o curso Google Cloud Compute Engine: escalabilidade e alta disponibilidade

O curso Google Cloud Compute Engine: escalabilidade e alta disponibilidade possui 129 minutos de vídeos, em um total de 41 atividades. Gostou? Conheça nossos outros cursos de Google Cloud Platform em DevOps, ou leia nossos artigos de DevOps.

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

• Provisionando uma aplicação no Google Cloud
• Utilizando a CLI gcloud
• Preparando o front-end
• Escalando o site
• Alta disponibilidade