Sebaiknya gunakan infrastruktur deklaratif untuk men-deploy fondasi Anda secara konsisten dan dapat dikontrol. Pendekatan ini membantu menciptakan tata kelola yang konsisten dengan menerapkan kontrol kebijakan tentang konfigurasi resource yang dapat diterima ke dalam pipeline Anda. Blueprint di-deploy menggunakan alur GitOps, dengan Terraform digunakan untuk mendefinisikan Infrastructure as Code (IaC), repositori Git untuk kontrol versi dan persetujuan kode, serta Cloud Build untuk otomatisasi CI/CD di pipeline deployment. Untuk pengantar konsep ini, baca artikel mengelola infrastruktur sebagai kode dengan Terraform, Cloud Build, dan GitOps.
Bagian berikut menjelaskan cara pipeline deployment digunakan untuk mengelola resource di organisasi Anda.
Lapisan pipeline
Untuk memisahkan tim dan technology stack yang bertanggung jawab mengelola berbagai lapisan lingkungan Anda, sebaiknya gunakan model yang menggunakan pipeline dan persona berbeda yang bertanggung jawab untuk setiap lapisan stack.
Diagram berikut memperkenalkan model yang kami rekomendasikan untuk memisahkan pipeline foundation, pipeline infrastruktur, dan pipeline aplikasi.
Diagram memperkenalkan lapisan pipeline dalam model ini:
- Pipeline foundation men-deploy resource fondasi yang digunakan di seluruh platform. Sebaiknya ada satu tim pusat yang bertanggung jawab untuk mengelola resource dasar yang digunakan oleh beberapa unit bisnis dan workload.
- Pipeline infrastruktur men-deploy project dan infrastruktur yang digunakan oleh beban kerja, seperti instance atau database VM. Cetak biru ini menyiapkan pipeline infrastruktur terpisah untuk setiap unit bisnis, atau Anda mungkin lebih memilih pipeline infrastruktur tunggal yang digunakan oleh beberapa tim.
- Pipeline aplikasi men-deploy artefak untuk setiap beban kerja, seperti container atau image. Anda mungkin memiliki banyak tim aplikasi yang berbeda dengan setiap pipeline aplikasi.
Bagian berikut memperkenalkan penggunaan setiap lapisan pipeline.
Pipeline fondasi
Pipeline fondasi men-deploy resource fondasi. Framework ini juga menyiapkan pipeline infrastruktur yang digunakan untuk men-deploy infrastruktur yang digunakan oleh workload.
Untuk membuat pipeline fondasi, pertama-tama Anda harus meng-clone atau melakukan fork
terraform-example-foundation ke repositori Git Anda sendiri. Ikuti langkah-langkah dalam
file README 0-bootstrap untuk mengonfigurasi folder dan resource bootstrap.
| Tahap | Deskripsi |
|---|---|
Melakukan bootstrap pada organisasi Google Cloud. Langkah ini juga mengonfigurasi pipeline CI/CD untuk kode blueprint pada tahap berikutnya.
|
Setelah Anda membuat pipeline fondasi di tahap 0-bootstrap, tahap
berikut akan men-deploy resource di pipeline fondasi. Tinjau petunjuk README
untuk setiap tahap dan terapkan setiap tahap secara berurutan.
| Tahap | Deskripsi |
|---|---|
Menyiapkan folder bersama tingkat atas, project untuk layanan bersama, logging tingkat organisasi, dan setelan keamanan dasar pengukuran melalui kebijakan organisasi. |
|
Siapkan lingkungan pengembangan, non-produksi, dan produksi dalam organisasi Google Cloud yang telah Anda buat. |
|
atau |
Siapkan VPC bersama dalam topologi yang Anda pilih dan resource jaringan terkait. |
Pipeline infrastruktur
Pipeline infrastruktur men-deploy project dan infrastruktur (misalnya, instance dan database VM) yang digunakan oleh workload. Pipeline foundation men-deploy beberapa pipeline infrastruktur. Pemisahan antara pipeline fondasi dan pipeline infrastruktur ini memungkinkan pemisahan antara resource tingkat platform dan resource khusus workload.
Diagram berikut menjelaskan cara blueprint mengonfigurasi beberapa pipeline infrastruktur yang dimaksudkan untuk digunakan oleh tim yang terpisah.
Diagram ini menjelaskan konsep utama berikut:
- Setiap pipeline infrastruktur digunakan untuk mengelola resource infrastruktur secara terpisah dari resource dasar.
- Setiap unit bisnis memiliki pipeline infrastruktur sendiri yang dikelola dalam project khusus di folder
common. - Setiap pipeline infrastruktur memiliki akun layanan dengan izin untuk men-deploy resource hanya ke project yang terkait dengan unit bisnis tersebut. Strategi ini menciptakan pemisahan tugas antara akun layanan dengan hak istimewa yang digunakan untuk pipeline dasar dan yang digunakan oleh setiap pipeline infrastruktur
Pendekatan dengan beberapa pipeline infrastruktur ini direkomendasikan jika Anda memiliki beberapa entity di dalam organisasi yang memiliki keterampilan dan keinginan untuk mengelola infrastrukturnya secara terpisah, terutama jika mereka memiliki persyaratan berbeda seperti jenis kebijakan validasi pipeline yang ingin diterapkan. Atau, Anda mungkin lebih suka memiliki satu pipeline infrastruktur yang dikelola oleh satu tim dengan kebijakan validasi yang konsisten.
Dalam terraform-example-foundation, tahap 4 mengonfigurasi pipeline infrastruktur, dan tahap 5 menunjukkan contoh penggunaan pipeline tersebut untuk men-deploy resource infrastruktur.
| Tahap | Deskripsi |
|---|---|
Menyiapkan struktur folder, project, dan pipeline infrastruktur. |
|
|
Men-deploy project workload dengan instance Compute Engine menggunakan pipeline infrastruktur sebagai contoh. |
Pipeline aplikasi
Pipeline aplikasi bertanggung jawab untuk men-deploy artefak aplikasi untuk setiap workload individual, seperti image atau container Kubernetes yang menjalankan logika bisnis aplikasi Anda. Artefak ini di-deploy ke resource infrastruktur yang di-deploy oleh pipeline infrastruktur Anda.
Blueprint fondasi perusahaan menyiapkan pipeline fondasi dan pipeline infrastruktur Anda, tetapi tidak men-deploy pipeline aplikasi. Untuk contoh pipeline aplikasi, lihat cetak biru aplikasi perusahaan.
Mengotomatiskan pipeline dengan Cloud Build
Blueprint ini menggunakan Cloud Build untuk mengotomatiskan proses CI/CD. Tabel berikut menjelaskan kontrol yang dibangun ke dalam pipeline dasar dan pipeline infrastruktur yang di-deploy oleh repositori terraform-example-foundation. Jika Anda mengembangkan pipeline sendiri menggunakan alat otomatisasi CI/CD lainnya, sebaiknya Anda menerapkan kontrol serupa.
| Kontrol | Deskripsi |
|---|---|
Memisahkan konfigurasi build untuk memvalidasi kode sebelum men-deploy |
Blueprint menggunakan dua file konfigurasi build Cloud Build untuk seluruh pipeline, dan setiap repositori yang terkait dengan suatu tahap memiliki dua pemicu Cloud Build yang terkait dengan file konfigurasi build tersebut. Saat kode dikirim ke cabang repositori, file konfigurasi build akan dipicu untuk menjalankan |
Pemeriksaan kebijakan Terraform | Blueprint mencakup serangkaian batasan Open Policy Agent yang diterapkan oleh validasi kebijakan di Google Cloud CLI. Batasan ini menentukan konfigurasi resource yang dapat diterima, yang dapat di-deploy oleh pipeline Anda. Jika build tidak memenuhi kebijakan dalam konfigurasi build pertama, konfigurasi build kedua tidak akan men-deploy resource apa pun. Kebijakan
yang diterapkan dalam blueprint diambil dari |
Prinsip hak istimewa terendah | Pipeline dasar memiliki akun layanan yang berbeda untuk setiap tahap dengan kebijakan izinkan yang hanya memberikan peran IAM minimum untuk tahap tersebut. Setiap pemicu Cloud Build dijalankan sebagai akun layanan spesifik untuk tahap tersebut. Menggunakan akun yang berbeda membantu mengurangi risiko
memodifikasi satu repositori dapat memengaruhi resource yang dikelola oleh
repositori lain. Untuk memahami peran IAM tertentu yang diterapkan pada setiap akun layanan, lihat kode Terraform |
Kumpulan pribadi Cloud Build | Blueprint menggunakan kumpulan pribadi Cloud Build. Kumpulan pribadi memungkinkan Anda untuk menerapkan kontrol tambahan secara opsional, seperti membatasi akses ke repositori publik atau menjalankan Cloud Build di dalam perimeter Kontrol Layanan VPC. |
Builder kustom Cloud Build | Blueprint membuat builder kustom-nya sendiri untuk menjalankan Terraform. Untuk informasi selengkapnya, lihat |
Persetujuan deployment | Secara opsional, Anda dapat menambahkan tahap persetujuan manual ke Cloud Build. Persetujuan ini menambahkan checkpoint tambahan setelah build dipicu, tetapi sebelum build dijalankan, sehingga pengguna dengan hak istimewa dapat menyetujui build secara manual. |
Strategi percabangan
Sebaiknya gunakan strategi cabang persisten untuk mengirimkan kode ke sistem Git Anda dan men-deploy resource melalui pipeline dasar. Diagram berikut menjelaskan strategi cabang persisten.
Diagram ini menjelaskan tiga cabang persisten di Git (pengembangan, non-produksi, dan produksi) yang mencerminkan lingkungan Google Cloud yang sesuai. Ada juga beberapa cabang fitur sementara yang tidak sesuai dengan resource yang di-deploy di lingkungan Google Cloud Anda.
Sebaiknya terapkan proses permintaan pull (PR) ke dalam sistem Git Anda sehingga setiap kode yang digabungkan ke cabang persisten memiliki PR yang disetujui.
Untuk mengembangkan kode dengan strategi cabang persisten ini, ikuti langkah-langkah tingkat tinggi berikut:
- Saat Anda mengembangkan kemampuan baru atau mengerjakan perbaikan bug, buat cabang
baru berdasarkan cabang pengembangan. Gunakan konvensi penamaan untuk cabang Anda
yang menyertakan jenis perubahan, nomor tiket atau ID lainnya,
dan deskripsi yang dapat dibaca manusia, seperti
feature/123456-org-policies. - Setelah Anda menyelesaikan pekerjaan di cabang fitur, buka PR yang menargetkan cabang pengembangan.
- Saat Anda mengirimkan PR, PR memicu pipeline fondasi untuk melakukan
terraform plandanterraform validateuntuk menyusun dan memverifikasi perubahan. - Setelah memvalidasi perubahan pada kode, gabungkan fitur atau perbaikan bug ke cabang pengembangan.
- Proses penggabungan akan memicu pipeline fondasi untuk menjalankan
terraform applyguna men-deploy perubahan terbaru di cabang pengembangan ke lingkungan pengembangan. - Tinjau perubahan di lingkungan pengembangan menggunakan peninjauan manual, pengujian fungsi, atau pengujian menyeluruh yang relevan dengan kasus penggunaan Anda. Kemudian, promosikan perubahan ke lingkungan non-produksi dengan membuka PR yang menargetkan cabang non-produksi dan menggabungkan perubahan Anda.
- Untuk men-deploy resource ke lingkungan produksi, ulangi proses yang sama seperti di langkah 6: tinjau dan validasi resource yang di-deploy, buka PR ke cabang produksi, lalu gabungkan.
Langkah selanjutnya
- Baca praktik terbaik operasi (dokumen berikutnya dalam seri ini).