Marco/ RyotaPortfólio pessoal

Curitiba, Brasil

GitHub
Todas as notas

NOTAS DE ESTUDO

Google Cloud Platform (GCP) – Fundamentos

Google Cloud Platform (GCP) – Fundamentos

Estas notas resumem conceitos centrais do Google Cloud, com foco em hierarquia de recursos, IAM e Cloud Storage. Baseiam-se nos estudos práticos pelo Google Cloud Skills Boost e servem como documentação do portfólio.

1. Hierarquia de recursos Google Cloud

O GCP organiza recursos hierarquicamente, permitindo governança centralizada, herança de políticas e controle de acesso escalável.

Níveis da hierarquia

  1. Organização, nível 04:
    • Contêiner de nível superior.
    • Representa uma empresa ou instituição.
    • Pastas, projetos e recursos pertencem à organização.
  2. Pasta, nível 03:
    • Agrupa projetos logicamente.
    • Suporta subpastas.
    • Permite aplicar políticas entre os níveis da organização e dos projetos.
  3. Projeto, nível 02:
    • Unidade principal de organização de recursos e cobrança.
    • Recursos GCP são criados dentro de projetos.
    • Vários projetos podem pertencer à mesma pasta ou organização.
  4. Recursos, nível 01:
    • Serviços e componentes de nuvem propriamente ditos.
    • Exemplos: VMs Compute Engine, buckets Cloud Storage e tabelas BigQuery.

Herança de políticas

  • Políticas podem ser aplicadas na organização, pasta, projeto ou, em alguns casos, diretamente no recurso.
  • A herança ocorre de cima para baixo.
  • Uma política em nível superior afeta os recursos inferiores, salvo substituição explícita, conforme descrito no material estudado.

2. Projetos no Google Cloud

Cada projeto possui três identificadores.

ID do projeto

  • Globalmente único.
  • Atribuído durante a criação; pode ser definido pelo usuário nessa etapa.
  • Imutável depois da criação.

Nome do projeto

  • Não precisa ser único.
  • Escolhido pelo usuário.
  • Pode ser alterado.

Número do projeto

  • Globalmente único.
  • Atribuído pelo Google Cloud.
  • Imutável.
  • Usado internamente pelas APIs GCP.

3. Resource Manager

  • A API Resource Manager permite gerenciar organizações, pastas e projetos por código.
  • Casos comuns:
    • Automatizar a criação de projetos.
    • Gerenciar estruturas hierárquicas.
    • Aplicar e auditar políticas IAM.

4. Pastas

  • Oferecem granularidade flexível para políticas.
  • Permitem agrupar projetos por equipe, ambiente ou unidade de negócio.
  • Facilitam a aplicação consistente de políticas IAM e de organização.
  • São úteis para governança sem aplicar todas as políticas globalmente.

5. Identity and Access Management (IAM)

IAM define quem pode fazer o quê em quais recursos.

Identidades IAM

Políticas podem ser aplicadas a contas Google, grupos Google, contas de serviço e domínios Cloud Identity.

Papéis e permissões

  • Permissões representam ações individuais, como compute.instances.start.
  • Papéis reúnem conjuntos de permissões.

Papéis básicos no projeto

  • Owner: acesso completo aos recursos, com gerenciamento de papéis IAM e cobrança.
  • Editor: cria, altera e exclui recursos, mas não gerencia papéis IAM.
  • Viewer: acesso somente de leitura.
  • Billing Administrator: gerencia contas e configurações de cobrança, sem alterar recursos do projeto.

Papéis básicos são abrangentes e geralmente não são recomendados para controle de acesso granular.

Papéis predefinidos

  • Específicos de serviços e gerenciados pelo Google Cloud.
  • Projetados para acesso com menor privilégio.
  • Exemplos: Compute Engine Admin e Storage Object Viewer.

A maioria das organizações prefere papéis predefinidos para reduzir riscos de segurança.

6. Google Cloud Storage (GCS)

Visão geral

  • Armazenamento de objetos durável e altamente disponível.
  • Projetado para dados não estruturados e grandes objetos binários, BLOBs.

Modelo de objetos

  • Dados são armazenados como objetos, em vez de arquivos e diretórios.
  • Cada objeto reúne dados, metadados e um identificador único.

Casos de uso

  • Arquivamento e recuperação de desastres.
  • Distribuição de mídia, como vídeos e imagens.
  • Armazenamento de backups.
  • Armazenamento intermediário em pipelines de processamento.

Buckets

  • Objetos são armazenados em buckets.
  • Os nomes dos buckets precisam ser globalmente únicos.
  • O bucket é criado em uma localização geográfica:
    • Região, como southamerica-east1.
    • Multirregião.
  • Uma localização próxima dos usuários reduz a latência.

Imutabilidade e versionamento

  • Objetos são imutáveis; atualizações criam novas versões.
  • É possível sobrescrever versões anteriores ou preservá-las para auditoria e recuperação.

Controle de acesso

  • Gerenciado por papéis IAM, recomendados, ou ACLs quando necessárias.
  • O menor privilégio garante que cada usuário acesse somente o necessário.

Ciclo de vida

  • Regras automatizam a transição entre classes de armazenamento e a exclusão de objetos após um prazo definido.

7. Classes de armazenamento

  • Standard: dados acessados frequentemente.
  • Nearline: dados acessados com pouca frequência, aproximadamente uma vez por mês.
  • Coldline: acesso no máximo uma vez a cada 90 dias.
  • Archive: opção de menor custo, adequada a arquivamento de longo prazo, backups e recuperação de desastres.