Pertimbangan organisasi sumber daya untuk Azure Red Hat OpenShift (opsional)

Organisasi sumber daya sebagian besar dikelola oleh fondasi platform. Berikut adalah beberapa cara fondasi platform dapat memengaruhi akselerator zona pendaratan Azure Red Hat OpenShift Anda.

Desain grup langganan dan sumber daya adalah pertimbangan utama dalam rekomendasi zona pendaratan Azure generik. Mereka memainkan peran mendasar dalam cara Anda mengelola organisasi sumber daya Azure Red Hat OpenShift Anda. Langganan adalah batas manajemen untuk tata kelola dan isolasi sumber daya. Seperti yang dijelaskan dalam Grup manajemen dan organisasi langganan, gunakan langganan dan grup manajemen untuk menetapkan kebijakan ke sumber daya dalam batas.

Misalnya, jika Anda memiliki aplikasi publik dan privat, pisahkan ke dalam langganan yang berbeda, dan letakkan ke dalam Grup Manajemen yang sesuai bernama Corp dan Online, atau Grup Manajemen lainnya di bawah Zona Pendaratan. Langganan yang berada dalam Corp Grup Manajemen memiliki kebijakan yang mencegah pembuatan alamat IP publik. Langganan yang berada di bawah Online Grup Manajemen memungkinkan konektivitas internet dan akses publik secara langsung. Untuk informasi selengkapnya tentang kebijakan mana yang diterapkan pada berbagai tingkat desain zona pendaratan Azure, termasuk kebijakan khusus ARO, lihat Kebijakan yang disertakan dalam implementasi referensi zona pendaratan Azure.

Mempertimbangkan rancangan

• Tentukan siapa yang akan mengelola host kontainer:

  • Jika host dikelola secara terpusat, Anda dapat mengurangi jumlah instans zona pendaratan. Mengharuskan pengembang untuk mengikuti proses yang ditentukan untuk menyebarkan host dan menggunakan dasbor dan pemberitahuan bersama untuk operasi tingkat beban kerja.

  • Jika tim beban kerja mengelola host, Anda memerlukan lebih banyak instans zona pendaratan untuk segmentasi lingkungan host. Tim beban kerja dapat mengontrol penyebaran mereka.

  • Apakah host dikelola secara terpusat oleh tim beban kerja, perluas pertimbangan ini ke sumber daya yang berdampingan dan terkait seperti firewall aplikasi web, brankas kunci, agen build alur, dan berpotensi untuk jump box.

• Pilih model sewa untuk kluster:

  • Beban kerja yang dioperasikan tim, penyewa tunggal: Host kluster tunggal yang mendukung satu beban kerja kemungkinan memerlukan zona pendaratan khusus untuk segmentasi dan kontrol tim beban kerja.

  • Platform teknologi, host multipenyewa: Ketika host dikelola secara terpusat, efisiensi operasional berasal dari mengonsolidasikan beberapa host dan beberapa beban kerja dalam langganan zona pendaratan bersama. Konsolidasi mengurangi jumlah zona pendaratan dan host yang didedikasikan untuk mendukung satu kluster atau beban kerja.

    Anda mungkin perlu menambahkan langganan zona pendaratan jika segmentasi diperlukan untuk memisahkan beban kerja berdasarkan wilayah, unit bisnis, lingkungan, kekritisan, atau batasan eksternal lainnya.

    Tip

    Tinjau menyesuaikan arsitektur zona pendaratan Azure untuk memenuhi persyaratan sebelum membuat Grup Manajemen tambahan.

  • Penyewa tunggal yang dioperasikan secara terpusat: Untuk beban kerja yang bermusuhan atau diatur yang masih dioperasikan secara terpusat, biasanya memiliki host khusus untuk beban kerja. Anda mungkin masih mengalami efisiensi operasional dengan mengonsolidasikan zona pendaratan pendukung.

• Pilih hierarki grup manajemen berdasarkan skala umum dan penyelarasan lingkungan dan host yang diperlukan untuk mendukung persyaratan portofolio secara keseluruhan:

  • Gunakan struktur datar untuk mendukung banyak host khusus di lingkungan khusus untuk operasi terdesentralisasi yang dijalankan oleh setiap tim beban kerja.
  • Gunakan struktur tersegmentasi untuk membuat grup manajemen untuk host yang dikelola secara terpusat dan grup manajemen terpisah untuk operasi terdesentralisasi.
  • Gunakan struktur hierarkis untuk lingkungan segmen lebih lanjut untuk mencerminkan persyaratan penagihan, tata kelola, atau operasional.

• Tentukan registri kontainer mana yang akan digunakan:

  • Gunakan registri Red Hat OpenShift Container Platform terintegrasi. Pertimbangkan faktor-faktor ini:
    • Anda harus mengonfigurasi registri kontainer bawaan.
    • Untuk registri kontainer berkualitas perusahaan, gunakan registri Red Hat Quay.
  • Gunakan Azure Container Registry. Pertimbangkan faktor-faktor ini:
    • Menerapkan praktik terbaik Azure Container Registry.
    • Gunakan pola karantina untuk memastikan bahwa registri hanya berisi gambar yang telah dipindai kerentanan.
  • Gunakan registri kontainer pihak ketiga.

• Tentukan topologi registri kontainer mana yang akan digunakan untuk distribusi artefak Open Container Initiative (OCI):

  • Satu registri per beban kerja.
  • Satu registri per kluster, dengan beberapa beban kerja dalam registri.
  • Satu registri untuk semua kluster di zona pendaratan, dengan beberapa beban kerja dan kluster dalam registri yang sama.
  • Satu registri untuk semua kluster di beberapa zona pendaratan, dengan beberapa beban kerja dan kluster dalam registri yang sama.

• Tentukan cakupan kebijakan registri kontainer di Azure Policy:

  • Tetapkan kebijakan di tingkat langganan untuk mengharuskan semua host di zona pendaratan menggunakan registri yang ditentukan.
  • Tetapkan lebih banyak kebijakan granular di tingkat grup sumber daya.
  • Tetapkan kebijakan yang lebih luas di tingkat grup manajemen.

Rekomendasi desain

• Tentukan standar penamaan dan pemberian tag untuk diterapkan ke semua sumber daya kontainer yang disebarkan ke Azure. Minimal, standar harus mencakup:
  • Nama beban kerja: Beban kerja atau beban kerja yang didukung setiap kluster.
  • Sumber daya kluster: Elevasi penyelarasan sumber daya kluster dari pertimbangan sebelumnya.
  • Operator host: Tim mana yang bertanggung jawab atas operasi host.
• Terapkan kebijakan untuk memerlukan registri artefak OCI tertentu yang didasarkan pada topologi registri kontainer organisasi Anda.

Langkah berikutnya

• Tinjau rekomendasi keamanan untuk Azure Red Hat OpenShift.