Bagikan melalui


Fungsionalitas sistem operasi di Azure App Service

Artikel ini menjelaskan fungsionalitas sistem operasi dasar yang tersedia untuk semua aplikasi Windows yang berjalan di Azure App Service. Fungsionalitas ini mencakup akses file, jaringan, dan registri, bersama dengan log dan peristiwa diagnostik.

Nota

Aplikasi Linux di App Service berjalan di kontainer mereka sendiri. Anda memiliki akses root ke kontainer tetapi tidak ada akses ke sistem operasi host. Demikian juga, untuk aplikasi yang berjalan di kontainer Windows, Anda memiliki akses administratif ke kontainer tetapi tidak ada akses ke sistem operasi host.

Tingkat paket layanan App

App Service menjalankan aplikasi pelanggan di lingkungan hosting multipenyewa.

  • Aplikasi yang disebarkan di lapisan Gratis dan Bersama berjalan dalam proses kerja pada mesin virtual yang dibagi bersama.
  • Aplikasi yang disebarkan di tingkat Standar dan Premium berjalan pada VM yang didedikasikan khusus untuk aplikasi yang terkait dengan satu pelanggan.

Nota

Paket layanan App Service Free dan Shared (pratinjau) adalah tingkat dasar yang berjalan pada komputer virtual Azure yang sama dengan aplikasi App Service lainnya. Beberapa aplikasi mungkin milik pelanggan lain. Tingkatan ini hanya ditujukan untuk tujuan pengembangan dan pengujian.

Karena App Service mendukung pengalaman penskalaan yang mulus antar tingkatan, konfigurasi keamanan yang diberlakukan untuk aplikasi App Service tetap sama. Konfigurasi ini memastikan bahwa aplikasi tidak tiba-tiba berperilaku berbeda dan gagal dengan cara yang tidak terduga saat paket App Service beralih dari satu tingkat ke tingkat lainnya.

Kerangka kerja pengembangan

Tingkat harga App Service mengontrol jumlah sumber daya komputasi (CPU, penyimpanan disk, memori, dan keluarnya jaringan) yang tersedia untuk aplikasi. Namun, luasnya fungsionalitas kerangka kerja yang tersedia untuk aplikasi tetap sama terlepas dari tingkat penskalaan.

App Service mendukung berbagai kerangka kerja pengembangan, termasuk ASP.NET, ASP klasik, Node.js, PHP, dan Python. Untuk menyederhanakan dan menormalkan konfigurasi keamanan, aplikasi App Service biasanya menjalankan kerangka kerja pengembangan dengan pengaturan defaultnya. Kerangka kerja dan komponen runtime yang disediakan platform diperbarui secara berkala untuk memenuhi persyaratan keamanan dan kepatuhan. Untuk alasan ini, kami tidak menjamin versi minor atau patch tertentu. Sebaiknya pelanggan menargetkan versi utama sesuai kebutuhan.

Bagian berikut merangkum jenis umum fungsionalitas sistem operasi yang tersedia untuk aplikasi App Service.

Akses file

Berbagai drive ada dalam App Service, termasuk drive lokal dan drive jaringan.

Drive lokal

Pada intinya, App Service adalah layanan yang berjalan di atas infrastruktur platform as a service (PaaS) Azure. Akibatnya, drive lokal yang terkait dengan VM adalah jenis drive yang sama yang tersedia untuk peran pekerja apa pun yang berjalan di Azure. Mereka meliputi:

  • Drive sistem operasi (%SystemDrive%) yang ukurannya tergantung pada ukuran VM.
  • Drive sumber daya (%ResourceDrive%) yang digunakan oleh App Service secara internal.

Praktik terbaik adalah selalu menggunakan variabel lingkungan %SystemDrive% dan %ResourceDrive% daripada jalur file yang dikodekan secara permanen. Jalur akar yang dikembalikan dari dua variabel lingkungan ini telah bergeser dari waktu ke waktu dari d:\ ke c:\. Namun, aplikasi lama yang dihardcode dengan referensi jalur file untuk d:\ terus berfungsi karena App Service secara otomatis memetakan d:\ untuk mengarahkan ke c:\. Seperti disebutkan sebelumnya, kami sangat menyarankan Anda selalu menggunakan variabel lingkungan saat membangun jalur file dan menghindari kebingungan atas perubahan platform ke jalur file akar default.

Penting untuk memantau pemanfaatan disk Anda saat aplikasi Anda tumbuh. Mencapai kuota disk dapat berdampak buruk pada aplikasi Anda. Contohnya:

  • Aplikasi mungkin melemparkan kesalahan yang menunjukkan tidak ada cukup ruang pada disk.
  • Anda mungkin melihat kesalahan disk saat menjelajah ke konsol Kudu.
  • Penyebaran dari Azure DevOps atau Visual Studio mungkin gagal dengan ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
  • Aplikasi Anda mungkin memiliki performa yang lambat.

Drive jaringan (share UNC)

Salah satu aspek unik dari App Service yang membuat penyebaran dan pemeliharaan aplikasi menjadi mudah adalah bahwa semua konten berbagi disimpan dalam serangkaian berbagi Universal Naming Convention (UNC). Model ini memetakan dengan baik pola umum penyimpanan konten yang digunakan oleh lingkungan hosting web lokal yang memiliki beberapa server yang seimbang beban.

Dalam App Service, UNC share dibuat di setiap pusat data. Persentase konten pengguna untuk semua pelanggan di setiap pusat data dialokasikan ke bagian UNC masing-masing. Langganan setiap pelanggan memiliki struktur direktori yang telah disediakan pada share UNC tertentu di pusat data. Pelanggan mungkin memiliki beberapa aplikasi yang dibuat di pusat data tertentu, sehingga semua direktori milik satu langganan pelanggan dibuat pada berbagi UNC yang sama.

Karena cara kerja layanan Azure, VM tertentu yang bertanggung jawab untuk menghosting berbagi UNC berubah dari waktu ke waktu. Saham UNC dipasang oleh VM yang berbeda saat diaktifkan dan dinonaktifkan selama operasi Azure yang normal. Untuk alasan ini, aplikasi tidak boleh membuat asumsi yang dikodekan secara permanen bahwa informasi komputer dalam jalur file UNC tetap stabil dari waktu ke waktu. Sebaliknya, mereka harus menggunakan jalur absolut faux yang nyaman yang disediakan %HOME%\site oleh App Service.

Jalur absolut palsu adalah metode yang memudahkan untuk merujuk ke aplikasi Anda sendiri. Ini tidak khusus untuk aplikasi atau pengguna apa pun. Dengan menggunakan %HOME%\site, Anda dapat mentransfer file bersama dari aplikasi ke aplikasi tanpa harus mengonfigurasi jalur absolut baru untuk setiap transfer.

Jenis akses file yang diberikan ke aplikasi

Direktori %HOME% dalam aplikasi dipetakan ke berbagi konten di Azure Storage yang didedikasikan khusus untuk aplikasi tersebut. Tingkat harga Anda menentukan ukurannya. Ini mungkin termasuk direktori seperti untuk konten, log kesalahan dan diagnostik, dan versi aplikasi yang lebih lama yang dibuat kontrol sumber. Direktori ini tersedia untuk kode aplikasi saat runtime untuk akses baca dan tulis. Karena file tidak disimpan secara lokal, file tersebut persisten di seluruh mulai ulang aplikasi.

Pada drive sistem, App Service mencadangkan %SystemDrive%\local untuk penyimpanan lokal sementara khusus aplikasi. Perubahan pada file dalam direktori ini tidak akan tetap setelah aplikasi dimulai ulang. Meskipun aplikasi memiliki akses baca dan tulis penuh ke penyimpanan lokal sementaranya sendiri, penyimpanan tersebut tidak ditujukan untuk penggunaan langsung oleh kode aplikasi. Sebaliknya, niatnya adalah menyediakan penyimpanan file sementara untuk IIS dan kerangka kerja aplikasi web.

App Service membatasi jumlah penyimpanan untuk %SystemDrive%\local setiap aplikasi untuk mencegah aplikasi individual mengkonsumsi penyimpanan file lokal dalam jumlah yang berlebihan. Untuk tingkat Gratis, Bersama, dan Konsumsi (Azure Functions), batasnya adalah 500 MB. Tabel berikut ini mencantumkan tingkatan lain:

Tier Batas penyimpanan lokal
B1/S1/P1 11 GB
B2/S2/P2 15 GB
B3/S3/P3 58 GB
P0v3/P0v4 11 GB
P1v2/P1v3/P1mv3/P1mv4/Isolated1/Isolated1v2 21 GB
P2v2/P2v3/P2mv3/P2mv4/Isolated2/Isolated2v2 61 GB
P3v2/P3v3/P3mv3/P3mv4/Isolated3/Isolated3v2 140 GB
Terisolasi4v2 276 GB
P4mv3/P4mv4 280 GB
Terisolasi5v2 552 GB
P5mv3/P5mv4 560 GB
Terisolasi6v2 1.104 GB

Direktori untuk file ASP.NET sementara dan direktori untuk file terkompresi IIS adalah dua contoh bagaimana App Service menggunakan penyimpanan lokal sementara. Sistem kompilasi ASP.NET menggunakan %SystemDrive%\local\Temporary ASP.NET Files direktori sebagai lokasi cache kompilasi sementara. IIS menggunakan %SystemDrive%\local\IIS Temporary Compressed Files direktori untuk menyimpan output respons terkompresi. Kedua jenis penggunaan file ini (bersama dengan yang lain) dipetakan ulang di App Service ke penyimpanan lokal sementara per aplikasi. Proses remapping ini membantu memastikan bahwa fungsi tetap berlanjut sesuai harapan.

Setiap aplikasi di App Service berjalan sebagai identitas proses pekerja dengan hak istimewa rendah yang acak dan unik yang disebut identitas pool aplikasi. Kode aplikasi menggunakan identitas ini untuk akses baca-saja dasar ke drive sistem operasi. Akses ini berarti bahwa kode aplikasi dapat mencantumkan struktur direktori umum dan membaca file umum pada drive sistem operasi. Meskipun tingkat akses ini mungkin tampak luas, direktori dan file yang sama dapat diakses saat Anda menyediakan peran pekerja dalam layanan yang dihosting Azure dan membaca konten drive.

Akses file di beberapa instance

Direktori berbagi konten (%HOME%) berisi konten aplikasi, dan kode aplikasi dapat menulis ke dalamnya. Jika aplikasi berjalan pada beberapa instans, %HOME% direktori dibagikan di antara semua instans sehingga semua instans melihat direktori yang sama. Misalnya, jika aplikasi menyimpan file yang diunggah ke %HOME% direktori, file tersebut segera tersedia untuk semua instans.

Direktori penyimpanan lokal sementara (%SystemDrive%\local) tidak dibagikan antar instans. Ini juga tidak dibagikan antar aplikasi dan aplikasi Kudu-nya.

Akses jaringan

Kode aplikasi dapat menggunakan protokol berbasis TCP/IP dan UDP untuk membuat koneksi jaringan keluar ke titik akhir yang dapat diakses internet yang mengekspos layanan eksternal. Aplikasi dapat menggunakan protokol yang sama ini untuk menyambungkan ke layanan dalam Azure--misalnya, dengan membuat koneksi HTTPS ke Azure SQL Database.

Ada juga kapabilitas terbatas bagi aplikasi untuk membuat satu koneksi loopback lokal dan membuat aplikasi mendengarkan soket loopback lokal tersebut. Fitur ini memungkinkan aplikasi untuk mendengarkan soket loopback lokal sebagai bagian dari fungsinya. Setiap aplikasi memiliki koneksi loopback pribadi. Satu aplikasi tidak dapat mendengarkan soket loopback lokal yang dibuat aplikasi lain.

Named pipe juga didukung sebagai mekanisme untuk komunikasi antarproses antara proses yang bersama-sama menjalankan aplikasi. Misalnya, modul IIS FastCGI bergantung pada pipa bernama untuk mengoordinasikan proses individual yang menjalankan halaman PHP.

Eksekusi kode, proses, dan memori

Seperti disebutkan sebelumnya, aplikasi berjalan di dalam proses pekerja dengan hak istimewa rendah dengan menggunakan identitas kumpulan aplikasi acak. Kode aplikasi memiliki akses ke ruang memori yang terkait dengan proses pekerja, serta setiap proses turunan yang dapat dihasilkan oleh CGI atau aplikasi lainnya. Namun, satu aplikasi tidak dapat mengakses memori atau data aplikasi lain, meskipun berada di VM yang sama.

Aplikasi dapat menjalankan skrip atau halaman yang ditulis dengan kerangka kerja pengembangan web yang didukung. App Service tidak mengonfigurasi pengaturan kerangka kerja web apa pun ke mode yang lebih terbatas. Misalnya, ASP.NET aplikasi yang berjalan di App Service berjalan dengan kepercayaan penuh, dibandingkan dengan mode kepercayaan yang lebih terbatas. Kerangka kerja web, termasuk ASP klasik dan ASP.NET, dapat memanggil komponen COM dalam proses (seperti Objek Data ActiveX) yang terdaftar secara default pada sistem operasi Windows. Kerangka kerja web tidak dapat memanggil komponen COM di luar proses.

Aplikasi dapat menelurkan dan menjalankan kode arbitrer, membuka shell perintah, atau menjalankan skrip PowerShell. Namun, program dan skrip yang dapat dieksekusi masih dibatasi untuk hak istimewa yang diberikan ke kumpulan aplikasi induk. Misalnya, aplikasi dapat menelurkan program yang dapat dieksekusi yang melakukan panggilan HTTP keluar, tetapi program yang dapat dieksekusi tidak dapat mencoba untuk membatalkan ikatan alamat IP VM dari adaptor jaringannya. Melakukan panggilan jaringan keluar diizinkan untuk kode dengan hak istimewa rendah, tetapi mencoba mengonfigurasi ulang pengaturan jaringan pada VM memerlukan hak istimewa administratif.

Catatan dan kejadian diagnostik

Informasi log adalah kumpulan data lain yang coba diakses oleh beberapa aplikasi. Jenis informasi log yang tersedia untuk kode yang berjalan di App Service mencakup informasi diagnostik dan log yang dihasilkan aplikasi dan dapat dengan mudah diakses.

Misalnya, log HTTP W3C yang dihasilkan aplikasi tersedia:

  • Di direktori log di lokasi berbagi jaringan yang Anda buat untuk aplikasi.
  • Di penyimpanan blob jika Anda menyiapkan pengelogan W3C ke penyimpanan.

Opsi terakhir memungkinkan aplikasi untuk mengumpulkan log dalam jumlah besar tanpa melebihi batas penyimpanan file yang terkait dengan berbagi jaringan.

Demikian pula, informasi diagnostik real-time dari aplikasi .NET dapat dicatat melalui infrastruktur pelacakan dan diagnostik .NET. Anda kemudian dapat menulis informasi pelacakan ke berbagi jaringan aplikasi atau lokasi penyimpanan blob.

Area pengelogan dan pelacakan diagnostik yang tidak tersedia untuk aplikasi adalah peristiwa Windows Event Tracing untuk Windows (ETW) dan log peristiwa Windows umum (misalnya, log peristiwa sistem, aplikasi, dan keamanan). Karena informasi jejak ETW berpotensi dapat dilihat di seluruh komputer dengan menggunakan daftar kontrol akses yang tepat, akses baca dan akses tulis ke peristiwa ETW diblokir. Panggilan API untuk membaca dan menulis peristiwa ETW dan log peristiwa Windows umum mungkin tampak berfungsi, tetapi pada kenyataannya, kode aplikasi tidak memiliki akses ke data peristiwa ini.

Akses registri

Aplikasi memiliki akses baca-saja ke banyak, meskipun tidak semua, dari registri VM yang mereka jalankan. Akses ini berarti bahwa aplikasi dapat mengakses kunci registri yang memungkinkan akses baca-saja ke grup Pengguna Lokal. Salah satu area registri yang saat ini tidak didukung untuk akses baca atau tulis adalah "hive" HKEY_CURRENT_USER.

Akses tulis ke registri diblokir, termasuk akses ke kunci registri per pengguna. Dari perspektif aplikasi, aplikasi tidak dapat mengandalkan akses tulis ke registri di lingkungan Azure karena aplikasi dapat dimigrasikan di seluruh VM. Satu-satunya penyimpanan yang dapat ditulis persisten yang dapat diandalkan aplikasi adalah struktur direktori konten per aplikasi yang disimpan di berbagi UNC App Service.

Akses desktop jarak jauh

App Service tidak menyediakan akses desktop jarak jauh ke instans VM.

Untuk informasi paling up-to-tanggal tentang lingkungan eksekusi App Service, lihat kotak pasir Azure App Service. Tim pengembangan App Service mempertahankan halaman ini.