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:
- CI/CD modern dengan GKE: Framework pengiriman software
- CI/CD modern dengan GKE: Membangun sistem CI/CD (dokumen ini)
- CI/CD modern dengan GKE: Menerapkan alur kerja developer
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:
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:
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:
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:
Setiap namespace mencakup akun layanan yang digunakan untuk Workload Identity Federation for GKE, agar 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:
- Google Kubernetes Engine (GKE)
- Edisi Google Kubernetes Engine (GKE) Enterprise untuk Config Sync dan Pengontrol Kebijakan
- Cloud Build
- Artifact Registry
- Cloud Deploy
Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda,
gunakan kalkulator harga.
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
-
Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.
-
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
-
Di konsol Google Cloud, aktifkan Cloud Shell.
Men-deploy arsitektur referensi
Di Cloud Shell, tetapkan project:
gcloud config set core/project PROJECT_ID
Ganti
PROJECT_ID
dengan ID project Google Cloud Anda.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
Buat token akses pribadi di GitHub dengan cakupan berikut:
repo
delete_repo
admin:org
admin:repo_hook
Ada file kosong bernama
vars.sh
dalam foldersoftware-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.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
- Di browser web, buka github.com dan login ke akun Anda.
- Klik ikon gambar di bagian atas antarmuka.
- Klik Organisasi Anda.
- Pilih organisasi yang Anda berikan sebagai input dalam file
vars.sh
. - 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.
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 folderk8s
.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
danskaffold.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 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:
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:
Di konsol Google Cloud, buka halaman Cloud Build.
- Ada lima pemicu webhook Cloud Build. Cari pemicu dengan nama
create-infra
. Pemicu ini membuat infrastruktur bersama, termasuk cluster GKE.
- Ada lima pemicu webhook Cloud Build. Cari pemicu dengan nama
Klik nama pemicu. Definisi pemicu akan terbuka.
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
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 repositorigke-infrastructure-repo
yang memulai pipeline ini dan membuat cluster GKE dev.Untuk membuat cluster GKE staging, kirimkan permintaan pull dari cabang dev ke cabang staging:
Buka GitHub dan buka repositori
gke-infrastructure-repo
.Klik Pull requests, lalu New pull request.
Di menu Dasar, pilih staging, lalu di menu Compare, pilih dev.
Klik Create pull request.
Jika Anda adalah administrator di repositori, gabungkan permintaan pull. Jika tidak, minta administrator untuk menggabungkan permintaan pull.
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.
Untuk membuat cluster GKE prod, kirimkan
pull request
dari staging ke cabang prod:Buka GitHub dan buka repositori
gke-infrastructure-repo
.Klik Pull requests, lalu New pull request.
Di menu Base, pilih prod dan di menu Compare, pilih staging.
Klik Create pull request.
Jika Anda adalah administrator di repositori, gabungkan permintaan pull. Jika tidak, minta administrator untuk menggabungkan permintaan pull.
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
):
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
- Di konsol Google Cloud, buka halaman Manage resource.
- Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
- 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
- Buat aplikasi baru dengan mengikuti langkah-langkah di bagian CI/CD Modern dengan GKE: Menerapkan alur kerja developer.
- Pelajari praktik terbaik untuk menyiapkan penggabungan identitas.
Baca Kubernetes dan tantangan deployment software yang berkelanjutan.
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.