Bagikan melalui

Terapkan dan konfigurasikan aplikasi Java SE, Tomcat, atau JBoss EAP di Azure App Service

Artikel ini memperlihatkan kepada Anda konfigurasi penyebaran dan runtime yang paling umum untuk aplikasi Java di Azure App Service. Jika ini pertama kalinya Anda menggunakan Azure App Service, Anda harus membaca terlebih dahulu panduan memulai cepat Java. Anda dapat menemukan jawaban atas pertanyaan umum tentang menggunakan App Service yang tidak spesifik untuk pengembangan Java di FAQ App Service.

Azure App Service menjalankan aplikasi web Java pada layanan yang dikelola sepenuhnya dalam tiga varian:

  • Java Standard Edition (SE): Dapat menjalankan aplikasi yang disebarkan sebagai paket Java Archive (JAR) yang berisi server yang disematkan (seperti Spring Boot, Quarkus, Dropwizard, atau aplikasi dengan server Tomcat atau Jetty yang disematkan).
  • Tomcat: Server Tomcat bawaan dapat menjalankan aplikasi yang disebarkan sebagai paket arsip aplikasi web (WAR).
  • JBoss Enterprise Application Platform (EAP): Server JBoss EAP bawaan dapat menjalankan aplikasi yang disebarkan sebagai paket WAR atau arsip perusahaan (EAR). Didukung untuk aplikasi Linux dalam serangkaian tingkat harga yang mencakup Gratis, Premium v3, dan Terisolasi v2.gti

Perlihatkan versi Java

Untuk memperlihatkan versi Java saat ini, jalankan perintah berikut di Azure Cloud Shell:

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

Untuk menampilkan semua versi Java yang didukung, jalankan perintah berikut di Cloud Shell:

az webapp list-runtimes --os linux | grep "JAVA\|TOMCAT\|JBOSSEAP"

Mendapatkan versi Java di kontainer Linux

Untuk informasi versi yang lebih rinci dalam kontainer Linux, buka sesi SSH dengan kontainer. Berikut adalah beberapa contoh yang bisa Anda jalankan.

Untuk melihat versi Java dalam sesi SSH:

java -version

Untuk melihat versi server Tomcat di sesi SSH:

sh /usr/local/tomcat/version.sh

Atau, jika server Tomcat Anda berada di lokasi kustom, temukan version.sh dengan:

find / -name "version.sh"

Untuk melihat versi server JBoss EAP di sesi SSH:

$JBOSS_HOME/bin/jboss-cli.sh --connect --commands=:product-info

Untuk informasi lebih lanjut tentang dukungan versi, lihat Kebijakan Dukungan Runtime Bahasa App Service.

Apa yang terjadi terhadap runtime yang kedaluwarsa di App Service?

Runtime yang ketinggalan jaman tidak digunakan lagi oleh organisasi yang memelihara atau ditemukan 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 telah dihapus di portal, tetapi masih didukung.

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

Menyebarkan aplikasi Anda

Membangun alat

Maven

Dengan menggunakan Maven Plugin untuk Azure Web Apps, Anda dapat dengan mudah menyiapkan proyek Anda dengan satu perintah di akar proyek Anda:

mvn com.microsoft.azure:azure-webapp-maven-plugin:2.13.0:config

Perintah ini menambahkan azure-webapp-maven-plugin plugin dan konfigurasi terkait dengan meminta Anda untuk memilih Azure Web App yang sudah ada atau untuk membuat yang baru. Selama konfigurasi, ia mencoba mendeteksi apakah aplikasi Anda harus disebarkan ke Java SE, Tomcat, atau (khusus Linux) JBoss EAP. Kemudian Anda dapat menyebarkan aplikasi Java ke Azure dengan menggunakan perintah berikut:

mvn package azure-webapp:deploy

Berikut adalah konfigurasi sampel di pom.xml:

<plugin> 
  <groupId>com.microsoft.azure</groupId>  
  <artifactId>azure-webapp-maven-plugin</artifactId>  
  <version>2.11.0</version>  
  <configuration>
    <subscriptionId>111111-11111-11111-1111111</subscriptionId>
    <resourceGroup>spring-boot-xxxxxxxxxx-rg</resourceGroup>
    <appName>spring-boot-xxxxxxxxxx</appName>
    <pricingTier>B2</pricingTier>
    <region>westus</region>
    <runtime>
      <os>Linux</os>      
      <webContainer>Java SE</webContainer>
      <javaVersion>Java 17</javaVersion>
    </runtime>
    <deployment>
      <resources>
        <resource>
          <type>jar</type>
          <directory>${project.basedir}/target</directory>
          <includes>
            <include>*.jar</include>
          </includes>
        </resource>
      </resources>
    </deployment>
  </configuration>
</plugin>

Gradle

  1. Siapkan Plugin Gradle untuk Azure Web Apps dengan menambahkan plugin ke build.gradle:

    plugins {
  id "com.microsoft.azure.azurewebapp" version "1.10.0"
}

  2. Konfigurasikan detail aplikasi web Anda. Sumber daya Azure yang sesuai akan dibuat jika belum ada. Berikut adalah konfigurasi sampel. Untuk detailnya, lihat dokumen ini.

    azurewebapp {
    subscription = '<your subscription id>'
    resourceGroup = '<your resource group>'
    appName = '<your app name>'
    pricingTier = '<price tier like 'P1v2'>'
    region = '<region like 'westus'>'
    runtime {
      os = 'Linux'
      webContainer = 'Tomcat 10.0' // or 'Java SE' if you want to run an executable jar
      javaVersion = 'Java 17'
    }
    appSettings {
        <key> = <value>
    }
    auth {
        type = 'azure_cli' // support azure_cli, oauth2, device_code and service_principal
    }
}

  3. Sebarkan dengan hanya satu perintah.

    gradle azureWebAppDeploy

IDE

Azure menyediakan pengalaman pengembangan Java App Service yang mulus di Lingkungan Pengembangan Terpadu (IDE) Java yang populer, termasuk:

API Kudu dan OneDeploy

Klien penerapan seperti plugin Maven, GitHub Actions menggunakan azure/webapps-deploy@v3 dan yang lebih baru, atau perintah az webapp deploy menggunakan OneDeploy, yang dijalankan dengan memanggil /api/publish titik akhir situs Kudu secara internal. Untuk informasi selengkapnya tentang API ini, lihat dokumentasi ini.

Ketika metode penyebaran ini digunakan, mereka akan secara otomatis mengganti nama file JAR yang disediakan menjadi app.jar selama proses penyebaran. Ini akan ditempatkan di bawah /home/site/wwwwroot. Untuk menyebarkan file JAR ke Java SE, lihat dokumentasi ini.

Catatan

Jika Anda menggunakan metode alternatif seperti FTP atau API ZipDeploy yang lebih lama, metode mengganti nama file JAR yang disediakan ini tidak akan dipanggil. Perhatikan hal ini jika menggunakan kotak teks File Startup di bagian Konfigurasi portal untuk secara eksplisit memanggil file JAR Anda.

Anda dapat menyebarkan file WAR ke aplikasi Tomcat Anda dengan mengikuti dokumentasi ini. Ketika metode penyebaran di atas digunakan, mereka akan secara otomatis mengganti nama file WAR yang disediakan menjadi app.war selama proses penyebaran. Ini akan ditempatkan di bawah /home/site/wwwwroot dan secara default hanya mendukung penyebaran satu file WAR di bawah wwwroot. Ini tidak akan ditempatkan di bawah direktori tertentu seperti yang terlihat saat menggunakan API penyebaran seperti WarDeploy. Untuk menghindari masalah dengan konflik struktur berkas, disarankan untuk hanya menggunakan salah satu jenis penyebaran saja.

Untuk menyebarkan file WAR ke JBoss EAP, lihat dokumentasi ini. Ketika OneDeploy digunakan, ini akan secara otomatis mengganti nama file WAR menjadi app.war dan ditempatkan di bawah /home/site/wwwroot.

Untuk menyebarkan file EAR, gunakan FTP. Aplikasi EAR Anda disebarkan ke akar konteks yang ditentukan dalam konfigurasi aplikasi Anda. Jika Anda ingin aplikasi web Anda dilayani di jalur akar, pastikan aplikasi Anda mengatur akar konteks ke jalur akar: <context-root>/</context-root>. Untuk informasi selengkapnya, lihat Mengatur akar konteks aplikasi web.

Jangan sebarkan WAR atau JAR Anda dengan menggunakan FTP. Alat FTP dirancang untuk mengunggah skrip startup, dependensi, atau file runtime lainnya. Ini bukan pilihan optimal untuk menyebarkan aplikasi web.

Menulis ulang atau mengalihkan URL

Untuk menulis ulang atau mengalihkan URL, gunakan salah satu penulis ulang URL yang tersedia, seperti UrlRewriteFilter.

Tomcat juga menyediakan katup penulisan ulang.

JBoss EAP juga menyediakan katup penulisan ulang.

Aplikasi pencatatan dan debugging

Laporan performa, visualisasi lalu lintas, dan pemeriksaan kesehatan tersedia untuk setiap aplikasi melalui portal Azure. Untuk informasi selengkapnya, lihat Gambaran umum diagnostik Azure App Service.

Streaming 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

Ganti <app-name> 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, pilih Ctrl+C.

Untuk informasi selengkapnya, lihat Mengalirkan log di Cloud Shell.

Akses konsol SSH di Linux

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

Gunakan perintah az webapp ssh .

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 direktori /home disimpan dalam kontainer itu sendiri dan tidak bertahan setelah aplikasi dimulai ulang.

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

Alat pemecahan masalah Linux

Gambar Java bawaan didasarkan pada sistem operasi Alpine Linux . Gunakan pengelola paket apk untuk memasang alat atau perintah pemecahan masalah.

Profiler Java

Semua runtime Java di Azure App Service dilengkapi dengan Java Development Kit (JDK) Flight Recorder untuk melakukan profiling terhadap beban kerja Java. Anda dapat menggunakannya untuk merekam Java Virtual Machine (JVM), sistem, dan peristiwa aplikasi, dan untuk memecahkan masalah dalam aplikasi Anda.

Untuk mempelajari selengkapnya tentang profiler Java, kunjungi dokumentasi Azure Application Insights.

Perekam Penerbangan Java

Semua runtime Java di App Service dilengkapi dengan Java Flight Recorder. Anda dapat menggunakannya untuk merekam peristiwa JVM, sistem, dan aplikasi dan untuk memecahkan masalah di aplikasi Java Anda.

SSH ke App Service dan jalankan jcmd perintah untuk melihat daftar semua proses Java yang berjalan. Selain jcmd itu sendiri, Anda harus melihat aplikasi Java Anda berjalan dengan nomor ID proses (PID).

078990bbcd11:/home# jcmd
Picked up JAVA_TOOL_OPTIONS: -Djava.net.preferIPv4Stack=true
147 sun.tools.jcmd.JCmd
116 /home/site/wwwroot/app.jar

Jalankan perintah berikut untuk memulai rekaman 30 detik JVM. Ini memprofilkan JVM dan membuat file Java Flight Recorder (JFR) bernama jfr_example.jfr di direktori beranda. Ganti 116 dengan PID aplikasi Java Anda.

jcmd 116 JFR.start name=MyRecording settings=profile duration=30s filename="/home/jfr_example.jfr"

Selama interval 30 detik, Anda dapat memvalidasi rekaman yang sedang berlangsung dengan menjalankan jcmd 116 JFR.check. Perintah menunjukkan semua rekaman untuk proses Java yang diberikan.

Perekaman berkelanjutan

Anda dapat menggunakan Java Flight Recorder untuk terus memprofilkan aplikasi Java Anda dengan dampak minimal pada performa runtime. Untuk melakukannya, jalankan perintah Azure CLI berikut untuk membuat pengaturan aplikasi bernama JAVA_OPTS dengan konfigurasi yang diperlukan. Konten JAVA_OPTS pengaturan aplikasi diteruskan ke java perintah saat aplikasi Anda dimulai.

az webapp config appsettings set -g <your_resource_group> -n <your_app_name> --settings JAVA_OPTS=-XX:StartFlightRecording=disk=true,name=continuous_recording,dumponexit=true,maxsize=1024m,maxage=1d

Setelah perekaman dimulai, Anda dapat membuang data rekaman saat ini kapan saja dengan menggunakan JFR.dump perintah .

jcmd <pid> JFR.dump name=continuous_recording filename="/home/recording1.jfr"

Menganalisis file JFR

Gunakan FTPS untuk mengunduh file JFR Anda ke komputer lokal Anda. Untuk menganalisis file JFR, unduh dan instal Java Mission Control (JMC). Untuk petunjuk tentang cara menggunakan Java Mission Control, lihat dokumentasi JMC dan instruksi penginstalan.

Pengelogan Aplikasi

Untuk mengonfigurasi App Service untuk menulis output konsol standar aplikasi Anda dan aliran kesalahan konsol standar ke sistem file lokal atau Azure Blob Storage, lakukan hal berikut. Aktifkan pengelogan aplikasi melalui portal Microsoft Azure atau di Azure CLI. Jika Anda memerlukan retensi yang lebih lama, konfigurasikan aplikasi untuk menulis output ke kontainer Blob Storage.

Log aplikasi Java dan Tomcat Anda dapat ditemukan di /home/LogFiles/Application/ direktori.

Pengelogan Azure Blob Storage untuk aplikasi berbasis Linux hanya dapat dikonfigurasi dengan menggunakan Azure Monitor.

Jika aplikasi Anda menggunakan Logback atau Log4j untuk pelacakan, Anda dapat meneruskan jejak ini untuk ditinjau ke Azure Application Insights. Gunakan instruksi konfigurasi kerangka kerja pengelogan di Menjelajahi log jejak Java di Application Insights.

Catatan

Karena kerentanan CVE-2021-44228yang diketahui , pastikan untuk menggunakan Log4j versi 2.16 atau yang lebih baru.

Kustomisasi dan penyetelan

Azure App Service mendukung penyetelan dan penyesuaian di luar kotak melalui portal Microsoft Azure dan Azure CLI. Tinjau artikel berikut untuk konfigurasi aplikasi web non-Java tertentu:

Menyalin konten aplikasi secara lokal

Atur pengaturan aplikasi JAVA_COPY_ALL ke true untuk menyalin konten aplikasi Anda ke pekerja lokal dari sistem file bersama. Pengaturan ini membantu mengatasi masalah penguncian file.

Atur opsi runtime Java

Untuk mengatur memori yang dialokasikan atau opsi runtime JVM lainnya, buat pengaturan aplikasi bernama JAVA_OPTS dengan opsi . App Service mengoper pengaturan ini sebagai variabel lingkungan ke runtime Java ketika dimulai.

Di portal Microsoft Azure, di bawah Pengaturan Aplikasi untuk aplikasi web, buat pengaturan aplikasi baru bernama JAVA_OPTS yang menyertakan pengaturan lain, seperti -Xms512m -Xmx1204m.

Di portal Microsoft Azure, di bawah Pengaturan Aplikasi untuk aplikasi web, buat pengaturan aplikasi baru bernama CATALINA_OPTS yang menyertakan pengaturan lain, seperti -Xms512m -Xmx1204m.

Untuk mengonfigurasi pengaturan aplikasi dari plugin Maven, tambah tag pengaturan/nilai di bagian plugin Azure. Contoh berikut menetapkan ukuran heap Java minimum dan maksimum tertentu:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Xms1024m -Xmx1024m</value>
    </property>
</appSettings>

Catatan

Anda tidak perlu membuat file web.config saat menggunakan Tomcat di Windows App Service.

Secara default, App Service mengatur ukuran JVM Max Heap menjadi 70% dari total memori yang tersedia untuk Paket App Service. Untuk menonaktifkan pengaturan default, Anda dapat menggunakan pengaturan aplikasi WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION="true".

Meningkatkan performa aplikasi Anda di platform mungkin melibatkan penyesuaian ukuran timbunan agar lebih sesuai dengan kebutuhan spesifik Anda. Saat menyetel pengaturan timbunan aplikasi, tinjau detail paket App Service Anda dan pertimbangkan persyaratan beberapa aplikasi dan slot penyebaran untuk menemukan alokasi memori yang optimal.

Mengaktifkan soket web

Aktifkan dukungan untuk soket web di portal Microsoft Azure di pengaturan Aplikasi untuk aplikasi. Anda perlu menghidupkan ulang aplikasi agar pengaturan diterapkan.

Aktifkan dukungan soket web dengan menggunakan Azure CLI dengan perintah berikut:

az webapp config set --name <app-name> --resource-group <resource-group-name> --web-sockets-enabled true

Kemudian, mulai ulang aplikasi Anda:

az webapp stop --name <app-name> --resource-group <resource-group-name>
az webapp start --name <app-name> --resource-group <resource-group-name>

Tetapkan pengodean karakter default

Di portal Microsoft Azure, di bawah Pengaturan Aplikasi untuk aplikasi web, buat pengaturan aplikasi baru bernama JAVA_OPTS dengan nilai -Dfile.encoding=UTF-8.

Atau, Anda dapat mengonfigurasi pengaturan aplikasi dengan menggunakan plugin App Service Maven. Tambah nama pengaturan dan tag nilai dalam konfigurasi plugin:

<appSettings>
    <property>
        <name>JAVA_OPTS</name>
        <value>-Dfile.encoding=UTF-8</value>
    </property>
</appSettings>

File JSP prakompilasi

Untuk meningkatkan performa aplikasi Tomcat, Anda dapat mengompilasi file JSP sebelum menyebarkan ke Azure App Service. Anda dapat menggunakan plugin Maven yang disediakan oleh Apache Sling, atau menggunakan file build Ant ini.

Abaikan pesan robots933456 dalam log

Anda mungkin melihat pesan berikut di log kontainer:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Anda dapat mengabaikan pesan ini dengan aman. /robots933456.txt adalah jalur URL dummy yang digunakan App Service untuk memeriksa apakah kontainer mampu melayani permintaan. Respons 404 menunjukkan bahwa jalur tidak ada, dan memberi sinyal ke App Service bahwa kontainer sehat dan siap merespons permintaan.

Pilih versi runtime Java

App Service memungkinkan pengguna untuk memilih versi utama JVM, seperti Java 8 atau Java 11, dan versi patch, seperti 1.8.0_232 atau 11.0.5. Anda juga dapat memilih untuk memperbarui versi patch secara otomatis saat versi minor baru tersedia. Dalam kebanyakan kasus, aplikasi produksi harus menggunakan versi JVM patch yang disematkan, yang mencegah pemadaman yang tidak diantisipasi selama pembaruan otomatis versi patch. Semua aplikasi web Java menggunakan JVM 64-bit, dan tidak dapat dikonfigurasi.

Jika Anda menggunakan Tomcat, Anda dapat memilih untuk menetapkan versi patch Tomcat. Di Windows, Anda dapat menyematkan versi patch JVM dan Tomcat secara terpisah. Di Linux, Anda dapat menyematkan versi patch Tomcat. Versi patch JVM juga disematkan tetapi tidak dapat dikonfigurasi secara terpisah.

Jika Anda memilih untuk menyematkan versi minor, Anda perlu memperbarui versi minor JVM secara berkala pada aplikasi tersebut. Untuk memastikan aplikasi Anda berjalan di versi minor terbaru, buat slot staging dan tingkatkan versi minor di slot staging tersebut. Setelah Anda mengonfirmasi bahwa aplikasi berjalan dengan benar pada versi minor baru, Anda dapat mengubah slot penahapan dan produksi.

Jalankan JBoss CLI

Dalam sesi SSH aplikasi JBoss EAP Anda, Anda dapat menjalankan JBoss CLI dengan perintah berikut:

$JBOSS_HOME/bin/jboss-cli.sh --connect

Tergantung pada fase siklus server di mana JBoss EAP berada, Anda mungkin tidak dapat terhubung. Silakan tunggu beberapa menit, lalu coba kembali. Pendekatan ini berguna untuk pemeriksaan cepat status server Anda saat ini (misalnya, untuk melihat apakah sumber data dikonfigurasi dengan benar).

Selain itu, perubahan yang Anda buat pada server dengan JBoss CLI di sesi SSH tidak bertahan setelah aplikasi dimulai ulang. Setiap kali aplikasi dimulai, server JBoss EAP dimulai dengan penginstalan yang bersih. Selama siklus hidup startup, App Service membuat konfigurasi server yang diperlukan dan menyebarkan aplikasi. Untuk membuat perubahan persisten di server JBoss EAP, gunakan skrip startup kustom atau perintah startup. Untuk contoh end-to-end, lihat Mengonfigurasi sumber data untuk aplikasi Java SE, Tomcat, atau JBoss EAP di Azure App Service.

Atau, Anda dapat mengonfigurasi App Service secara manual untuk menjalankan file apa pun saat memulai. Contohnya:

az webapp config set --resource-group <group-name> --name <app-name> --startup-file /home/site/scripts/foo.sh

Untuk informasi selengkapnya tentang perintah CLI yang bisa Anda jalankan, lihat:

Pengklusteran

App Service mendukung pengklusteran untuk JBoss EAP versi 7.4.1 dan yang lebih baru. Untuk mengaktifkan pengklusteran, aplikasi web Anda harus diintegrasikan dengan jaringan virtual. Ketika aplikasi web terintegrasi dengan jaringan virtual, aplikasi ini dimulai ulang, dan penginstalan JBoss EAP secara otomatis dimulai dengan konfigurasi berkluster. Saat Anda menjalankan beberapa instans dengan penskalaan otomatis, instans JBoss EAP berkomunikasi satu sama lain melalui subnet yang ditentukan dalam integrasi jaringan virtual. Anda dapat menonaktifkan pengklusteran dengan membuat pengaturan aplikasi bernama WEBSITE_DISABLE_CLUSTERING dengan nilai apa pun.

Diagram yang menunjukkan aplikasi App Service JBoss EAP terintegrasi jaringan virtual, diskalakan ke tiga instans.

Catatan

Jika Anda mengaktifkan integrasi jaringan virtual dengan templat ARM, Anda perlu mengatur properti vnetPrivatePorts secara manual ke nilai 2. Jika Anda mengaktifkan integrasi jaringan virtual dari CLI atau portal, properti ini diatur untuk Anda secara otomatis.

Saat pengklusteran diaktifkan, instans JBoss EAP menggunakan FILE_PING protokol penemuan JGroups untuk menemukan instans baru dan mempertahankan informasi kluster (misalnya: anggota kluster, pengidentifikasi mereka, dan alamat IP mereka). Pada App Service, file-file ini berada di bawah /home/clusterinfo/. Instans EAP pertama yang mulai mendapatkan izin baca/tulis pada file keanggotaan kluster. Instans lain membaca file, menemukan simpul utama, dan berkoordinasi dengan simpul tersebut untuk disertakan dalam kluster dan ditambahkan ke file.

Catatan

Anda dapat menghindari timeout pengelompokan JBoss EAP dengan membersihkan file penemuan usang selama proses awal aplikasi Anda.

Jenis Paket App Service Premium V3, Premium V4, dan V2 Terisolasi dapat didistribusikan secara opsional di seluruh Zona Ketersediaan untuk meningkatkan ketahanan dan keandalan beban kerja penting bisnis Anda. Arsitektur ini juga dikenal sebagai redundansi zona. Fitur pengklusteran JBoss EAP kompatibel dengan fitur redundansi zona.

Aturan Autoscale

Saat Anda mengonfigurasi aturan skala otomatis untuk penskalaan horizontal, penting untuk menghapus instans secara bertahap (satu per satu) untuk memastikan bahwa setiap instans yang dihapus dapat mentransfer aktivitasnya (seperti menangani transaksi database) ke anggota kluster lain. Saat Anda mengonfigurasi aturan skala otomatis di portal untuk menurunkan skala, gunakan opsi berikut:

  • Operasi: "Kurangi jumlah sebanyak"
  • Pendinginan: "5 menit" atau lebih
  • Jumlah instance: 1

Anda tidak perlu menambahkan unit secara bertahap (memperluas kapasitas). Anda dapat menambahkan beberapa instans ke kluster sekaligus.

Paket Layanan Aplikasi

JBoss EAP tersedia dalam tingkat harga berikut: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, P5mv3, P0v4, P1mv4, P2mv4, P3mv4, P4mv4, dan P5mv4.

JBoss EAP siklus hidup server

Aplikasi JBoss EAP di App Service melewati lima fase berbeda sebelum meluncurkan server:

  1. Fase penyiapan lingkungan
  2. Fase peluncuran server
  3. Fase konfigurasi server
  4. Fase penyebaran aplikasi
  5. Fase muat ulang server

Lihat bagian berikut untuk detail dan peluang untuk dikustomisasi (seperti melalui pengaturan aplikasi).

1. Fase penyiapan lingkungan

  • Layanan SSH dimulai untuk mengaktifkan sesi SSH yang aman dengan kontainer.
  • Keystore runtime Java diperbarui dengan sertifikat publik dan privat apa pun yang ditentukan di portal Microsoft Azure.
    • Sertifikat publik disediakan oleh platform di /var/ssl/certs direktori, dan dimuat ke $JRE_HOME/lib/security/cacerts.
    • Sertifikat privat disediakan oleh platform di /var/ssl/private direktori, dan dimuat ke $JRE_HOME/lib/security/client.jks.
  • Jika ada sertifikat yang dimuat dalam Java keystore pada langkah ini, properti javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword, dan javax.net.ssl.keyStoreType akan ditambahkan ke variabel lingkungan JAVA_OPTS.
  • Beberapa konfigurasi JVM awal ditentukan, seperti direktori pengelogan dan parameter tumpukan memori Java:
    • Jika Anda memberikan –Xms atau –Xmx parameter untuk memori di pengaturan aplikasi JAVA_OPTS, nilai-nilai ini akan menggantikan yang disediakan oleh platform.
    • Jika Anda mengkonfigurasi pengaturan aplikasi WEBSITES_CONTAINER_STOP_TIME_LIMIT, nilai tersebut akan diteruskan ke properti runtime org.wildfly.sigterm.suspend.timeout, yang mengontrol waktu tunggu maksimal untuk mematikan (dalam detik) ketika JBoss EAP sedang dihentikan.
  • Jika aplikasi terintegrasi dengan jaringan virtual, runtime App Service meneruskan daftar port yang akan digunakan untuk komunikasi antar server dalam variabel WEBSITE_PRIVATE_PORTS lingkungan dan meluncurkan JBoss EAP dengan menggunakan clustering konfigurasi. Jika tidak, konfigurasi standalone digunakan.
    • Untuk konfigurasi clustering, file konfigurasi server standalone-azure-full-ha.xml digunakan.
    • Untuk konfigurasi standalone, file konfigurasi server standalone-full.xml digunakan.

2. Fase peluncuran server

  • Jika JBoss EAP diluncurkan dalam konfigurasi clustering:
    • Setiap instance JBoss EAP menerima pengenal internal antara 0 dan jumlah instance yang digunakan saat aplikasi ditingkatkan skalanya.
    • Jika beberapa file ditemukan di jalur penyimpanan transaksi untuk instans server ini (dengan menggunakan pengidentifikasi internalnya), itu berarti instans server ini menggantikan instans layanan yang identik. Instans layanan lain sebelumnya mengalami crash dan meninggalkan transaksi yang tidak dilakukan. Server dikonfigurasi untuk melanjutkan pekerjaan pada transaksi ini.
  • Terlepas dari apakah JBoss EAP dimulai dalam konfigurasi clustering atau standalone, jika versi server adalah 7.4 atau yang lebih baru dan runtime menggunakan Java 17, maka konfigurasi diperbarui untuk mengaktifkan subsistem Elytron untuk keamanan.
  • Jika Anda mengonfigurasi pengaturan aplikasi WEBSITE_JBOSS_OPTS, nilai tersebut akan diteruskan ke skrip peluncur JBoss. Pengaturan ini dapat digunakan untuk menyediakan jalur ke berkas properti dan lebih banyak bendera yang mempengaruhi proses startup JBoss EAP.

3. Fase konfigurasi server

  • Pada awal tahap ini, App Service akan terlebih dahulu menunggu hingga server JBoss EAP dan antarmuka admin siap menerima permintaan sebelum melanjutkan. Proses ini dapat memakan waktu beberapa detik lagi jika Application Insights diaktifkan.

  • Ketika JBoss EAP Server dan antarmuka admin siap, App Service mengambil tindakan berikut:

    • Menambahkan modul JBoss EAP azure.appservice, yang menyediakan kelas utilitas untuk pencatatan dan integrasi dengan App Service.
    • Memperbarui pencatat konsol untuk menggunakan mode tanpa warna sehingga file log tidak penuh dengan urutan pelepasan warna.
    • Menyiapkan integrasi dengan log Azure Monitor.
    • Memperbarui alamat IP pengikatan Bahasa Deskripsi Layanan Web (WSDL) dan antarmuka manajemen.
    • Menambahkan modul azure.appservice.easyauth JBoss EAP untuk integrasi dengan autentikasi App Service dan ID Microsoft Entra.
    • Memperbarui konfigurasi pengelogan log akses dan nama dan rotasi file log server utama.

  • Kecuali jika pengaturan aplikasi WEBSITE_SKIP_AUTOCONFIGURE_DATABASE telah ditentukan, App Service secara otomatis mendeteksi URL Java Database Connectivity (JDBC) dalam pengaturan aplikasi App Service. Jika URL JDBC yang valid ada untuk PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, atau Azure SQL Database, url menambahkan driver yang sesuai ke server, menambahkan sumber data untuk setiap URL JDBC, dan mengatur nama Java Naming and Directory Interface (JNDI) untuk setiap sumber data ke java:jboss/env/jdbc/<app-setting-name>_DS, di mana <app-setting-name> adalah nama pengaturan aplikasi.

  • Jika konfigurasi clustering diaktifkan, pencatat konsol yang akan dikonfigurasi akan diverifikasi.

  • Jika ada file JAR yang disebarkan ke /home/site/libs direktori, modul global baru dibuat dengan semua file JAR ini.

  • Di akhir fase, App Service menjalankan skrip startup kustom, jika ada. Logika pencarian untuk skrip startup kustom didefinisikan sebagai berikut:

    • Jika Anda mengonfigurasi perintah startup (misalnya, melalui portal Microsoft Azure atau Azure CLI), jalankan; Sebaliknya
    • Jika jalur /home/site/scripts/startup.sh ada, gunakan; jika tidak,
    • Jika jalur /home/startup.sh ada, gunakan jalur tersebut.

Perintah startup kustom atau skrip berjalan sebagai pengguna root (tidak perlu sudo), sehingga mereka dapat menginstal paket Linux atau meluncurkan JBoss CLI untuk melakukan lebih banyak perintah penginstalan/kustomisasi JBoss EAP seperti membuat sumber data dan menginstal adaptor sumber daya. Untuk informasi tentang perintah manajemen paket Ubuntu, lihat dokumentasi Ubuntu Server. Untuk perintah JBoss CLI, lihat Panduan CLI Manajemen JBoss.

4. Fase penyebaran aplikasi

Script startup men-deploy aplikasi ke JBoss EAP dengan mencari di lokasi-lokasi berikut, berdasarkan urutan prioritas:

  • Jika Anda mengonfigurasi pengaturan aplikasi WEBSITE_JAVA_WAR_FILE_NAME, sebarkan file yang ditentukan olehnya.
  • Jika /home/site/wwwroot/app.war ada, sebarkan.
  • Jika ada file EAR dan WAR lainnya di /home/site/wwwroot, sebarkan.
  • Jika /home/site/wwwroot/webapps ada, sebarkan file dan direktori di dalamnya. File WAR diluncurkan sebagai aplikasi itu sendiri, dan direktori diluncurkan sebagai aplikasi web terkompresi (tidak dikompresi).
  • Jika ada halaman JSP mandiri di /home/site/wwwroot, salin ke root server web dan sebarkan sebagai satu aplikasi web.
  • Jika tidak ada file yang dapat disebarkan yang ditemukan, sebarkan halaman selamat datang default (halaman parkir) dalam konteks akar.

5. Fase muat ulang server

  • Setelah langkah-langkah penyebaran selesai, server JBoss EAP dimuat ulang untuk menerapkan perubahan apa pun yang memerlukan pemuatan ulang server.
  • Setelah server dimuat ulang, aplikasi yang disebarkan ke server JBoss EAP harus siap merespons permintaan.
  • Server berjalan hingga aplikasi App Service dihentikan atau dimulai ulang. Anda dapat menghentikan atau memulai ulang aplikasi App Service secara manual, atau memicu mulai ulang saat menyebarkan file atau membuat perubahan konfigurasi pada aplikasi App Service.
  • Jika server JBoss EAP keluar secara tidak normal dalam konfigurasi clustering, suatu fungsi akhir yang disebut emit_alert_tx_store_not_empty akan dijalankan. Fungsi ini memeriksa apakah proses JBoss EAP meninggalkan file penyimpanan transaksi yang tidak kosong di disk. Jika demikian, kesalahan dicatat di konsol: Error: finishing server with non-empty store for node XXXX. Ketika instans server baru dimulai, ia mencari file penyimpanan transaksi yang tidak kosong untuk melanjutkan pekerjaan (lihat 2. Fase peluncuran server).

Konfigurasi dasar Tomcat

Catatan

Bagian ini hanya berlaku untuk Linux.

Pengembang Java dapat menyesuaikan pengaturan server, memecahkan masalah, dan menyebarkan aplikasi ke Tomcat dengan percaya diri jika mereka tahu tentang file server.xml dan detail konfigurasi Tomcat. Kemungkinan penyesuaian meliputi:

  • Menyesuaikan konfigurasi Tomcat: Saat Anda memahami file server.xml dan detail konfigurasi Tomcat, Anda dapat menyempurnakan pengaturan server agar sesuai dengan kebutuhan aplikasi mereka.
  • Debugging: Saat aplikasi disebarkan di server Tomcat, pengembang perlu mengetahui konfigurasi server untuk memecahkan masalah apa pun yang mungkin muncul. Proses ini termasuk memeriksa log server, memeriksa file konfigurasi, dan mengidentifikasi kesalahan apa pun yang mungkin terjadi.
  • Pemecahan masalah Tomcat: Tak pelak, pengembang Java mengalami masalah dengan server Tomcat mereka, seperti masalah performa atau kesalahan konfigurasi. Ketika Anda memahami file server.xml dan detail konfigurasi Tomcat, pengembang dapat dengan cepat mendiagnosis dan memecahkan masalah ini, yang dapat menghemat waktu dan upaya.
  • Menyebarkan aplikasi ke Tomcat: Untuk menyebarkan aplikasi web Java ke Tomcat, pengembang perlu tahu cara mengonfigurasi file server.xml dan pengaturan Tomcat lainnya. Anda perlu memahami detail ini untuk berhasil menyebarkan aplikasi dan memastikan bahwa aplikasi berjalan lancar di server.

Saat Anda membuat aplikasi dengan Tomcat bawaan untuk menghosting beban kerja Java Anda (file WAR atau file JAR), ada pengaturan bawaan yang Anda dapatkan untuk konfigurasi Tomcat. Anda dapat merujuk ke dokumentasi resmi Apache Tomcat untuk informasi terperinci, termasuk konfigurasi default untuk Tomcat Web Server.

Selain itu, ada transformasi tertentu yang diterapkan pada sistem distribusi Tomcat server.xml saat startup. Transformasi ini mencakup perubahan pada pengaturan Konektor, Host, dan Katup .

Versi terbaru Tomcat memiliki server.xml (8.5.58 dan 9.0.38 dan seterusnya). Versi Lama Tomcat tidak menggunakan transformasi dan mungkin memiliki perilaku yang berbeda sebagai hasilnya.

Konektor

<Connector port="${port.http}" address="127.0.0.1" maxHttpHeaderSize="16384" compression="on" URIEncoding="UTF-8" connectionTimeout="${site.connectionTimeout}" maxThreads="${catalina.maxThreads}" maxConnections="${catalina.maxConnections}" protocol="HTTP/1.1" redirectPort="8443"/>
  • maxHttpHeaderSize diatur ke 16384.
  • URIEncoding diatur ke UTF-8.
  • connectionTimeout diatur ke WEBSITE_TOMCAT_CONNECTION_TIMEOUT, yang secara default diatur ke 240000.
  • maxThreads diatur ke WEBSITE_CATALINA_MAXTHREADS, yang secara default diatur ke 200.
  • maxConnections diatur ke WEBSITE_CATALINA_MAXCONNECTIONS, yang secara default diatur ke 10000.

Catatan

Pengaturan connectionTimeout, maxThreads, dan maxConnections dapat disetel dengan pengaturan aplikasi.

Berikut ini adalah contoh perintah CLI yang mungkin Anda gunakan untuk mengubah nilai connectionTimeout, , maxThreadsatau maxConnections:

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_TOMCAT_CONNECTION_TIMEOUT=120000

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXTHREADS=100

az webapp config appsettings set --resource-group myResourceGroup --name myApp --settings WEBSITE_CATALINA_MAXCONNECTIONS=5000

Konektor menggunakan alamat kontainer alih-alih 127.0.0.1.

Tuan Rumah

<Host appBase="${site.appbase}" xmlBase="${site.xmlbase}" unpackWARs="${site.unpackwars}" workDir="${site.tempdir}" errorReportValveClass="com.microsoft.azure.appservice.AppServiceErrorReportValve" name="localhost" autoDeploy="true">
  • appBase diatur ke AZURE_SITE_APP_BASE, yang defaultnya ke lokal WebappsLocalPath.
  • xmlBase diatur ke AZURE_SITE_HOME, yang secara default diatur ke /site/wwwroot.
  • unpackWARs diatur ke AZURE_UNPACK_WARS, yang secara default diatur ke true.
  • workDir diatur ke JAVA_TMP_DIR, yang defaultnya TMP.
  • errorReportValveClass menggunakan katup laporan kesalahan kustom kami.

Katup

<Valve prefix="site_access_log.${catalina.instance.name}" pattern="%h %l %u %t &quot;%r&quot; %s %b %D %{x-arr-log-id}i" directory="${site.logdir}/http/RawLogs" maxDays="${site.logRetentionDays}" className="org.apache.catalina.valves.AccessLogValve" suffix=".txt"/>
  • directory diatur ke AZURE_LOGGING_DIR, yang secara default diatur ke home\logFiles.
  • maxDays diatur ke WEBSITE_HTTPLOGGING_RETENTION_DAYS, yang secara default diatur ke 7. Nilai ini selaras dengan default platform pengelogan aplikasi.

Di Linux, ia memiliki semua kustomisasi yang sama, dan menambahkan beberapa halaman kesalahan dan pelaporan ke katup:

<xsl:attribute name="appServiceErrorPage">
    <xsl:value-of select="'${appService.valves.appServiceErrorPage}'"/>
</xsl:attribute>

<xsl:attribute name="showReport">
    <xsl:value-of select="'${catalina.valves.showReport}'"/>
</xsl:attribute>

<xsl:attribute name="showServerInfo">
    <xsl:value-of select="'${catalina.valves.showServerInfo}'"/>
</xsl:attribute>

Konten terkait

Kunjungi pusat Azure untuk Pengembang Java untuk menemukan panduan cepat, tutorial, dan dokumentasi referensi Azure Java.