Wymagania wstępne¶
Zanim zaczniesz, musisz mieć dostęp do kilku zewnętrznych serwisów i lokalnie zainstalowane narzędzia. Ten rozdział jest krótki — wróć do niego gdy napotkasz błąd "command not found".
Konta zewnętrzne¶
| Serwis | Wymagane | Po co |
|---|---|---|
| Google Cloud | Konto z billing account | Projekt GCP, wszystkie zasoby |
| GitHub | Konto + org lub user | Repo, Actions, Secrets |
| Cloudflare | Konto z domeną | CDN, SSL, DNS dla frontendu |
Billing account
Musisz mieć aktywne konto rozliczeniowe GCP. Free tier nie wystarczy — Cloud Run i API Gateway wymagają włączonego billing (nawet jeśli koszty są $0). Uruchom:
Jeśli puste — dodaj kartę w console.cloud.google.com/billing.Narzędzia lokalne¶
# Sprawdź co już masz
terraform version # wymaga >= 1.5.0
gcloud version # Google Cloud SDK
gh version # GitHub CLI
docker version # Docker Engine
git version
Instalacja (macOS)¶
Instalacja (Linux/Debian)¶
wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform
Konfiguracja lokalna¶
1. Uwierzytelnienie gcloud¶
- Application Default Credentials (ADC) — używane przez Terraform lokalnie. Bez tego
terraform planzwróci błąd autentykacji.
2. GitHub CLI¶
3. Weryfikacja uprawnień GCP¶
Potrzebujesz uprawnień na poziomie organizacji (do tworzenia projektów) lub przynajmniej prawa do tworzenia projektu w folderze.
Jeśli pusta — skontaktuj się z adminem GCP. Projekt możesz też tworzyć bez organizacji, ale stracisz hierarchię uprawnień.
Struktura repo¶
Po wykonaniu bootstrapu repo będzie wyglądać tak:
.
├── scripts/
│ ├── run.sh # entry point — generuje project ID i odpala bootstrap
│ ├── bob_budowniczy.sh # 7-etapowy idempotentny bootstrap
│ └── cleanup.sh # usuwa wszystko (nieodwracalne)
├── tf/
│ ├── bootstrap/ # WIF, Service Accounts — tylko lokalnie
│ ├── infra/ # VPC, subnet, firewall
│ ├── backend/ # Cloud Run, Artifact Registry
│ ├── auth/ # Identity Platform, Google SSO
│ ├── api-gateway/ # API Gateway, OpenAPI spec
│ ├── database/ # Firestore
│ ├── frontend/ # GCS buckets (prod + staging)
│ ├── frontend-lb/ # (opcjonalna) Google LB + CDN + Cloud Armor
│ └── monitoring/ # Cloud Monitoring dashboard + alerty
├── app/
│ ├── main.py # FastAPI backend
│ ├── test_main.py # 15 testów pytest
│ ├── requirements.txt
│ └── Dockerfile
├── frontend/
│ ├── index.html
│ └── app.js
├── .github/
│ └── workflows/
│ ├── deploy.yml # ręczny deploy TF (wszystkie warstwy)
│ ├── deploy-backend.yml # pytest → docker → Trivy → Cloud Run
│ ├── deploy-frontend.yml # auto-deploy po push do frontend/
│ ├── security.yml # pip-audit + Trivy + Checkov
│ └── release-please.yml # semantic versioning + auto-CHANGELOG
└── docs/
├── adr/ # Architecture Decision Records
└── guide/ # ten przewodnik
Warstwy Terraform
Każda warstwa (tf/<nazwa>/) ma własny stan Terraform w osobnym prefiksie GCS. Możesz deployować je niezależnie — zmiana w tf/frontend/ nie dotyka stanu tf/backend/. To kluczowa decyzja architektoniczna (separacja odpowiedzialności + bezpieczeństwo stanu).