Men-deploy blueprint

Last reviewed 2023-12-20 UTC

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

Menyatukan semuanya!

Untuk mengimplementasikan 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 yang baru, selesaikan langkah-langkah berikut:

  1. Buat infrastruktur dasar Anda menggunakan blueprint fondasi perusahaan. Isi kolom berikut:

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

    Jika Anda tidak menggunakan blueprint Enterprise Foundation, lihat Men-deploy blueprint tanpa blueprint Enterprise Foundation.

  2. Administrator platform developer menggunakan pipeline infrastruktur dasar untuk membuat pipeline infrastruktur multi-tenant, pabrik aplikasi, dan pipeline cakupan fleet.

  3. Administrator platform developer menggunakan pipeline infrastruktur multi-tenant untuk men-deploy cluster GKE dan infrastruktur bersama.

  4. Operator aplikasi menggunakan factory aplikasi untuk mengaktivasi aplikasi baru. Operator menambahkan satu atau beberapa entri dalam repositori factory aplikasi, yang memicu pembuatan resource khusus aplikasi.

  5. Developer aplikasi menggunakan pipeline CI/CD aplikasi dalam infrastruktur khusus aplikasi mereka untuk men-deploy aplikasi ke infrastruktur multi-tenant.

Deploy blueprint tanpa blueprint Enterprise Foundation

Jika Anda tidak men-deploy blueprint aplikasi perusahaan pada blueprint Enterprise Foundation, selesaikan langkah-langkah berikut:

  1. Buat referensi 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 sesuai dengan postur keamanan Anda
    • Mekanisme untuk mengakses Google Cloud API melalui alamat IP pribadi
    • Mekanisme konektivitas dengan lingkungan lokal Anda
    • Pencatatan 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 fleet
  2. Setelah men-deploy resource, lanjutkan ke langkah 2 di Deploy blueprint di organisasi baru.

Gabungkan blueprint ke deployment GKE yang sudah 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 menjalankan aplikasi dalam container di Google Cloud.

Penggunaan yang ada Strategi migrasi

Sudah memiliki pipeline CI/CD.

Anda dapat menggunakan arsitektur fleet dan cluster blueprint bahkan saat produk yang berbeda digunakan untuk build dan deployment aplikasi. Setidaknya, sebaiknya Anda mencerminkan gambar ke dua region.

Memiliki struktur organisasi yang ada yang tidak sesuai dengan blueprint fondasi perusahaan.

Sebaiknya Anda memiliki minimal dua lingkungan untuk deployment berurutan yang lebih aman. Anda tidak perlu men-deploy lingkungan di VPC atau folder Bersama yang terpisah. Namun, jangan men-deploy workload yang berada di lingkungan berbeda ke dalam 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. Mengimpor resource yang ada ke project Terraform lain yang disusun 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 fleet. Pastikan namespace Anda memiliki makna 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.

Terdapat kumpulan lingkungan yang berbeda.

Anda dapat memodifikasi cetak biru untuk mendukung lebih dari atau kurang dari tiga lingkungan.

Pembuatan cluster didelegasikan kepada tim developer aplikasi atau 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 bisa, Anda masih dapat mengadopsi banyak praktik cetak biru tersebut. Misalnya, Anda dapat menambahkan cluster yang dimiliki oleh tim aplikasi yang berbeda ke fleet. Namun, saat menggabungkan cluster dengan kepemilikan independen, jangan gunakan Workload Identity atau Anthos Service Mesh, karena tidak memberikan kontrol yang cukup terkait siapa yang dapat menegaskan identitas workload 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 perangkat 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 di set lima cluster yang sama.

Blueprint menggunakan serangkaian lima cluster (dua dalam produksi, dua dalam non-produksi, dan satu dalam pengembangan). Anda dapat memodifikasi {i>blueprint<i} untuk membuat set tambahan yang terdiri dari lima klaster.

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

  • Kelompokkan beberapa aplikasi yang memiliki masalah peraturan khusus (misalnya PCI-DSS).
  • Mengisolasi aplikasi yang memerlukan penanganan khusus selama upgrade cluster (misalnya, aplikasi stateful yang menggunakan volume persisten).
  • Mengisolasi aplikasi dengan profil keamanan yang 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 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 dijalankan di dalam perimeter Kontrol Layanan VPC. Buat satu cluster yang ditetapkan di perimeter dan satu cluster yang ditetapkan di luar perimeter.

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

  • Aplikasi yang tidak memanfaatkan ukuran cluster minimum (3 VM x 2 region) dengan baik bahkan dengan jenis instance terkecil yang tersedia.
  • Kehilangan potensi pengurangan biaya dari pengemasan aplikasi yang berbeda.
  • Perencanaan pertumbuhan kapasitas yang menjemukan dan tidak pasti karena perencanaan diterapkan pada setiap aplikasi secara individual. Prediksi kapasitas akan lebih akurat jika dilakukan secara gabungan untuk berbagai aplikasi.
  • Penundaan dalam pembuatan cluster baru untuk tenant atau aplikasi baru, sehingga mengurangi kepuasan penyewa dengan platform. Misalnya, di beberapa organisasi, alokasi alamat IP yang diperlukan mungkin memerlukan waktu dan memerlukan persetujuan tambahan.
  • Mencapai batas cluster pribadi dalam jaringan VPC.

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

Untuk latensi yang lebih rendah kepada 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 dengan arsitektur regional ganda atau multi-regional.

Jika aplikasi memiliki persyaratan ketersediaan yang berbeda, Anda dapat membuat kumpulan 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 kebutuhan 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-nya 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 pabrik aplikasi dari blueprint untuk mendukung repositori Anda. Isi kolom berikut:

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

Langkah selanjutnya