Men-deploy blueprint

Last reviewed 2024-04-19 UTC

Bagian ini menjelaskan proses yang dapat Anda gunakan untuk men-deploy blueprint, konvensi penamaannya, dan alternatif untuk rekomendasi blueprint.

Menyatukan semuanya

Untuk menerapkan arsitektur yang dijelaskan dalam dokumen ini, selesaikan langkah-langkah di bagian ini.

Men-deploy blueprint di organisasi baru

Untuk men-deploy blueprint di organisasi Google Cloud baru, selesaikan langkah-langkah berikut:

  1. Buat infrastruktur dasar Anda menggunakan cetakan dasar perusahaan. Selesaikan langkah-langkah berikut:

    1. Buat struktur organisasi, termasuk folder untuk pemisahan lingkungan.
    2. Konfigurasikan izin IAM dasar untuk memberikan akses kepada administrator platform developer.
    3. Buat jaringan VPC.
    4. Men-deploy pipeline infrastruktur dasar.

    Jika Anda tidak menggunakan blueprint dasar-dasar perusahaan, lihat Men-deploy blueprint tanpa blueprint dasar-dasar perusahaan.

  2. Deploy cetak biru aplikasi perusahaan sebagai berikut:

    1. Administrator platform developer menggunakan pipeline infrastruktur fondasi untuk membuat pipeline infrastruktur multi-tenant, factory aplikasi, dan pipeline cakupan armada.
    2. Administrator platform developer menggunakan pipeline infrastruktur multi-tenant untuk men-deploy cluster GKE dan infrastruktur bersama.
    3. Operator aplikasi menggunakan factory aplikasi untuk melakukan aktivasi aplikasi baru. Operator menambahkan satu atau beberapa entri di repositori factory aplikasi, yang memicu pembuatan resource khusus aplikasi.
    4. Developer aplikasi menggunakan pipeline CI/CD aplikasi dalam infrastruktur khusus aplikasi mereka untuk men-deploy aplikasi ke infrastruktur multi-tenant.

Men-deploy blueprint tanpa blueprint dasar-dasar perusahaan

Jika Anda tidak men-deploy blueprint aplikasi perusahaan di blueprint fondasi perusahaan, selesaikan langkah-langkah berikut:

  1. Buat resource berikut:
    • Hierarki organisasi dengan folder development, nonproduction, dan production
    • Jaringan VPC Bersama di setiap folder
    • Skema alamat IP yang memperhitungkan rentang IP yang diperlukan untuk cluster GKE Anda
    • Mekanisme DNS untuk cluster GKE Anda
    • Kebijakan firewall yang selaras dengan postur keamanan Anda
    • Mekanisme untuk mengakses Google Cloud API melalui alamat IP pribadi
    • Mekanisme konektivitas dengan lingkungan lokal Anda
    • Logging terpusat untuk keamanan dan audit
    • Security Command Center untuk pemantauan ancaman
    • Kebijakan organisasi yang selaras dengan postur keamanan Anda
    • Pipeline yang dapat digunakan untuk men-deploy factory aplikasi, pipeline infrastruktur multi-tenant, dan pipeline cakupan armada
  2. Setelah men-deploy resource, lanjutkan dengan langkah 2 di Men-deploy blueprint di organisasi baru.

Menyertakan blueprint ke deployment GKE yang ada

Blueprint ini mengharuskan Anda men-deploy platform developer terlebih dahulu, lalu men-deploy aplikasi ke platform developer. Tabel berikut menjelaskan cara menggunakan blueprint jika Anda sudah memiliki aplikasi dalam container yang berjalan di Google Cloud.

Penggunaan yang ada Strategi migrasi

Sudah memiliki pipeline CI/CD.

Anda dapat menggunakan arsitektur cluster dan armada blueprint meskipun produk yang berbeda digunakan untuk build dan deployment aplikasi. Setidaknya, sebaiknya Anda mencerminkan gambar ke dua wilayah.

Memiliki struktur organisasi yang ada dan tidak cocok dengan blueprint fondasi perusahaan.

Sebaiknya memiliki minimal dua lingkungan untuk deployment berurutan yang lebih aman. Anda tidak perlu men-deploy lingkungan di VPC atau folder Shared yang terpisah. Namun, jangan deploy workload yang berasal dari lingkungan yang berbeda ke cluster yang sama.

Jangan gunakan IaC.

Jika proses deployment aplikasi Anda saat ini tidak menggunakan IaC, Anda dapat menilai kesiapan Anda dengan model kematangan Terraform di Google Cloud. Impor resource yang ada ke project Terraform lain yang diatur mirip dengan blueprint ini, dengan pemisahan pipeline multi-tenant dan per-tenant. Untuk membuat cluster baru, Anda dapat menggunakan modul Terraform untuk Google Cloud.

Cluster tersebar di beberapa project dalam lingkungan yang sama.

Anda dapat mengelompokkan cluster dari beberapa project ke dalam satu fleet. Pastikan bahwa namespace Anda memiliki arti unik dalam fleet yang sama. Sebelum menambahkan cluster ke fleet, minta tim untuk memindahkan aplikasi mereka ke namespace dengan nama unik (misalnya, bukan default).

Kemudian, Anda dapat mengelompokkan namespace ke dalam cakupan.

Cluster berada di satu region.

Anda tidak perlu menggunakan beberapa region dalam produksi dan non-produksi untuk mengadopsi blueprint.

Ada berbagai kumpulan lingkungan.

Anda dapat mengubah blueprint untuk mendukung lebih dari tiga atau kurang dari tiga lingkungan.

Pembuatan cluster didelegasikan kepada developer aplikasi atau tim operator aplikasi.

Untuk platform developer yang paling aman dan konsisten, Anda dapat mencoba memindahkan kepemilikan cluster dari tim aplikasi ke tim platform developer. Jika tidak dapat, Anda masih dapat mengadopsi banyak praktik blueprint. Misalnya, Anda dapat menambahkan cluster yang dimiliki oleh tim aplikasi yang berbeda ke armada. Namun, saat menggabungkan cluster dengan kepemilikan independen, jangan gunakan Workload Identity Federation untuk GKE atau Cloud Service Mesh, karena tidak memberikan kontrol yang memadai atas siapa yang dapat menyatakan identitas beban kerja apa. Sebagai gantinya, gunakan kebijakan organisasi kustom untuk mencegah tim mengaktifkan fitur ini di cluster GKE.

Saat cluster dikelompokkan ke dalam fleet, Anda masih dapat mengaudit dan menerapkan kebijakan. Anda dapat menggunakan kebijakan organisasi kustom untuk mewajibkan cluster dibuat dalam fleet yang sesuai dengan folder lingkungan tempat project cluster berada. Anda dapat menggunakan konfigurasi default armada untuk mewajibkan cluster baru menggunakan kontrol kebijakan.

Alternatif untuk rekomendasi default

Bagian ini menjelaskan alternatif untuk rekomendasi default yang disertakan dalam panduan ini.

Area keputusan Alternatif yang memungkinkan

Semua aplikasi berjalan dalam kumpulan lima cluster yang sama.

Blueprint menggunakan kumpulan lima cluster (dua dalam produksi, dua dalam non-produksi, dan satu dalam pengembangan). Anda dapat mengubah blueprint untuk membuat kumpulan tambahan dari lima cluster.

Tetapkan aplikasi ke kumpulan lima cluster. Jangan mengikat cakupan aplikasi atau namespace fleet ke cluster dalam set lainnya. Anda dapat memisahkan aplikasi ke dalam set cluster yang berbeda untuk menyelesaikan aktivitas seperti berikut:

  • Mengelompokkan beberapa aplikasi dengan masalah peraturan khusus (misalnya, PCI-DSS).
  • Mengisolasi aplikasi yang memerlukan penanganan khusus selama upgrade cluster (misalnya, aplikasi stateful yang menggunakan volume persisten).
  • Isolasi aplikasi dengan profil keamanan berisiko (misalnya, memproses konten yang disediakan pengguna dalam bahasa yang tidak aman untuk memori).
  • Isolasi aplikasi yang memerlukan GPU, sensitivitas biaya, dan sensitivitas performa.
  • Jika Anda mendekati batas cluster GKE untuk jumlah node (15.000 node), Anda dapat membuat kumpulan cluster baru.
  • Gunakan VPC Bersama yang berbeda untuk aplikasi yang perlu berjalan dalam perimeter Kontrol Layanan VPC. Buat satu set cluster di perimeter dan satu set cluster di luar perimeter.

Hindari membuat set cluster baru untuk setiap aplikasi atau tenant, karena praktik ini dapat menyebabkan salah satu situasi berikut:

  • Aplikasi yang tidak memanfaatkan ukuran cluster minimum (3 VM x 2 region) dengan baik meskipun dengan jenis instance terkecil yang tersedia.
  • Melewatkan potensi pengurangan biaya dari bin-packing berbagai aplikasi.
  • Perencanaan pertumbuhan kapasitas yang melelahkan dan tidak pasti karena perencanaan diterapkan ke setiap aplikasi satu per satu. Prediksi kapasitas akan lebih akurat jika dilakukan secara gabungan untuk berbagai aplikasi.
  • Penundaan dalam membuat cluster baru untuk tenant atau aplikasi baru, sehingga mengurangi kepuasan tenant terhadap platform. Misalnya, di beberapa organisasi, alokasi alamat IP yang diperlukan mungkin memerlukan waktu dan persetujuan tambahan.
  • Mencapai batas cluster pribadi di jaringan VPC.

Lingkungan produksi dan non-produksi memiliki cluster di dua region.

Untuk latensi yang lebih rendah bagi pengguna akhir di beberapa region, Anda dapat men-deploy beban kerja produksi dan non-produksi di lebih dari dua region (misalnya, tiga region untuk produksi, tiga region untuk non-produksi, dan satu region untuk pengembangan). Strategi deployment ini meningkatkan biaya dan overhead pemeliharaan resource di region tambahan.

Jika semua aplikasi memiliki persyaratan ketersediaan yang lebih rendah, Anda dapat men-deploy workload produksi dan non-produksi hanya ke satu region (satu lingkungan produksi, satu lingkungan non-produksi, dan satu lingkungan pengembangan). Strategi ini membantu mengurangi biaya, tetapi tidak melindungi tingkat ketersediaan yang sama seperti arsitektur dual-region atau multi-region.

Jika aplikasi memiliki persyaratan ketersediaan yang berbeda, Anda dapat membuat set cluster yang berbeda untuk aplikasi yang berbeda (misalnya, cluster-set-1 dengan dua lingkungan produksi, dua lingkungan non-produksi, dan satu lingkungan pengembangan serta cluster-set-2 dengan satu lingkungan produksi, satu lingkungan non-produksi, dan satu lingkungan pengembangan).

Topologi hub-and-spoke lebih cocok dengan persyaratan Anda daripada VPC Bersama.

Anda dapat men-deploy blueprint dalam konfigurasi hub-and-spoke, dengan setiap lingkungan (pengembangan, produksi, dan non-produksi) dihosting di spoke sendiri. Topologi hub-and-spoke dapat meningkatkan pemisahan lingkungan. Untuk mengetahui informasi selengkapnya, lihat Topologi jaringan hub-and-spoke.

Setiap aplikasi memiliki repositori Git terpisah.

Beberapa organisasi menggunakan satu repositori Git (monorepo) untuk semua kode sumber, bukan beberapa repositori. Jika menggunakan monorepo, Anda dapat mengubah komponen factory aplikasi dari blueprint untuk mendukung repositori Anda. Selesaikan langkah-langkah berikut:

  • Daripada membuat repositori baru untuk setiap aplikasi baru, buat sub-direktori di repositori yang ada.
  • Daripada memberikan izin pemilik di repositori baru kepada grup developer aplikasi, berikan izin tulis di repositori yang ada dan jadikan grup developer aplikasi sebagai peninjau yang diperlukan untuk perubahan pada subdirektori baru. Gunakan fitur CODEOWNERS dan perlindungan cabang.

Langkah selanjutnya