5 "Aha!" Momentos com o Google Cloud Platform

Google Developers em Google Developers Follow Mar 27 · 9 min ler

Postado por: Jerome Poudevigne, arquiteto de inicialização, Google Cloud

Ao longo dos últimos dois anos, ajudei um bom número de empresas, grandes e pequenas, a migrar seus sistemas para o Google Cloud Platform (também conhecido como GCP). No decorrer dessas migrações, há sempre alguns desses momentos em que as pessoas visualizam um recurso específico do Google Cloud e dizem: "agora, isso é legal!".

Na maioria das vezes, é porque, vindo de outras plataformas, eles se acostumaram com alguns recursos que exigem várias etapas, ou algumas operações sendo complicadas, etc. E muitas vezes eles descobrem que no GCP você pode fazer essa operação específica em um par cliques ou configurando uma configuração simples baseada em texto. Então você vê aquela lâmpada acendendo em sua cabeça, e lá vai você … cliente feliz.

Algumas delas acontecem com tanta frequência que eu as compilei em uma lista para compartilhar com outras pessoas que também poderiam se beneficiar desses momentos “aha!”. Você poderia dizer que estas são as cinco coisas que gostaria de me contar quando comecei a usar o Google Cloud.

1- Projetos: naturalmente agrupar recursos juntos.

Um projeto é um namespace onde os recursos vivem. Todo recurso que você instancia no GCP, de balanceadores de carga a clusters do Kubernetes a máquinas virtuais, pertence a um único projeto e não tem acesso (por padrão) a recursos de outros projetos. As funções e autorizações do usuário podem ser definidas por projeto e gotejar até tudo nele. Isso tem dois benefícios imediatos: você pode agrupar coisas que estão juntas em unidades lógicas, e as que não pertencem juntas são isoladas umas das outras (e isolamento é uma coisa boa)

Isto é poderoso e bastante simples, mas muitas vezes leva novos usuários desprevenidos. Muitos clientes me ligaram e me perguntaram “Como posso ter certeza de que meus desenvolvedores não podem acessar as máquinas de produção? Qual é a melhor maneira de criar políticas de acesso? "

A resposta para isso é realmente super simples:

  • ter um projeto para desenvolvimento onde seus desenvolvedores tenham direitos,
  • tem um projeto para produção onde eles não.
  • É isso aí.

Toda máquina / outro recurso no projeto de produção não estará acessível aos desenvolvedores.

Claro que há muito mais, e você pode refinar papéis e permissões em um grau muito maior usando Organizações , Pastas , etc. Sem mencionar todas as coisas malucas que você pode fazer com o faturamento por projeto. Mas pelo menos você pode dizer “ei, se é uma máquina no ambiente de teste, então ela pode ser encontrada no projeto de“ encenação ””.

2- Redes virtuais globais que são * verdadeiramente * globais

Imagine que você esteja usando um provedor de nuvem e que você tenha servidores nos EUA e servidores em Cingapura e que eles precisem se comunicar.

Assim, você cria uma rede VPC (Virtual Private Cloud) no data center dos EUA, outra no datacenter de Cingapura e, em seguida, conecta-os configurando o emparelhamento VPC entre regiões ou uma VPN (Virtual Private Network) ou um sistema de trânsito. VPC ou outra mágica de roteamento.

Muito trabalho, certo? E muitas partes móveis, muitas oportunidades para as coisas se quebrarem.

Com o GCP, no entanto, o que faz meus clientes serem “aha!” É quando eles percebem que no GCP uma única rede VPC cobre todo o planeta. Somente sub-redes estão conectadas a uma localização geográfica e as máquinas virtuais se comunicam entre sub-redes em IPs privados (bons endereços RFC1918 antigos) – não é necessário roteamento extra.

Assim, para tornar seu servidor uma comunicação entre continentes no GCP, veja as etapas:

  • criar uma rede VPC
  • crie uma sub-rede nos EUA, coloque seus servidores nos EUA
  • crie uma sub-rede em Cingapura, coloque seus servidores de Cingapura nela

Isso é tudo que existe para isso. Sua rede VPC abrangendo 2 continentes está pronta para uso. Abaixo está uma imagem da minha conta, para uma rede VPC chamada 'my-global-network' com 2 sub-redes. A primeira coluna ("us-central1" e "asia-southeast1") contém o nome das regiões do GCP (leia-se: datacenters). A segunda coluna é o nome da sub-rede que escolhi quando as criei.

Uma rede que abrange os EUA e Singapura

Uma máquina nos EUA (na sub-rede “us-central”) com IP 10.0.0.5 pode se comunicar diretamente com uma máquina na sub-rede de Singapura (no “singapore”) com o IP 10.10.0.8 .

Nada mais para configurar.

E, graças à maneira como essas redes funcionam, o Google Cloud Load Balancer pode apresentar um único IP para o mundo e encaminhar o tráfego para as instâncias mais próximas geograficamente sem precisar configurar um enfadonho balanceamento de carga baseado em DNS. Mas isso vale um blog inteiro. Vou guardar para outro dia.

3- Firewalls com tags e (quase) sem endereços IP

Não há segurança de rede sem um firewall, portanto, sem surpresa, o GCP vem com um embutido.

Agora, eu não sei sobre você, mas nada faz meu cérebro doer como uma lista de regras de firewall exibindo intervalos IP e endereços e diretivas 'Permitir / negar'. Parece um pouco assim:

Um conjunto de regras de firewall baseadas em IP

Se você imaginar uma rede normal com algumas dúzias de servidores, poderá ver rapidamente como isso pode ficar fora de controle. É melhor que você tenha uma impressão sólida do layout da sua rede para se referir quando você começar a adicionar e alterar as regras. E boa sorte depurando as coisas!

Não seria legal se, em vez disso, você pudesse simplesmente dizer ao firewall: “o tráfego HTTP vindo de fora só pode alcançar os servidores HTTP e o banco de dados MySQL só pode ser acessado pelo (s) servidor (es) HTTP na mesma rede?”

Acontece que é muito simples no GCP usando uma pequena coisa chamada tags de rede. Como a documentação diz:

Tags de rede são atributos de texto que você pode adicionar às instâncias de máquina virtual (VM) do Compute Engine. As tags permitem que você crie regras de firewall e rotas aplicáveis a instâncias de VMs específicas. "

Então vamos ver como funciona. As regras de firewall no GCP são definidas em termos de origem e destino (o tráfego flui da origem para o destino). Você pode definir regras de filtragem que se aplicam à origem ou ao destino e, em ambos os casos, pode usar tags.

Isso é mais simples mostrado com um exemplo. A regra abaixo afirma que na rede default , o tráfego para as VMs com a tag mysql-server pode vir das VMs com a tag http-appserver . Qualquer outro tráfego é "Negar" -ed por padrão.

Tudo o que você precisa fazer é marcar suas máquinas corretamente e elas serão automaticamente cobertas pela regra. Você não precisa inserir seu intervalo de IP.

Isso é legal se você me perguntar. Isso torna muito mais simples entender o que está acontecendo.

É claro que há mais TON para firewalls no GCP. Tags também se aplicam a rotas e você pode misturar e combinar regras baseadas em IP com regras baseadas em tags. Sem mencionar essa coisa chamada contas de serviço, mas vou deixar isso para outro dia.

A linha inferior é que você pode criar a maioria das regras apenas expressando uma necessidade de negócios e não ter que se lembrar de layouts de rede complicados. Eu não tenho estatísticas difíceis, mas tenho certeza que isso me salvou horas de trabalho.

4- Acesso ao console para máquinas virtuais a partir do navegador

Acessar facilmente máquinas virtuais (VMs) do console do Google Cloud foi um dos meus primeiros momentos de "aha!" Quando comecei a usar o GCP.

Esta é uma captura de tela do meu console do Google Cloud, com uma máquina virtual e seu IP interno.

A última coluna tem um cabeçalho que diz “Conectar” e quando você clica na palavra “SSH” aparece uma janela separada. Você espera por alguns segundos e… é isso que você recebe. Seu acesso pessoal ao shell – em um navegador, não menos.

Você está conectado por meio do ssh à máquina virtual de sua escolha. Você não precisa baixar as chaves ssh e colocá-las no ~/.ssh directory , fazer o comando chmod correto e executar um longo ssh -i ~/.ssh/somekey me@<it-took-me-forever-to-copy-paste-the-address-here>

Além disso, você tem acesso a alguns recursos interessantes, como o upload e o download de arquivos, a alteração do usuário, etc. Basta usar o menu atrás do ícone da engrenagem no canto superior direito.

Na verdade, você não precisa se conectar diretamente com frequência, mas quando precisa, isso é uma dádiva de Deus.

5- Seu jumphost pessoal no console do Google Cloud

O console do Google Cloud tem um truque legal: você pode se conectar a um ambiente virtual gerenciado pelo próprio console do Google Cloud. Ele serve um pouco como um host de salto. Você pode acessar a maioria dos recursos dos projetos a partir dele e ativá-lo diretamente no menu superior com nenhuma configuração específica ao seu lado. É chamado de Cloud Shell.

É assim que fica no canto superior direito do console:

Quando você ativa o Cloud Shell, a sessão é aberta na parte inferior do console. Você recebe um prompt de linha de comando e ele está totalmente configurado com a ferramenta de linha de comando gcloud (o recurso de todos os negócios do Google Cloud scripting).

Você pode fazer muitas coisas a partir daí, e isso inclui até mesmo fazer o upload e o download de arquivos, editar código ou implantá-lo, uma visualização da Web para seu aplicativo do AppEngine e muito mais .

Assim, você pode obter acesso a um ambiente de shell totalmente configurado em seu projeto a partir de qualquer laptop onde possa se conectar com suas credenciais. Além disso, ele persiste entre as conexões, para que você possa ajustá-lo às suas necessidades e disponibilizá-las na próxima vez em que se reconectar.

Isso me salvou muitas vezes durante minha vida anterior como consultor itinerante!

6- Migração ao vivo

Eu disse 5 momentos "Aha!" Bem, você foi paciente lendo todo o caminho até aqui, então aqui está mais um de graça.

O Google Cloud tem uma maneira incrível de "teletransportar" literalmente uma máquina virtual em execução entre hosts físicos sem interrompê-la. É chamado Migração ao Vivo . Ele permite que o Google mova sua máquina virtual para longe de um host defeituoso, ou de um host que precise de um patch ou de uma atualização, ou por qualquer outro motivo relacionado à infraestrutura.

Tudo é feito em segundo plano e é totalmente transparente, então você nunca realmente vê isso acontecendo . A menos que você olhe muito de perto. Certa vez, fiz uma demonstração para um cliente, em que uma máquina foi migrada ao vivo enquanto ele simulava uma carga de rede sólida – e não perdíamos um único pacote, sem degradação perceptível na latência.

E isso é um envoltório!

Então você vai. Estas são 5 + 1 coisas que me fizeram “Aha!” Quando me familiarizei mais com o Google Cloud Platform e que ainda fazem meus clientes fazerem o mesmo.

Há muita profundidade na plataforma, e meus exemplos acima apenas arranham a superfície de nossos recursos. Encorajo-vos a experimentar você mesmo. Há um nível gratuito generoso e, quando você estiver pronto para mergulhar e criar essa nova empresa, entre em contato no Google Cloud for Startups . Nós vamos colocá-lo em funcionamento em pouco tempo.

Jerome é arquiteto de inicialização do Google Cloud. Com sede em Cingapura, ele ajuda as startups a aproveitar ao máximo o Google Cloud Platform.