Bagikan melalui

Menyebarkan dan mengonfigurasi aplikasi Tomcat, JBoss, atau Java SE di Azure App Service

  • Artikel

Artikel ini memperlihatkan kepada Anda konfigurasi penyebaran dan runtime yang paling umum untuk aplikasi Java di App Service. Jika Anda belum pernah menggunakan Azure App Service, Anda harus membaca mulai cepat Java dahulu. Pertanyaan umum tentang menggunakan Azure App Service yang tidak spesifik untuk pengembangan Java dijawab dalam Tanya Jawab Umum Azure App Service.

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

  • Java SE - Dapat menjalankan aplikasi yang disebarkan sebagai paket JAR yang berisi server yang disematkan (seperti Spring Boot, Dropwizard, Quarkus, atau satu dengan server Tomcat atau Jetty yang disematkan).
  • Tomcat - Server Tomcat bawaan dapat menjalankan aplikasi yang disebarkan sebagai paket WAR.
  • JBoss EAP - Hanya didukung untuk aplikasi Linux di tingkat harga Gratis, Premium v3, dan Terisolasi v2. Server JBoss EAP bawaan dapat menjalankan aplikasi yang disebarkan sebagai paket WAR atau EAR.

Catatan

Untuk aplikasi Spring, sebaiknya gunakan Azure Spring Apps. Namun, Anda masih dapat menggunakan Azure App Service sebagai tujuan. Lihat Panduan Tujuan Beban Kerja Java untuk saran.

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 memperlihatkan semua versi Java yang didukung, jalankan perintah berikut di Azure Cloud Shell:

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

Untuk informasi selengkapnya tentang dukungan versi, lihat Kebijakan dukungan runtime bahasa app service.

Menyebarkan aplikasi Anda

Build Tools

Maven

Dengan Maven Plugin untuk Azure Web Apps, Anda dapat menyiapkan proyek Maven Java untuk Azure Web App dengan mudah 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 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 Anda ke Azure 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 dibuat jika tidak ada. Berikut adalah contoh konfigurasi, 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 satu perintah.

    gradle azureWebAppDeploy

IDE

Azure memberikan pengalaman pengembangan Java App Service yang mulus di IDE Java yang populer, termasuk:

API Kudu

Untuk menyebarkan file .jar ke Java SE, gunakan titik akhir /api/publish dari situs Kudu. Untuk informasi selengkapnya tentang API ini, lihat dokumentasi ini.

Catatan

Aplikasi .jar Anda harus diberi nama app.jar untuk Azure App Service agar mengidentifikasi dan menjalankan aplikasi Anda. Plugin Maven melakukan ini untuk Anda secara otomatis selama penyebaran. Jika tidak ingin mengganti nama JAR menjadi app.jar, Anda dapat mengunggah skrip shell dengan perintah untuk menjalankan aplikasi .jar Anda. Tempel jalur absolut ke skrip ini di kotek teks File Startup di bagian Konfigurasi Portal. Skrip startup tidak berjalan dari direktori ke tempatnya ditempatkan. Oleh karena itu, selalu gunakan jalur absolut untuk mereferensikan file dalam skrip startup Anda (misalnya: java -jar /home/myapp/myapp.jar ).

Untuk menyebarkan file .war ke Tomcat, gunakan titik akhir /api/wardeploy/ untuk MEMPOSTING file arsip Anda. Untuk informasi selengkapnya tentang API ini, lihat dokumentasi ini.

Untuk menyebarkan file .war ke JBoss, gunakan titik akhir /api/wardeploy/ untuk MEMPOSTING file arsip Anda. Untuk informasi selengkapnya tentang API ini, lihat dokumentasi ini.

Untuk menyebarkan file .ear, gunakan FTP. Aplikasi .ear Anda disebarkan ke akar konteks yang ditentukan dalam konfigurasi aplikasi Anda. Misalnya, jika akar konteks aplikasi Anda adalah <context-root>myapp</context-root>, maka Anda dapat menelusuri situs di /myapp jalur: http://my-app-name.azurewebsites.net/myapp. 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 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 juga menyediakan katup penulisan ulang.

Aplikasi pengelogan dan penelusuran kesalahan

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

Mengalirkan 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 informasi selengkapnya, lihat Streaming log di Cloud Shell.

Akses konsol SSH di Linux

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.

Alat pemecahan masalah Linux

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

Java Profiler

Semua runtime Java di Azure App Service dilengkapi dengan JDK Flight Recorder untuk membuat profil beban kerja Java. Anda dapat menggunakannya untuk merekam JVM, sistem, dan peristiwa aplikasi dan memecahkan masalah dalam aplikasi Anda.

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

Perekam Aktivitas

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

SSH ke dalam Azure App Service Anda dan jalankan perintah jcmd untuk melihat daftar semua proses Java yang berjalan. Selain itu jcmd , Anda akan 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 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 dengan nama JAVA_OPTS dengan konfigurasi yang diperlukan. Konten Pengaturan Aplikasi JAVA_OPTS diteruskan ke perintah java 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 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. Untuk menganalisis file JFR, unduh dan instal Java Mission Control. Untuk petunjuk tentang Java Mission Control, lihat dokumentasi JMC dan instruksi penginstalan.

Pengelogan Aplikasi

Aktifkan pengelogan aplikasi melalui portal Azure atau Azure CLI untuk mengonfigurasi Azure App Service untuk menulis output konsol standar aplikasi Anda dan aliran kesalahan konsol standar ke sistem file lokal atau Azure Blob Storage. Jika Anda memerlukan retensi lebih lama, konfigurasikan aplikasi untuk menulis output ke kontainer penyimpanan Objek Besar Biner.

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

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

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

Catatan

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

Kustomisasi dan penyetelan

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

Salin Konten Aplikasi Secara Lokal

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

Mengatur opsi runtime Java

Untuk mengatur memori yang dialokasikan atau opsi runtime JVM lainnya, buat pengaturan aplikasi yang diberi nama JAVA_OPTS dengan opsi tersebut. Azure App Service melewati pengaturan ini sebagai variabel lingkungan ke runtime Java saat dimulai.

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

Di portal 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.

Pengembang yang menjalankan satu aplikasi dengan satu slot penyebaran dalam paket Azure App Service mereka dapat menggunakan opsi berikut:

  • Instans B1 dan S1: -Xms1024m -Xmx1024m
  • Instans B2 dan S2: -Xms3072m -Xmx3072m
  • Instans B3 dan S3: -Xms6144m -Xmx6144m
  • Instans P1v2: -Xms3072m -Xmx3072m
  • Instans P2v2: -Xms6144m -Xmx6144m
  • Instans P3v2: -Xms12800m -Xmx12800m
  • Instans P1v3: -Xms6656m -Xmx6656m
  • Instans P2v3: -Xms14848m -Xmx14848m
  • Instans P3v3: -Xms30720m -Xmx30720m
  • Instans I1: -Xms3072m -Xmx3072m
  • Instans I2: -Xms6144m -Xmx6144m
  • Instans I3: -Xms12800m -Xmx12800m
  • Instans I1v2: -Xms6656m -Xmx6656m
  • Instans I2v2: -Xms14848m -Xmx14848m
  • Instans I3v2: -Xms30720m -Xmx30720m

Saat menyetel pengaturan heap aplikasi, tinjau detail paket Azure App Service Anda dan perhitungkan beberapa aplikasi dan slot penyebaran perlu menemukan alokasi memori yang optimal.

Mengaktifkan soket web

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

Aktifkan dukungan soket web 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>

Mengatur pengodean karakter default

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

Atau, Anda dapat mengonfigurasi pengaturan aplikasi menggunakan plugin Maven Azure App Service. 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 Sebelum Kompilasi

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 bangun Ant ini.

robot933456 dalam log

Anda mungkin melihat pesan berikut dalam 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 hanya menunjukkan bahwa jalur tersebut tidak ada, tetapi ini memberi tahu App Service bahwa kontainernya sehat dan siap untuk menanggapi permintaan.

Memilih versi runtime Java

App Service memungkinkan pengguna 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 agar versi patch diperbarui secara otomatis saat versi minor baru tersedia. Dalam kebanyakan kasus, aplikasi produksi harus menggunakan versi JVM patch yang disematkan. Ini mencegah pemadaman yang tidak terantisipasi 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 menyematkan 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 di aplikasi. Untuk memastikan bahwa aplikasi Anda berjalan pada versi minor yang lebih baru, buat slot penahapan dan tingkatkan versi minor pada slot penahapan. Setelah mengonfirmasi bahwa aplikasi berjalan dengan benar pada versi minor baru, Anda dapat menukar slot penahapan dan produksi.

Jalankan JBoss CLI

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

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

Tergantung di mana JBoss berada dalam siklus hidup server, 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 berlanjut 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, gunakan skrip startup kustom atau perintah startup. Untuk contoh end-to-end, lihat Mengonfigurasi sumber data untuk aplikasi Tomcat, JBoss, atau Java SE 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 dapat 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 terintegrasi 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 terintegrasi vnet, 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 protokol penemuan JGroups FILE_PING untuk menemukan instans baru dan mempertahankan informasi kluster seperti anggota kluster, pengidentifikasi kluster, dan alamat IP kluster. 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 batas waktu pengklusteran JBoss dengan membersihkan file penemuan usang selama startup aplikasi Anda.

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

Aturan Skala Otomatis

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

  • Operasi: "Kurangi hitungan sebanyak"
  • Pendinginan: "5 menit" atau lebih
  • Jumlah instans: 1

Anda tidak perlu menambahkan instans secara bertahap (perluasan skala), Anda dapat menambahkan beberapa instans ke kluster sekaligus.

Paket App Service

JBoss EAP tersedia dalam tingkat harga berikut: F1, P0v3, P1mv3, P2mv3, P3mv3, P4mv3, dan P5mv3.

Siklus hidup server JBoss

Aplikasi JBoss EAP di App Service melewati lima fase berbeda sebelum benar-benar meluncurkan server.

Lihat masing-masing bagian di bawah ini untuk detail serta peluang untuk menyesuaikannya (seperti melalui pengaturan aplikasi).

1. Fase penyiapan lingkungan

  • Layanan SSH mulai mengaktifkan sesi SSH yang aman dengan kontainer.
  • Keystore runtime Java diperbarui dengan sertifikat publik dan privat apa pun yang ditentukan dalam portal Azure.
    • Sertifikat publik disediakan oleh platform di direktori /var/ssl/certs , dan dimuat ke $JRE_HOME/lib/security/cacerts.
    • Sertifikat privat disediakan oleh platform di direktori /var/ssl/private , dan dimuat ke $JRE_HOME/lib/security/client.jks.
  • Jika ada sertifikat yang dimuat di keystore Java dalam langkah ini, properti javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword dan javax.net.ssl.keyStoreType ditambahkan ke JAVA_TOOL_OPTIONS variabel lingkungan.
  • Beberapa konfigurasi JVM awal ditentukan seperti direktori pengelogan dan parameter tumpukan memori Java:
    • Jika Anda memberikan –Xms bendera atau –Xmx untuk memori di pengaturan JAVA_OPTSaplikasi, nilai-nilai ini akan mengambil alih yang disediakan oleh platform.
    • Jika Anda mengonfigurasi pengaturan WEBSITES_CONTAINER_STOP_TIME_LIMITaplikasi , nilai diteruskan ke properti org.wildfly.sigterm.suspend.timeoutruntime , yang mengontrol waktu tunggu matikan maksimum (dalam detik) saat JBoss 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 menggunakan clustering konfigurasi. Jika tidak, standalone konfigurasi digunakan.
    • clustering Untuk konfigurasi, file konfigurasi server standalone-azure-full-ha.xml digunakan.
    • standalone Untuk konfigurasi, file konfigurasi server standalone-full.xml digunakan.

2. Fase peluncuran server

  • Jika JBoss diluncurkan dalam clustering konfigurasi:
    • Setiap instans JBoss menerima pengidentifikasi internal antara 0 dan jumlah instans tempat aplikasi diskalakan.
    • Jika beberapa file ditemukan di jalur penyimpanan transaksi untuk instans server ini (dengan menggunakan pengidentifikasi internalnya), itu berarti instans server ini menggantikan instans layanan identik yang mengalami crash sebelumnya dan meninggalkan transaksi yang tidak dikomit. Server dikonfigurasi untuk melanjutkan pekerjaan pada transaksi ini.
  • Terlepas dari apakah JBoss dimulai dalam clustering konfigurasi atau standalone , jika versi server adalah 7.4 atau lebih tinggi dan runtime menggunakan Java 17, konfigurasi diperbarui untuk mengaktifkan subsistem Elytron untuk keamanan.
  • Jika Anda mengonfigurasi pengaturan WEBSITE_JBOSS_OPTSaplikasi , nilai diteruskan ke skrip peluncur JBoss. Pengaturan ini dapat digunakan untuk menyediakan jalur ke file properti dan lebih banyak bendera yang memengaruhi startup JBoss.

3. Fase konfigurasi server

  • Pada awal fase ini, App Service terlebih dahulu menunggu server JBoss dan antarmuka admin siap menerima permintaan sebelum melanjutkan. Ini dapat memakan waktu beberapa detik lagi jika Application Insights diaktifkan.
  • Ketika JBoss Server dan antarmuka admin siap, App Service melakukan hal berikut:
    • Menambahkan modul azure.appserviceJBoss , yang menyediakan kelas utilitas untuk pengelogan 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 antarmuka WSDL dan manajemen.
    • Menambahkan modul azure.appservice.easyauth JBoss untuk integrasi dengan autentikasi App Service dan ID Microsoft Entra.
    • Memperbarui konfigurasi pengelogan log akses dan nama dan rotasi file log server utama.
  • Kecuali pengaturan WEBSITE_SKIP_AUTOCONFIGURE_DATABASE aplikasi ditentukan, App Service secara otomatis menentukan URL JDBC di 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 dan menambahkan sumber data untuk setiap URL JDBC dan mengatur nama JNDI untuk setiap sumber data ke java:jboss/env/jdbc/<app-setting-name>_DS, di mana <app-setting-name> adalah nama pengaturan aplikasi.
  • clustering Jika konfigurasi diaktifkan, pencatat konsol yang akan dikonfigurasi akan diperiksa.
  • Jika ada file JAR yang disebarkan ke direktori /home/site/libs , 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 sebagai berikut:
    • Jika Anda mengonfigurasi perintah startup (di portal Azure, dengan Azure CLI, dll.), jalankan; jika tidak,
    • 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 (membuat sumber data, menginstal adaptor sumber daya), dll. Untuk informasi tentang perintah manajemen paket Ubuntu, lihat dokumentasi Ubuntu Server. Untuk perintah JBoss CLI, lihat Panduan CLI Manajemen JBoss.

4. Fase penyebaran aplikasi

Skrip startup menyebarkan aplikasi ke JBoss dengan melihat di lokasi berikut, dalam urutan prioritas:

  • Jika Anda mengonfigurasi pengaturan WEBSITE_JAVA_WAR_FILE_NAMEaplikasi , sebarkan file yang ditunjuk olehnya.
  • Jika ada /home/site/wwwroot/app.war , sebarkan.
  • Jika ada file EAR dan WAR lainnya di /home/site/wwwroot, sebarkan.
  • Jika ada /home/site/wwwroot/webapps , sebarkan file dan direktori di dalamnya. File WAR disebarkan sebagai aplikasi itu sendiri, dan direktori disebarkan sebagai aplikasi web "meledak" (tidak dikompresi).
  • Jika ada halaman JSP mandiri di /home/site/wwwroot, salin ke root server web dan sebarkan sebagai satu aplikasi web.
  • Jika belum 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 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 keluar secara tidak normal dalam clustering konfigurasi, fungsi akhir yang disebut emit_alert_tx_store_not_empty dijalankan. Fungsi ini memeriksa apakah proses JBoss meninggalkan file penyimpanan transaksi yang tidak ada dalam 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 ada gunanya melanjutkan pekerjaan (lihat 2. Fase peluncuran server).

Konfigurasi garis besar 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: Dengan memahami file server.xml dan detail konfigurasi Tomcat, Anda dapat menyempurnakan pengaturan server agar sesuai dengan kebutuhan aplikasi mereka.
  • Penelusuran kesalahan: Saat aplikasi disebarkan di server Tomcat, pengembang perlu mengetahui konfigurasi server untuk men-debug masalah apa pun yang mungkin muncul. 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. Dengan 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. Memahami detail ini sangat penting 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 tertentu yang Anda keluarkan dari kotak untuk konfigurasi Tomcat. Anda dapat merujuk ke Dokumentasi Resmi Apache Tomcat untuk informasi terperinci, termasuk konfigurasi default untuk Server Web Tomcat.

Selain itu, ada transformasi tertentu yang diterapkan lebih lanjut di atas server.xml untuk distribusi Tomcat pada awalnya. Ini adalah transformasi ke 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
  • conectionTimeout diatur ke WEBSITE_TOMCAT_CONNECTION_TIMEOUT, yang defaultnya 240000
  • maxThreads diatur ke WEBSITE_CATALINA_MAXTHREADS, yang defaultnya 200
  • maxConnections diatur ke WEBSITE_CATALINA_MAXCONNECTIONS, yang defaultnya 10000

Catatan

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

Berikut adalah contoh perintah CLI yang mungkin Anda gunakan untuk mengubah nilai conectionTimeout, maxThreads, atau 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

Host

<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 defaultnya /site/wwwroot
  • unpackWARs diatur ke AZURE_UNPACK_WARS, yang defaultnya true
  • workDir diatur ke JAVA_TMP_DIR, yang default 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 defaultnya home\logFiles
  • maxDays adalah untuk WEBSITE_HTTPLOGGING_RETENTION_DAYS, yang default ke 0 [selamanya]

Di Linux, ia memiliki semua kustomisasi yang sama, ditambah:

  • 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>

Langkah berikutnya

Kunjungi pusat Azure for Java Developers untuk menemukan mulai cepat Azure, tutorial, dan dokumentasi referensi Java.