Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Setiap tim pengembangan memiliki persyaratan unik yang dapat membuat penerapan alur penyebaran yang efisien sulit di layanan cloud apa pun. Artikel ini memperkenalkan tiga komponen utama penyebaran ke Azure App Service: sumber penempatan, pipeline build, dan metode penyebaran. Artikel ini juga membahas beberapa praktik terbaik dan tips untuk tumpukan bahasa tertentu.
Komponen Penerapan
Bagian ini menjelaskan tiga komponen utama untuk disebarkan ke App Service.
Sumber penerapan
Sumber penyebaran adalah lokasi kode aplikasi Anda. Untuk aplikasi produksi, sumber penyebaran biasanya merupakan repositori yang dihosting oleh perangkat lunak kontrol versi seperti GitHub, Bitbucket, atau Azure Repos. Untuk skenario pengembangan dan pengujian, sumber penyebaran mungkin merupakan proyek di komputer lokal Anda.
Pipelain pembangunan
Setelah Anda memutuskan sumber penyebaran, langkah Anda selanjutnya adalah memilih jalur pembangunan. Alur build membaca kode sumber Anda dari sumber penyebaran dan menjalankan serangkaian langkah untuk mendapatkan aplikasi dalam keadaan dapat dijalankan.
Langkah-langkah dapat mencakup mengkompilasi kode, menambang HTML dan JavaScript, menjalankan pengujian, dan komponen pengemasan. Perintah tertentu yang dijalankan oleh alur build bergantung pada tumpukan bahasa Anda. Anda dapat menjalankan operasi ini di server build, seperti Azure Pipelines, atau secara lokal.
Mekanisme penyebaran
Mekanisme penyebaran adalah tindakan yang digunakan untuk memasukkan aplikasi bawaan Anda ke direktori /home/site/wwwroot aplikasi web Anda. Direktori /wwwroot adalah lokasi penyimpanan yang dipasang yang dibagikan oleh semua instans aplikasi web Anda. Ketika mekanisme penyebaran menempatkan aplikasi Anda dalam direktori ini, instans Anda menerima pemberitahuan untuk menyinkronkan file baru.
App Service mendukung mekanisme penyebaran berikut:
- Titik akhir Kudu: Kudu adalah alat produktivitas pengembang sumber terbuka yang berjalan sebagai proses terpisah di Windows App Service. Ini berjalan sebagai kontainer kedua di Linux App Service. Kudu menangani penyebaran berkelanjutan dan menyediakan titik akhir HTTP untuk penyebaran, seperti zipdeploy/.
- FTP dan WebDeploy: Menggunakan info masuk situs atau penggunaAnda, Anda dapat mengunggah file melalui FTP atau WebDeploy. Mekanisme ini tidak melalui Kudu.
Alat penyebaran seperti Azure Pipelines, Jenkins, dan plugin editor menggunakan salah satu mekanisme penyebaran ini.
Gunakan slot untuk penyebaran
Jika memungkinkan, saat Anda menyebarkan build produksi baru, gunakan slot penyebaran. Dengan tingkat Paket App Service Standar atau yang lebih baik, Anda dapat menyebarkan aplikasi ke lingkungan penahapan, memvalidasi perubahan, dan melakukan pengujian asap. Setelah Anda siap, tukar slot panggung dan produksi Anda. Operasi pertukaran menyiapkan instans pekerja yang diperlukan agar sesuai dengan skala produksi Anda, memastikan tidak ada waktu henti.
Terus menyebarkan kode
Jika proyek Anda memiliki branch yang ditunjuk untuk pengujian, QA, dan staging, masing-masing branch tersebut harus terus disebarkan ke slot staging. Pendekatan ini dikenal sebagai desain Gitflow. Desain ini memungkinkan pemangku kepentingan Anda untuk dengan mudah menilai dan menguji cabang yang disebarkan.
Penyebaran berkelanjutan tidak boleh diaktifkan untuk slot produksi Anda. Sebagai gantinya, cabang produksi Anda (sering kali utama) harus disebarkan ke slot nonproduksi. Ketika Anda siap untuk merilis cabang dasar, tukarkan ke slot produksi. Menukar ke lingkungan produksi, alih-alih menerapkan ke lingkungan produksi, mencegah waktu henti dan memungkinkan Anda untuk mengembalikan perubahan dengan menukar kembali.
Terus menyebarkan kontainer
Untuk kontainer kustom dari Docker atau registri kontainer lainnya, sebarkan image ke slot staging dan swap ke slot produksi untuk mencegah waktu henti. Otomatisasi lebih kompleks daripada penyebaran kode. Anda harus mendorong gambar ke registri kontainer dan memperbarui tag gambar di webapp.
Untuk setiap branch yang ingin Anda sebarkan ke slot, siapkan otomatisasi untuk melakukan tugas-tugas ini pada setiap commit ke branch tersebut.
- Buat dan beri tag pada gambar. Sebagai bagian dari alur build, tandai gambar dengan ID komit git, tanda waktu, atau informasi identitas lainnya. Sebaiknya jangan gunakan tag latest default. Jika tidak, sulit untuk melacak kembali kode apa yang saat ini dikerahkan, yang membuat penelusuran kesalahan lebih sulit.
- Unggah gambar yang ditandai. Setelah citra dibuat dan ditandai, alur mengunggah citra ke registri kontainer. Pada langkah berikutnya, slot penyebaran menarik gambar yang ditandai dari registri kontainer.
- Perbarui slot penempatan dengan tag gambar baru. Ketika properti ini diperbarui, situs secara otomatis memulai ulang dan menarik gambar kontainer baru.
Artikel ini berisi contoh untuk kerangka kerja otomatisasi umum.
Gunakan Azure DevOps
App Service memiliki fitur integrasi pengiriman berkelanjutan untuk kontainer melalui Pusat Penyebaran (Deployment Center). Navigasi ke aplikasi Anda di portal Azure. Di bawah Penyebaran, pilih Pusat Penyebaran. Ikuti instruksi untuk memilih repositori dan cabang Anda. Pendekatan ini mengonfigurasi alur build-and-release DevOps untuk secara otomatis membuat, menandai, dan menyebarkan kontainer Anda saat komit-komit baru didorong ke cabang yang Anda pilih.
Gunakan GitHub Actions
Anda juga dapat mengotomatiskan penyebaran kontainer Anda dengan GitHub Actions. File alur kerja menyusun dan menandai kontainer dengan ID penerapan, mendorongnya ke registri kontainer, dan memperbarui aplikasi web yang ditentukan dengan tag gambar baru.
on:
push:
branches:
- <your-branch-name>
name: Linux_Container_Node_Workflow
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# checkout the repo
- name: 'Checkout GitHub Action'
uses: actions/checkout@main
- uses: azure/docker-login@v1
with:
login-server: contoso.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
- run: |
docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
- uses: azure/webapps-deploy@v2
with:
app-name: 'node-rnc'
publish-profile: ${{ secrets.azureWebAppPublishProfile }}
images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'
Gunakan penyedia otomatisasi lainnya
Langkah-langkah yang tercantum sebelumnya berlaku untuk utilitas otomatisasi lain seperti CircleCI atau Travis CI. Namun, Anda perlu menggunakan Azure CLI untuk memperbarui slot penyebaran dengan tag gambar baru di langkah terakhir. Untuk menggunakan Azure CLI di skrip otomatisasi Anda, buat Perwakilan Layanan menggunakan perintah berikut.
az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
--scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
--sdk-auth
Dalam skrip Anda, masuk menggunakan az login --service-principal
dengan menyediakan informasi utama. Anda kemudian dapat menggunakan az webapp config container set
untuk mengatur nama kontainer, tag, URL registri, dan kata sandi registri. Untuk informasi selengkapnya, lihat Cara masuk ke Azure CLI di Circle CI.
Pertimbangan khusus bahasa
Perlu diingat pertimbangan berikut untuk implementasi Java, Node, dan .NET.
Jawa
Gunakan API zipdeploy Kudu untuk menyebarkan aplikasi JAR. Gunakan wardeploy untuk aplikasi WAR. Jika Anda menggunakan Jenkins, Anda dapat menggunakan API tersebut secara langsung dalam fase penyebaran Anda. Untuk informasi selengkapnya, lihat Menyebarkan ke Azure App Service dengan Jenkins.
Simpul
Secara default, Kudu menjalankan langkah-langkah build untuk aplikasi Node Anda (npm install
). Jika Anda menggunakan layanan build seperti Azure DevOps, build Kudu tidak diperlukan. Untuk menonaktifkan build Kudu, buat pengaturan aplikasi, SCM_DO_BUILD_DURING_DEPLOYMENT
, dengan nilai false
.
.NET
Secara default, Kudu menjalankan langkah-langkah build untuk aplikasi .NET Anda (dotnet build
). Jika Anda menggunakan layanan build seperti Azure DevOps, build Kudu tidak diperlukan. Untuk menonaktifkan build Kudu, buat pengaturan aplikasi, SCM_DO_BUILD_DURING_DEPLOYMENT
, dengan nilai false
.
Pertimbangan penyebaran lainnya
Pertimbangan lain termasuk cache lokal dan CPU atau memori tinggi.
Cache lokal
Konten Azure App Service disimpan di Azure Storage dan ditampilkan dengan cara yang tahan lama sebagai konten berbagi. Namun, beberapa aplikasi hanya memerlukan penyimpanan konten berkinerja tinggi yang bersifat baca-saja dan dapat dijalankan dengan ketersediaan tinggi. Aplikasi ini dapat memperoleh manfaat dari menggunakan cache lokal. Untuk informasi selengkapnya, lihat Panduan Gambaran Umum Cache Lokal Azure App Service.
Catatan
Cache lokal tidak disarankan untuk situs manajemen konten seperti WordPress.
Untuk mencegah downtime, selalu gunakan cache lokal dengan penyebaran slot. Untuk informasi tentang menggunakan fitur-fitur ini bersama-sama, lihat Praktik terbaik.
CPU atau memori tinggi
Jika Paket App Service Anda menggunakan lebih dari 90% CPU atau memori yang tersedia, komputer virtual yang mendasar mungkin mengalami masalah dalam memproses penyebaran Anda. Ketika situasi ini terjadi, tingkatkan jumlah instans Anda untuk sementara waktu untuk melakukan penyebaran. Setelah penyebaran selesai, Anda dapat mengembalikan jumlah instans ke nilai sebelumnya.
Untuk informasi selengkapnya, kunjungi App Service Diagnostics untuk mengetahui praktik terbaik yang dapat ditindaklanjuti dan yang khusus untuk sumber daya Anda.
Navigasi ke Web App Anda di portal Azure.
Pilih Diagnosis dan selesaikan masalah di navigasi kiri, yang membuka Diagnostik App Service.
Pilih Ketersediaan dan Performa atau jelajahi opsi lain, seperti Analisis CPU Tinggi.
Lihat status aplikasi Anda saat ini sehubungan dengan praktik terbaik ini.
Anda juga dapat menggunakan tautan ini untuk langsung membuka Diagnostik App Service untuk sumber daya Anda: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot
.