Penyebaran full-stack dengan Azure Developer CLI

Aplikasi tumpukan penuh yang menggabungkan layanan front-end dan back-end adalah pola umum dalam pengembangan web modern. Azure Developer CLI (azd) mendukung penyebaran aplikasi tumpukan penuh di mana ujung depan dan ujung belakang dihosting sebagai layanan terpisah. Artikel ini menjelaskan cara menyebarkan aplikasi tumpukan penuh menggunakan azd dan menyoroti strategi dan manfaat untuk penyebaran yang efektif.

Apa itu penyebaran tumpukan penuh?

Penyebaran tumpukan penuh dengan azd biasanya terdiri dari:

  • Layanan front-end: Aplikasi web yang menghadap pengguna, sering dibangun dengan kerangka kerja seperti React, Angular, Vue, atau Blazor. Front end mungkin dihost sebagai situs statis atau sebagai aplikasi kontainer.
  • Layanan back-end: API atau lapisan layanan yang menangani logika bisnis, akses data, dan integrasi. Back end biasanya dihosting dalam kontainer atau sebagai fungsi tanpa server.
  • Sumber daya bersama: Database, akun penyimpanan, brankas kunci, dan sumber daya Azure lainnya yang mungkin digunakan kedua layanan.

Dengan menggunakan azd, Anda dapat menentukan kedua layanan dalam satu azure.yaml file dan memprovisikannya bersama-sama menggunakan infrastruktur sebagai kode (Bicep atau Terraform).

Siklus hidup Azure Developer CLI

Azure Developer CLI mengikuti alur kerja terstruktur dengan peristiwa siklus hidup yang berbeda:

Diagram memperlihatkan siklus hidup Azure Developer CLI dengan fase paket, provisi, dan penyebaran.

  1. Paket: Buat kode sumber aplikasi Anda dan siapkan artefak untuk penyebaran.
  2. Provisi: Membuat atau memperbarui sumber daya infrastruktur Azure dengan menggunakan Bicep atau Terraform.
  3. Sebarkan: Sebarkan kode aplikasi paket Anda ke infrastruktur yang disediakan.

Perintah azd up menjalankan ketiga fase secara berurutan. Anda juga dapat menjalankan setiap fase secara independen dengan menggunakan azd package, azd provision, dan azd deploy untuk kontrol yang lebih terperinci. Memahami siklus hidup ini sangat penting untuk mengelola dependensi antar layanan, terutama dalam deployment full-stack di mana waktu dan urutan sangat penting.

Untuk informasi selengkapnya tentang azd kustomisasi siklus hidup dan alur kerja, lihat Menjelajahi alur kerja azd up.

Pertimbangan desain infrastruktur

Saat menyusun aplikasi full-stack dengan azd, pilih layanan hosting Azure yang sesuai untuk front-end dan back-end Anda.

Jenis layanan Pilihan hosting Skenario penggunaan
Front-end Azure Static Web Apps, Azure App Service, Azure Container Apps Situs statis, SPAs, aplikasi yang dirender server
Back-end Azure Container Apps, Azure App Service, Azure Functions, Azure Kubernetes Service API, layanan mikro, fungsi tanpa server

Pelajari selengkapnya tentang menghosting aplikasi di Azure.

Memahami interdependensi antara aplikasi front-end dan back-end

Penyebaran tumpukan penuh sering mengalami tantangan dependensi melingkar di mana setiap layanan membutuhkan informasi tentang yang lain sebelum dapat dikonfigurasi sepenuhnya. Memahami interdependensi ini membantu Anda merancang alur kerja penyebaran yang efektif.

Diagram yang mengilustrasikan dependensi melingkar antara layanan front-end dan back-end dalam penyebaran tumpukan penuh.

Front-end memerlukan URL back-end: Aplikasi front-end Anda biasanya perlu mengetahui URL titik akhir API back-end pada waktu build atau runtime. Namun, layanan back-end tidak memiliki URL hingga disebarkan ke Azure.

Back-end memerlukan URL front-end: Layanan back-end Anda mungkin memerlukan URL front-end untuk mengonfigurasi kebijakan CORS, tetapi front-end tidak memiliki URL hingga disebarkan.

Dependensi sumber daya bersama: Kedua layanan mungkin bergantung pada sumber daya bersama seperti database, brankas kunci, atau akun penyimpanan. Sumber daya ini harus disediakan sebelum salah satu layanan dapat dikonfigurasi untuk menggunakannya.

Konfigurasi khusus lingkungan: Lingkungan yang berbeda (pengembangan, penahapan, produksi) memerlukan URL dan konfigurasi titik akhir yang berbeda, tetapi nilai-nilai ini tidak diketahui sampai provisi selesai.

Memahami strategi konfigurasi

Azure Developer CLI menangani interdependensi ini melalui dua pendekatan:

  • Konfigurasi waktu penyebaran: Mengatasi dependensi selama provisi dan penyebaran
  • Konfigurasi runtime: Menunda konfigurasi dependensi hingga saat aplikasi berjalan

Pendekatan ini mewakili keputusan desain yang Anda buat saat membangun aplikasi Anda. Anda dapat menggunakan satu strategi secara eksklusif atau menggabungkan keduanya tergantung pada arsitektur dan persyaratan Anda.

Diagram membandingkan strategi konfigurasi deploy-time versus runtime untuk penyebaran tumpukan penuh.

Konfigurasi pada saat penerapan

Konfigurasi waktu penyebaran berarti bahwa koneksi dan konfigurasi layanan ditentukan dan dikunci selama fase azd provision dan azd deploy. Dengan menggunakan pendekatan ini, Anda mengonfigurasi layanan dengan URL titik akhir tertentu, string koneksi, dan informasi dependensi lainnya sebelum mulai berjalan. Konfigurasi ini menjadi bagian dari lingkungan layanan yang disebarkan, baik sebagai variabel lingkungan atau dalam file konfigurasi yang dibungkus dengan penyebaran.

Infrastruktur dibangun terlebih dahulu: Saat Anda menjalankan azd up atau azd provision, infrastruktur dibuat lebih dulu. Langkah ini menghasilkan URL dan string koneksi yang diperlukan sebelum penyebaran dimulai, memastikan layanan dependen memiliki informasi yang mereka butuhkan.

Variabel keluaran: Bicep dan Terraform dapat menghasilkan nilai, seperti URL dan string koneksi, setelah penyediaan. Output ini tersedia sebagai variabel lingkungan selama fase penyebaran, sehingga Anda dapat mengonfigurasi layanan dengan titik akhir yang benar sebelum dimulai.

Penyebaran berurutan: Untuk skenario kompleks, Anda mungkin perlu menyebarkan layanan dalam urutan tertentu. Gunakan azdhooks untuk mengontrol urutan penyebaran, memastikan bahwa layanan pra-syarat berjalan sebelum layanan dependen disebarkan.

Pola upsert kontainer: Azure Verified Modules (AVM) menyediakan pola aplikasi kontainer seperti container-app-upsert yang bekerja dengan mulus dengan alur kerja dua fase azd. Selama penyediaan, infrastruktur dan kontainer awal dibuat. Selama penyebaran, azd melakukan upsert pada citra kontainer dengan variabel lingkungan yang diperbarui, yang mencakup nilai-nilai yang dihasilkan saat provisi, seperti string sambungan database atau URL layanan. Pola ini menyelesaikan masalah ayam dan telur dengan memungkinkan infrastruktur ada terlebih dahulu, lalu memperbarui konfigurasi kontainer dengan semua informasi dependensi yang diperlukan.

Contoh alur kerja untuk front-end React dengan back-end API kontainer:

  1. Jalankan azd up, yang menjalankan tahap paket, penyediaan, dan penerapan secara berurutan.
  2. Saat penyediaan, Bicep membuat infrastruktur Azure Container Apps menggunakan modul AVM container-app-upsert dan mengeluarkan URL API back-end.
  3. Selama penyebaran, azd secara otomatis memperbarui atau menambahkan kedua kontainer dengan variabel lingkungan yang benar, termasuk URL API untuk front-end.
  4. Kedua layanan dimulai dengan konfigurasi yang benar. azd up atau azd deploy di masa mendatang akan menjalankan atau memperbarui kontainer dengan nilai konfigurasi baru.

Konfigurasi runtime

Konfigurasi runtime memungkinkan aplikasi memuat konfigurasi saat aplikasi berjalan alih-alih selama penyebaran. Pendekatan ini memberikan fleksibilitas untuk memperbarui titik akhir layanan, string koneksi, dan kebijakan tanpa menyebarkan ulang aplikasi Anda.

Sumber konfigurasi: Aplikasi dapat memuat konfigurasi runtime dari dua sumber utama:

  • File konfigurasi lokal: Sebarkan file konfigurasi, seperti config.json, bersama aplikasi Anda. Aplikasi memuat file ini saat startup untuk mendapatkan URL titik akhir saat ini, pengaturan autentikasi, dan nilai konfigurasi lainnya. Pendekatan ini berfungsi dengan baik untuk kerangka kerja sisi klien seperti React, Angular, Vue, dan Blazor WebAssembly yang dapat mengambil konfigurasi ketika aplikasi dimulai di browser.

  • Layanan konfigurasi cloud: Gunakan Azure App Configuration atau layanan serupa untuk mengelola konfigurasi secara terpusat di semua lingkungan. Aplikasi mengkueri layanan konfigurasi saat startup atau sesuai permintaan untuk mengambil nilai saat ini. Pendekatan ini berguna untuk arsitektur layanan mikro di mana beberapa layanan memerlukan pembaruan konfigurasi terkoordinasi.

Manfaat: Dengan salah satu pendekatan, perubahan konfigurasi segera tersedia tanpa penyebaran ulang. Perbarui file konfigurasi melalui alur penyebaran Anda, atau ubah nilai di Azure App Configuration melalui portal Microsoft Azure. Saat aplikasi memulai ulang atau me-refresh konfigurasinya, aplikasi mengambil nilai baru. Pola ini sangat berguna untuk:

  • Aplikasi front-end yang perlu menemukan URL API back-end, titik akhir autentikasi, dan lokasi layanan mikro
  • Layanan back-end yang perlu memperbarui kebijakan CORS saat URL front-end berubah
  • Layanan yang membutuhkan konfigurasi yang berbeda di seluruh lingkungan pengembangan, penahapan, dan produksi

Contoh alur kerja untuk front-end React yang menemukan API back-end:

  1. Jalankan azd up untuk memprovisikan infrastruktur dan menyebarkan kedua layanan.
  2. Hook pasca-penyebaran menghasilkan sebuah file config.json yang berisi URL back-end dan mengunggahnya ke lokasi penyimpanan front-end.
  3. Aplikasi React mengambil config.json saat startup untuk menemukan titik akhir API.
  4. Untuk memperbarui titik akhir nanti, ubah config.json tanpa melakukan penerapan ulang pada front-end.

Pendekatan ini tidak berfungsi untuk situs yang dihasilkan secara statis di mana semua konten telah dirender sebelumnya pada waktu build.

Merencanakan alur kerja penyebaran Anda

Pertimbangkan faktor-faktor ini saat merancang penerapan stack lengkap Anda:

  1. Mengidentifikasi dependensi: Memetakan layanan mana yang memerlukan informasi dari layanan lain. Untuk dependensi satu arah (seperti saat API bergantung pada database), platform penyediaan (Bicep atau Terraform) secara otomatis menangani pengurutannya. Untuk dependensi melingkar (seperti layanan front-end dan back-end yang sama-sama membutuhkan URL satu sama lain saat startup), Anda harus merancang koordinasi menggunakan strategi konfigurasi deploy-time atau runtime.
  2. Provisi sebelum penyebaran: Pastikan semua infrastruktur ada sebelum menyebarkan kode aplikasi.
  3. Gunakan variabel lingkungan: Meneruskan konfigurasi antara infrastruktur dan lapisan aplikasi dengan menggunakan variabel lingkungan azd.
  4. Desain untuk beberapa lingkungan: Merencanakan bagaimana konfigurasi berbeda di seluruh lingkungan pengembangan, penahapan, dan produksi.
  5. Pertimbangkan urutan penyebaran: Beberapa skenario mungkin memerlukan penyebaran layanan dalam urutan tertentu.

Perintah azd up menangani sebagian besar skenario penyebaran dengan menjalankan provisi secara otomatis diikuti dengan penyebaran dalam satu alur kerja. Untuk aplikasi tunggal standar, pendekatan ini berfungsi dengan baik dan membutuhkan konfigurasi minimal.

Untuk penyebaran yang lebih rumit, seperti full stack yang memiliki dependensi melingkar:

  • Mengonfigurasi urutan layanan: Dalam file Anda azure.yaml , tentukan layanan dalam urutan yang Anda inginkan untuk disebarkan. Saat azd menyebarkan layanan secara paralel secara default, Anda dapat menggunakan kait untuk memberlakukan penyebaran berurutan saat diperlukan.

  • Kustomisasi langkah-langkah alur kerja: Ambil alih alur kerja default azd up dengan menentukan properti kustom workflows dalam file Anda azure.yaml . Misalnya, Anda dapat mengubah perilaku default untuk menjalankan provisi sebelum membangun kode sumber aplikasi Anda:

    name: todo-nodejs-mongo
    metadata:
      template: todo-nodejs-mongo@0.0.1-beta
    workflows:
      up: 
        steps:
          - azd: provision
          - azd: package
          - azd: deploy
    

    Pola ini berguna ketika proses build Anda memerlukan nilai konfigurasi yang hanya tersedia setelah provisi selesai.

  • Memisahkan provisi dan penyebaran: Alih-alih menggunakan azd up, jalankan azd provision dan azd deploy sebagai perintah terpisah. Pemisahan ini berguna saat Anda perlu memverifikasi konfigurasi infrastruktur sebelum menyebarkan kode aplikasi, atau saat memecahkan masalah penyebaran. Anda dapat menyediakan infrastruktur sekali, lalu menyebarkan dan menyebarkan ulang kode aplikasi beberapa kali tanpa melakukan penyediaan ulang.

  • Kustomisasi dengan hook: Tambahkan hook pra dan pasca di file Anda azure.yaml untuk menjalankan logika kustom antara fase provisioning dan penyebaran. Gunakan kait untuk mengisi file konfigurasi, memvalidasi status lingkungan, atau mengoordinasikan urutan penyebaran yang kompleks.

Praktik terbaik

Saat membangun aplikasi tumpukan penuh dengan azd, ikuti praktik terbaik berikut:

  1. Petakan dependensi lebih awal: Identifikasi layanan mana yang memerlukan informasi dari layanan lain selama fase desain Anda. Memahami perbedaan antara dependensi satu arah yang ditangani secara otomatis oleh Bicep atau Terraform dan dependensi melingkar yang memerlukan strategi konfigurasi selama waktu penyebaran atau eksekusi.
  2. Pilih strategi konfigurasi yang tepat: Gunakan konfigurasi waktu penyebaran saat layanan memerlukan konfigurasi yang dikunci saat penyebaran. Gunakan konfigurasi runtime saat Anda memerlukan fleksibilitas untuk memperbarui konfigurasi tanpa penyebaran ulang. Gabungkan kedua strategi jika sesuai.
  3. Gunakan Modul Terverifikasi Azure (AVM): Manfaatkan modul Bicep Modul Terverifikasi Azure seperti container-app-upsert untuk aplikasi kontainer. Pola-pola ini bekerja dengan mulus dengan azdalur kerja dua tahap untuk menyelesaikan dependensi melingkar.
  4. Kustomisasi alur kerja saat diperlukan: Untuk penyebaran sederhana, gunakan azd up dengan pengaturan default. Untuk skenario kompleks dengan dependensi melingkar, sesuaikan workflows properti dalam azure.yaml file Anda untuk mengontrol urutan paket, provisi, dan tahapan penyebaran.
  5. Memanfaatkan konfigurasi runtime: Untuk fleksibilitas maksimum di seluruh lingkungan, gunakan Azure App Configuration atau file konfigurasi lokal untuk mengelola titik akhir layanan dan pengaturan yang dapat diperbarui tanpa melakukan penyebaran ulang.
  6. Uji di seluruh lingkungan: Pastikan strategi konfigurasi Anda berfungsi dengan benar di seluruh lingkungan pengembangan, penahapan, dan produksi di mana URL dan konfigurasi layanan berbeda.

Langkah selanjutnya