CI/CD modern dengan GKE: Membangun sistem CI/CD


Arsitektur referensi ini memberi Anda metode dan infrastruktur awal untuk membangun sistem continuous integration/continuous delivery (CI/CD) yang modern menggunakan alat seperti Google Kubernetes Engine, Cloud Build, Skaffold, kustomize, Config Sync, Policy Controller, Artifact Registry, Artifact Registry

Dokumen ini adalah bagian dari rangkaian:

Dokumen ini ditujukan untuk arsitek perusahaan dan developer aplikasi, serta tim keamanan IT, DevOps, dan Site Reliability Engineering. Beberapa pengalaman dengan alat dan proses deployment otomatis berguna untuk memahami konsep dalam dokumen ini.

Alur kerja CI/CD

Untuk membangun sistem CI/CD modern, Anda harus terlebih dahulu memilih alat dan layanan yang menjalankan fungsi utama sistem. Arsitektur referensi ini berfokus pada penerapan fungsi inti dari sistem CI/CD yang ditunjukkan dalam diagram berikut:

Berbagai tim mengelola atau berbagi tanggung jawab atas sistem CI/CD.

Implementasi referensi ini menggunakan alat berikut untuk setiap komponen:

  • Untuk pengelolaan kode sumber: GitHub
    • Menyimpan kode aplikasi dan konfigurasi.
    • Memungkinkan Anda meninjau perubahan.
  • Untuk pengelolaan konfigurasi aplikasi: kustomize
    • Mendefinisikan konfigurasi aplikasi yang diinginkan.
    • Memungkinkan Anda menggunakan kembali dan memperluas primitif konfigurasi atau cetak biru.
  • Untuk continuous integration: Cloud Build
    • Menguji dan memvalidasi kode sumber.
    • Membangun artefak yang digunakan lingkungan deployment.
  • Untuk continuous delivery: Cloud Deploy
    • Mendefinisikan proses peluncuran kode di seluruh lingkungan.
    • Menyediakan rollback untuk perubahan yang gagal.
  • Untuk konfigurasi infrastruktur: Config Sync
    • Secara konsisten menerapkan konfigurasi cluster dan kebijakan.
  • Untuk penegakan kebijakan: Pengontrol Kebijakan
    • Menyediakan mekanisme yang dapat Anda gunakan untuk menentukan apa saja yang diizinkan untuk dijalankan di lingkungan tertentu berdasarkan kebijakan organisasi.
  • Untuk orkestrasi container: Google Kubernetes Engine
    • Menjalankan artefak yang dibangun selama CI.
    • Menyediakan metodologi penskalaan, health check, dan peluncuran untuk beban kerja.
  • Untuk artefak container: Artifact Registry
    • Menyimpan artefak (image container) yang dibangun selama CI.

Arsitektur

Bagian ini menjelaskan komponen CI/CD yang diimplementasikan menggunakan arsitektur referensi ini: infrastruktur, pipeline, repositori kode, dan zona landing.

Untuk diskusi umum tentang aspek-aspek sistem CI/CD ini, lihat CI/CD modern dengan GKE: Framework pengiriman software.

Varian Arsitektur Referensi

Arsitektur referensi memiliki dua model deployment:

  • Varian multi-project yang lebih mirip dengan deployment produksi dengan batas isolasi yang lebih baik
  • Varian proyek tunggal, yang berguna untuk demonstrasi

Arsitektur referensi multi-project

Versi multi-project dari arsitektur referensi menyimulasikan skenario seperti produksi. Dalam skenario ini, persona yang berbeda menciptakan infrastruktur, pipeline CI/CD, dan aplikasi dengan batas isolasi yang tepat. Persona atau tim ini hanya dapat mengakses resource yang diperlukan.

Untuk mengetahui informasi lebih lanjut, lihat CI/CD Modern dengan GKE: Framework pengiriman software.

Untuk mengetahui detail tentang cara menginstal dan menerapkan arsitektur referensi versi ini, lihat blueprint pengiriman software

Arsitektur referensi project tunggal

Versi single-project arsitektur referensi menunjukkan cara menyiapkan seluruh platform pengiriman software dalam satu project Google Cloud. Versi ini dapat membantu pengguna yang tidak memiliki peran IAM yang ditingkatkan untuk menginstal dan mencoba arsitektur referensi hanya dengan peran pemilik pada suatu project. Dokumen ini menunjukkan arsitektur referensi versi project tunggal.

Infrastruktur platform

Infrastruktur untuk arsitektur referensi ini terdiri dari cluster Kubernetes untuk mendukung lingkungan aplikasi pengembangan, staging, dan produksi. Diagram berikut menunjukkan tata letak logis cluster:

Tata letak cluster mendukung berbagai beban kerja platform.

Repositori kode

Dengan arsitektur referensi ini, Anda akan menyiapkan repositori untuk operator, developer, platform, dan engineer keamanan.

Diagram berikut menunjukkan implementasi arsitektur referensi dari berbagai repositori kode serta cara tim operasi, pengembangan, dan keamanan berinteraksi dengan repositori:

Repositori berisi hal-hal tersebut untuk praktik terbaik serta konfigurasi platform dan aplikasi.

Dalam alur kerja ini, operator Anda dapat mengelola praktik terbaik untuk CI/CD dan konfigurasi aplikasi di repositori operator. Saat developer mengaktivasi aplikasi di repositori pengembangan, mereka akan otomatis mendapatkan praktik terbaik, logika bisnis untuk aplikasi, dan konfigurasi khusus yang diperlukan agar aplikasi dapat beroperasi dengan benar. Sementara itu, tim operasi dan keamanan Anda dapat mengelola konsistensi dan keamanan platform dalam repositori kebijakan dan konfigurasi.

Zona landing aplikasi

Dalam arsitektur referensi ini, zona landing untuk aplikasi dibuat saat aplikasi disediakan. Dalam dokumen berikutnya dalam seri ini, Modern CI/CD with GKE: Apply the Developer Workflow, Anda akan menyediakan aplikasi baru yang membuat zona landingnya sendiri. Diagram berikut mengilustrasikan komponen penting dari zona landing yang digunakan dalam arsitektur referensi ini:

Cluster GKE mencakup tiga namespace untuk aplikasi yang berbeda.

Setiap namespace mencakup akun layanan yang digunakan untuk federasi identitas workload agar GKE dapat mengakses layanan di luar container Kubernetes, seperti Cloud Storage atau Spanner. Namespace ini juga mencakup resource lain seperti kebijakan jaringan untuk mengisolasi atau berbagi batas dengan namespace atau aplikasi lain.

Namespace ini dibuat oleh akun layanan eksekusi CD. Sebaiknya tim mengikuti prinsip hak istimewa terendah untuk membantu memastikan bahwa akun layanan eksekusi CD hanya dapat mengakses namespace yang diperlukan.

Anda dapat menentukan akses akun layanan di Config Sync dan menerapkannya menggunakan peran kontrol akses berbasis peran (RBAC) dan binding peran Kubernetes. Dengan model ini, tim dapat men-deploy resource apa pun langsung ke namespace yang mereka kelola, tetapi tidak akan menimpa atau menghapus resource dari namespace lain.

Tujuan

  • Men-deploy arsitektur referensi project tunggal.
  • Mempelajari repositori kode.
  • Pelajari pipeline dan infrastruktur.

Biaya

Dalam dokumen ini, Anda menggunakan komponen Google Cloud yang dapat ditagih berikut:

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga. Pengguna baru Google Cloud mungkin memenuhi syarat untuk mendapatkan uji coba gratis.

Setelah menyelesaikan tugas yang dijelaskan dalam dokumen ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk mengetahui informasi selengkapnya, lihat Pembersihan.

Sebelum memulai

  1. Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.

    Buka pemilih project

  2. Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.

  3. Di konsol Google Cloud, aktifkan Cloud Shell.

    Aktifkan Cloud Shell

Men-deploy arsitektur referensi

  1. Di Cloud Shell, tetapkan project:

    gcloud config set core/project PROJECT_ID
    

    Ganti PROJECT_ID dengan ID project Google Cloud Anda.

  2. Di Cloud Shell, clone repositori Git:

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
    cd software-delivery-blueprint/launch-scripts
    git checkout single-project-blueprint
    
  3. Buat token akses pribadi di GitHub dengan cakupan berikut:

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook
  4. Ada file kosong bernama vars.sh dalam folder software-delivery-bluprint/launch-scripts. Tambahkan teks berikut ke file:

    cat << EOF >vars.sh
    export INFRA_SETUP_REPO="gke-infrastructure-repo"
    export APP_SETUP_REPO="application-factory-repo"
    export GITHUB_USER=GITHUB_USER
    export TOKEN=TOKEN
    export GITHUB_ORG=GITHUB_ORG
    export REGION="us-central1"
    export SEC_REGION="us-west1"
    export TRIGGER_TYPE="webhook"
    EOF
    

    Ganti GITHUB_USER dengan nama pengguna GitHub.

    Ganti TOKEN dengan token akses pribadi GitHub.

    Ganti GITHUB_ORG dengan nama organisasi GitHub.

  5. Jalankan skrip bootstrap.sh. Jika Cloud Shell meminta Anda untuk melakukan otorisasi, klik Authorize:

    ./bootstrap.sh
    

    Skrip ini melakukan bootstrap pada platform pengiriman software.

Mempelajari repositori kode

Di bagian ini, Anda akan mempelajari repositori kode.

Login ke GitHub

  1. Di browser web, buka github.com dan login ke akun Anda.
  2. Klik ikon gambar di bagian atas antarmuka.
  3. Klik Organisasi Anda.
  4. Pilih organisasi yang Anda berikan sebagai input dalam file vars.sh.
  5. Klik tab Repositories.

Mempelajari repositori starter, operator, konfigurasi, dan infrastruktur

Repositori pemicu, operator, konfigurasi, dan infrastruktur adalah tempat operator dan administrator platform menentukan praktik terbaik umum untuk membangun dan mengoperasikan platform. Repositori ini dibuat di organisasi GitHub Anda saat arsitektur referensi di-bootstrap.

Setiap repositori dalam daftar menyertakan deskripsi singkat.

Repositori awal

Repositori awal membantu penerapan CI/CD, infrastruktur, dan praktik terbaik pengembangan di seluruh platform. Untuk mengetahui informasi selengkapnya, baca artikel CI/CD Modern dengan GKE: Framework pengiriman software

Repositori awal aplikasi

Dalam repositori awal aplikasi, operator Anda dapat mengodifikasi dan mendokumentasikan praktik terbaik seperti CI/CD, pengumpulan metrik, logging, langkah container, dan keamanan untuk aplikasi. Contoh repositori awal untuk aplikasi Go, Python, dan Java tercakup dalam arsitektur referensi.

Repositori awal aplikasi app-template-python, app-template-java, dan app-template-golang berisi kode boilerplate yang dapat Anda gunakan untuk membuat aplikasi baru. Selain membuat aplikasi baru, Anda dapat membuat template baru berdasarkan persyaratan aplikasi. Repositori awal aplikasi yang disediakan oleh arsitektur referensi berisi:

  • Dasar kustomize dan patch dalam folder k8s.

  • Kode sumber aplikasi.

  • Dockerfile yang menjelaskan cara membangun dan menjalankan aplikasi.

  • File cloudbuild.yaml yang menjelaskan praktik terbaik untuk langkah-langkah CI.

  • File skaffold.yaml yang menjelaskan langkah-langkah deployment.

Dalam dokumen berikutnya dalam seri ini, Modern CI/CD dengan GKE: Menerapkan alur kerja developer, Anda menggunakan repositori app-template-python untuk membuat aplikasi baru.

Repositori awal infrastruktur

Dalam repositori pemula infrastruktur, operator dan administrator infrastruktur Anda dapat mengodifikasi dan mendokumentasikan praktik terbaik seperti pipeline CI/CD, IaC, pengumpulan metrik, logging, dan keamanan untuk infrastruktur. Contoh repositori awal infrastruktur yang menggunakan Terraform juga disertakan dalam arsitektur referensi. Repositori awal infrastruktur infra-template berisi kode boilerplate untuk Terraform yang dapat Anda gunakan untuk membuat resource infrastruktur yang diperlukan aplikasi, seperti bucket Cloud Storage, database Spanner, atau lainnya.

Repositori template bersama

Dalam repositori template bersama, administrator dan operator infrastruktur menyediakan template standar untuk melakukan tugas. Ada repositori bernama terraform-modules yang disediakan dengan arsitektur referensi. Repositori menyertakan kode Terraform dengan template untuk membuat berbagai resource infrastruktur.

Repositori operator

Dalam arsitektur referensi, repositori operator sama dengan repositori awal aplikasi. Operator mengelola file yang diperlukan untuk CI dan CD di repositori starter aplikasi. Arsitektur referensi mencakup repositori app-template-python, app-template-java, dan app-template-golang.

  • Ini adalah template awal dan berisi manifes Kubernetes dasar untuk aplikasi yang berjalan di Kubernetes pada platform. Operator dapat memperbarui manifes di template awal sesuai kebutuhan. Update dipilih saat aplikasi dibuat.
  • File cloudbuild.yaml dan skaffold.yaml dalam repositori ini menyimpan praktik terbaik untuk menjalankan CI dan CD masing-masing di platform. Serupa dengan konfigurasi aplikasi, operator dapat memperbarui dan menambahkan langkah ke praktik terbaik. Masing-masing pipeline aplikasi dibuat menggunakan langkah-langkah terbaru.

Dalam implementasi referensi ini, operator menggunakan kustomize untuk mengelola konfigurasi dasar di folder k8s dari repositori awal. Kemudian, developer bebas memperluas manifes dengan perubahan khusus aplikasi, seperti nama resource dan file konfigurasi. Alat kustomize mendukung konfigurasi sebagai data. Dengan metodologi ini, input dan output kustomize merupakan resource Kubernetes. Anda dapat menggunakan output dari satu modifikasi manifes untuk modifikasi lainnya.

Diagram berikut mengilustrasikan konfigurasi dasar untuk aplikasi Spring Boot:

Konfigurasi aplikasi dibuat di beberapa repositori yang dikelola oleh tim terpisah.

Konfigurasi sebagai model data di kustomize memiliki manfaat besar: saat operator memperbarui konfigurasi dasar, pembaruan tersebut akan otomatis digunakan oleh pipeline deployment developer pada proses selanjutnya tanpa perubahan apa pun dari pihak developer.

Untuk mengetahui informasi selengkapnya tentang penggunaan kustomize untuk mengelola manifes Kubernetes, lihat dokumentasi kustomize.

Repositori konfigurasi dan kebijakan

Termasuk dalam arsitektur referensi adalah implementasi repositori konfigurasi dan kebijakan yang menggunakan Config Sync dan Pengontrol Kebijakan. Repositori acm-gke-infrastructure-repo berisi konfigurasi dan kebijakan yang Anda deploy di seluruh cluster lingkungan aplikasi. Konfigurasi yang ditentukan dan disimpan oleh admin platform dalam repositori ini penting untuk memastikan platform memiliki tampilan dan nuansa yang konsisten bagi tim operasi dan pengembangan.

Bagian berikut membahas cara arsitektur referensi menerapkan repositori kebijakan dan konfigurasi secara lebih mendetail.

Konfigurasi

Dalam implementasi referensi ini, Anda menggunakan Config Sync untuk mengelola konfigurasi cluster di platform secara terpusat dan menerapkan kebijakan. Pengelolaan terpusat memungkinkan Anda menerapkan perubahan konfigurasi ke seluruh sistem.

Dengan Config Sync, organisasi Anda dapat mendaftarkan cluster-nya untuk menyinkronkan konfigurasinya dari repositori Git, sebuah proses yang dikenal sebagai GitOps. Saat Anda menambahkan cluster baru, cluster akan otomatis disinkronkan ke konfigurasi terbaru dan terus merekonsiliasi status cluster dengan konfigurasi jika ada orang yang melakukan perubahan out-of-band.

Untuk mengetahui informasi lebih lanjut tentang Config Sync, lihat dokumentasinya.

Kebijakan

Dalam implementasi referensi ini, Anda menggunakan Pengontrol Kebijakan, yang didasarkan pada Agen Kebijakan Terbuka, untuk menangkap dan memvalidasi setiap permintaan ke cluster Kubernetes di platform. Anda dapat membuat kebijakan menggunakan Bahasa kebijakan Rego, yang memungkinkan Anda sepenuhnya mengontrol jenis resource yang dikirimkan ke cluster, tetapi juga konfigurasinya.

Arsitektur di diagram berikut menunjukkan alur permintaan untuk menggunakan Pengontrol Kebijakan guna membuat resource:

Aturan kebijakan pertama-tama ditentukan lalu diterapkan menggunakan berbagai alat, seperti klien kubectl dan API.

Anda membuat dan menetapkan aturan pada repositori Config Sync, dan perubahan ini akan diterapkan pada cluster. Setelah itu, permintaan resource baru dari klien CLI atau API akan divalidasi berdasarkan batasan oleh Pengontrol Kebijakan.

Untuk informasi selengkapnya tentang mengelola kebijakan, lihat ringkasan Pengontrol Kebijakan.

Repositori infrastruktur

Referensi tersebut mencakup implementasi repositori infrastruktur yang menggunakan Terraform. Repositori gke-infrastructure-repo berisi infrastruktur sebagai kode guna membuat cluster GKE untuk lingkungan pengembangan, staging, dan produksi serta mengonfigurasi Config Sync pada lingkungan tersebut menggunakan repositori acm-gke-infrastructure-repo. gke-infrastructure-repo berisi tiga cabang, satu untuk setiap lingkungan pengembangan, staging, dan produksi. Paket ini juga berisi folder dev, staging, dan production di setiap cabang.

Mempelajari pipeline dan infrastruktur

Arsitektur referensi membuat pipeline dalam project Google Cloud. Pipeline ini bertanggung jawab untuk menciptakan infrastruktur bersama.

Pipeline

Di bagian ini, Anda akan mempelajari pipeline infrastruktur sebagai kode dan menjalankannya untuk membuat infrastruktur bersama, termasuk cluster GKE. Pipeline adalah pemicu Cloud Build bernama create-infra di project Google Cloud yang ditautkan ke repositori infrastruktur gke-infrastructure-repo. Anda akan mengikuti metodologi GitOps untuk membuat infrastruktur seperti yang dijelaskan dalam Video Lingkungan GCP yang Dapat Diulang dalam Skala Besar dengan Pipeline Infra-As Kode Cloud Build.

gke-infrastructure-repo memiliki cabang dev, staging, dan produksi. Dalam repositori, ada juga folder dev, staging, dan production yang sesuai dengan cabang ini. Ada aturan perlindungan cabang pada repositori yang memastikan bahwa kode hanya dapat dikirim ke cabang dev. Untuk mengirim kode ke cabang staging dan production, Anda perlu membuat permintaan pull.

Biasanya, seseorang yang memiliki akses ke repositori akan meninjau perubahan, lalu menggabungkan permintaan pull untuk memastikan hanya perubahan yang diinginkan yang dipromosikan ke cabang yang lebih tinggi. Agar individu dapat mencoba cetak biru tersebut, aturan perlindungan cabang telah dilonggarkan di arsitektur referensi sehingga administrator repositori dapat mengabaikan peninjauan dan menggabungkan permintaan pull.

Saat dibuat ke gke-infrastructure-repo, push akan memanggil pemicu create-infra. Pemicu tersebut mengidentifikasi cabang tempat push terjadi dan mengarah ke folder terkait di repositori pada cabang tersebut. Setelah menemukan folder yang sesuai, Terraform menggunakan file yang ada di folder tersebut. Misalnya, jika kode dikirim ke cabang dev, pemicu akan menjalankan Terraform di folder dev dari cabang dev untuk membuat cluster GKE dev. Demikian pula, saat push terjadi ke cabang staging, pemicu akan menjalankan Terraform di folder staging cabang staging untuk membuat cluster GKE staging.

Jalankan pipeline untuk membuat cluster GKE:

  1. Di konsol Google Cloud, buka halaman Cloud Build.

    Buka halaman Cloud Build

    • Ada lima pemicu webhook Cloud Build. Cari pemicu dengan nama create-infra. Pemicu ini membuat infrastruktur bersama, termasuk cluster GKE.
  2. Klik nama pemicu. Definisi pemicu akan terbuka.

  3. Klik BUKA EDITOR untuk melihat langkah-langkah yang dijalankan pemicu.

    Pemicu lainnya digunakan saat Anda mengaktivasi aplikasi di Modern CI/CD dengan GKE: Menerapkan alur kerja developer

    Pemicu Cloud Build.

  4. Di konsol Google Cloud, buka halaman Cloud Build.

    Buka halaman Cloud Build history

    Tinjau pipeline yang ada di halaman histori. Saat Anda men-deploy platform pengiriman software menggunakan bootstrap.sh, skrip mengirimkan kode ke cabang dev dari repositori gke-infrastructure-repo yang memulai pipeline ini dan membuat cluster GKE dev.

  5. Untuk membuat cluster GKE staging, kirimkan permintaan pull dari cabang dev ke cabang staging:

    1. Buka GitHub dan buka repositori gke-infrastructure-repo.

    2. Klik Pull requests, lalu New pull request.

    3. Di menu Dasar, pilih staging, lalu di menu Compare, pilih dev.

    4. Klik Create pull request.

  6. Jika Anda adalah administrator di repositori, gabungkan permintaan pull. Jika tidak, minta administrator untuk menggabungkan permintaan pull.

  7. Di konsol Google Cloud, buka halaman Cloud Build history.

    Buka halaman Cloud Build history

    Pipeline Cloud Build kedua dimulai dari project. Pipeline ini membuat cluster GKE staging.

  8. Untuk membuat cluster GKE prod, kirimkan pull request dari staging ke cabang prod:

    1. Buka GitHub dan buka repositori gke-infrastructure-repo.

    2. Klik Pull requests, lalu New pull request.

    3. Di menu Base, pilih prod dan di menu Compare, pilih staging.

    4. Klik Create pull request.

  9. Jika Anda adalah administrator di repositori, gabungkan permintaan pull. Jika tidak, minta administrator untuk menggabungkan permintaan pull.

  10. Di konsol Google Cloud, buka halaman Cloud Build history.

    Buka halaman Cloud Build history

    Pipeline Cloud Build ketiga dimulai dari project. Pipeline ini membuat cluster GKE produksi.

Infrastruktur

Di bagian ini, Anda akan mempelajari infrastruktur yang dibuat oleh pipeline.

  • Di konsol Google Cloud, buka halaman Cluster Kubernetes.

    Buka halaman cluster Kubernetes

    Halaman ini mencantumkan cluster yang digunakan untuk pengembangan (gke-dev-us-central1), staging (gke-staging-us-central1), dan produksi ( gke-prod-us-central1, gke-prod-us-west1):

    Detail cluster meliputi lokasi, ukuran cluster, dan total inti.

Cluster pengembangan

Cluster pengembangan (gke-dev-us-central1) memberi developer Anda akses ke namespace yang dapat mereka gunakan untuk melakukan iterasi pada aplikasi. Sebaiknya tim menggunakan alat seperti Skaffold yang menyediakan alur kerja berulang dengan secara aktif memantau kode dalam pengembangan dan menerapkannya kembali ke lingkungan pengembangan saat perubahan dilakukan. Loop iterasi ini mirip dengan hot reload. Namun, loop ini tidak bergantung pada bahasa pemrograman tertentu, tetapi berfungsi dengan aplikasi apa pun yang dapat Anda bangun dengan image Docker. Anda dapat menjalankan loop di dalam cluster Kubernetes.

Atau, developer Anda dapat mengikuti loop CI/CD untuk lingkungan pengembangan. Loop tersebut membuat perubahan kode siap untuk dipromosikan ke lingkungan yang lebih tinggi.

Dalam dokumen berikutnya dalam seri ini, Modern CI/CD with GKE: Apply the developer Workflow, Anda akan menggunakan Skaffold dan CI/CD untuk membuat loop pengembangan.

Cluster staging

Cluster ini menjalankan lingkungan staging aplikasi Anda. Dalam arsitektur referensi ini, Anda akan membuat satu cluster GKE untuk staging. Biasanya, lingkungan staging adalah replika yang tepat dari lingkungan produksi.

Cluster produksi

Dalam arsitektur referensi, Anda memiliki dua cluster GKE untuk lingkungan produksi. Untuk sistem geo-redundansi atau ketersediaan tinggi (HA), sebaiknya tambahkan beberapa cluster ke setiap lingkungan. Untuk semua cluster tempat aplikasi di-deploy, sebaiknya gunakan cluster regional. Pendekatan ini mengisolasi aplikasi Anda dari kegagalan tingkat zona dan gangguan apa pun yang disebabkan oleh upgrade cluster atau node pool.

Untuk menyinkronkan konfigurasi resource cluster, seperti namespace, kuota, dan RBAC, sebaiknya gunakan Config Sync. Untuk mengetahui informasi selengkapnya tentang cara mengelola resource tersebut, lihat Repositori kebijakan dan konfigurasi.

Menerapkan arsitektur referensi

Setelah menjelajahi arsitektur referensi, Anda dapat menjelajahi alur kerja developer yang didasarkan pada implementasi ini. Dalam dokumen berikutnya dalam seri ini, Modern CI/CD dengan GKE: Menerapkan alur kerja developer, Anda akan membuat aplikasi baru, menambahkan fitur, lalu men-deploy aplikasi ke lingkungan staging dan lingkungan production.

Pembersihan

Jika Anda ingin mencoba dokumen berikutnya dalam seri ini, Modern CI/CD dengan GKE: Menerapkan alur kerja developer, jangan menghapus project atau resource yang terkait dengan arsitektur referensi ini. Jika tidak, agar tidak menimbulkan biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam arsitektur referensi, Anda dapat menghapus project atau menghapus resource secara manual.

Menghapus project

  1. Di konsol Google Cloud, buka halaman Manage resource.

    Buka Manage resource

  2. Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
  3. Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Menghapus resource secara manual

  • Di Cloud Shell, hapus infrastruktur:

      gcloud container clusters delete gke-dev-us-central1
      gcloud container clusters delete gke-staging-us-central1
      gcloud container clusters delete gke-prod-us-central1
      gcloud container clusters delete gke-prod-us-west1
      gcloud beta builds triggers delete create-infra
      gcloud beta builds triggers delete add-team-files
      gcloud beta builds triggers delete create-app
      gcloud beta builds triggers delete tf-plan
      gcloud beta builds triggers delete tf-apply
    

Langkah selanjutnya