cloud-journey/gcp-class-1

Google Cloud class 1

GCP Class 1

Esse repositório é destinado a todo o conteúdo de educação sobre nuvem e o provedor de plataformas em nuvem Google Cloud.

Requisitos

• Um editor visual de código (recomendado vscode);
• git instalado;
• Uma conta no GitHub;
• Chaves SSH cadastradas no GitHub;
• Opcional: Terraform CLI;

Aprendizes

Cada aprendiz tem um ID, memorize o seu ID pois ele será necessário durante todo o período do curso. O link do ID leva direto para a branch de estudo de cada aprendiz.

Aprendiz	ID	Username
victor.franca	8C1C	vflopes
anderson.damasceno	FE5A	Anderberserk
antonio.raposo	7329	antoniocarlosraposo
danielle.benites	3DF4	danibenites
dejair.santos	E4E4	dejair-tech
diego.doi	BDEC
karla.nascimento	97F1	Karlaouros
luciano.torquato	CFA1	Ltorquato10
luiz.andrade	606B	Luizfvandrade
marisa.cavalcanti	A709	MarisaMello
paulo.carmo	09B0	PHCarmo
ricson.sampaio	AC1C	RicsonSampaio
thiago.castilho	FCF9	ThiCastilho
thomas.bispo	3A9D	thomasnakamura
tiago.alexandre	B675	tasale
ygor.pereira	7949
guilherme.kojima	7F24
bruno.avelar	139D	AvelarB
claudemir.junior	B0AE	claudemirAvelino
elton.luiz	F029	eltonpeixoto
jonatha.brassolatti	F33E	jbrasso
julio.barcellos	C4C4
klelber.xavier	E855	betodoescher
lucas.praxedes	5BC0	LucasPinheiroCarvalho
rodrigo.cassiano	AB8B	RodCas11
fagner.carvalho	C08C	Fagner-Carvalho
ricardo.baptista	4BF8	ribaptista
elton.ferreira	08C7	eltonbf
phillipe.morais	A6F0	phillipe-morais
dante.mesquita	AA31	danteGroove

Branches

Nesse repositório cada aprendiz tem uma branch nomeada com o ID do aprendiz, exemplo: 8C1C é a branch de estudo do aprendiz victor.franca.

Quando você for trabalhar em alguma atividade prática do curso, sempre comece a partir da sua branch:

# Define a branch atual local utilizando o ID do aprendiz
git checkout 8C1C
# Faz o download de qualquer atualização remota na branch do aprendiz
git pull origin 8C1C

Ao começar o trabalho, crie uma de trabalho a partir da sua utilizando o prefixo WIP (work in progress) um sufixo da sessão:

git checkout 8C1C
git pull origin 8C1C
# Cria uma nova branch a partir da branch do aprendiz
git checkout -b WIP/8C1C/session-1

Ao terminar as atividades práticas você deve realizar o commit e push das suas alterações para o servidor remoto git (GitHub):

git add ./
git commit -m "Descreva suas alterações aqui"
git push origin WIP/8C1C/session-1

Pull Requests

Os pull requests são uma forma de uma pessoa que tem mudanças publicadas em uma branch peça que as mudanças sejam aplicadas a uma outra branch. Iremos utilizar os pull requests para validar e testar os exercícios do curso.

Vamos exemplificar como esse fluxo funciona utilizando o aprendiz victor.franca (ID 8C1C) em um exercício prático.

1. victor.franca fez uma nova VPC com terraform na branch WIP/8C1C/session-1 localmente em sua máquina;
2. Então ele faz o commit e push de suas alterações para a branch WIP;
3. Na sequência ele navega até a página de Pull Requests e clica em New Pull Request;
4. Na opção de branch base ele seleciona sua branch de estudo 8C1C, na opção compare ele escolhe sua branch de trabalho WIP/8C1C/session-1;
5. Então clica em Create Pull Request;
6. Ele então coloca um título para seu PR descrevendo brevemente o que as alterações representam, no campo descrição são colocados mais detalhes importantes das alterações;
7. Ao lado do botão verde abaixo do campo de descrição Create pull request, existe uma setinha apontando para baixo, ele então escolhe criar um Create draft pull request, isso indicará que ainda poderá fazer alterações na branch WIP;
8. Quando o victor.franca conclui que finalizou o exercício prático, ele clica no botão Ready for review;
   1. Isso indicará ao guia que o mesmo poderá avaliar os resultados do exercício, caso alguma modificação precise ser feita, o PR voltará para o estado de "Draft" e seguirá novamente o passo 8;
   2. Ao mesmo tempo, ao indicar que um PR está pronto para ser revisado, o GitHub Actions irá dispará uma automação que valida o código Terraform produzido;
   3. Essa automação também busca valores sensíveis no repositório com o Gitleaks e valida alguns parâmetros de qualidade utilizando o Codacy;
9. Após as alterações feitas, a automação de validação obter êxito e a revisão concluída, o guia comenta em um arquivo do PR: Terraform, go ahead and apply it!;
   1. Isso irá disparar uma automação (workflow) no GitHub Actions que irá provisionar sua infraestrutura na nuvem;
   2. Nesse momento o guia pedirá para que você valide sua infraestrutura agora provisionada na nuvem;
10. Após a validação, o PR é aplicado à branch de estudo (8C1C);
    1. A branch de trabalho (WIP) agora pode ser excluída, já que as alterações estão aplicadas na branch de estudo;
    2. Ao fechar um PR, o GitHub Actions executará uma automação para remover todos os recursos provisionados na nuvem, já que agora não são mais necessários para o estudo;

Issues

As issues nesse repositório servem para abrir discussões sobre as sessões de estudo e temas relacionados. Caso você tenha alguma dúvida que não está contemplada em uma issue, sinta-se livre para abrir uma nova explicando a questão para que outras pessoas possam colaborar.

Milestones

As milestones nesse repositório serão agrupadores das etapas e programação de conteúdo do curso. Você pode ver todas as milestones clicando aqui. Através delas podemos marcar pull requests e issues que estão vinculadas gerando automaticamente uma visão de progresso e toda a produção feita durante o curso sobre o tema abordado na milestone.

Segurança

Não coloque dados sensíveis no repositório como:

• Senhas;
• Dados de credenciais (usuário e senha);
• Dados de acesso (como chaves de API, chaves SSH);

Quando algum dado sensível de saída (output) for gerado no Terraform declare como sensitive = true, as instruções para implementar essa funcionalidade estão aqui.

Os logs gerados pela execução dos workflows pelo GitHub Actions são retidos por 15 dias. Caso você suspeite ou tenha certeza que algum dado sensível foi exposto nos logs do workflow:

1. Copie o link da execução do workflow (exemplo: https://github.com/cloud-journey/gcp-class-1/actions/runs/1131192182);
2. Se possível, tire um print da(s) parte(s) do log onde ocorreu a exposição;
3. Envie o link, os prints se possível, explicando o ocorrido para o dono do repositório (https://github.com/vflopes) pelo Discord ou por e-mail.

Termos de Uso e Conduta

• Utilize comunicação objetiva e cordial;
• Não utilize esse repositório para projetos pessoais;
• Não utilize esse repositório para conteúdos que não são exclusivamente relacionados ao curso;
• Não será tolerada nenhuma forma de discriminação, ofensa ou qualquer outro tipo de manifestação que possa diminuir, prejudicar ou ofender qualquer pessoa, situações dessa natureza estão sujeitas aos termos da lei vigente;
• Todas as pessoas participando desse curso declaram-se cientes de que os dados gerados e concedidos durante o mesmo são de uso público;

gcp-class-1's Issues

Vamos então aprender sobre nuvem? ☁️

Olá pessoal! Tudo bem com vocês?

Primeiramente quero agradecer pela oportunidade de ajudá-los e ajudá-las a aprender, estudar e aplicar conceitos e práticas sobre computação, plataformas e provedores na nuvem. Nesse curso vocês trilharão o próprio caminho até o conhecimento, individualizando assim a forma e velocidade que cada pessoa aprende, mas ainda sim, mantendo a colaboratividade como facilitadora na aquisição de novos conhecimentos. Estou aqui para dar todo o suporte e apoio necessário para que esse caminho seja incrível. ⭐️

Então para começar vou pedir alguns favores para todas as pessoas listadas como aprendizes do curso. Recomendo que antes da nossa primeira sessão todas as tarefas abaixo sejam feitas:

• Ler o README.md do repositório para entender seu funcionamento e preparar todos os requisitos listados;
• Mandar uma mensagem no Discord assim: Olá! Meu nome é [nome completo], meu usuário no GitHub é [seu username no GitHub] e meu ID de aprendiz é [ID de aprendiz]. Isso vai me ajudar a colocar todas as pessoas que farão o curso no time do GitHub que dá acessos de colaboração nesse repositório;

Simples não? 😉

Aguardo vocês para nossa primeira sessão de aprendizado! ❤️️

[session-3] Visão geral sobre os recursos básicos de redes

O contexto de redes na nuvem

Antes de falar um pouco mais sobre redes na nuvem, vamos falar um pouco de redes e como essa parte da tecnologia se desenvolveu para suportar as operações de grandes volumes de indicadores de conectividade como acontece hoje em dia nas clouds. A rede de comunicação de dispositivos, ou rede de computadores, ou de forma encurtada, rede (redes no plural) são uma forma de comunicação de dispositivos e aplicações para compartilhar recursos, recursos esses normalmente disponibilizados em "nós" na própria rede.

Para que essa comunicação ocorra de forma íntegra, eficiente e segura, esses dispositivos e aplicações implementam regras de protocolos para comunicação, definindo assim a forma de transmissão e interpretação dos dados que trafegam pela rede. Exemplo de protocolos: HTTP(S), gRPC, OpenAPI, QUIC, TLS, UDP, TCP, ICMP, IP. Claro, estamos aqui falando de vários protocolos que estão contidos em diferentes camadas do modelo OSI.

Como isso tudo é implementado?

Estamos falando de muitos detalhes de implementação de cada arquitetura para redes e se formos para o campo das soluções de segurança, armazenamento e distribuição de capacidade computacional com otimização para aplicações com tecnologias específicas, uma pergunta surge: como fazer tudo isso fisicamente? Ou seja, qual a operação envolvendo hardware para isso tudo ser viável?

Uma das respostas é que começamos a virtualizar dispositivos de redes e começamos então a gerenciar a implementação de arquitetura, engenharia e operação de redes através de software, como abordagens como SDN e NFV.

Entender como os avanços em redes possibilitaram a escala que a nuvem alcançou é muito importante, afinal, um dos recursos que mais falamos sobre é a VPC, que em sua tradução de Virtual Private Cloud é Nuvem Privada Virtual.

Como tornamos uma rede no Google Cloud funcional?

Primeiramente criamos uma VPC Network (VPC somente ou Network somente, tem o mesmo significado). Em seguida criamos as subredes nessa VPC onde o siginificado dependerá da topologia adotada para comunicação entre os nós, das regras de segurança e segregação de redes e também da distribuição física (localizações e regiões).

Lembre-se, uma VPC no Google é um recurso global, uma subnet (subnetwork ou subrede) é um recurso regional. É importante falar também do firewall logo no início, afinal, segurança é um assunto que nunca se deixa para depois. No GCP, o firewall está diretamente relacionado com uma VPC de forma também global.

É importante também definir as rotas que direcionarão o tráfego através dos endereços de origem e destino dos pacotes.

A partir desse momento as operações de provisionamento e configuração dependem dos requerimentos da arquitetura que está sendo implementada.

Uma pausa para conceitos importantes

Você sabe o que é taxonomia e convenção de nomenclatura (nesse link tem um exemplo do que o Google utiliza para as APIs de sua nuvem)? Com esses dois conceitos conseguimos criar critérios para nomenclatura dos recursos que estamos provisionando na nuvem. Lembre-se: o segredo de uma boa implementação de padronização é a consistência.

Um desafio para as equipes

1. Cada equipe criará uma documentação com base nas questões listadas, as questões bônus são opcionais;
2. A pessoa que está como guia deverá então criar uma branch WIP com o seguinte formato: WIP/nome_da_equipe/session-3;
3. Nessa branch a equipe deverá criar uma pasta docs/ no repositório e nela um arquivo session-3.md;
4. No ponto em que a equipe considera finalizado uma pessoa deverá comentar nessa issue com o nome da branch WIP;

👾 Então para as perguntas do desafio:

• Q1. Qual o padrão de nomenclatura devemos adotar para nomear os recursos de redes que serão provisionados?
• Q2. Quais são as vantagens e funcionalidades de uma SDN?
• Q3. Quais são os tipos de regras de firewall e o que cada tipo impacta na VPC?
• 🚀 Pergunta Bônus B1: O que é um NAT Gateway e quais as vantagens do serviço Cloud NAT do Google?
• 🚀 Pergunta Bônus B2: Quais são os tipos de endereço de IP (externos e internos) que o Google Cloud disponibiliza e qual a diferença de cada um?
• 🚀 Pergunta Bônus B3: Quais os serviços o Google tem para promover segurança para VPC?

Nesse arquivo estruture um conteúdo para que como uma boa documentação, objetiva e simples, responde as dúvidas acima para alguém que está aprendendo.

Feedback da sessão

Dê uma reação com os emojis para ajudar na melhoria contínua do curso:

• 🎉 Está incrível!
• ❤️️ Está muito legal!
• 👍 Está legal.
• 👎 Não gostei ou não consegui acompanhar.

[session-4] Criando uma máquina bastion na nuvem

Arquitetura

Vamos então finalmente construir o código e automações para uma infraestrutura com máquinas virtuais no GCP. Basicamente o que teremos um cliente com um par de chaves (pública e privada) para se autenticar em uma máquina virtual. Para isso o Firewall da VPC precisa de uma regra que permita o tráfego da internet para a porta 22 em instâncias onde a interface de redes tenha a tag ssh. Atente-se para no desenho os nomes que possuem {leaner_id} devem ser substituídos dinâmicamente pelo seu ID de aprendiz (o arquivo variables.tf tem uma variável que carrega esse valor).

                       ┌──────────────────────────────────────────────────────────────────────────────────┐
                       │                                                                                  │
                       │  vpc-{learner_id}                                                                │
                       │                                                                                  │
                       │ ┌─────────────────────────────┐   ┌────────────────────────────────────────────┐ │
                       │ │                             │   │ subnet-us-west2-bastion                    │ │
                       │ │     firewall                │   │                                            │ │
                       │ │                             │   │ CIDR: 10.20.30.0/28                        │ │
                       │ │                             │   │   ┌─────────────────────────────────────┐  │ │
                       │ │                             │   │   │ bastion-vm-{learner_id}             │  │ │
                       │ │                             │   │   │                                     │  │ │
                       │ │                             │   │   │  Can IP Forward: yes                │  │ │
┌──────────────┐       │ │                             │   │   │  OS: Debian 10 (buster)             │  │ │
│              │       │ │                             │   │   │  Intance type: e2-micro             │  │ │
│ SSH key pair │       │ │                             │   │   ├───────────────────────────────────┐ │  │ │
│              │       │ ├─────────────────────────────┤   │   │ Network Interface Card (NIC)      │ │  │ │
├──────────────┤       │ │ source: 0.0.0.0/0           │   │   │                                   │ │  │ │
│              │       │ │ destination tag: ssh        │ SSH   │ Must have a public ephemeral IP   │ │  │ │
│    Client    ├───────┼─► allowed: tcp on port 22     ├───┬───► Must have a private IP            │ │  │ │
│              │       │ │                             │   │   │                                   │ │  │ │
└──────────────┘       │ ├─────────────────────────────┤   │   ├───────────────────────────────────┘ │  │ │
                       │ │                             │   │   │                                     │  │ │
                       │ │                             │   │   └─────────────────────────────────────┘  │ │
                       │ │                             │   │                                            │ │
                       │ └─────────────────────────────┘   └────────────────────────────────────────────┘ │
                       │                                                                                  │
                       └──────────────────────────────────────────────────────────────────────────────────┘

Especificações

• firewall
  • Regra de firewall que permita todo o tráfego da internet para instâncias com a tag ssh na porta 22 e protocolo TCP;
• subnet-us-west-2-bastion
  • CIDR: 10.20.30.0/28;
  • Região: us-west2;
• bastion-vm-{learner_id}
  • Deve ter IP privado na subnet acima e IP público efêmero;
  • Deve poder fazer forward para outros endereços na rede (doc do google, atributo can_ip_forward do recurso no terraform);
  • Sistema Operacional: Debian 10 (buster);
  • Tamanho do Disco: 30GB;
  • Tipo da Instância: e2-micro;
  • Deve ter tag de rede ssh para permitir conexões de sockets TCP na porta 22;
  • Deve aceitar assinaturas da chave pública que você gerou (pergunta no stackoverflow de como adicionar chaves ssh em uma instância com terraform);

💡 Dica

Você pode achar vários módulos para Terraform aqui.

👾 Um desafio para as equipes

Precisamos de um código no Terraform que provisione a infraestrutura para a arquitetura apresentada acima, respeitando as configurações de rede e firewall para que eu possa realizar o acesso SSH. Preciso também gerar um par de chaves SSH para acessar minha instância e configurar a instância para aceitar minha conexão.

Existem dois caminhos possíveis para implementar essa arquitetura com Terraform.

1. 🎁 Utilizando módulos prontos da comunidade

Quando encontramos uma demanda para implementar alguma arquitetura na nuvem utilizando ferramentas de automação e provisionamento de infraestrutura a primeira coisa que normalmente fazemos é pesquisar se já existem implementações que são usadas por outras pessoas, equipes e comunidades. A comunidade de Terraform produz muitos módulos que facilitam bastante a implementação de arquiteturas de uso comum seguindo padrões de boas práticas. Uma dica interessante é entender como o módulo foi construído, lendo o código que está no repositório. Você verá que os módulos são apenas códigos de configuração Terraform.

Para esse desafio, recomendo o uso dos módulos abaixo:

• https://github.com/terraform-google-modules/terraform-google-network para implementar toda a parte de rede e firewall;
• https://github.com/terraform-google-modules/terraform-google-vm para implementar a VM;

2. 📦 Escrevendo os próprios módulos de Terraform

Você também pode optar por escrever seus próprios módulos e código utilizando os recursos de cada provedor (provider) do terraform. No caso estamos utilizando o provider para o google. Na própria documentação da Hashicorp sobre Terraform também é explicado e detalhado como a composição e desenvolvimento de módulos é feita. Pense que nesse caminho, você está optando por construir a arquitetura como código utilizando APIs de mais baixo nível, ou componentes mais primários como data e resource.

Para esse desafio recomendo a leitura sobre os seguintes recursos:

• https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_subnetwork
• https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_firewall
• https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_address
• https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_instance

Recursos adicionais podem ser necessários, utilize a própria documentação do provider para buscá-los.

🏅 Para isso vamos às regras do desafio:

• Devemos utilizar o Terraform;
• Cada equipe criará sua branch nesse repositório a partir da branch main (dica: git checkout main && git pull origin main && git checkout -b WIP/minha-equipe/session-4);
• A equipe terminar o desenvolvimento do desafio, uma pessoa da equipe deve avisar nessa issue;
• Ao concluir a solução, cada aprendiz da equipe deve abrir um Pull Request para puxar as alterações da branch WIP/minha-equipe/session-4 para a branch com o ID de aprendiz de quem está criando o PR;

📀 O que é esperado de resultado do desafio:

1. Que a arquitetura seja implementada utilizando o caminho 1 ou 2 nesse repositório;
2. Nas variáveis de entrada para a execução do Terraform deverá ter uma variável que aceita a chave pública SSH que será usada pelo servidor SSH na VM para autenticar as conexões dos usuários;
3. Que um PR seja aberto da branch de trabalho da equipe para a branch de aprendiz de cada pessoa da equipe;

🚀 Bônus (se for possível entregar, a solução fica mais completa)

1. Alguns recursos possuem um atribulo labels, padronizar as labels (que são um conjunto de chave-valores) documentando
2. Um arquivo /outputs.tf que retorna o IP público e o IP privado da VM recém-criada;
3. Um script de inicialização na máquina configurado pelo Terraform que instale o Docker;
4. Uma pasta docs/ no repositório e nela um arquivo session-4.md com a explicação do que é um "bastion";

Feedback da sessão

Dê uma reação com os emojis para ajudar na melhoria contínua do curso:

• 🎉 Está incrível!
• ❤️️ Está muito legal!
• 👍 Está legal.
• 👎 Não gostei ou não consegui acompanhar.

[session-1] Formando as equipes e aprofundando nos conceitos sobre nuvem

Formação de equipes

As equipes serão formadas por grupos de 5 pessoas com a seguinte metodologia:

1. A pessoa guia pegará a tabela de aprendizes do README.md da branch main;
2. Então utilizará o serviço https://www.random.org/lists/ para randomizar a lista;
3. Da lista randomizada serão formadas equipes a cada 5 aprendizes de cima para baixo;
4. Ao final caso o número de pessoas seja menor do que 5, cada uma será distribuida por uma equipe de cima para baixo;
5. Todas as pessoas então deverão entrar no grupo do Discord que quem guia especificar;
6. Essa pessoa enviará um convite para se tornar sua amiga e poder criar os grupos das equipes;
7. Aceite o convite de amizade 😊;
8. Nos grupos agora vocês deverão definir dois nomes possíveis para a equipe utilizando esse site ou esse site, uma dica: caso encontre algum termo com mais de uma palavra, pegue somente uma palavra do termo para ser o nome da equipe;

📋 Os resultados deverão ser apresentados logo abaixo.

Aprendiz	ID	Username	Equipe
rodrigo.cassiano	AB8B	RodCas11	barf-in-barf
dante.mesquita	AA31	danteGroove	barf-in-barf
klelber.xavier	E855	betodoescher	barf-in-barf
marisa.cavalcanti	A709	MarisaMello	barf-in-barf
karla.nascimento	97F1	Karlaouros	barf-in-barf
jonatha.brassolatti	F33E	jbrasso	miranhas
fagner.carvalho	C08C	Fagner-Carvalho	miranhas
antonio.raposo	7329	antoniocarlosraposo	miranhas
claudemir.junior	B0AE	claudemirAvelino	miranhas
elton.ferreira	08C7	eltonbf	miranhas
ricson.sampaio	AC1C	RicsonSampaio	undervoid
thiago.castilho	FCF9	ThiCastilho	undervoid
tiago.alexandre	B675	tasale	undervoid
luiz.andrade	606B	Luizfvandrade	undervoid
luciano.torquato	CFA1	Ltorquato10	undervoid
dejair.santos	E4E4	dejair-tech	tabajaras
ricardo.baptista	4BF8	ribaptista	tabajaras
danielle.benites	3DF4	danibenites	tabajaras
anderson.damasceno	FE5A	Anderberserk	tabajaras
thomas.bispo	3A9D	thomasnakamura	tabajaras
paulo.carmo	09B0	PHCarmo	chamacocos
bruno.avelar	139D	AvelarB	chamacocos
phillipe.morais	A6F0	phillipe-morais	chamacocos
lucas.praxedes	5BC0	LucasPinheiroCarvalho	chamacocos
elton.luiz	F029	eltonpeixoto	chamacocos

O que a Cloud resolve e como?

Imagine que você começou uma empresa, com apenas um servidor na sua infraestrutura para suportar a demanda de usuários que você espera no pico do seu negócio. Então seu negócio cresce e a demanda se mantém dinâmica, com vales e picos de acessos de usuários. Você então desenvolve mais features, isso impacta mais uma vez no crescimento da sua infraestrutura.

Em um certo ponto dessa história de crescimento e suporte aos picos de demanda, você já tem uma infraestrutura gigantesca com distribuição de capacidade global ou regional e para atender as variações da sua demanda, você acaba mantendo uma capacidade de computação ociosa muito grande, o que em caso de ociosidade gera custos.

Mas perceba, existe uma capacidade ociosa de computação que seu negócio pode ou não precisar a qualquer momento (de forma preditiva ou não, por exemplo, numa campanha de marketing, ou em um movimento de redes sociais). E se ao além de falar de servidores, de operação de datacenter nós falarmos sobre o próprio gerenciamento da capacidade em serviços que toda essa infraestrutura possibilita? E se ao invés de distribuir as aplicações por servidores físicos, criássemos unidades lógicas de capacidade de computação?

Poderíamos inclusive criar produtos com esse recurso de gestão computacional e monetizá-los.

Essa nova perspectiva gera uma demanda por talvez o desenvolvimento de produtos de tecnologia, mas permite transformar capacidade ociosa em negócio tornando acessível fatores qualitativos e quantitativos da tecnologia e serviços que suportam a operação.

💬 Uma pausa para um conceito!

Faça um mapa mental de sobre o conceito de Time-sharing (Tempo Compartilhado), alguns links que podem ajudar:

• Meio confuso, mas deve-se ler como uma composição de conceitos: https://pt.wikipedia.org/wiki/Tempo_compartilhado
• Mais bem estruturado, porém em inglês: https://en.wikipedia.org/wiki/Time-sharing

As ferramentas recomendadas são o Whimsical, mindmeister e diagrams.net (antigo draw.io). Escolha a que se sentir mais confortável para

☁️ Voltando ao texto

Então agora que você viu na prática uma breve demonstração da economia de escala aplicada para uma solução tecnológica, vamos pular um pouco os conceitos históricos e falar um pouco dos provedores de nuvem.

Os provedores de nuvem (ou em inglês, cloud provider) é como a empresa que te fornece internet, só que o serviço que ela te fornece são serviços e produtos para computação em nuvem. Hoje no mercado, existem várias, muitas além das que normalmente conhecemos (aqui uma "pequena" lista), mas vamos falar de 3 e nesse curso apenas de uma para reduzir o escopo. As 3 são:

• AWS ou Amazon Web Services
• GCP ou Google Cloud
• Azure ou Microsoft Azure

E nesse curso vamos falar especificamente da Google Cloud. Ao longo do curso falaremos das diferenças entre elas, do negócio de cada uma, como a marca vinculada a cada empresa impacta na comunidade que normalmente utiliza aquele provedor e muito mais.

Um desafio para as equipes

1. Cada equipe deverá ler a página de visão geral sobre redes no GCP;
2. A pessoa que está como guia deverá então criar uma branch WIP com o seguinte formato: WIP/nome_da_equipe/session-1;
3. Nessa branch a equipe deverá criar uma pasta docs/ no repositório e nela um arquivo session-1.md;
4. Esse tipo de arquivo se chama Markdown e o trabalho da equipe deverá ser consolidado nele;
   1. Caso precise de um editor rápido de markdown, utilize: https://dillinger.io/
5. No ponto em que a equipe considera finalizado uma pessoa deverá comentar nessa issue com o nome da branch WIP;

👾 Então para as perguntas do desafio:

• Q1. O que é uma VPC no GCP?
• Q2. Quais são os componentes de uma VPC?
• Q3. Quais são os conceitos com um breve resumo sobre redes que devo me atentar ao pensar em uma VPC?
• Q4. Para o que uma VPC serve? Cite um exemplo.
• 🚀 Pergunta Bônus B1: Quanto custa ter uma VPC no GCP?
• 🚀 Pergunta Bônus B2: Quais são as opções para aumentar a segurança de uma VPC?
• 🚀 Pergunta Bônus B3: O que são endereços e intervalos de IP?

Nesse arquivo estruture um conteúdo para que como uma boa documentação, objetiva e simples, responde as dúvidas acima para alguém que está aprendendo.

Feedback da sessão

Dê uma reação com os emojis para ajudar na melhoria contínua do curso:

• 🎉 Está incrível!
• ❤️️ Está muito legal!
• 👍 Está legal.
• 👎 Não gostei ou não consegui acompanhar.

[session-2] Terraform, uma breve introdução

Terraform

O Terraform é uma ferramenta para provisionar recursos de infraestrutura orquestrando seus possíveis estados através de arquivos de configuração declarativos. A forma mais comum de usá-lo é como uma CLI. Exemplos:

terraform init # Executa rotinas de inicialização do estado, download de dependências em suas versões e etc
terraform validate # Valida somente os arquivos Terraform quanto a sintaxe e consistência da configuração
terraform plan # Cria o plano de mundaças
terraform apply # Executa as ações do plano de mudanças
terraform destroy # Destrói todos os recursos gerenciados pelo Terraform nessa configuração

Dica: todos esses comandos aceitam parâmetros, para ver quais são os parâmetros aceitos por cada você pode adicionar um -h ao comando ou entrar na página de referência dos comandos do Terraform. O exemplo abaixo é da saída após a execução do comando terraform plan -h:

Usage: terraform [global options] plan [options]

  Generates a speculative execution plan, showing what actions Terraform
  would take to apply the current configuration. This command will not
  actually perform the planned actions.

  You can optionally save the plan to a file, which you can then pass to
  the "apply" command to perform exactly the actions described in the plan.

Plan Customization Options:

  The following options customize how Terraform will produce its plan. You
  can also use these options when you run "terraform apply" without passing
  it a saved plan, in order to plan and apply in a single command.

  -destroy            Select the "destroy" planning mode, which creates a plan
                      to destroy all objects currently managed by this
                      Terraform configuration instead of the usual behavior.

  -refresh-only       Select the "refresh only" planning mode, which checks
                      whether remote objects still match the outcome of the
                      most recent Terraform apply but does not propose any
                      actions to undo any changes made outside of Terraform.

  -refresh=false      Skip checking for external changes to remote objects
                      while creating the plan. This can potentially make
                      planning faster, but at the expense of possibly planning
                      against a stale record of the remote system state.

  -replace=resource   Force replacement of a particular resource instance using
                      its resource address. If the plan would've normally
                      produced an update or no-op action for this instance,
                      Terraform will plan to replace it instead.

  -target=resource    Limit the planning operation to only the given module,
                      resource, or resource instance and all of its
                      dependencies. You can use this option multiple times to
                      include more than one object. This is for exceptional
                      use only.

  -var 'foo=bar'      Set a value for one of the input variables in the root
                      module of the configuration. Use this option more than
                      once to set more than one variable.

  -var-file=filename  Load variable values from the given file, in addition
                      to the default files terraform.tfvars and *.auto.tfvars.
                      Use this option more than once to include more than one
                      variables file.

Other Options:

  -compact-warnings   If Terraform produces any warnings that are not
                      accompanied by errors, shows them in a more compact form
                      that includes only the summary messages.

  -detailed-exitcode  Return detailed exit codes when the command exits. This
                      will change the meaning of exit codes to:
                      0 - Succeeded, diff is empty (no changes)
                      1 - Errored
                      2 - Succeeded, there is a diff

  -input=true         Ask for input for variables if not directly set.

  -lock=false         Don't hold a state lock during the operation. This is
                      dangerous if others might concurrently run commands
                      against the same workspace.

  -lock-timeout=0s    Duration to retry a state lock.

  -no-color           If specified, output won't contain any color.

  -out=path           Write a plan file to the given path. This can be used as
                      input to the "apply" command.

  -parallelism=n      Limit the number of concurrent operations. Defaults to 10.

  -state=statefile    A legacy option used for the local backend only. See the
                      local backend's documentation for more information.

Arquivos .tf e a HCL

Para escrever um arquivo Terraform que de forma declarativa que pode especificar:

• Variáveis de Entrada (variables): variáveis de entrada são como argumentos para funções.
• Saída de Valores (outputs): esses valores são como os valores de retorno da função
• Provedores (providers): adicionam suporte no Terraform para novos tipos de recursos e fontes de dados.
• Recursos (resources): os recursos são o elemento mais importante no Terraform. Cada bloco de recursos descreve um ou mais objetos de infraestrutura, como redes virtuais, VMs ou componentes de alto nível, como registros DNS.
• Fontes de dados (data sources): as fontes de dados permitem que o Terraform use informações definidas fora do Terraform, definidas por outra configuração separada do Terraform ou modificadas por funções.
• Módulos (modules): módulos são agrupadores e interfaces para vários recursos usados juntos.
• Configurações do Terraform e HCL (terraform): o bloco de configuração especial terraform é usado para configurar alguns comportamentos do próprio Terraform, como exigir uma versão mínima do Terraform para aplicar sua configuração.

Utilizamos uma linguagem desenvolvida pela Hashicorp chamada Hashicorp Configuration Language ou HCL.

Como o Terraform funciona?

Na própria página da documentação da Hashicorp um ótimo exemplo do workflow de trabalho com o terraform é explicado. O Terraform funciona gerenciando os plugins que aumentam suas funcionalidades por provedor, então quando você executa um terraform init esse processo de gerenciar e adquirir essas dependências já está abstraído. Esses plugins são responsáveis pela interação com a interface do provedor, no caso do Google Cloud, é a API do mesmo.

Cada plugin também define novos resources e data sources aceitos pelo Terraform declarados nos nossos arquivos de configuração com HCL. Esse arquivo então é executado, aplicando todas as funcionalidades como funções, condições e loops suportados pela linguagem. Isso gera um estado de saída. Esse estado de saída é comparado com o estado atual da infraestrutura e então é criado um plano de execução. É desse plano de execução inclusive que o Terraform nos dá uma previsão de quais mudanças serão aplicadas.

Uma coisa importante de se perceber é o que Terraform constrói um grafo de relação entre os recursos, ou seja, ele consegue entender se um recurso depende do outro pois algo deve ser criado depois de algo. Algumas vezes esse grafo não consegue ser inferido e temos opções de manualmente dizer quais são as relações de dependências (com o atributo depends_on).

A documentação oficial para os recursos (resources) e fontes de dados (data sources) para o provider google se encontra aqui.

Um exemplo de estrutura de repositório

Vamos exemplificar com a estrutura repositório para criar um arquivo num bucket na Google Cloud.

Estrutura de arquivos e pastas de repositório:

--|📄README.md
--|📄backend.tf # Arquivo para especificar onde o Terraform irá salvar o estado da infraestrutura.
--|📄terraform.tf # Arquivo para especificar providers e configurações do terraform.
--|📄main.tf # Para declarar estado dos recursos e módulo da infraestrutura.
--|📄variables.tf # Declaração de variáveis do terraform.
--|📄outputs.tf # Declaração de valores de saída do estado da infraestrutura.
--|📁modules
----|📁meu-modulo
------|📄README.md
------|📄main.tf
------|📄variables.tf
------|📄outputs.tf

Exemplo de /main.tf:

# Isso é um comentário em HCL
# Cria um arquivo em um bucket no GCS (Google Cloud Storage)
# Dica: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/storage_bucket_object
resource "google_storage_bucket_object" "learner_id_file" {
  name   = "gcp-class/1/${var.learner_id}"
  source = "./learner-id"
  bucket = "cloud-journey"
}

Exemplo de /terraform.tf:

# Especificamos parâmetros do terraform e provedores
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "3.79.0"
    }
    google-beta = {
      source  = "hashicorp/google-beta"
      version = "3.79.0"
    }
  }
}

provider "google" {
}

provider "google-beta" {
}

Exemplo de /backend.tf:

# Onde o terraform deve armazenar o estado da infraestrutura
terraform {
  backend "gcs" {
    bucket = "cloud-journey"
    prefix = "terraform-state/gcp-class-1"
  }
}

Exemplo de /variables.tf:

# Uma variável de entrada
# Dica: https://www.terraform.io/docs/language/values/variables.html#variable-definition-precedence
variable "learner_id" {
  type        = string
  description = "The learner four-characters identifier"
}

Exemplo de /outputs.tf:

# Um valor de saíde que depende do nosso resource
output "file_md5hash" {
  description = "Uploaded content md5 hash"
  value       = google_storage_bucket_object.learner_id_file.md5hash
}

👾 Um desafio para as equipes

Precisamos de uma solução na Google Cloud e ela vai precisar de uma rede!

Para isso vamos às regras do desafio:

• Devemos utilizar o Terraform;
• Cada equipe criará sua branch nesse repositório a partir da branch main (dica: git checkout main && git pull origin main && git checkout -b WIP/minha-equipe/session-2);
• A equipe terminar o desenvolvimento do desafio, uma pessoa da equipe deve avisar nessa issue;
• Ao concluir a solução, cada aprendiz da equipe deve abrir um Pull Request para puxar as alterações da branch WIP/minha-equipe/session-2 para a branch com o ID de aprendiz de quem está criando o PR;

📀 O que é esperado de resultado do desafio:

1. Que seja criado um recurso google_compute_network no arquivo /main.tf desse repositório;
2. Que cada campo desse recurso esteja apropriadamente explicado/documento como comentários no próprio arquivo /main.tf;
3. Que um PR seja aberto da branch de trabalho da equipe para a branch de aprendiz de cada pessoa da equipe;

🚀 Bônus (se for possível entregar, a solução fica mais completa)

1. No arquivo /variables.tf uma variável de entrada que é um tipo string que coloca um prefixo no nome da rede que é criada no /main.tf;
2. Um arquivo /outputs.tf que retorna o valor do atributo .id do recurso google_compute_network;

Feedback da sessão

Dê uma reação com os emojis para ajudar na melhoria contínua do curso:

• 🎉 Está incrível!
• ❤️️ Está muito legal!
• 👍 Está legal.
• 👎 Não gostei ou não consegui acompanhar.