Blog/08
Architektura

Google Cloud Platform krok po kroku: jak zacząć, co wybrać i czego unikać na starcie

8 min czytania

GCP to potężna platforma z wyjątkowymi możliwościami w obszarze danych, AI i Kubernetes - ale ma swoją specyfikę, która może zaskoczyć osoby przyzwyczajone do AWS lub Azure.

Google Cloud Platform zajmuje trzecie miejsce na rynku chmury publicznej, ale w kilku obszarach nie ma sobie równych: BigQuery (analityka danych), Vertex AI (uczenie maszynowe), GKE (zarządzany Kubernetes) i sieć szkieletowa Google. Jeśli Twoja firma pracuje z dużymi zbiorami danych lub planuje projekty ML/AI - GCP jest warte poważnego rozważenia.

Struktura kont i projektów w GCP

Pierwsza różnica, którą zauważysz po AWS: w GCP nie ma kont IAM jako głównej jednostki organizacyjnej. Zamiast tego masz hierarchię: Organizacja → Foldery → Projekty → Zasoby.

  • Organizacja - powiązana z domeną Google Workspace lub Cloud Identity. Jeden punkt zarządzania politykami dla całej firmy
  • Foldery - opcjonalne grupowanie projektów (np. per środowisko, per dział)
  • Projekt - podstawowa jednostka rozliczeniowa i izolacji zasobów. Każdy zasób w GCP należy do dokładnie jednego projektu

Zalecana struktura na start: osobny projekt dla każdego środowiska (production, staging, dev) i jeden projekt dla zasobów współdzielonych (sieć VPC, artifact registry, monitoring).

IAM w GCP - co różni go od AWS

GCP używa koncepcji ról. Trzy typy:

  • Basic roles - Owner, Editor, Viewer. Bardzo szerokie - unikaj ich na produkcji
  • Predefined roles - granularne role per usługa (np. roles/storage.objectViewer). To powinieneś używać
  • Custom roles - tworzysz sam z wybranych uprawnień. Dla szczególnych przypadków

Ważna różnica od AWS: w GCP uprawnienia dziedziczą się w dół hierarchii. Rola nadana na poziomie organizacji obowiązuje we wszystkich projektach.

Pierwsze kroki - co skonfigurować przed wdrożeniem czegokolwiek

1. Cloud Identity lub Google Workspace

Zanim cokolwiek zrobisz - skonfiguruj organizację GCP powiązaną z domeną firmową. Logowanie kontami Gmail (@gmail.com) na produkcji to poważne ryzyko bezpieczeństwa.

2. Billing Budgets i alerty

Ustaw budżet z alertami zanim poniesiesz pierwsze koszty. GCP pozwala ustawić automatyczne wyłączenie usług po przekroczeniu budżetu (Budget Actions).

# Włącz billing export do BigQuery gcloud services enable bigquerydatatransfer.googleapis.com gcloud beta billing export bigquery enable \ --billing-account=BILLING_ACCOUNT_ID \ --project=PROJECT_ID \ --dataset-id=billing_export

3. Organization Policy Service

Odpowiednik AWS Service Control Policies. Pozwala wymusić zasady na poziomie organizacji: brak publicznych adresów IP, dozwolone regiony, wymagane etykiety (labels). Skonfiguruj przed pierwszymi wdrożeniami.

4. VPC w trybie Custom mode

GCP ma dwa tryby VPC: Auto mode (subnety tworzone automatycznie - wygodne, ale trudniejsze do kontroli) i Custom mode (tworzysz subnety ręcznie - zalecane dla produkcji). Używaj Custom mode i planuj przestrzeń adresową z wyprzedzeniem.

Usługi, od których warto zacząć

  • Cloud Run - serverless kontenery. Płacisz tylko za czas obsługi requestów. Idealne dla API i mikroserwisów bez stałego ruchu
  • Cloud SQL - zarządzane bazy danych (PostgreSQL, MySQL, SQL Server). Odpowiednik AWS RDS
  • GKE Autopilot - zarządzany Kubernetes, gdzie Google zarządza węzłami. Prostszy niż standardowy GKE
  • Cloud Storage - odpowiednik S3 z czterema klasami: Standard (częsty dostęp), Nearline (rzadziej niż raz w miesiącu), Coldline (rzadziej niż raz na kwartał), Archive (rzadziej niż raz w roku). Ważne: wszystkie klasy zapewniają dostęp z opóźnieniem rzędu milisekund - Archive nie wymaga przywracania ani oczekiwania
  • Artifact Registry - prywatne repozytorium obrazów Docker i paczek (zastąpił stary Container Registry, wyłączony 18.03.2025)

Czego unikać na początku

  • Compute Engine z domyślną siecią - domyślna sieć VPC ma otwarte reguły firewall. Usuń ją i stwórz własną od zera
  • Konta serwisowe z rolą Editor - jedna z najczęstszych pomyłek. Konto serwisowe aplikacji powinno mieć tylko to, czego potrzebuje
  • Klucze kont serwisowych jako pliki JSON - GCP zaleca Workload Identity Federation zamiast pobierania kluczy JSON. Klucze JSON to statyczne poświadczenia, które łatwo zgubić lub wykraść
  • Brak etykiet (labels) na zasobach - bez etykiet nie wiesz, który projekt lub środowisko generuje koszty. Dodaj labeling od pierwszego dnia
💡

Ważna różnica od AWS S3: Cloud Storage Archive nie wymaga żadnego przywracania - dane są dostępne natychmiast, z opóźnieniem rzędu milisekund, tak samo jak w warstwie Standard. Różnica polega wyłącznie na cenie przechowywania i opłatach za odczyt.

Zaczynasz z GCP lub migrujesz z innej chmury?

Pomożemy zaplanować architekturę od początku. Zacznij od Cloud Checku.

PoprzedniDevSecOps z GitLabem: jak wbudować bezpieczeństwo w pipeline CI/CD zamiast doklejać je na końcu