Mengelola lingkungan pengembangan aplikasi di zona pendaratan Azure

Artikel
12/13/2023

Artikel ini menjelaskan bagaimana tim platform cloud dapat menerapkan pagar pembatas untuk mengelola lingkungan aplikasi di zona pendaratan Azure. Ini juga menjelaskan cara menyelaraskan berbagai lingkungan pengembangan aplikasi dengan kerangka kerjanya. Aspek utama dalam membuat lingkungan yang tepat adalah menempatkan langganan di grup manajemen yang sesuai.

Mengatur fondasi

Tim pengembangan memerlukan kemampuan untuk melakukan iterasi dengan cepat, dan tata kelola cloud dan tim platform perlu mengelola risiko organisasi, kepatuhan, dan keamanan dalam skala besar. Anda dapat mengelola lingkungan aplikasi dengan benar dengan berfokus pada dua prinsip desain zona pendaratan Azure utama: tata kelola berbasis kebijakan dan demokratisasi langganan. Prinsip-prinsip ini menyediakan pagar pembatas dasar dan menjelaskan cara mendelegasikan kontrol ke tim aplikasi. Tim aplikasi menggunakan panduan Azure Well-Architected Framework untuk merancang beban kerja mereka. Mereka menyebarkan dan mengelola sumber daya zona pendaratan mereka sendiri, dan tim platform mengontrol sumber daya dengan menetapkan kebijakan Azure.

Penting untuk menyediakan sumber daya kotak pasir untuk sumber daya semi-diatur , sehingga tim aplikasi dapat bereksperimen dengan teknologi dan kemampuan.

Saat pemilik aplikasi menggunakan penjual langganan atau proses pembuatan langganan lainnya, mereka harus tahu cara meminta langganan untuk beberapa lingkungan pengembangan.

Artikel ini menjelaskan zona pendaratan Azure, termasuk grup manajemen, kebijakan, dan arsitektur platform bersama, dan beban kerja atau zona pendaratan aplikasi.

Catatan

Panduan dalam artikel ini hanya untuk beban kerja atau zona pendaratan aplikasi. Untuk pengujian dan pemisahan lingkungan untuk platform zona pendaratan Azure itu sendiri, lihat Pendekatan pengujian untuk zona pendaratan Azure, yang menjelaskan pendekatan kenari.

Dalam praktiknya, Anda dapat menggunakan jumlah dan jenis lingkungan bertahas apa pun. Artikel ini mereferensikan lingkungan bertahas berikut.

Lingkungan	Deskripsi	Grup manajemen
Sandbox	Lingkungan yang digunakan untuk inovasi prototipe yang cepat tetapi bukan konfigurasi terikat produksi	Grup manajemen kotak pasir
Pengembangan	Lingkungan yang digunakan untuk membangun kandidat rilis potensial	Grup manajemen arketipe, seperti corp atau online
Tes	Lingkungan yang digunakan untuk melakukan pengujian, termasuk pengujian unit, pengujian penerimaan pengguna, dan pengujian jaminan kualitas	Grup manajemen arketipe, seperti corp atau online
Produksi	Lingkungan yang digunakan untuk memberikan nilai kepada pelanggan	Grup manajemen arketipe, seperti corp atau online

Untuk informasi selengkapnya, lihat video Menangani lingkungan pengembangan, pengujian, dan produksi untuk beban kerja aplikasi dan Berapa banyak langganan yang harus saya gunakan di Azure?

Lingkungan, langganan, dan grup manajemen

Sebagai prasyarat untuk bagian ini, lihat Area desain organisasi sumber daya.

Anda harus mengatur langganan dengan benar saat mengadopsi praktik zona pendaratan Azure. Idealnya, setiap lingkungan aplikasi harus memiliki langganannya sendiri. Metode ini menyediakan kontrol keamanan dan kebijakan yang menjaga lingkungan tetap terisolasi. Ini berisi potensi masalah ke satu lingkungan.

Langganan terpisah memiliki kebijakan yang sama pada tingkat arketipe. Jika diperlukan, pemilik aplikasi dapat menetapkan kebijakan khusus langganan untuk memberlakukan aplikasi dan perilaku khusus lingkungan.

Beberapa arsitektur aplikasi mengharuskan layanan dibagikan di antara lingkungan. Jika demikian, Anda dapat menggunakan satu langganan untuk beberapa lingkungan. Kami menyarankan agar pemilik beban kerja bekerja dengan tim platform cloud untuk menentukan apakah satu langganan untuk beberapa lingkungan diperlukan.

Gunakan satu langganan untuk beberapa lingkungan aplikasi jika:

Lingkungan tidak dapat diisolasi dalam langganan mereka sendiri.
Lingkungan memiliki tim yang sama yang ditetapkan ke peran fungsi, seperti operator jaringan.
Lingkungan dapat menggunakan kebijakan yang sama.

Jika beban kerja aplikasi atau layanan perlu berada dalam satu langganan, dan Anda perlu membuat perubahan pada kebijakan yang berlaku untuk setiap lingkungan, Anda dapat:

Buat grup manajemen baru yang selaras dengan arketipe di bawah grup manajemen zona pendaratan. Untuk informasi selengkapnya, lihat Hierarki grup manajemen di artikel ini.
Gunakan langganan kotak pasir untuk aktivitas pengembangan. Kotak pasir memiliki set kebijakan yang tidak terlalu ketat.
Gunakan kebijakan yang diterapkan di tingkat langganan alih-alih tingkat grup manajemen. Anda dapat menambahkan tag dalam definisi kebijakan untuk membantu memfilter dan menerapkan kebijakan ke lingkungan yang benar. Anda juga dapat menetapkan kebijakan ke atau mengecualikannya dari grup sumber daya tertentu.

Anda dapat menetapkan kebijakan selama proses pembuatan langganan sebagai bagian dari penjual langganan.

Untuk kebijakan yang Anda terapkan untuk membantu mengontrol biaya, terapkan definisi kebijakan pada tingkat langganan jika diperlukan. Atau Anda dapat membuat pemilik zona pendaratan bertanggung jawab atas biaya, yang memberikan otonomi sejati. Untuk informasi selengkapnya, lihat Otomatisasi platform dan DevOps.

Peringatan

Tidak seperti kebijakan dan kontrol di tingkat grup manajemen, kebijakan dan tag berbasis langganan dapat diubah oleh individu dengan izin yang ditingkatkan ke langganan. Administrator dengan peran yang sesuai dapat melewati kontrol ini dengan mengecualikan kebijakan, memodifikasi kebijakan, atau mengubah tag pada sumber daya.

Akibatnya, Anda tidak boleh menerapkan tag dalam definisi kebijakan yang berfokus pada keamanan. Selain itu, jangan tetapkan izin sebagai selalu aktif untuk tindakan berikut:

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

Anda dapat mengontrol tindakan ini dengan menggunakan Privileged Identity Management (PIM).

Hierarki grup manajemen

Hindari hierarki grup manajemen yang rumit. Mereka dapat memerlukan amandemen yang sering, skala tidak efisien, dan nilai kurang. Untuk menghindari potensi masalah ini, grup manajemen zona pendaratan Azure diselaraskan dengan arketipe beban kerja. Untuk informasi selengkapnya, lihat Grup manajemen dan organisasi langganan.

Selaras dengan arketipe berarti bahwa grup manajemen hanya dibuat untuk arketipe beban kerja tertentu. Misalnya, dalam arsitektur konseptual, grup manajemen zona pendaratan memiliki grup manajemen corp dan anak online . Grup manajemen anak ini selaras dengan pola arketipe yang berbeda untuk beban kerja yang mereka miliki. Grup manajemen anak berfokus pada persyaratan konektivitas hibrid (VPN/Azure ExpressRoute), seperti hanya internal versus aplikasi dan layanan yang menghadap publik.

Tidak termasuk lingkungan kotak pasir, berbagai lingkungan aplikasi harus menggunakan arketipe yang sama untuk penyebaran. Bahkan jika lingkungan dibagi di beberapa langganan, lingkungan tersebut disimpan dalam grup manajemen tunggal yang sama (corp atau online), berdasarkan arketipe grup manajemen dan persyaratan.

Anda dapat menggunakan langganan kotak pasir untuk pengembangan yang tidak terstruktur, seperti lab pribadi atau untuk beban kerja yang tidak memiliki arketipe. Tim beban kerja aplikasi atau layanan menggunakan grup manajemen kotak pasir untuk menguji berbagai layanan Azure untuk menentukan apa yang paling sesuai dengan kebutuhan mereka. Setelah memutuskan layanan, mereka dapat menyediakan zona pendaratan (dalam grup manajemen yang selaras dengan arketipe beban kerja yang benar di hierarki grup manajemen zona pendaratan) untuk tim.

Lingkungan kotak pasir dapat digunakan untuk aplikasi tertentu, atau tim beban kerja dapat menggunakannya untuk eksperimen.

Untuk informasi selengkapnya, lihat:

Grup manajemen.
Area desain organisasi sumber daya.
Sesuaikan arsitektur zona pendaratan Azure untuk memenuhi persyaratan.

Tantangan grup manajemen berbasis lingkungan

Grup manajemen untuk lingkungan dalam arketipe dapat menambahkan overhead manajemen dan memberikan nilai minimal.

Grup manajemen zona pendaratan harus memiliki kebijakan universal yang memberlakukan pagar pembatas untuk grup manajemen corp dan anak online. Corp dan online memiliki kebijakan unik yang menegakkan pedoman perusahaan yang terkait dengan beban kerja publik dan privat.

Banyak organisasi membuat grup manajemen terpisah untuk lingkungan siklus hidup pengembangan perangkat lunak beban kerja (SDLC) untuk menetapkan kebijakan dan kontrol lingkungan. Dalam praktiknya, metode ini menciptakan lebih banyak tantangan bagi tim beban kerja daripada yang dipecahkan. Lingkungan SDLC tidak boleh memiliki kebijakan yang berbeda, jadi kami tidak merekomendasikan grup manajemen terpisah.

Pemilik aplikasi dapat mengubah topologi atau konfigurasi sumber daya beban kerja untuk menyelaraskan dengan kebijakan di beberapa lingkungan SDLC yang dipromosikan. Metode ini meningkatkan risiko. Aturan yang khusus untuk setiap lingkungan dapat mengakibatkan pengalaman pengembangan yang buruk bagi pengembang dan tim jaminan kualitas. Masalah juga dapat muncul jika aplikasi memiliki satu set kebijakan pagar pembatas yang berfungsi di satu lingkungan, dan aplikasi diekspos ke serangkaian kebijakan yang berbeda nanti dalam siklus promosinya. Anda mungkin harus membuat penyesuaian pada aplikasi jika kontrol berubah.

Untuk mencegah pekerjaan ekstra ini, buat kebijakan yang konsisten di seluruh promosi kode di lingkungan SDLC. Anda tidak boleh membuat kebijakan untuk setiap lingkungan, tetapi sebaliknya menyediakan set yang konsisten untuk semua lingkungan pengembangan, tidak termasuk lingkungan kotak pasir.

Misalnya, bayangkan organisasi mendefinisikan kebijakan yang mengharuskan akun penyimpanan dikonfigurasi dengan aturan firewall tertentu untuk mencegah masuknya dari jaringan publik. Sebagai gantinya, akun penyimpanan menggunakan titik akhir privat di dalam jaringan zona pendaratan Azure untuk komunikasi. Jika lingkungan pengembangan tidak memiliki kebijakan seperti itu, menguji beban kerja tidak menemukan kesalahan konfigurasi akun penyimpanan yang memungkinkan akses publik. Penyebaran pengujian berfungsi di lingkungan pengembangan dan diulang. Ketika solusi dipromosikan ke lingkungan lain yang memiliki kebijakan akun penyimpanan, penyebaran gagal karena kebijakan yang diberlakukan.

Akibatnya, tim pengembangan aplikasi harus mengerjakan ulang penyebaran dan arsitektur mereka, setelah menginvestasikan upaya yang signifikan. Contoh ini menunjukkan bagaimana kebijakan yang berbeda di berbagai lingkungan dapat menciptakan masalah.

Catatan

Persamaan berikut menunjukkan mengapa grup manajemen terpisah untuk setiap lingkungan atau beban kerja tidak diskalakan dengan baik: N beban kerja x grup manajemen Z = total grup manajemen.

Jika organisasi memiliki 30 beban kerja yang masing-masing memerlukan grup manajemen dan grup manajemen anak untuk lingkungan pengembangan, pengujian, dan produksi, organisasi dibiarkan dengan:

N = jumlah beban kerja/aplikasi = 30

Z = jumlah grup manajemen untuk beban kerja dan lingkungan (1 untuk beban kerja + 3 untuk lingkungan) = 4

N (30) x Z (4) = 120 total grup manajemen

Pemilik aplikasi mungkin memerlukan kebijakan untuk diterapkan secara berbeda ke beberapa lingkungan. Misalnya, pemilik aplikasi mungkin memerlukan konfigurasi cadangan untuk lingkungan produksi tetapi tidak untuk lingkungan lain.

Beberapa kebijakan dapat diaktifkan sebagai kebijakan audit di tingkat grup manajemen. Tim aplikasi menentukan cara menerapkan kontrol. Metode ini tidak mencegah penyebaran, tetapi menciptakan kesadaran dan memungkinkan tim aplikasi untuk mengelola kebutuhan unik mereka. Mereka kemudian dapat membuat kebijakan sublevel atau memasukkan persyaratan ini ke dalam modul penyebaran infrastruktur sebagai kode (IaC).

Dalam model tanggung jawab bersama ini, tim platform mengaudit praktik, dan tim aplikasi mengelola implementasi. Model ini dapat meningkatkan kelincahan penyebaran.

Operator platform harus bekerja dengan setiap aplikasi atau tim beban kerja layanan (pemilik zona pendaratan) untuk memahami persyaratan mereka. Operator platform dapat menyediakan langganan berdasarkan persyaratan dan paket aplikasi. Operator platform mungkin juga memutuskan untuk menunjuk lini produk untuk berbagai jenis beban kerja sehingga mereka dapat membangun proses pembuatan langganan dan peralatan berdasarkan persyaratan umum dari tim beban kerja aplikasi atau layanan.

Skenario: Beban kerja berbasis komputer virtual (VM)

Beban kerja awal di zona pendaratan Azure sering terdiri dari Azure VM. Anda dapat menyebarkan beban kerja ini di Azure atau memigrasikannya dari pusat data yang ada.

Alih-alih menyebarkan VM ke beberapa lingkungan dalam satu langganan, Anda dapat:

Buat langganan untuk setiap lingkungan aplikasi, dan tempatkan semuanya dalam grup manajemen arketipe yang sama.
Sebarkan jaringan virtual untuk setiap lingkungan aplikasi dalam langganan yang sesuai. Anda dapat menentukan ukuran jaringan virtual berdasarkan ukuran lingkungan aplikasi.
Sebarkan VM ke langganan yang sesuai. VM dapat menggunakan SKU yang berbeda dan konfigurasi ketersediaan yang berbeda untuk setiap lingkungan, jika sesuai.

Berbagai sumber daya lingkungan aplikasi dilindungi oleh kontrol akses yang berbeda. Akibatnya, ketika pengembang aplikasi menyiapkan alur penyebaran, identitas setiap alur dapat dibatasi pada lingkungan. Konfigurasi ini membantu melindungi lingkungan dari penyebaran yang tidak disengaja.

Skenario: Azure App Service

Beban kerja dengan langganan lingkungan yang menggunakan App Service dapat menciptakan tantangan. Untuk pengembang aplikasi, praktik terbaik App Service adalah menggunakan slot penyebaran untuk membantu mengelola perubahan dan pembaruan pada aplikasi web.

Namun, fitur ini hanya dapat digunakan dengan aplikasi yang ada di paket App Service, yang hanya dapat hidup dalam satu langganan. Jika operator platform mengamanatkan bahwa pemilik aplikasi menggunakan langganan terpisah untuk lingkungan pengembangan, pengujian, dan produksi, siklus hidup penyebaran aplikasi mungkin lebih sulit dikelola.

Untuk contoh ini, opsi terbaik adalah satu langganan untuk beban kerja aplikasi atau layanan. Pemilik aplikasi dapat menggunakan kontrol akses berbasis peran Azure (RBAC) dengan PIM di tingkat grup sumber daya untuk meningkatkan keamanan.

Bagikan melalui