Setup Project Kelompok

KoordinatorSebagian terujiArti badge ini

Panduan ini digunakan oleh pemegang akun Google Cloud Platform (GCP) yang mengelola Billing Account dan kredit pelatihan. Isinya menjelaskan satu project kelompok dari pembuatan sampai penyiapannya untuk peserta, beserta alasan di balik setiap pilihan.

Skema operasional yang berlaku sekarang memakai tiga project per akun master dengan empat peserta per project, dan seluruh pekerjaan batch itu ada pada panduan batch peserta. Pakai panduan ini saat kamu perlu memahami atau mengerjakan satu project saja: pembuatan project, penautan billing, API bersama, urutan perintahnya, dan pembongkaran di akhir.

Skema ini ditujukan untuk kelompok pelatihan yang saling percaya. Peserta mendapat role luas pada project kelompok sehingga mereka dapat melihat dan mengubah resource peserta lain. Jangan memakai skema ini pada project produksi.

Status pengujian

Bagian yang sudah diuji dengan satu email dan satu project:

1. Pembuatan project dan penautan Billing Account.
2. Pengaktifan API bersama.
3. Pemberian role IAM kepada satu email.
4. Pembuatan resource bersama: firewall, Artifact Registry, dan budget alert.

Bagian yang belum diuji dan menjadi tugas bersama:

1. Undangan beberapa email peserta ke satu project yang sama.
2. Pemberian sembilan role kepada beberapa email sekaligus.
3. Pembuatan beberapa GitHub connection dalam satu project.
4. Pemeriksaan bahwa role IAM tidak saling menimpa antar peserta.

Catat hasil setiap langkah pada workbook asisten trainer.

Pembagian tiga project sekaligus, impor peserta dari CSV, dan peserta susulan ada pada panduan batch peserta.

Hasil akhir yang diharapkan

Setelah panduan ini selesai:

1. Satu project kelompok terhubung ke Billing Account penyelenggara.
2. Peserta menerima sembilan role yang dibutuhkan, sebanyak jumlah email yang diundang.
3. API, firewall, Artifact Registry, dan budget alert tersedia sebagai resource bersama.
4. Setiap peserta mempunyai identitas penamaan yang unik untuk VM, Service Account, GitHub connection, trigger, image, alamat IP, dan slug.
5. Satu Billing Account menangani paling banyak tiga project kelompok. Setiap project kelompok menampung paling banyak empat peserta, sehingga kapasitas satu akun adalah dua belas peserta.

1. Struktur project kelompok

Kredit berada pada Billing Account dan dipakai bersama oleh semua project yang terhubung. Asisten tidak menerima role pada Billing Account.

Billing Account Arkabumi
│
├── geoportal-kelompok-a-xxxxx        Peserta A01–A04
├── geoportal-kelompok-b-xxxxx        Peserta B01–B04
└── geoportal-kelompok-c-xxxxx        Peserta C01–C04

Skema operasional ini menetapkan paling banyak tiga project kelompok untuk satu akun, dengan paling banyak empat peserta per project. Jadi kapasitas satu akun adalah dua belas peserta, bukan lima belas seperti rancangan awal.

Angka empat peserta itu bukan pilihan sembarang. Kuota alamat IP publik adalah empat per region, sehingga satu project hanya dapat menjalankan empat VM ber-IP publik pada satu region. Project kelima tidak akan dapat dibuat VM-nya tanpa memindahkan sebagian peserta ke region lain.

Batas tiga project berbayar berasal dari hasil pengujian Billing Account yang dipakai, bukan batas umum seluruh akun GCP.

2. Siapkan nilai project

Buka Cloud Shell memakai akun master, lalu tentukan nilai berikut:

Cloud Shell akun master

PROJECT_ID="geoportal-kelompok-a-xxxxx"
PROJECT_NAME="Geoportal Kelompok A"
BILLING_ACCOUNT_ID="ISI_BILLING_ACCOUNT_ID"
REGION="asia-southeast2"
ZONE="asia-southeast2-b"

Untuk project kelompok baru, gunakan suffix acak agar Project ID unik secara global:

Cloud Shell akun master

SUFFIX="$(openssl rand -hex 3 | cut -c1-5)"
PROJECT_ID="geoportal-kelompok-b-${SUFFIX}"
echo "$PROJECT_ID"

Project ID tidak dapat diganti setelah project dibuat. Simpan Project ID final dalam catatan operasional penyelenggara.

2.1 Periksa slot billing yang tersisa

Batasnya tiga project berbayar per Billing Account, dan project bawaan ikut dihitung. Periksa sebelum membuat project baru:

Cloud Shell akun master

gcloud billing projects list --billing-account="$BILLING_ACCOUNT_ID"

Kalau daftarnya sudah berisi tiga project, lepas salah satunya lebih dahulu, atau tukar tautannya ke Billing Account lain:

Cloud Shell akun master

# Melepas tautan mematikan seluruh isi project itu.
gcloud billing projects unlink "PROJECT_ID"

# Atau pindahkan ke Billing Account lain tanpa mematikan apa pun.
gcloud billing projects link "PROJECT_ID" \
  --billing-account="BILLING_ACCOUNT_LAIN"

Slot yang bebas setelah langkah ini menentukan berapa project kelompok yang masih boleh ditautkan. Caranya membebaskan slot untuk batch berikutnya ada pada panduan batch peserta bagian 2.1.

Untuk akun master baru yang perlu membuat ketiga project kelompok sekaligus beserta penautan billing, label, API, dan resource bersamanya, pakai panduan batch peserta bagian 2.3.

3. Buat project dan hubungkan billing

Lewati perintah pembuatan jika project sudah tersedia.

Cloud Shell akun master

gcloud projects create "$PROJECT_ID" \
  --name="$PROJECT_NAME"

gcloud billing projects link "$PROJECT_ID" \
  --billing-account="$BILLING_ACCOUNT_ID"

gcloud config set project "$PROJECT_ID"

Periksa status billing:

Cloud Shell akun master

gcloud billing projects describe "$PROJECT_ID"

Nilai billingEnabled harus true sebelum resource berbayar dibuat.

4. Aktifkan API sebagai resource bersama

API cukup diaktifkan satu kali pada setiap project kelompok. Asisten tidak perlu mengulangi langkah ini.

Cloud Shell akun master

gcloud services enable \
  compute.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  iap.googleapis.com \
  dns.googleapis.com \
  domains.googleapis.com \
  secretmanager.googleapis.com

Periksa hasilnya:

Cloud Shell akun master

gcloud services list --enabled \
  --filter="config.name:(compute.googleapis.com OR cloudbuild.googleapis.com OR artifactregistry.googleapis.com OR iap.googleapis.com OR dns.googleapis.com OR domains.googleapis.com OR secretmanager.googleapis.com)" \
  --format="value(config.name)"

5. Berikan IAM kepada empat peserta

Contoh mapping Project Kelompok A untuk empat peserta:

Kode	Email	Slug resource
A01	asisten01@example.com	nama01
A02	asisten02@example.com	nama02
A03	asisten03@example.com	nama03
A04	asisten04@example.com	nama04

Nama asisten01@example.com sampai asisten04@example.com adalah contoh. Alamat email asli peserta tidak disimpan di repo ini; daftar yang sebenarnya ada pada spreadsheet operasional penyelenggara.

Jalankan binding dari akun master:

Cloud Shell akun master

PROJECT_ID="geoportal-kelompok-a-xxxxx"

PARTICIPANTS=(
  "asisten01@example.com"
  "asisten02@example.com"
  "asisten03@example.com"
  "asisten04@example.com"
)

ROLES=(
  roles/editor
  roles/resourcemanager.projectIamAdmin
  roles/serviceusage.serviceUsageAdmin
  roles/iam.serviceAccountAdmin
  roles/iam.serviceAccountUser
  roles/compute.osAdminLogin
  roles/iap.tunnelResourceAccessor
  roles/cloudbuild.connectionAdmin
  roles/logging.viewer
)

for EMAIL in "${PARTICIPANTS[@]}"; do
  for ROLE in "${ROLES[@]}"; do
    gcloud projects add-iam-policy-binding "$PROJECT_ID" \
      --member="user:$EMAIL" \
      --role="$ROLE" \
      --condition=None \
      --quiet
  done
done

--condition=None mencegah prompt interaktif ketika policy sudah memiliki binding bersyarat dari Cloud Build.

Daftar role yang berlaku ada pada panduan batch peserta bagian 5.1. Blok ROLES di halaman ini adalah salinan untuk pekerjaan satu project, dan salinan itu hanya sah selama isinya sama dengan sumber di sana. Kalau berbeda, sumber di panduan batch yang berlaku. Untuk memasang role ke seluruh peserta tiga project sekaligus, termasuk membacanya dari berkas CSV, pakai panduan batch itu.

Fungsi setiap role

Role	Fungsi dalam pelatihan
roles/editor	Membuat dan mengelola sebagian besar resource project.
roles/resourcemanager.projectIamAdmin	Memberikan role deployment kepada Service Account, dan mengerjakan langkah IAM pada Modul 5.4.
roles/serviceusage.serviceUsageAdmin	Mengaktifkan API jika ada API yang terlewat.
roles/iam.serviceAccountAdmin	Membuat dan mengelola Service Account deployment.
roles/iam.serviceAccountUser	Memakai Service Account pada VM dan trigger.
roles/compute.osAdminLogin	Login administratif ke VM melalui OS Login.
roles/iap.tunnelResourceAccessor	Membuka SSH melalui Identity-Aware Proxy (IAP).
roles/cloudbuild.connectionAdmin	Membuat GitHub connection dan linked repository.
roles/logging.viewer	Membaca log Cloud Build saat build gagal.

roles/domains.admin dan roles/dns.admin sudah tidak diberikan kepada peserta sejak 16 September 2026. Alasan lengkapnya ada pada panduan batch peserta bagian 5. Ringkasnya: pelatihan memakai subdomain dari domain milik instruktur, sehingga Cloud DNS per project tidak dipakai, dan roles/domains.admin memungkinkan peserta membeli domain atas nama Billing Account penyelenggara.

roles/resourcemanager.projectIamAdmin dan roles/editor memberi akses luas. Peserta dapat mengubah resource peserta lain dalam project yang sama. Skema ini diterima untuk pelatihan terkontrol, tetapi pemilik akun tetap perlu memantau perubahan.

Akses luas dalam project kelompok

Gunakan skema ini hanya untuk kelompok pelatihan yang saling percaya. Jangan gunakan project yang sama untuk beban kerja produksi atau data rahasia.

6. Siapkan akses GitHub connection

Langkah ini menangani satu project. Untuk ketiga project kelompok sekaligus, blok siap pakai ada di panduan batch peserta bagian 4.2.

Cloud Build menyimpan token GitHub di Secret Manager. Buat identitas layanan Cloud Build, lalu berikan akses sementara kepada Cloud Build Service Agent:

Cloud Shell akun master

gcloud beta services identity create \
  --service=cloudbuild.googleapis.com \
  --project="$PROJECT_ID"

PROJECT_NUMBER="$(gcloud projects describe "$PROJECT_ID" \
  --format="value(projectNumber)")"

CLOUD_BUILD_SERVICE_AGENT="service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com"

gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:$CLOUD_BUILD_SERVICE_AGENT" \
  --role="roles/secretmanager.admin" \
  --condition=None

Biarkan role ini tersedia selama keempat peserta membuat GitHub connection. Setelah semua connection berstatus COMPLETE, cabut kembali:

Cloud Shell akun master

gcloud projects remove-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:$CLOUD_BUILD_SERVICE_AGENT" \
  --role="roles/secretmanager.admin" \
  --condition=None

7. Buat resource bersama project

Artifact Registry, firewall, dan network tag dipakai bersama. Jangan meminta setiap peserta membuat resource ini karena nama yang sama akan menghasilkan error ALREADY_EXISTS.

Artifact Registry

Cloud Shell akun master

gcloud artifacts repositories create katalog-images \
  --repository-format=docker \
  --location="$REGION" \
  --description="Docker image bersama pelatihan WebGIS"

Firewall HTTP dan HTTPS

Cloud Shell akun master

gcloud compute firewall-rules create allow-webgis-http \
  --network=default \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=webgis-http

Firewall SSH melalui IAP

Cloud Shell akun master

gcloud compute firewall-rules create allow-webgis-iap-ssh \
  --network=default \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --target-tags=webgis-iap-ssh

8. Tetapkan pola nama unik

Peserta boleh memakai nama sendiri selama slug memakai huruf kecil, angka, atau tanda hubung dan tidak sama dengan peserta lain di dalam project yang sama.

Empat peserta memakai slug yang berbeda. Kolom contoh di bawah memakai pola namaNN, tetapi peserta boleh memilih nama sendiri selama tetap unik dan tidak lebih dari 18 karakter.

Nama VM, static IP, dan Service Account wajib unik di dalam satu project. DNS zone tidak lagi memakai slug peserta, karena pelatihan ini memakai subdomain dari domain milik instruktur.

Resource	A01	A02	A03	A04
Region	asia-southeast2	asia-southeast2	asia-southeast2	asia-southeast2
Zone	asia-southeast2-b	asia-southeast2-b	asia-southeast2-b	asia-southeast2-b
GitHub connection	github-nama01	github-nama02	github-nama03	github-nama04
Linked repository	repo-nama01	repo-nama02	repo-nama03	repo-nama04
Trigger	deploy-nama01	deploy-nama02	deploy-nama03	deploy-nama04
Service Account	cb-deployer-nama01	cb-deployer-nama02	cb-deployer-nama03	cb-deployer-nama04
VM	webgis-nama01	webgis-nama02	webgis-nama03	webgis-nama04
Image	nextjs-nama01	nextjs-nama02	nextjs-nama03	nextjs-nama04
Static IP	webgis-ip-nama01	webgis-ip-nama02	webgis-ip-nama03	webgis-ip-nama04
Uptime check	portal-webgis-nama01	portal-webgis-nama02	portal-webgis-nama03	portal-webgis-nama04
Alert policy	Portal webgis-nama01 tidak tersedia	Portal webgis-nama02 tidak tersedia	Portal webgis-nama03 tidak tersedia	Portal webgis-nama04 tidak tersedia
Notification channel	Email webgis-nama01	Email webgis-nama02	Email webgis-nama03	Email webgis-nama04

Keempat peserta boleh memakai region yang sama, berbeda dari skema lima asisten yang dipakai pada pengujian sebelumnya. Alasannya: kuota alamat IPv4 publik dihitung per project per region, bukan per akun, jadi empat peserta dalam satu project tetap berada di dalam batas empat alamat pada asia-southeast2. Peserta kelima pada project yang sama adalah yang tidak lagi dapat memakai alamat IP publik di region itu.

Nama Static IP mengikuti pola webgis-ip-SLUG yang dipakai panduan deployment, jadi kalau seorang peserta memilih slug pribadi, nama Static IP-nya ikut menyesuaikan.

Path /opt/webgis/app, Docker Compose project app, Artifact Registry katalog-images, dan network tag boleh sama karena setiap peserta memakai VM yang berbeda.

Monitoring juga harus unik

Tiga resource monitoring hidup di dalam project, bukan di dalam VM. Jadi walau VM setiap peserta terpisah, uptime check, alert policy, dan notification channel bisa tertukar kalau namanya tidak unik.

Nama bukan satu-satunya pengaman. Yang benar-benar memisahkan policy satu peserta dari yang lain adalah check_id di dalam filter, karena setiap uptime check punya ID sendiri:

metric.labels.check_id="portal-nama01-AbCdEfGhIjKl"

GCP menambahkan akhiran acak pada check_id, sehingga dua peserta tidak mungkin bertabrakan walaupun nama depannya sama. Karena itu, langkah yang paling menentukan saat membuat policy adalah menyalin check_id milik sendiri dari uptime list-configs, bukan mengetik ulang dari ingatan. Policy yang salah tempel check_id akan memantau portal orang lain, dan gejalanya baru terasa ketika peserta lain mematikan VM-nya.

Ada satu jebakan pada pola nama yang perlu dihindari: slug seorang peserta tidak boleh menjadi bagian dari slug peserta lain, bukan hanya awalan. Kalau ada nama1 dan nama01, filter displayName~'nama1' ikut menemukan milik nama01. Pilih slug yang tidak saling mengandung sejak awal, lalu jalankan perintah list dengan filter itu dan periksa hasilnya sebelum menghapus apa pun. Nama tidak dijaga unik oleh sistem, jadi verifikasi mata sendiri yang menjadi pengamannya.

Perintah berikut memakai filter supaya hanya menyentuh resource milik sendiri, dan aman dijalankan di project bersama. Ganti nama01 dengan slug peserta:

Cloud Shell peserta

SLUG="nama01"

gcloud monitoring uptime list-configs \
  --filter="displayName~'${SLUG}'" \
  --format="table(displayName,name,period)"

gcloud alpha monitoring policies list \
  --filter="displayName~'${SLUG}'" \
  --format="table(displayName,enabled)"

gcloud alpha monitoring channels list \
  --filter="displayName~'${SLUG}'" \
  --format="table(displayName,type,labels.email_address)"

Verifikasi ini sebaiknya dijalankan dua kali: sekali sebelum membuat policy, untuk memastikan tidak ada sisa milik sendiri, dan sekali lagi setelah selesai, untuk memastikan jumlahnya sesuai harapan dan tidak ada yang tertinggal.

9. Buat budget alert

Buat budget dari akun master melalui Billing, lalu Budgets & alerts. Gunakan konfigurasi berikut untuk project kelompok yang meliputi pembelian domain:

Pengaturan	Nilai
Jenis	Alerts only
Scope	Satu project kelompok
Periode	Monthly
Nominal	USD 75
Threshold aktual	50%, 80%, dan 100%
Threshold perkiraan	100% forecasted

Keluarkan promotional credits dari pilihan Savings jika pemilik akun ingin memantau biaya kotor sebelum kredit trial diterapkan. Budget alert hanya mengirim notifikasi. Alert tidak menghentikan VM, Cloud Build, pembelian domain, atau billing.

Budget tidak menghentikan layanan

Notifikasi budget adalah alat pemantauan. Akun master tetap harus menghentikan VM dan memeriksa Billing Reports secara berkala.

Tambahkan budget USD 250 pada seluruh Billing Account sebagai pengaman kedua. Nilai ini menyisakan ruang dari kredit awal USD 300, tetapi pemilik akun tetap harus memeriksa saldo kredit dan Billing Reports selama pelatihan.

10. Verifikasi sebelum diserahkan

Periksa billing, resource bersama, dan sembilan role setiap peserta:

Cloud Shell akun master

gcloud billing projects describe "$PROJECT_ID"

gcloud artifacts repositories describe katalog-images \
  --location="$REGION"

gcloud compute firewall-rules list \
  --filter="name:(allow-webgis-http OR allow-webgis-iap-ssh)"

for EMAIL in "${PARTICIPANTS[@]}"; do
  echo "IAM untuk $EMAIL"
  gcloud projects get-iam-policy "$PROJECT_ID" \
    --flatten="bindings[].members" \
    --filter="bindings.members=user:$EMAIL" \
    --format="value(bindings.role)" \
    | sort
done

Kirim informasi berikut kepada peserta:

Project ID: geoportal-kelompok-a-xxxxx
Region: asia-southeast2
Zone: asia-southeast2-b
Slug: nama01 sampai nama04, satu untuk setiap peserta
Subdomain: sesuai daftar terpusat penyelenggara
Artifact Registry bersama: katalog-images
App directory: /opt/webgis/app

Checklist sebelum sesi:

1. Billing project aktif.
2. Sembilan role tersedia untuk setiap email peserta.
3. API sudah aktif, termasuk iam.googleapis.com.
4. Artifact Registry dan dua firewall rule sudah tersedia.
5. Budget alert project dan Billing Account sudah aktif.
6. Kuota region cukup untuk empat VM e2-medium. Yang perlu diperiksa lebih dahulu adalah kuota IN_USE_ADDRESSES yang hanya empat alamat per region, karena kuota itulah yang membatasi jumlah peserta dalam satu project.
7. Setiap peserta menerima slug yang berbeda di dalam project ini. Slug yang sama di project lain tidak masalah.

Checkpoint akun master

Serahkan project kepada peserta hanya setelah billing aktif, seluruh API tersedia, dan sembilan role terlihat untuk setiap email.

11. Kendalikan biaya

Setiap peserta menghentikan VM miliknya setelah sesi:

Cloud Shell akun master

gcloud compute instances stop "webgis-NAMA" \
  --zone="asia-southeast2-b" \
  --project="$PROJECT_ID"

Disk dan alamat IP tertentu masih dapat menimbulkan biaya saat VM berhenti. Biaya compute VM berhenti berjalan setelah status instance menjadi TERMINATED.

12. Cabut akses setelah pelatihan

Gunakan daftar role yang sama seperti bagian 5:

Cloud Shell akun master

for EMAIL in "${PARTICIPANTS[@]}"; do
  for ROLE in "${ROLES[@]}"; do
    gcloud projects remove-iam-policy-binding "$PROJECT_ID" \
      --member="user:$EMAIL" \
      --role="$ROLE" \
      --condition=None \
      --quiet
  done
done

Periksa kembali policy sebelum project dipakai untuk kelompok berikutnya.

13. Bongkar project pengujian lama

Bagian ini dipakai saat satu project pengujian tidak diperlukan lagi dan seluruh isinya ingin dihapus, misalnya karena pengujian lama sudah selesai dan akan diganti dengan skema project kelompok.

Fork GitHub tidak ikut terhapus

Repository GitHub berdiri sendiri di luar project GCP. Menghapus VM, Service Account, atau seluruh project tidak menyentuh fork sama sekali. Commit dan berkas konfigurasi pada fork tetap aman, dan fork yang sama bisa dipakai ulang untuk project baru.

Langkah 1: Daftar semua yang akan dihapus

Jangan menghapus sebelum daftarnya dilihat. Jalankan dari Cloud Shell dengan akun pemilik project:

Cloud Shell project lama

PROJECT_ID="PROJECT_ID"
REGION="asia-southeast2"
ZONE="asia-southeast2-b"

gcloud config set project "$PROJECT_ID"

gcloud compute instances list
gcloud compute disks list
gcloud compute addresses list
gcloud artifacts repositories list --location="$REGION"
gcloud builds connections list --region="$REGION"
gcloud builds triggers list --region="$REGION"
gcloud iam service-accounts list
gcloud compute firewall-rules list
gcloud secrets list

Catat setiap nama yang muncul. Periksa juga apakah ada VM yang masih menyala, karena VM yang menyala tetap menagih biaya selama proses pembongkaran.

Langkah 2: Hentikan VM lebih dahulu

Cloud Shell project lama

gcloud compute instances stop NAMA_VM --zone="$ZONE"

Hentikan seluruh VM sebelum menghapus apa pun. Langkah ini menghentikan biaya compute paling besar lebih dahulu, sehingga sisa proses bisa dikerjakan tanpa terburu-buru.

Langkah 3: Hapus resource berbayar

Urutan ini penting. Hapus VM sebelum disk, karena disk tidak bisa dihapus saat masih terpasang.

Cloud Shell project lama

# VM beserta boot disk-nya
gcloud compute instances delete NAMA_VM \
  --zone="$ZONE" \
  --delete-disks=all \
  --quiet

# Static IP supaya tidak ditagih saat menganggur
gcloud compute addresses delete NAMA_STATIC_IP \
  --region="$REGION" \
  --quiet

# Disk sisa dari VM yang sudah tidak ada
gcloud compute disks delete NAMA_DISK \
  --zone="$ZONE" \
  --quiet

Ulangi untuk setiap VM dan disk yang tercatat pada langkah 1.

Langkah 4: Hapus resource pendukung

Cloud Shell project lama

# Image container, termasuk seluruh tag di dalamnya
gcloud artifacts repositories delete katalog-images \
  --location="$REGION" \
  --quiet

# Trigger sebelum connection, karena trigger memakai connection
gcloud builds triggers delete NAMA_TRIGGER --region="$REGION" --quiet
gcloud builds connections delete NAMA_CONNECTION --region="$REGION" --quiet

# Service Account deployment milik setiap peserta
gcloud iam service-accounts delete NAMA_SA@PROJECT_ID.iam.gserviceaccount.com --quiet

# Firewall bersama
gcloud compute firewall-rules delete allow-webgis-http allow-webgis-iap-ssh --quiet

Hapus trigger lebih dahulu daripada connection. Connection yang masih dipakai trigger akan menolak dihapus.

Langkah 5: Periksa sisa resource

Cloud Shell project lama

gcloud compute instances list
gcloud compute disks list
gcloud compute addresses list
gcloud artifacts repositories list --location="$REGION"
gcloud builds connections list --region="$REGION"
gcloud builds triggers list --region="$REGION"
gcloud iam service-accounts list
gcloud compute firewall-rules list

Seluruh perintah harus menghasilkan daftar kosong atau hanya berisi Service Account bawaan Compute Engine. Service Account default tidak perlu dihapus.

Langkah 6: Lepas billing

Setelah langkah 5 bersih, lepas Billing Account dari project supaya tidak ada lagi tagihan yang mungkin muncul, dan supaya slot tiga project berbayar itu kembali bebas:

Cloud Shell project lama

# Lihat keadaan sebelum dilepas.
gcloud billing projects describe "$PROJECT_ID" \
  --format="value(billingAccountName,billingEnabled)"

# Lepaskan tautannya.
gcloud billing projects unlink "$PROJECT_ID"

Melepas tautan billing mematikan seluruh isi project itu

gcloud billing projects unlink menghentikan semua resource dan layanan berbayar di project tersebut: VM berhenti, API mati, aplikasinya tidak jalan. Biaya yang sudah terjadi tetap ditagihkan ke Billing Account lama.

Jalankan langkah ini hanya setelah langkah 5 bersih, dan hanya untuk project yang memang tidak dipakai lagi. Kalau project-nya masih dipakai, pindahkan tautannya ke Billing Account lain dengan gcloud billing projects link, karena perintah itu menggantikan tautan lama tanpa mematikan apa pun.

Slot billing kembali bebas setelah langkah ini. Batas tiga project berbayar dihitung per Billing Account, jadi melepas satu project berarti satu project baru boleh ditautkan. Itu sebabnya project bawaan atau project pengujian harus dilepas sebelum batch berikutnya ditautkan.

Periksa Billing Reports sebelum melupakan project ini

Mematikan billing menghentikan tagihan baru, tetapi tidak membatalkan tagihan yang sudah berjalan. Buka Billing lalu Reports dan pastikan tidak ada biaya yang masih tercatat untuk project lama pada beberapa hari berikutnya.

Langkah 7: Pilihan lain, hapus project sekaligus

Kalau seluruh isi project memang tidak diperlukan lagi dan project-nya bukan bagian dari skema tiga project kelompok, menghapus project lebih singkat daripada menghapus resource satu per satu:

Cloud Shell project lama

gcloud projects delete "$PROJECT_ID"

Penghapusan project bersifat sementara selama 30 hari. Selama masa itu project bisa dipulihkan, tetapi seluruh resource di dalamnya sudah tidak berjalan dan tidak ditagih. Setelah 30 hari project hilang permanen.

Jangan memakai cara ini untuk project kelompok yang masih akan dipakai pelatihan.

14. Status script lama

Script create-project-peserta.sh membuat satu project untuk setiap email. Script tersebut disimpan sebagai catatan pendekatan awal, tetapi tidak dipakai pada skema satu project untuk empat peserta. Gunakan langkah pada panduan ini untuk membuat Project Kelompok B dan Project Kelompok C.