Sebaiknya gunakan infrastruktur deklaratif untuk men-deploy fondasi Anda dengan cara yang konsisten dan dapat dikontrol. Pendekatan ini membantu mengaktifkan 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 menentukan infrastruktur sebagai kode (IaC), repositori Git untuk kontrol versi dan persetujuan kode, serta Cloud Build untuk otomatisasi CI/CD di pipeline deployment. Untuk pengantar konsep ini, lihat 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 stack teknologi yang bertanggung jawab untuk mengelola berbagai lapisan lingkungan Anda, sebaiknya gunakan model yang menggunakan pipeline dan persona yang berbeda, yang bertanggung jawab untuk setiap lapisan stack.
Diagram berikut memperkenalkan model yang kami rekomendasikan untuk memisahkan pipeline fondasi, pipeline infrastruktur, dan pipeline aplikasi.
Diagram ini memperkenalkan lapisan pipeline dalam model ini:
- Pipeline foundation men-deploy resource foundation yang digunakan di seluruh platform. Sebaiknya satu tim pusat bertanggung jawab untuk mengelola resource fondasi yang digunakan oleh beberapa unit bisnis dan beban kerja.
- Pipeline infrastruktur men-deploy project dan infrastruktur yang digunakan oleh workload, seperti instance VM atau database. Blueprint menyiapkan pipeline infrastruktur terpisah untuk setiap unit bisnis, atau Anda mungkin lebih memilih satu pipeline infrastruktur 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 pipeline aplikasi individual.
Bagian berikut memperkenalkan penggunaan setiap lapisan pipeline.
Pipeline fondasi
Pipeline fondasi men-deploy resource fondasi. Alat ini juga menyiapkan pipeline infrastruktur yang digunakan untuk men-deploy infrastruktur yang digunakan oleh beban kerja.
Untuk membuat pipeline dasar, Anda harus meng-clone atau melakukan fork
terraform-example-foundation ke repositori Git Anda sendiri terlebih dahulu. Ikuti langkah-langkah dalam
file README 0-bootstrap untuk mengonfigurasi folder dan resource bootstrap Anda.
| Tahap | Deskripsi |
|---|---|
Melakukan bootstrap organisasi Google Cloud. Langkah ini juga mengonfigurasi pipeline CI/CD untuk kode blueprint di 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 teratas, project untuk layanan bersama, logging tingkat organisasi, dan setelan keamanan dasar melalui kebijakan organisasi. |
|
Menyiapkan lingkungan pengembangan, non-produksi, dan produksi dalam organisasi Google Cloud yang telah Anda buat. |
|
atau |
Menyiapkan VPC bersama dalam topologi yang Anda pilih dan resource jaringan terkait. |
Pipeline infrastruktur
Pipeline infrastruktur men-deploy project dan infrastruktur (misalnya, instance VM dan database) yang digunakan oleh workload. Pipeline foundation men-deploy beberapa pipeline infrastruktur. Pemisahan antara pipeline fondasi dan pipeline infrastruktur ini memungkinkan pemisahan antara resource seluruh platform dan resource khusus beban kerja.
Diagram berikut menjelaskan cara blueprint mengonfigurasi beberapa pipeline infrastruktur yang ditujukan untuk digunakan oleh tim terpisah.
Diagram ini menjelaskan konsep utama berikut:
- Setiap pipeline infrastruktur digunakan untuk mengelola resource infrastruktur secara terpisah dari resource fondasi.
- Setiap unit bisnis memiliki pipeline infrastrukturnya 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 fondasi dan yang digunakan oleh setiap pipeline infrastruktur
Pendekatan ini dengan beberapa pipeline infrastruktur direkomendasikan jika Anda memiliki beberapa entitas di dalam organisasi yang memiliki keterampilan dan keinginan untuk mengelola infrastrukturnya secara terpisah, terutama jika mereka memiliki persyaratan yang berbeda seperti jenis kebijakan validasi pipeline yang ingin mereka terapkan. Atau, Anda mungkin lebih memilih untuk memiliki satu pipeline infrastruktur yang dikelola oleh satu tim dengan kebijakan validasi yang konsisten.
Di 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 beban kerja, seperti image atau penampung Kubernetes yang menjalankan logika bisnis aplikasi Anda. Artefak ini di-deploy ke resource infrastruktur yang di-deploy oleh pipeline infrastruktur Anda.
Blueprint dasar-dasar perusahaan menyiapkan pipeline fondasi dan pipeline infrastruktur, tetapi tidak men-deploy pipeline aplikasi. Untuk contoh pipeline aplikasi, lihat blueprint aplikasi perusahaan.
Mengotomatiskan pipeline dengan Cloud Build
Blueprint menggunakan Cloud Build untuk mengotomatiskan proses CI/CD. Tabel berikut menjelaskan kontrol yang di-build ke dalam pipeline fondasi dan pipeline infrastruktur yang di-deploy oleh repositori terraform-example-foundation. Jika Anda mengembangkan pipeline Anda sendiri menggunakan alat otomatisasi CI/CD lainnya, sebaiknya terapkan 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 tahap memiliki dua
pemicu Cloud Build yang
terkait dengan file konfigurasi build tersebut. Saat kode di-push ke
cabang repositori, file konfigurasi build dipicu untuk terlebih dahulu menjalankan |
Pemeriksaan kebijakan Terraform | Blueprint ini 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 di-fork dari |
Prinsip hak istimewa terendah | Pipeline fondasi memiliki akun layanan
yang berbeda untuk setiap tahap dengan kebijakan izin yang hanya memberikan peran IAM minimum
untuk tahap tersebut. Setiap pemicu Cloud Build berjalan sebagai akun layanan
tertentu untuk tahap tersebut. Menggunakan akun yang berbeda membantu mengurangi risiko
bahwa mengubah satu repositori dapat memengaruhi resource yang dikelola oleh
repositori lain. Untuk memahami peran IAM tertentu yang diterapkan ke setiap akun layanan, lihat kode Terraform |
Kumpulan pribadi Cloud Build | Blueprint menggunakan kumpulan pribadi Cloud Build. Dengan pool pribadi, Anda dapat 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 titik pemeriksaan tambahan setelah build dipicu, tetapi sebelum dijalankan sehingga pengguna dengan hak istimewa dapat menyetujui build secara manual. |
Strategi cabang
Sebaiknya gunakan strategi cabang persisten untuk mengirimkan kode ke sistem Git Anda dan men-deploy resource melalui pipeline fondasi. 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 sistem Git Anda sehingga kode apa pun 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 menyelesaikan pekerjaan di cabang fitur, buka PR yang menargetkan cabang pengembangan.
- Saat Anda mengirimkan PR, PR akan memicu pipeline fondasi untuk menjalankan
terraform plandanterraform validateguna melakukan staging dan memverifikasi perubahan. - Setelah Anda memvalidasi perubahan pada kode, gabungkan fitur atau perbaikan bug ke dalam cabang pengembangan.
- Proses penggabungan 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 fungsional, 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 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 rangkaian ini).