Bagikan melalui

Mengonfigurasi aplikasi Linux Python untuk Azure App Service

Sebarkan ke Azure

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 menginstal dependensi dari file requirements.txt, pyproject.toml, atau setup.py saat Anda menyebarkan repositori Git atau paket zip dengan otomatisasi build diaktifkan.

Artikel ini menyediakan konsep dan instruksi utama untuk pengembang Python yang menggunakan kontainer Linux bawaan di App Service. Jika Anda belum pernah menggunakan App Service, pertama-tama selesaikan mulai cepat Python dan Flask, Django, atau FastAPI dengan tutorial 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 membuat gambar kontainer Windows kustom Anda sendiri dan menjalankannya di App Service. Untuk informasi selengkapnya, lihat Menggunakan gambar Docker kustom.

Mengonfigurasi versi Python

  • Portal Microsoft Azure: Gunakan tab Pengaturan umum di halaman Konfigurasi , seperti yang dijelaskan dalam Mengonfigurasi pengaturan umum untuk kontainer Linux.

  • Azure CLI:

    • Tampilkan versi Python saat ini dengan menggunakan 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 menggunakan az webapp config set:

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

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

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

Anda dapat menjalankan versi Python yang tidak didukung dengan membangun gambar kontainer Anda sendiri. Untuk informasi selengkapnya, lihat Menggunakan gambar Docker kustom.

Apa yang terjadi terhadap runtime yang kedaluwarsa di App Service?

Runtime yang ketinggalan jaman tidak digunakan lagi oleh organisasi yang memelihara atau memiliki kerentanan yang signifikan. Dengan demikian, halaman tersebut dihapus dari halaman buat dan konfigurasikan di portal. Saat runtime yang kedaluarsa disembunyikan dari portal, aplikasi apa pun yang masih menggunakan runtime tersebut terus berjalan.

Jika Anda ingin membuat aplikasi dengan versi runtime usang yang tidak lagi ditampilkan di portal, gunakan Azure CLI, templat ARM, atau Bicep. Alternatif penyebaran ini memungkinkan Anda membuat runtime yang tidak digunakan lagi yang dihapus dari portal tetapi masih didukung.

Jika runtime sepenuhnya dihapus dari platform App Service, pemilik langganan Azure Anda menerima pemberitahuan email sebelum penghapusan.

Sesuaikan otomatisasi pembangunan

Catatan

Ketika aplikasi Python disebarkan dengan otomatisasi build, konten disebarkan ke dan dilayani dari /tmp/<uid>, bukan di bawah /home/site/wwwroot. Anda dapat mengakses direktori konten ini dengan menggunakan APP_PATH variabel lingkungan. Anda harus menulis file tambahan apa pun yang dibuat saat runtime ke lokasi di bawah /home atau dengan menggunakan Bring Your Own Storage untuk persistensi. Untuk informasi selengkapnya tentang perilaku ini, lihat Perubahan Build Python.

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-bangun khusus, jika langkah tersebut ditentukan oleh pengaturan PRE_BUILD_COMMAND. (Skrip itu sendiri dapat menjalankan skrip Python dan Node.js lainnya, perintah pip dan npm, dan alat berbasis Node seperti Yarn, misalnya, yarn install dan yarn build.)

  2. Instal dependensi. Sistem build memeriksa file berikut di akar proyek:

    • requirements.txt: Menjalankan pip install -r requirements.txt.
    • pyproject.toml dengan uv.lock: Menggunakan uv.
    • pyproject.toml dengan poetry.lock: Menggunakan poetry.
    • pyproject.toml: Menggunakan poetry.
    • setup.py: Menjalankan pip install ..

    Catatan

    Jika pyproject.toml ada tetapi uv.lock hilang, App Service default menggunakan Puisi, bahkan jika poetry.lock juga hilang. Untuk menggunakan uv, Anda harus menyertakan uv.lock dalam penerapan Anda.

    Jika tidak ada file ini yang ditemukan, proses build melaporkan kesalahan "Tidak dapat menemukan setup.py atau requirements.txt; Tidak menjalankan penginstalan pip."

  3. Jika manage.py ditemukan di akar repositori (yang 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 dalam 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 berjalan collectstatic saat membangun aplikasi Django, atur pengaturan ke DISABLE_COLLECTSTATICtrue .

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

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

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

Untuk informasi tentang 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, mengaktifkan 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-build 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

Anda dapat menyebarkan ulang aplikasi web yang ada ke Azure sebagai berikut:

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

    • File dependensi Anda (seperti requirements.txt, pyproject.toml, atau setup.py) harus berada di akar repositori Anda jika Anda ingin App Service menginstal paket yang diperlukan secara otomatis.

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

  3. Sumber daya App Service. Buat grup sumber daya, paket App Service, dan aplikasi web App Service untuk menghosting aplikasi Anda. Anda dapat membuat sumber daya ini dengan mudah dengan menjalankan perintah az webapp upAzure CLI . Atau Anda dapat membuat dan menyebarkan sumber daya seperti yang ditunjukkan dalam tutorial Flask, Django, atau FastAPI dengan PostgreSQL. Ganti nama grup sumber daya, paket App Service, dan aplikasi web dengan nama yang 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. Startup aplikasi. Tinjau bagian Proses startup kontainer nanti di artikel ini untuk informasi tentang cara App Service mencoba menjalankan aplikasi Anda. App Service menggunakan server web Gunicorn secara default. Gunicorn harus dapat menemukan objek aplikasi atau folder wsgi.py Anda. 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 terhubung ke kontainer dengan menggunakan SSH. Untuk contoh menjalankan migrasi database Django, lihat Tutorial: Menyebarkan aplikasi web Django dengan PostgreSQL.

    • Saat menggunakan penyebaran berkelanjutan, Anda dapat melakukan tindakan tersebut dengan menggunakan perintah pasca-build, seperti yang dijelaskan sebelumnya di bagian Kustomisasi 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 App Service, aplikasi Django harus mengikuti panduan dalam 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 dalam Pengaturan aplikasi Access sebagai variabel lingkungan. Anda dapat menyimpan nilai sebagai rahasia di Azure Key Vault.
DEBUG Buat DEBUG pengaturan di App Service dengan nilai 0 (false), lalu muat nilai sebagai variabel lingkungan. Di lingkungan pengembangan Anda, buat DEBUG variabel lingkungan 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 menggunakan 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 dapat menyimpan nilai secara alternatif (terutama nama pengguna dan kata sandi) sebagai rahasia 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) untuk mengatur Django STATIC_URL dan STATIC_ROOT variabel secara dinamis. 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, 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 front-end dan Yarn menghasilkan folder yang build/static berisi file statis, sertakan folder tersebut seperti yang ditunjukkan di sini:

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

    Dalam kode ini, FRONTEND_DIR digunakan untuk membangun jalur ke tempat alat build seperti Yarn dijalankan. Anda dapat kembali menggunakan variabel lingkungan dan pengaturan aplikasi jika mau.

  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 melayani 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. MIDDLEWARE Ubah 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 front-end statis, pertama-tama ikuti instruksi dalam 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 wadah

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

Kontainer ini memiliki karakteristik sebagai berikut:

  • Aplikasi dijalankan oleh Server HTTP Gunicorn WSGI dengan 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, gambar kontainer dasar hanya menyertakan kerangka kerja web Flask, tetapi kontainer mendukung kerangka kerja lain yang sesuai dengan WSGI dan kompatibel dengan Python 3.6 dan yang lebih baru, seperti Django.

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

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

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

  • npm dan Node.js diinstal 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 mulai Gunicorn jika terdeteksi.
  3. Periksa keberadaan aplikasi Flask, dan mulai 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 dengan 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 --access-logfile parameter dan --error-logfile , seperti yang ditunjukkan dalam contoh untuk perintah startup 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 bawaan

Jika App Service tidak menemukan perintah kustom, aplikasi Django, atau aplikasi Flask, app tersebut 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 startup dapat menggunakan nama apa pun yang Anda pilih, seperti startup.sh, startup.cmd, atau startup.txt.

Semua perintah harus menggunakan jalur yang relatif terhadap folder akar proyek.

Untuk menentukan perintah atau file perintah saat startup:

  • Portal Microsoft Azure. Di bawah Pengaturan di panel kiri halaman aplikasi, pilih Konfigurasi, lalu pilih Pengaturan umum. Dalam kotak Perintah Startup , masukkan teks lengkap perintah startup Anda atau nama file perintah startup Anda. Lalu pilih Simpan untuk menerapkan perubahan. Lihat Mengonfigurasi pengaturan umum untuk kontainer Linux.

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

    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 apa pun yang terjadi saat memproses perintah atau file startup kustom, lalu melanjutkan proses startup-nya dengan mencari aplikasi Django dan Flask. Jika Anda tidak melihat perilaku yang Anda harapkan, verifikasi bahwa perintah atau file startup Anda bebas kesalahan dan bahwa file perintah startup disebarkan ke App Service bersama dengan kode aplikasi Anda. Anda juga dapat memeriksa log diagnostik untuk informasi selengkapnya. Dan Anda dapat memeriksa halaman Diagnosis dan pemecahan 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 that contains 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 dengan menggunakan NUM_CORES variabel lingkungan dalam perintah startup Anda. Contohnya, --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 Pencatatan 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, Anda harus menyesuaikan perintah startup. Misalnya, jika Anda memiliki aplikasi Flask yang modul utamanya hello.py dan objek aplikasi Flask dalam file tersebut bernama myapp, ini adalah perintah:

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

    Jika modul utama Anda berada di subfolder, seperti situs web, tentukan folder tersebut --chdir dengan argumen :

    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 melalui pola os.environ standar.

Misalnya, jika Anda 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, periksa X-Forwarded-Proto header:

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 X-Forwarded-* informasi dalam pola aplikasi standar Anda. Misalnya, di Django Anda dapat menggunakan SECURE_PROXY_SSL_HEADER untuk mengonfigurasi Django untuk menggunakan X-Forwarded-Proto header.

Akses log diagnostik

Anda dapat mengakses log konsol yang dihasilkan dari dalam kontainer.

Untuk mengaktifkan pengelogan kontainer, jalankan perintah berikut:

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

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

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

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

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

Untuk menghentikan streaming log kapan saja, gunakan pintasan keyboard Ctrl+C.

Untuk mengakses log di portal Microsoft Azure, pilih Memantau>aliran Log di panel kiri untuk aplikasi Anda.

Mengakses catatan penyebaran

Saat Anda menyebarkan kode, App Service melakukan proses build yang dijelaskan sebelumnya, di bagian Kustomisasi 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 halaman portal Microsoft Azure untuk aplikasi web Anda, pilihPusat Penyebaran> di panel 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 dalam file dependensi Anda dan kesalahan dalam skrip pra-build atau pasca-build, muncul di log ini. Kesalahan juga muncul jika file dependensi Anda tidak ditemukan di folder akar proyek Anda.

Membuka sesi SSH di browser

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

Gunakan perintah az webapp ssh .

Jika Anda tidak diautentikasi, Anda perlu mengautentikasi dengan langganan Azure Anda untuk menyambungkan. Saat diautentikasi, Anda akan melihat shell di 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 tidak bertahan di luar restart aplikasi.

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 yang menyatakan bahwa kontainer dimulai ulang, kesalahan mungkin mencegah kontainer aplikasi dimulai. Lihat Pemecahan masalah untuk informasi tentang menyelidiki kemungkinan masalah.

Penulisan ulang URL

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

Pemecahan Masalah

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

  1. Pada halaman portal Microsoft Azure untuk aplikasi web Anda, pilih Diagnosis dan selesaikan masalah di panel kiri.
  2. Pilih Ketersediaan dan Performa.
  3. Periksa informasi dalam Log Aplikasi, Crash Kontainer, dan Masalah Kontainer, tempat masalah yang paling umum 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 dependensi Anda 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 karena App Service gagal menemukan kode aplikasi Anda dan menjalankan aplikasi default sebagai gantinya.

    • Mulai ulang aplikasi, tunggu 20 detik, lalu periksa aplikasi lagi.

    • Gunakan SSH untuk terhubung langsung ke kontainer App Service dan verifikasi bahwa file Anda ada di bawah site/wwwroot. Jika file Anda tidak ada, lakukan 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, App Service tidak dapat mengidentifikasi file startup Anda. Pastikan aplikasi Anda disusun seperti yang diharapkan App Service untuk Django atau Flask, atau gunakan perintah startup kustom.

  • Anda melihat pesan "Layanan Tidak Tersedia" di browser. Waktu browser habis menunggu respons dari App Service. Ini 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.

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

    • Verifikasi bahwa aplikasi Anda disusun seperti yang diharapkan App Service untuk Django atau Flask, atau gunakan perintah startup kustom.

    • Periksa aliran log aplikasi untuk 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 penginstalan pip." Proses build Oryx gagal menemukan file requirements.txt, pyproject.toml, atau setup.py Anda.

    • Sambungkan ke kontainer aplikasi web melalui SSH dan verifikasi bahwa file dependensi Anda dinamai dengan benar dan ada langsung di bawah situs/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', 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 memaksa Oryx untuk menginstal paket Anda setiap kali Anda menyebarkan ke App Service. Untuk informasi selengkapnya, lihat artikel ini tentang portabilitas lingkungan virtual.

Basis Data terkunci

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. Namun, karakter sedang direkam, jadi ketik kata sandi Anda seperti biasa dan pilih Enter setelah Selesai.

  • Perintah dalam sesi SSH tampaknya terputus: Editor mungkin tidak membungkus teks perintah, tetapi perintah tersebut seharusnya tetap berjalan dengan benar.

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

  • Anda melihat pesan "Koneksi SSL Fatal Diperlukan": Periksa nama pengguna dan kata sandi apa pun yang digunakan untuk mengakses sumber daya (seperti database) dari dalam aplikasi.

Konten terkait

  • Last updated on