Baca dalam bahasa Inggris

Bagikan melalui

Memigrasikan aplikasi WebSphere ke WildFly di Azure Kubernetes Service

  • Artikel

Panduan ini menjelaskan apa yang harus Anda ketahui ketika Anda ingin memigrasikan aplikasi WebSphere yang ada untuk dijalankan di WildFly dalam kontainer Azure Kubernetes Service.

Pra-migrasi

Untuk memastikan keberhasilan migrasi, sebelum memulai, selesaikan langkah-langkah penilaian dan inventaris yang dijelaskan di bagian berikut.

Kapasitas server inventaris

Dokumentasikan perangkat keras (memori, CPU, disk) dari server produksi saat ini dan jumlah permintaan rata-rata dan puncak, serta pemanfaatan sumber daya. Anda akan memerlukan informasi ini terlepas dari jalur migrasi yang Anda pilih. Ini berguna, misalnya, untuk membantu memandu pemilihan ukuran VM di kumpulan simpul Anda, jumlah memori yang akan digunakan oleh kontainer, dan berapa banyak CPU yang berbagi kebutuhan kontainer.

Anda dapat mengubah ukuran kumpulan simpul di AKS. Untuk mempelajari caranya, lihat Mengubah ukuran kumpulan simpul di Azure Kubernetes Service (AKS).

Inventaris semua rahasia

Periksa semua properti dan file konfigurasi di server produksi untuk rahasia dan kata sandi apa pun. Pastikan untuk memeriksa ibm-web-bnd.xml di WAR Anda. File konfigurasi yang berisi kata sandi atau info masuk juga dapat ditemukan di dalam aplikasi Anda.

Inventaris semua sertifikat

Dokumentasikan semua sertifikat yang digunakan untuk titik akhir SSL publik. Anda bisa melihat semua sertifikat di server produksi dengan menjalankan perintah berikut ini:

keytool -list -v -keystore <path to keystore>

Memvalidasi bahwa versi Java yang didukung berfungsi dengan benar

Menggunakan WildFly di Azure Kubernetes Service memerlukan versi Java tertentu, sehingga Anda harus mengonfirmasi bahwa aplikasi Anda berjalan dengan benar menggunakan versi yang didukung tersebut.

Catatan

Validasi ini sangat penting jika server Anda saat ini berjalan pada JDK yang tidak didukung (seperti Oracle JDK atau IBM OpenJ9).

Untuk mendapatkan versi Java Anda saat ini, masuk ke server produksi Anda dan jalankan perintah berikut:

java -version

Lihat Persyaratan untuk panduan mengenai versi apa yang harus digunakan untuk menjalankan WildFly.

Inventaris sumber daya JNDI

Inventarisasikan semua sumber daya JNDI. Beberapa, seperti broker pesan JMS, mungkin memerlukan migrasi atau konfigurasi ulang.

Di dalam aplikasi Anda

Periksa file WEB-INF/ibm-web-bnd.xml dan/atau WEB-INF/web.xml.

Mendokumentasikan sumber data

Jika aplikasi Anda menggunakan database apa pun, Anda perlu mengambil informasi berikut:

  • Apa nama sumber datanya?
  • Apa konfigurasi kumpulan koneksinya?
  • Di mana saya dapat menemukan file JAR driver JDBC?

Untuk informasi selengkapnya, lihat Mengonfigurasi konektivitas database di dokumentasi WebSphere.

Menentukan apakah dan bagaimana sistem berkas digunakan

Setiap penggunaan sistem file pada server aplikasi akan memerlukan konfigurasi ulang atau, dalam kasus yang jarang terjadi, perubahan arsitektur. Sistem file dapat digunakan dengan modul WebSphere atau dengan kode aplikasi Anda. Anda dapat mengidentifikasi beberapa atau semua skenario yang dijelaskan di bagian berikut.

Konten statis baca-saja

Jika aplikasi Anda saat ini menyajikan konten statis, Anda memerlukan lokasi alternatif untuk itu. Anda mungkin ingin mempertimbangkan untuk memindahkan konten statik ke Azure Blob Storage dan menambahkan Azure CDN untuk unduhan secepat kilat secara global. Untuk informasi selengkapnya, lihat Hosting situs web statis di Penyimpanan Azure dan Mulai Cepat: Mengintegrasikan akun Microsoft Azure Storage dengan Azure CDN.

Konten statis yang diterbitkan secara dinamis

Jika aplikasi Anda memungkinkan konten statis yang diunggah/ diproduksi oleh aplikasi Anda tetapi tidak dapat diubah setelah pembuatannya, Anda dapat menggunakan Azure Blob Storage dan Azure CDN seperti yang dijelaskan di atas, dengan Azure Function untuk menangani unggahan dan refresh CDN. Kami telah menyediakan implementasi sampel untuk penggunaan Anda di Pengunggahan dan pramuat CDN konten statis dengan Azure Functions.

Konten dinamis atau internal

Untuk file yang sering ditulis dan dibaca oleh aplikasi Anda (seperti file data sementara), atau file statis yang hanya terlihat oleh aplikasi Anda, Anda dapat memasang Azure Storage bersama sebagai volume persisten. Untuk informasi selengkapnya, lihat Membuat dan menggunakan volume dengan Azure Files di Azure Kubernetes Service (AKS).

Menentukan apakah aplikasi Anda bergantung pada pekerjaan terjadwal atau tidak

Pekerjaan terjadwal, seperti tugas Quartz Scheduler atau pekerjaan Unix cron, TIDAK boleh digunakan dengan Azure Kubernetes Service (AKS). Azure Kubernetes Service tidak akan mencegah Anda menyebarkan aplikasi yang berisi tugas terjadwal secara internal. Namun, apabila skala aplikasi Anda diperluas, pekerjaan terjadwal yang sama dapat berjalan lebih dari satu kali per periode yang dijadwalkan. Situasi ini dapat menyebabkan konsekuensi yang tidak diinginkan.

Untuk menjalankan pekerjaan terjadwal di kluster AKS Anda, tentukan Kubernetes CronJobs sesuai kebutuhan. Untuk informasi selengkapnya, lihat Menjalankan Tugas Otomatis dengan CronJob.

Menentukan apakah koneksi ke lokal diperlukan

Jika aplikasi Anda perlu mengakses salah satu layanan lokal Anda, Anda harus menyediakan salah satu layanan konektivitas Azure. Untuk informasi selengkapnya, lihat Menyambungkan jaringan lokal ke Azure. Atau, Anda harus memfaktor ulang aplikasi untuk menggunakan API yang tersedia untuk umum yang diekspos sumber daya lokal Anda.

Menentukan apakah Antrean atau Topik Java Message Service (JMS) sedang digunakan

Jika aplikasi Anda menggunakan JMS Queues atau Topik, Anda harus memigrasikannya ke server JMS yang dihosting secara eksternal. Azure Service Bus dan Advanced Message Queuing Protocol (AMQP) dapat menjadi strategi migrasi yang bagus bagi mereka yang menggunakan JMS. Untuk informasi selengkapnya, lihat Menggunakan Java Message Service 1.1 dengan Standar Azure Bus Layanan dan AMQP 1.0.

Jika penyimpanan persisten JMS telah dikonfigurasi, Anda harus menangkap konfigurasinya dan menerapkannya setelah migrasi.

Tentukan apakah aplikasi Anda menggunakan API khusus WebSphere

Jika aplikasi Anda menggunakan API khusus WebSphere, Anda harus merefaktor untuk menghapus dependensi tersebut. Misalnya, jika Anda telah menggunakan kelas yang disebutkan di IBM WebSphere Application Server, Spesifikasi API Rilis 9.0, Anda telah menggunakan API khusus WebSphere di aplikasi Anda.

Menentukan apakah aplikasi Anda menggunakan Entity Beans atau EJB 2.x-style CMP Beans

Jika aplikasi Anda menggunakan Entity Beans atau EJB 2.x style CMP beans, Anda harus merefaktor aplikasi untuk menghapus dependensi ini.

Menentukan apakah fitur Java EE Application Client sedang digunakan

Jika Anda memiliki aplikasi klien yang terhubung ke aplikasi (server) Anda menggunakan fitur Java EE Application Client, Anda harus merefaktor aplikasi klien serta aplikasi (server) Anda untuk menggunakan HTTP API.

Tentukan apakah aplikasi Anda berisi kode khusus OS

Jika aplikasi Anda berisi kode apa pun dengan dependensi pada OS host, maka Anda perlu merefaktornya untuk menghapus dependensi tersebut. Misalnya, Anda mungkin perlu mengganti penggunaan / atau \ di jalur sistem file dengan File.Separator atau Paths.get jika aplikasi Anda berjalan di Windows.

Tentukan apakah timer EJB sedang digunakan

Jika aplikasi Anda menggunakan timer EJB, Anda harus memvalidasi bahwa kode timer EJB dapat dipicu oleh setiap instans WildFly secara independen. Validasi ini diperlukan karena, dalam skenario penyebaran Azure Kubernetes Service, setiap timer EJB akan dipicu pada instans WildFly masing-masing.

Menentukan apakah konektor JCA sedang digunakan

Jika aplikasi Anda menggunakan konektor JCA, Anda harus memvalidasi bahwa konektor JCA dapat digunakan di WildFly. Jika implementasi JCA terikat dengan WebSphere, Anda harus merefaktor aplikasi Anda untuk menghapus dependensi tersebut. Jika dapat digunakan, maka Anda harus menambahkan JAR ke classpath server dan menempatkan file konfigurasi yang diperlukan di lokasi yang benar di direktori server WildFly agar tersedia.

Menentukan apakah JAAS sedang digunakan

Jika aplikasi Anda menggunakan JAAS, Anda harus mengetahui bagaimana JAAS tersebut dikonfigurasi. Jika menggunakan database, Anda dapat mengonversinya menjadi domain JAAS di WildFly. Jika aplikasi Anda merupakan implementasi kustom, Anda harus memvalidasi bahwa aplikasi dapat digunakan di WildFly.

Menentukan apakah aplikasi Anda menggunakan Adaptor Sumber Daya

Jika aplikasi Anda memerlukan Resource Adapter (RA), aplikasi tersebut harus kompatibel dengan WildFly. Tentukan apakah RA berfungsi dengan baik pada instans WildFly yang berdiri sendiri dengan menyebarkannya ke server dan mengonfigurasinya dengan benar. Jika RA berfungsi dengan baik, Anda harus menambahkan JAR ke classpath server dari citra Docker dan menempatkan file konfigurasi yang diperlukan di lokasi yang benar pada direktori server WildFly agar tersedia.

Menentukan apakah aplikasi Anda terdiri dari beberapa WAR

Jika aplikasi Anda terdiri dari beberapa WAR, Anda harus memperlakukan masing-masing WAR tersebut sebagai aplikasi terpisah dan melalui panduan ini untuk masing-masing WAR.

Menentukan apakah aplikasi Anda dikemas sebagai EAR

Jika aplikasi Anda dikemas sebagai file EAR, pastikan untuk memeriksa file application.xml dan application-bnd.xml serta merekam konfigurasinya.

Catatan

Jika Anda ingin dapat menskalakan setiap aplikasi web secara independen untuk penggunaan sumber daya Azure Kubernetes Service (AKS) dengan lebih baik, Anda harus memecah EAR menjadi aplikasi web terpisah.

Identifikasi semua proses dan daemon luar yang berjalan di server produksi

Jika Anda memiliki proses yang berjalan di luar server aplikasi, seperti memantau daemon, Anda harus menghilangkannya atau memigrasikannya di tempat lain.

Melakukan pengujian di tempat

Sebelum membuat citra kontainer, migrasikan aplikasi Anda ke versi JDK dan WildFly yang ingin digunakan di AKS. Uji aplikasi secara menyeluruh untuk memastikan kompatibilitas dan performa.

Migration

Memprovisikan Azure Container Registry dan Azure Kubernetes Service

Gunakan perintah berikut untuk membuat registri kontainer dan kluster Azure Kubernetes dengan Perwakilan Layanan yang memiliki peran Pembaca di registri. Pastikan untuk memilih model jaringan yang sesuai untuk persyaratan jaringan kluster Anda.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

Membuat citra Docker untuk WildFly

Untuk membuat Dockerfile, Anda memerlukan prasyarat berikut:

  • JDK yang didukung.
  • Penginstalan WildFly.
  • Opsi runtime JVM Anda.
  • Cara untuk meneruskan variabel lingkungan (jika ada).

Anda kemudian dapat melakukan langkah-langkah yang dijelaskan di bagian berikut, jika berlaku. Anda dapat menggunakan repositori WildFly Container Quickstart sebagai titik awal untuk Dockerfile dan aplikasi web Anda.

Mengonfigurasikan KeyVault FlexVolume

Buat Azure KeyVault dan isi semua rahasia yang diperlukan. Untuk informasi selengkapnya, lihat Mulai Cepat: Mengatur dan mengambil rahasia dari Azure Key Vault menggunakan Azure CLI. Kemudian, konfigurasikan KeyVault FlexVolume untuk membuat rahasia tersebut dapat diakses oleh pod.

Anda juga perlu memperbarui skrip penyalaan yang digunakan untuk WildFly bootstrap. Skrip ini harus mengimpor sertifikat ke penyimpanan kunci yang digunakan oleh WildFly sebelum memulai server.

Menyiapkan sumber data

Untuk mengonfigurasi WildFly guna mengakses sumber data, Anda harus menambahkan JAR driver JDBC ke citra Docker, kemudian menjalankan perintah CLI JBoss yang sesuai. Perintah ini harus menyiapkan sumber data saat membangun citra Docker Anda.

Langkah-langkah berikut memberikan instruksi untuk PostgreSQL, MySQL dan SQL Server.

  1. Unduh driver JDBC untuk PostgreSQL, MySQL, atau SQL Server.

    Bongkar arsip yang diunduh untuk mendapatkan file .jar driver.

  2. Buat file dengan nama seperti module.xml dan tambahkan markup berikut. Ganti tempat penampung <module name> (termasuk kurung siku) dengan org.postgres untuk PostgreSQL, com.mysql untuk MySQL, atau com.microsoft untuk SQL Server. Ganti <JDBC .jar file path> dengan nama file .jar dari langkah sebelumnya, termasuk jalur lengkap ke lokasi tempat Anda akan menempatkan file di citra Docker, misalnya di /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Buat file dengan nama seperti datasource-commands.cli dan tambahkan kode berikut. Ganti <JDBC .jar file path> dengan nilai yang sama dengan yang Anda gunakan di langkah sebelumnya. Ganti <module file path> dengan nama file dan jalur dari langkah sebelumnya, misalnya /opt/database/module.xml.

    Catatan

    Microsoft merekomendasikan penggunaan alur autentikasi paling aman yang tersedia. Alur autentikasi yang dijelaskan dalam prosedur ini, seperti untuk database, cache, olahpesan, atau layanan AI, memerlukan tingkat kepercayaan yang sangat tinggi dalam aplikasi dan membawa risiko yang tidak ada dalam alur lain. Gunakan alur ini hanya ketika opsi yang lebih aman, seperti identitas terkelola untuk koneksi tanpa kata sandi atau tanpa kunci, tidak layak. Untuk operasi komputer lokal, lebih suka identitas pengguna untuk koneksi tanpa kata sandi atau tanpa kunci.

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

  4. Perbarui konfigurasi datasource JTA untuk aplikasi Anda:

    Buka file src/main/resources/META-INF/persistence.xml untuk aplikasi Anda dan temukan elemen <jta-data-source>. Ganti isinya seperti yang ditunjukkan di sini:

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

  5. Tambahkan elemen berikut ini ke Dockerfile sehingga sumber data dibuat saat membangun citra Docker Anda

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Tentukan DATABASE_CONNECTION_URL untuk digunakan karena mereka berbeda untuk setiap server database, dan berbeda dengan nilai di portal Microsoft Azure. Format URL yang ditampilkan di sini diperlukan untuk digunakan oleh WildFly:

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. Saat membuat YAML penyebaran pada tahap selanjutnya, Anda harus meneruskan variabel lingkungan, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME dan DATABASE_SERVER_ADMIN_PASSWORD berikut dengan nilai yang sesuai.

Catatan

Microsoft merekomendasikan penggunaan alur autentikasi paling aman yang tersedia. Alur autentikasi yang dijelaskan dalam prosedur ini, seperti untuk database, cache, olahpesan, atau layanan AI, memerlukan tingkat kepercayaan yang sangat tinggi dalam aplikasi dan membawa risiko yang tidak ada dalam alur lain. Gunakan alur ini hanya ketika opsi yang lebih aman, seperti identitas terkelola untuk koneksi tanpa kata sandi atau tanpa kunci, tidak layak. Untuk operasi komputer lokal, lebih suka identitas pengguna untuk koneksi tanpa kata sandi atau tanpa kunci.

Untuk info selengkapnya mengenai konfigurasi konektivitas database dengan WildFly, lihat PostgreSQL, MySQL, atau SQL Server.

Menyiapkan sumber daya JNDI

Untuk menyiapkan setiap sumber daya JNDI yang perlu Anda konfigurasikan di WildFly, Anda umumnya akan menggunakan langkah-langkah berikut:

  1. Unduh file JAR yang diperlukan dan salin ke dalam citra Docker.
  2. Buat file module.xml WildFly yang mereferensikan file JAR tersebut.
  3. Buat konfigurasi apa pun yang diperlukan oleh sumber daya JNDI tertentu.
  4. Buat skrip JBoss CLI yang akan digunakan selama pembangunan Docker untuk mendaftarkan sumber daya JNDI.
  5. Tambahkan semuanya ke Dockerfile.
  6. Teruskan variabel lingkungan yang sesuai dalam YAML penyebaran Anda.

Contoh di bawah ini menunjukkan langkah-langkah yang diperlukan untuk membuat sumber daya JNDI untuk konektivitas JMS ke Azure Service Bus.

  1. Unduh penyedia JMS Apache Qpid

    Bongkar arsip yang diunduh untuk mendapatkan file .jar.

  2. Buat file dengan nama seperti module.xml dan tambahkan markup berikut di /opt/servicebus. Pastikan nomor versi file JAR selaras dengan nama file JAR dari langkah sebelumnya.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Buat file jndi.properties di /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Buat file dengan nama seperti servicebus-commands.cli dan tambahkan kode berikut.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Tambahkan elemen berikut ini ke Dockerfile Anda, sehingga sumber daya JNDI dibuat saat membangun citra Docker Anda

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. Saat membuat YAML penyebaran pada tahap berikutnya, Anda harus meneruskan variabel lingkungan, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE dan SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC, dan SB_TOPIC berikut dengan nilai yang sesuai.

Meninjau konfigurasi WildFly

Tinjau Panduan Admin WildFly untuk mencakup langkah-langkah pramigrasi tambahan yang tidak tercakup oleh panduan sebelumnya.

Membangun dan mendorong citra Docker ke Azure Container Registry

Setelah membuat Dockerfile, Anda harus membangun gambar Docker dan menerbitkannya ke registri kontainer Azure Anda.

Jika menggunakan Repositori GitHub Mulai Cepat Kontainer WildFly kami, proses membangun dan mendorong citra Anda ke Azure Container Registry akan setara dengan memanggil tiga perintah berikut.

Dalam contoh ini, variabel lingkungan MY_ACR menyimpan nama Azure Container Registry Anda dan variabel MY_APP_NAME menyimpan nama aplikasi web yang ingin digunakan di Azure Container Registry Anda.

Membangun file WAR:

mvn package

Masuk ke registri kontainer Azure Anda:

az acr login --name ${MY_ACR}

Membangun dan mendorong citra:

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

Atau, Anda dapat menggunakan Docker CLI untuk terlebih dulu membangun dan menguji citra secara lokal, seperti yang ditunjukkan dalam perintah berikut. Pendekatan ini dapat menyederhanakan pengujian dan penyempurnaan gambar sebelum penyebaran awal ke ACR. Namun, pendekatan ini mengharuskan Anda untuk menginstal Docker CLI dan memastikan daemon Docker berjalan.

Membangun citra:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Jalankan gambar secara lokal:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Anda sekarang dapat mengakses aplikasi Anda di http://localhost:8080.

Masuk ke registri kontainer Azure Anda:

az acr login --name ${MY_ACR}

Dorong citra tersebut ke Azure Container Registry Anda:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Untuk informasi lebih mendalam mengenai membangun dan menyimpan citra kontainer di Azure, lihat modul Microsoft Learn Membangun dan menyimpan citra kontainer dengan Azure Container Registry.

Memprovisikan alamat IP publik

Jika aplikasi Anda dapat diakses dari luar jaringan internal atau virtual, Anda memerlukan alamat IP statik publik. Anda harus memprovisikan alamat IP ini di dalam grup sumber daya node kluster, seperti yang ditunjukkan pada contoh berikut:

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Menyebarkan ke Azure Kubernetes Service (AKS)

Buat dan terapkan file YAML Kubernetes Anda. Untuk informasi selengkapnya, lihat Mulai Cepat: Menyebarkan kluster Azure Kubernetes Service (AKS) menggunakan Azure CLI. Jika Anda membuat penyeimbang beban eksternal (baik untuk aplikasi Anda atau untuk pengontrol ingress), pastikan untuk memberikan alamat IP yang diprovisikan di bagian sebelumnya sebagai LoadBalancerIP.

Sertakan parameter eksternal sebagai variabel lingkungan. Untuk informasi selengkapnya, lihat Menentukan Variabel Lingkungan untuk Kontainer. Jangan sertakan rahasia (seperti kata sandi, kunci API, dan string koneksi JDBC). Hal ini dibahas dalam bagian berikut.

Pastikan untuk menyertakan pengaturan memori dan CPU saat membuat YAML penyebaran Anda sehingga kontainer Anda memiliki ukuran yang tepat.

Mengonfigurasi penyimpanan persisten

Jika aplikasi Anda memerlukan penyimpanan non-volatile, konfigurasikan satu atau beberapa Volume Persisten.

Memigrasikan pekerjaan terjadwal

Untuk menjalankan pekerjaan terjadwal di kluster AKS Anda, tentukan Kubernetes CronJobs sesuai kebutuhan. Untuk informasi selengkapnya, lihat Menjalankan Tugas Otomatis dengan CronJob.

Pasca-migrasi

Sekarang setelah Anda memigrasikan aplikasi ke Azure Kubernetes Service, Anda harus memveriifkasi bahwa aplikasi tersebut berungsi sesuai harapan. Setelah Anda melakukannya, kami memiliki beberapa rekomendasi untuk Anda yang dapat membuat aplikasi lebih cloud-native.

Rekomendasi