Bagikan melalui

Mengonfigurasi aplikasi Linux Python untuk Azure App Service

  • Artikel

Artikel ini menjelaskan cara Azure App Service menjalankan aplikasi Python, bagaimana Anda dapat memigrasikan aplikasi yang ada ke Azure, dan bagaimana Anda dapat menyesuaikan perilaku App Service saat diperlukan. Aplikasi Python harus disebarkan dengan semua modul pip yang diperlukan.

Mesin penyebaran App Service secara otomatis mengaktifkan lingkungan virtual dan berjalan pip install -r requirements.txt untuk Anda saat Anda menyebarkan repositori Git, atau saat Anda menyebarkan paket zip dengan otomatisasi build diaktifkan.

Panduan ini menyediakan konsep dan instruksi utama untuk pengembang Python yang menggunakan kontainer Linux bawaan di App Service. Jika Anda belum pernah menggunakan Azure App Service, pertama-tama ikuti mulai cepat Python dan Tutorial Python dengan PostgreSQL.

Anda dapat menggunakan portal Microsoft Azure atau Azure CLI untuk konfigurasi:

Catatan

Linux adalah satu-satunya opsi sistem operasi untuk menjalankan aplikasi Python di App Service. Python pada Windows tidak lagi didukung. Namun, Anda dapat membangun gambar kontainer Windows kustom Anda sendiri dan menjalankannya di App Service. Untuk mengetahui informasi selengkapnya, lihat menggunakan gambar Docker kustom.

Mengonfigurasi versi Python

  • portal Azure: gunakan tab Pengaturan umum pada halaman Konfigurasi seperti yang dijelaskan dalam Mengonfigurasi pengaturan umum untuk kontainer Linux.

  • Azure CLI:

    • Tampilkan versi Python saat ini dengan az webapp config show:

      az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

      Ganti <resource-group-name> dan <app-name> dengan nama yang sesuai untuk aplikasi web Anda.

    • Atur versi Python dengan az webapp config set

      az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"

    • Tampilkan semua versi Python yang didukung di Azure App Service dengan az webapp list-runtimes:

      az webapp list-runtimes --os linux | grep PYTHON

Anda dapat menjalankan versi Python yang tidak didukung dengan membangun citra kontainer Anda sendiri sebagai gantinya. Untuk mengetahui informasi selengkapnya, lihat menggunakan gambar Docker kustom.

Mengkustomisasi otomatisasi build

Sistem build App Service, yang disebut Oryx, melakukan langkah-langkah berikut saat Anda menyebarkan aplikasi, jika pengaturan SCM_DO_BUILD_DURING_DEPLOYMENT aplikasi diatur ke 1:

  1. Jalankan skrip pra-build kustom, jika langkah tersebut ditentukan oleh PRE_BUILD_COMMAND pengaturan. (Skrip itu sendiri dapat menjalankan skrip Python dan Node.js lainnya, perintah pip dan npm, dan alat berbasis simpul seperti yarn, misalnya, yarn install dan yarn build.)

  2. Jalankan pip install -r requirements.txt. File requirements.txt harus ada di folder akar proyek. Jika tidak, proses build akan melaporkan kesalahan: "Tidak dapat menemukan setup.py atau requirements.txt; Tidak menjalankan pip install."

  3. Jika manage.py ditemukan di akar repositori (menunjukkan aplikasi Django), jalankan manage.py collectstatic. Namun, jika pengaturan DISABLE_COLLECTSTATIC adalah true, lompati langkah ini.

  4. Jalankan skrip pasca-build kustom, jika langkah tersebut POST_BUILD_COMMAND ditentukan oleh pengaturan. (Sekali lagi, skrip dapat menjalankan skrip Python dan Node.js lainnya, perintah pip dan npm, dan alat berbasis Node.)

Secara default, pengaturan PRE_BUILD_COMMAND, POST_BUILD_COMMAND, dan DISABLE_COLLECTSTATIC akan kosong.

  • Untuk menonaktifkan menjalankan collectstatic saat membangun aplikasi Django, atur pengaturan ke DISABLE_COLLECTSTATIC true.

  • Untuk menjalankan perintah pra-build, atur PRE_BUILD_COMMAND pengaturan agar berisi perintah, seperti echo Pre-build command, atau jalur ke file skrip, relatif terhadap akar proyek Anda, seperti scripts/prebuild.sh. Semua perintah harus menggunakan jalur relatif ke folder akar proyek.

  • Untuk menjalankan perintah pasca-build, atur POST_BUILD_COMMAND pengaturan agar berisi perintah, seperti echo Post-build command, atau jalur ke file skrip, relatif terhadap akar proyek Anda, seperti scripts/postbuild.sh. Semua perintah harus menggunakan jalur relatif ke folder akar proyek.

Untuk pengaturan lain yang menyesuaikan otomatisasi build, lihat Konfigurasi Oryx.

Untuk mengakses log build dan penyebaran, lihat Mengakses log penyebaran.

Untuk informasi selengkapnya tentang cara App Service menjalankan dan membangun aplikasi Python di Linux, lihat Cara Oryx mendeteksi dan membangun aplikasi Python.

Catatan

Pengaturan PRE_BUILD_SCRIPT_PATH dan POST_BUILD_SCRIPT_PATH identik dengan PRE_BUILD_COMMAND dan POST_BUILD_COMMAND serta didukung untuk tujuan warisan.

Pengaturan bernama SCM_DO_BUILD_DURING_DEPLOYMENT, jika berisi true atau 1, memicu build Oryx yang terjadi selama penyebaran. Pengaturannya adalah true saat Anda menyebarkan dengan menggunakan Git, perintah az webapp upAzure CLI , dan Visual Studio Code.

Catatan

Selalu gunakan jalur relatif di semua skrip pra- dan pasca-build karena kontainer build tempat Oryx berjalan berbeda dari kontainer runtime tempat aplikasi berjalan. Jangan pernah mengandalkan penempatan tepat dari folder proyek aplikasi Anda dalam kontainer (misalnya, bahwa folder ditempatkan di bawah site/ wwwroot).

Memigrasikan aplikasi yang sudah ada ke Azure

Aplikasi web yang ada dapat disebarkan ulang ke Azure sebagai berikut:

  1. Repositori sumber: Pertahankan kode sumber Anda di repositori yang sesuai seperti GitHub, yang memungkinkan Anda untuk mengatur penyebaran berkelanjutan nanti dalam proses ini.

    • File requirements.txt Anda harus berada di akar repositori Anda untuk App Service untuk memasang paket yang diperlukan secara otomatis.

  2. Database: Jika aplikasi Anda bergantung pada database, buat sumber daya yang diperlukan di Azure juga.

  3. Sumber daya layanan aplikasi: Buat grup sumber daya, paket App Service, dan aplikasi web App Service untuk menghosting aplikasi Anda. Anda dapat melakukan ini dengan mudah dengan menjalankan perintah az webapp upAzure CLI . Atau, Anda dapat membuat dan menyebarkan sumber daya seperti yang ditunjukkan dalam Tutorial: Menyebarkan aplikasi web Python (Django atau Flask) dengan PostgreSQL. Ganti nama grup sumber daya, paket App Service, dan aplikasi web agar lebih cocok untuk aplikasi Anda.

  4. Variabel lingkungan: Jika aplikasi Anda memerlukan variabel lingkungan apa pun, buat pengaturan aplikasi App Service yang setara. Pengaturan App Service ini muncul ke kode Anda sebagai variabel lingkungan, seperti yang dijelaskan dalam Variabel lingkungan Akses.

  5. Pengaktifan aplikasi: Tinjau bagian Proses startup kontainer nanti di artikel ini untuk memahami cara App Service mencoba menjalankan aplikasi Anda. App Service menggunakan server web Gunicorn secara default, yang harus bisa menemukan objek aplikasi Anda atau folder wsgi.py. Jika perlu, Anda dapat Menyesuaikan perintah startup.

  6. Penyebaran berkelanjutan: Siapkan penyebaran berkelanjutan dari GitHub Actions, Bitbucket, atau Azure Repos seperti yang dijelaskan dalam artikel Penyebaran berkelanjutan ke Azure App Service. Atau, siapkan penyebaran berkelanjutan dari Git Lokal seperti yang dijelaskan dalam artikel Penyebaran Git Lokal ke Azure App Service.

  7. Tindakan kustom: Untuk melakukan tindakan dalam kontainer App Service yang menghosting aplikasi Anda, seperti migrasi database Django, Anda dapat menghubungkan ke kontainer melalui SSH. Untuk contoh menjalankan migrasi database Django, lihat Tutorial: Menyebarkan aplikasi web Django dengan PostgreSQL - menghasilkan skema database.

    • Saat menggunakan penyebaran berkelanjutan, Anda dapat melakukan tindakan tersebut menggunakan perintah pasca-build seperti yang dijelaskan sebelumnya di Mengkustomisasi otomatisasi build.

Setelah langkah-langkah ini diselesaikan, Anda dapat menerapkan perubahan pada repositori sumber Anda dan pembaruan tersebut akan secara otomatis disebarkan ke App Service.

Pengaturan produksi untuk aplikasi Django

Untuk lingkungan produksi seperti Azure App Service, aplikasi Django harus mengikuti daftar periksa Penyebaran Django.

Tabel berikut ini menjelaskan pengaturan produksi yang relevan dengan Azure. Pengaturan ini ditentukan dalam file setting.py aplikasi.

Pengaturan Django Instruksi untuk Azure
SECRET_KEY Simpan nilai dalam pengaturan App Service seperti yang dijelaskan pada Akses pengaturan aplikasi sebagai variabel lingkungan. Anda dapat menyimpan nilai sebagai rahasia di Azure Key Vault.
DEBUG Buat pengaturan DEBUG di App Service dengan nilai 0 (false), lalu muat nilai sebagai variabel lingkungan. Di lingkungan pengembangan Anda, buat variabel lingkungan DEBUG dengan nilai 1 (true).
ALLOWED_HOSTS Dalam produksi, Django mengharuskan Anda menyertakan URL aplikasi dalam ALLOWED_HOSTS array settings.py. Anda dapat mengambil URL ini saat runtime dengan kode os.environ['WEBSITE_HOSTNAME']. App Service secara otomatis mengatur variabel lingkungan WEBSITE_HOSTNAME ke URL aplikasi.
DATABASES Tentukan pengaturan di App Service untuk koneksi database dan muat sebagai variabel lingkungan untuk mengisi kamus DATABASES. Anda juga dapat menyimpan nilai (terutama nama pengguna dan kata sandi) sebagai rahasia Azure Key Vault.

Menyajikan file statis untuk aplikasi Django

Jika aplikasi web Django Anda menyertakan file front-end statis, pertama-tama ikuti instruksi tentang mengelola file statis dalam dokumentasi Django.

Untuk App Service, Anda kemudian melakukan modifikasi berikut:

  1. Pertimbangkan untuk menggunakan variabel lingkungan (untuk pengembangan lokal) dan Pengaturan Aplikasi (saat menyebarkan ke cloud) guna secara dinamis mengatur Django variabel STATIC_URL dan STATIC_ROOT. Contohnya:

    STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")

    DJANGO_STATIC_URL dan DJANGO_STATIC_ROOT dapat diubah seperlunya untuk lingkungan lokal dan cloud Anda. Misalnya, jika proses build untuk file statis Anda menempatkannya di folder bernama django-static, maka Anda dapat mengatur DJANGO_STATIC_URL ke /django-static/ untuk menghindari penggunaan default.

  2. Jika Anda memiliki skrip pra-build yang menghasilkan file statis di folder yang berbeda, sertakan folder tersebut dalam variabel STATICFILES_DIRS Django sehingga proses Django collectstatic menemukannya. Misalnya, jika Anda menjalankan yarn build di folder ujung depan, dan yarn menghasilkan folder build/static yang berisi file statis, maka sertakan folder tersebut sebagai berikut:

    FRONTEND_DIR = "path-to-frontend-folder" 
STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]

    Di sini, FRONTEND_DIR digunakan untuk membangun jalur ke tempat alat build seperti benang dijalankan. Anda dapat kembali menggunakan variabel lingkungan dan Pengaturan Aplikasi sesuai keinginan.

  3. Tambahkan whitenoise ke file requirements.txt Anda. WhiteNoise (whitenoise.evans.io) adalah paket Python yang memudahkan aplikasi Django produksi untuk melayani file statisnya sendiri. WhiteNoise secara khusus melayani file-file yang ditemukan di folder yang ditentukan oleh variabel Django STATIC_ROOT .

  4. Di file settings.py Anda, tambahkan baris berikut untuk WhiteNoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Ubah MIDDLEWARE juga daftar dan INSTALLED_APPS untuk menyertakan WhiteNoise:

    MIDDLEWARE = [                                                                   
    'django.middleware.security.SecurityMiddleware',
    # Add whitenoise middleware after the security middleware                             
    'whitenoise.middleware.WhiteNoiseMiddleware',
    # Other values follow
]

INSTALLED_APPS = [
    "whitenoise.runserver_nostatic",
    # Other values follow
]

Menyajikan file statis untuk aplikasi Flask

Jika aplikasi web Flask Anda menyertakan file ujung depan statis, pertama-tama ikuti instruksi pada Mengelola file statis dalam dokumentasi Flask. Untuk contoh penyajian file statis dalam aplikasi Flask, lihat contoh aplikasi Flask di GitHub.

Untuk menyajikan file statis langsung dari rute pada aplikasi Anda, Anda dapat menggunakan send_from_directory metode:

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

Karakteristik kontainer

Ketika disebarkan ke App Service, aplikasi Python berjalan dalam kontainer Linux Docker yang didefinisikan dalam Repositori GitHub App Service Python. Anda dapat menemukan konfigurasi citra di dalam direktori versi khusus.

Kontainer ini memiliki karakteristik sebagai berikut:

  • Aplikasi dijalankan menggunakan Gunicorn WSGI HTTP Server, menggunakan argumen --bind=0.0.0.0 --timeout 600tambahan .

    • Anda dapat menyediakan pengaturan konfigurasi untuk Gunicorn dengan menyesuaikan perintah pengaktifan.

    • Untuk melindungi aplikasi web Anda dari serangan DDOS yang tidak disengaja atau disengaja, Gunicorn dijalankan di belakang proksi terbalik Nginx seperti yang dijelaskan dalam Menyebarkan Gunicorn.

  • Secara default, citra kontainer dasar hanya menyertakan kerangka kerja web Flask, tetapi kontainer mendukung kerangka kerja lain yang mematuhi WSGI dan kompatibel dengan Python 3.6+, seperti Django.

  • Untuk menginstal paket lain, seperti Django, buat file requirements.txt di akar proyek Anda yang menentukan dependensi langsung Anda. App Service kemudian memasang dependensi tersebut secara otomatis saat Anda menyebarkan proyek.

    File requirements.txt harus berada di akar proyek agar dependensi dapat dipasang. Jika tidak, proses build melaporkan kesalahan: "Tidak dapat menemukan setup.py atau requirements.txt; Tidak menjalankan pip install." Jika Anda mengalami kesalahan ini, periksa lokasi file persyaratan Anda.

  • App Service secara otomatis mendefinisikan variabel lingkungan yang bernama WEBSITE_HOSTNAME dengan URL aplikasi web, seperti msdocs-hello-world.azurewebsites.net. App Service juga mendefinisikan WEBSITE_SITE_NAME dengan nama aplikasi Anda, seperti msdocs-hello-world.

  • npm dan Node.js dipasang dalam kontainer sehingga Anda dapat menjalankan alat build berbasis Node, seperti yarn.

Proses pengaktifan kontainer

Selama pengaktifan, App Service pada kontainer Linux menjalankan langkah-langkah berikut:

  1. Gunakan perintah startup kustom, jika disediakan.
  2. Periksa keberadaan aplikasi Django, dan luncurkan Gunicorn jika terdeteksi.
  3. Periksa keberadaan aplikasi Flask, dan luncurkan Gunicorn jika terdeteksi.
  4. Jika tidak ada aplikasi lain yang ditemukan, mulai aplikasi default yang disertakan dalam kontainer.

Bagian berikut ini menyediakan detail tambahan untuk setiap opsi.

Aplikasi Django

Untuk aplikasi Django, App Service mencari file bernama wsgi.py dalam kode aplikasi Anda, lalu menjalankan Gunicorn menggunakan perintah berikut:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Jika Anda menginginkan kontrol yang lebih spesifik atas perintah startup, gunakan perintah startup kustom, ganti <module> dengan nama folder yang berisi wsgi.py, dan tambahkan --chdir argumen jika modul tersebut tidak ada di akar proyek. Misalnya, jika wsgi.py Anda terletak di bawah knboard/backend/config dari akar proyek Anda, gunakan argumen --chdir knboard/backend config.wsgi.

Untuk mengaktifkan pengelogan produksi, tambahkan parameter --access-logfile dan --error-logfile seperti yang ditunjukkan dalam contoh untuk perintah pengaktifan kustom.

Aplikasi Flask

Untuk Flask, App Service mencari file bernama application.py atau app.py dan memulai Gunicorn sebagai berikut:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

Jika modul aplikasi utama Anda terkandung dalam file yang berbeda, gunakan nama yang berbeda untuk objek aplikasi. Jika Anda ingin memberikan argumen lain ke Gunicorn, gunakan perintah startup kustom.

Perilaku default

Jika App Service tidak menemukan perintah kustom, aplikasi Django, atau aplikasi Flask, maka aplikasi ini menjalankan aplikasi baca-saja default, yang terletak di folder opt/defaultsite dan ditampilkan dalam gambar berikut.

Jika Anda menyebarkan kode dan masih melihat aplikasi default, lihat Pemecahan Masalah - Aplikasi tidak muncul.

Cuplikan layar App Service default di halaman web Linux.

Mengkustomisasi perintah pengaktifan

Anda dapat mengontrol perilaku pengaktifan kontainer dengan menyediakan perintah pengaktifan kustom atau beberapa perintah dalam file perintah pengaktifan. File perintah pengaktifan dapat menggunakan nama apa pun yang Anda pilih, seperti startup.sh, startup.cmd, startup.txt, dan sebagainya.

Semua perintah harus menggunakan jalur relatif ke folder akar proyek.

Untuk menentukan perintah pengaktifan atau file perintah:

  • Portal Microsoft Azure: pilih halaman Konfigurasi aplikasi, lalu pilih Pengaturan umum. Di bidang Perintah Pengaktifan, letakkan teks lengkap perintah pengaktifan Anda atau nama file perintah pengaktifan Anda. Lalu pilih Simpan untuk menerapkan perubahan. Lihat Mengonfigurasi pengaturan umum untuk kontainer Linux.

  • Azure CLI: gunakan perintah az webapp config set dengan parameter --startup-file untuk mengatur perintah atau file pengaktifan:

    az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

    Ganti <custom-command> dengan teks perintah lengkap pengaktifan Anda atau nama file perintah pengaktifan Anda.

App Service mengabaikan kesalahan yang terjadi saat memproses perintah atau file pengaktifan kustom, kemudian melanjutkan proses pengaktifan dengan mencari aplikasi Django dan Flask. Jika Anda tidak melihat perilaku yang Anda harapkan, periksa apakah perintah atau file startup Anda bebas kesalahan, dan file perintah startup disebarkan ke App Service bersama dengan kode aplikasi Anda. Anda juga dapat memeriksa log diagnostik untuk informasi selengkapnya. Periksa juga halaman Mendiagnosis dan menyelesaikan masalah aplikasi di portal Microsoft Azure.

Contoh perintah pengaktifan

  • Menambahkan argumen Gunicorn: Contoh berikut menambahkan --workers=4 argumen ke baris perintah Gunicorn untuk memulai aplikasi Django:

    # <module-path> is the relative path to the folder that contains the module
# that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Untuk informasi selengkapnya, lihat Menjalankan Gunicorn. Jika Anda menggunakan aturan skala otomatis untuk meningkatkan dan menurunkan skala aplikasi web, Anda juga harus mengatur jumlah pekerja Gunicorn secara dinamis menggunakan NUM_CORES variabel lingkungan dalam perintah startup Anda, misalnya: --workers $((($NUM_CORES*2)+1)). Untuk informasi selengkapnya tentang mengatur jumlah pekerja Gunicorn yang direkomendasikan, lihat FAQ Gunicorn.

  • Mengaktifkan pengelogan produksi untuk Django: Tambahkan argumen --access-logfile '-' dan --error-logfile '-' ke baris perintah:

    # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'

    Log ini akan muncul di Aliran log App Service.

    Untuk informasi selengkapnya, lihat Pengelogan Gunicorn.

  • Modul utama Flask kustom: Secara default, App Service mengasumsikan bahwa modul utama aplikasi Flask application.py atau app.py. Jika modul utama Anda menggunakan nama yang berbeda, maka Anda harus menyesuaikan perintah pengaktifan. Misalnya, jika Anda memiliki aplikasi Flask yang modul utamanya adalah hello.py dan objek aplikasi Flask dalam file tersebut diberi nama myapp, maka perintahnya adalah sebagai berikut:

    gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp

    Jika modul utama Anda berada dalam subfolder, seperti website, tentukan folder tersebut dengan argumen --chdir:

    gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp

  • Menggunakan server non-Gunicorn: Untuk menggunakan server web lain, seperti aiohttp, gunakan perintah yang sesuai sebagai perintah pengaktifan atau dalam file perintah pengaktifan:

    python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func

Mengakses pengaturan aplikasi sebagai variabel lingkungan

Pengaturan aplikasi adalah nilai yang disimpan di cloud khusus untuk aplikasi Anda, seperti yang dijelaskan di Mengonfigurasi pengaturan aplikasi. Pengaturan ini tersedia untuk kode aplikasi Anda sebagai variabel lingkungan dan diakses menggunakan pola os.environ standar.

Misalnya, jika Anda telah membuat pengaturan aplikasi yang disebut DATABASE_SERVER, kode berikut mengambil nilai pengaturan tersebut:

db_server = os.environ['DATABASE_SERVER']

Mendeteksi sesi HTTPS

Dalam App Service, penghentian TLS/SSL terjadi pada load balancer jaringan, sehingga semua permintaan HTTPS mencapai aplikasi Anda sebagai permintaan HTTP yang tidak terenkripsi. Jika logika aplikasi Anda perlu memeriksa apakah permintaan pengguna dienkripsi atau tidak, periksa header X-Forwarded-Proto.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

Kerangka kerja web populer memungkinkan Anda mengakses informasi X-Forwarded-* dalam pola aplikasi standar Anda. Misalnya, di Django Anda dapat menggunakan SECURE_PROXY_SSL_HEADER untuk memberi tahu Django untuk menggunakan X-Forwarded-Proto header.

Mengakses log diagnostik

Anda dapat mengakses log konsol yang dihasilkan dari dalam kontainer.

Pertama, aktifkan pengelogan kontainer dengan menjalankan perintah berikut:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Ganti <app-name> dan <resource-group-name> dengan nama yang sesuai untuk aplikasi web Anda.

Setelah pengelogan kontainer diaktifkan, jalankan perintah berikut untuk melihat aliran log:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Jika Anda tidak segera melihat log konsol, periksa lagi dalam 30 detik.

Untuk menghentikan streaming log kapan saja, tekan Ctrl+C.

Anda juga dapat memeriksa file log di browser di https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Untuk mengakses log melalui portal Microsoft Azure, pilih Pemantauan>Aliran log di menu sebelah kiri untuk aplikasi Anda.

Mengakses log penyebaran

Saat Anda menyebarkan kode, App Service melakukan proses build yang dijelaskan sebelumnya di bagian Mengkustomisasi otomatisasi build. Karena build berjalan dalam kontainernya sendiri, log build disimpan secara terpisah dari log diagnostik aplikasi.

Gunakan langkah-langkah berikut untuk mengakses log penyebaran:

  1. Pada portal Azure untuk aplikasi web Anda, pilih Pusat Penyebaran>di menu sebelah kiri.
  2. Pada tab Log, pilih ID Penerapan untuk penerapan terbaru.
  3. Pada halaman Detail log yang muncul, pilih tautan Perlihatkan Log yang muncul di samping "Menjalankan build oryx...".

Masalah build seperti dependensi yang salah di requirements.txt dan kesalahan dalam skrip pra- atau pasca-build akan muncul di log ini. Kesalahan juga muncul jika file persyaratan Anda tidak bernama requirements.txt atau tidak muncul di folder akar proyek Anda.

Membuka sesi SSH di browser

Untuk membuka sesi SSH langsung dengan kontainer Anda, aplikasi Anda harus berjalan.

Tempelkan URL berikut ke browser Anda dan ganti <app-name> dengan nama aplikasi Anda:

https://<app-name>.scm.azurewebsites.net/webssh/host

Jika belum diautentikasi, Anda harus mengautentikasi dengan langganan Azure untuk menyambungkan. Setelah diautentikasi, Anda akan melihat shell dalam browser, tempat Anda dapat menjalankan perintah di dalam kontainer Anda.

Koneksi SSH

Catatan

Setiap perubahan yang Anda buat di luar direktori /home disimpan dalam kontainer itu sendiri dan hanya ada saat aplikasi dihidupkan ulang.

Untuk membuka sesi SSH jarak jauh dari komputer lokal Anda, lihat Membuka sesi SSH dari shell jarak jauh.

Ketika Anda berhasil tersambung ke sesi SSH, Anda akan melihat pesan "SSH CONNECTION ESTABLISHED" di bagian bawah jendela. Jika Anda melihat kesalahan seperti "SSH_CONNECTION_CLOSED" atau pesan bahwa kontainer dimulai ulang, kesalahan mungkin mencegah kontainer aplikasi dimulai. Lihat Pemecahan masalah untuk mengetahui langkah-langkah guna menyelidiki kemungkinan masalah.

Penulisan ulang URL

Saat menyebarkan aplikasi Python di Azure App Service untuk Linux, Anda mungkin perlu menangani penulisan ulang URL dalam aplikasi Anda. Ini sangat berguna untuk memastikan pola URL tertentu dialihkan ke titik akhir yang benar tanpa mengandalkan konfigurasi server web eksternal. Untuk aplikasi Flask, prosesor URL dan middleware kustom dapat digunakan untuk mencapai hal ini. Dalam aplikasi Django, dispatcher URL yang kuat memungkinkan manajemen penulisan ulang URL yang efisien.

Pemecahan Masalah

Secara umum, langkah pertama dalam pemecahan masalah adalah menggunakan diagnostik App Service:

  1. Di portal Azure untuk aplikasi web Anda, pilih Diagnosis dan selesaikan masalah dari menu sebelah kiri.
  2. Pilih Ketersediaan dan Performa.
  3. Periksa informasi dalam opsi Log Aplikasi, Crash Kontainer, dan Masalah Kontainer, tempat masalah paling umum akan muncul.

Selanjutnya, periksa log penyebaran dan log aplikasi untuk setiap pesan kesalahan. Log ini sering mengidentifikasi masalah spesifik yang dapat mencegah penyebaran aplikasi atau pengaktifan aplikasi. Misalnya, build dapat gagal jika file requirements.txt Anda memiliki nama file yang salah atau tidak ada di folder akar proyek Anda.

Bagian berikut ini menyediakan panduan untuk masalah tertentu.

Aplikasi tidak muncul

  • Anda akan melihat aplikasi default setelah menyebarkan kode aplikasi Anda sendiri. Aplikasi default muncul karena Anda belum menyebarkan kode aplikasi ke App Service, atau App Service gagal menemukan kode aplikasi Anda dan menjalankan aplikasi default sebagai gantinya.

    • Mulai ulang App Service, tunggu selama 15-20 detik, dan periksa kembali aplikasi.

    • Gunakan SSH untuk terhubung langsung ke kontainer App Service dan verifikasi bahwa file Anda ada di bawah site/wwwroot. Jika file Anda tidak ada, gunakan langkah-langkah berikut:

      1. Buat pengaturan aplikasi bernama SCM_DO_BUILD_DURING_DEPLOYMENT dengan nilai 1, sebarkan ulang kode Anda, tunggu beberapa menit, lalu coba akses aplikasi lagi. Untuk mengetahui informasi selengkapnya tentang pembuatan pengaturan aplikasi, lihat Mengonfigurasi aplikasi App Service di portal Microsoft Azure.
      2. Tinjau proses penyebaran Anda, periksa log penyebaran, perbaiki kesalahan apa pun, dan sebarkan ulang aplikasi.

    • Jika file Anda ada, Maka App Service tidak dapat mengidentifikasi file pengaktifan spesifik Anda. Pastikan aplikasi Anda disusun seperti yang diharapkan App Service untuk Django atau Flask, atau gunakan perintah pengaktifan kustom.

  • Anda melihat pesan "Layanan Tidak Tersedia" di browser. Browser telah kehabisan waktu menunggu respons dari App Service, yang menunjukkan bahwa App Service memulai server Gunicorn, tetapi aplikasi itu sendiri tidak dimulai. Kondisi ini dapat menunjukkan bahwa argumen Gunicorn salah, atau ada kesalahan dalam kode aplikasi.

    • Refresh browser, terutama jika Anda menggunakan tingkat harga terendah dalam paket App Service Anda. Aplikasi mungkin membutuhkan waktu lebih lama untuk memulai saat Anda menggunakan tingkat gratis, misalnya, dan menjadi responsif setelah Anda me-refresh browser.

    • Pastikan aplikasi Anda disusun seperti yang diharapkan App Service untuk Django atau Flask, atau gunakan perintah pengaktifan kustom.

    • Periksa aliran log aplikasi untuk setiap pesan kesalahan. Log akan menampilkan kesalahan apa pun dalam kode aplikasi.

Tidak dapat menemukan setup.py atau requirements.txt

  • Aliran log menunjukkan "Tidak dapat menemukan setup.py atau requirements.txt; Tidak menjalankan instalasi pip.": Proses build Oryx gagal menemukan file requirements.txt Anda.

    • Sambungkan ke kontainer aplikasi web melalui SSH dan verifikasi bahwa requirements.txt benar dan ada langsung di bawah site/wwwroot. Jika tidak ada, pastikan file ada di repositori Anda dan disertakan dalam penyebaran Anda. Jika ada di folder terpisah, pindahkan ke akar.

ModuleNotFoundError saat aplikasi dimulai

Jika Anda melihat kesalahan seperti ModuleNotFoundError: No module named 'example', maka Python tidak dapat menemukan satu atau beberapa modul Anda saat aplikasi dimulai. Kesalahan ini paling sering terjadi jika Anda menyebarkan lingkungan virtual dengan kode Anda. Lingkungan virtual tidak portabel, sehingga lingkungan virtual tidak boleh disebarkan dengan kode aplikasi Anda. Sebaliknya, biarkan Oryx membuat lingkungan virtual dan memasang paket Anda di aplikasi web dengan membuat pengaturan aplikasi, SCM_DO_BUILD_DURING_DEPLOYMENT, dan mengaturnya ke 1. Pengaturan ini akan memaksa Oryx untuk menginstal paket Anda setiap kali Anda menyebarkan ke App Service. Untuk informasi selengkapnya, lihat artikel ini tentang portabilitas lingkungan virtual.

Database dikunci

Saat mencoba menjalankan migrasi database dengan aplikasi Django, Anda mungkin melihat "sqlite3. OperationalError: database terkunci." Kesalahan menunjukkan bahwa aplikasi Anda menggunakan database SQLite, yang dikonfigurasi Django secara default, daripada menggunakan database cloud seperti Azure Database for PostgreSQL.

Periksa variabel DATABASES dalam file settings.py aplikasi untuk memastikan bahwa aplikasi Anda menggunakan database cloud, bukan SQLite.

Jika Anda mengalami kesalahan ini dengan sampel di Tutorial: Menyebarkan aplikasi web Django dengan PostgreSQL, periksa apakah Anda menyelesaikan langkah-langkah dalam Memverifikasi pengaturan koneksi.

Masalah Lain

  • Kata sandi tidak muncul di sesi SSH saat ditik: Untuk alasan keamanan, sesi SSH menjaga kata sandi Anda tetap tersembunyi saat Anda mengetik. Karakter sedang direkam, bagaimanapun, jadi ketik kata sandi Anda seperti biasa dan pilih Enter setelah selesai.

  • Perintah dalam sesi SSH tampaknya terputus: Editor mungkin bukan perintah pembungkus kata, tetapi masih harus berjalan dengan benar.

  • Aset statis tidak muncul di aplikasi Django: Pastikan Anda telah mengaktifkan modul WhiteNoise.

  • Anda melihat pesan, "Fatal SSL Connection is Required": Periksa nama pengguna dan kata sandi yang digunakan untuk mengakses sumber daya (seperti database) dari dalam aplikasi.

Konten terkait