Memigrasikan aplikasi WebSphere ke WildFly di Azure Kubernetes Service

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.

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

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).

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.

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>

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.

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.

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

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

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.

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.

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.

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.

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).

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

   • PostgreSQL
   • MySQL
   • SQL Server

   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:

   • PostgreSQL
   • MySQL
   • SQL Server

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

   • PostgreSQL
   • MySQL
   • SQL Server

   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.

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

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.

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

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.

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}."

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.

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

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

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.

• Pertimbangkan untuk menambahkan nama DNS ke alamat IP yang dialokasikan ke pengontrol ingress atau penyeimbang beban aplikasi Anda. Untuk informasi selengkapnya, lihat Menggunakan TLS dengan pengontrol ingress di Azure Kubernetes Service (AKS).

• Pertimbangkan untuk menambahkan bagan HELM untuk aplikasi Anda. Bagan helm memungkinkan Anda untuk membuat parameter penyebaran aplikasi untuk digunakan dan disesuaikan oleh serangkaian pelanggan yang lebih beragam.

• Merancang dan menerapkan strategi DevOps. Untuk menjaga keandalan sekaligus meningkatkan kecepatan pengembangan Anda, pertimbangkan untuk mengotomatiskan penyebaran dan pengujian dengan Azure Pipelines. Untuk informasi selengkapnya, lihat Membangun dan menyebarkan ke Azure Kubernetes Service dengan Azure Pipelines.

• Aktifkan Azure Monitor untuk kluster. Untuk informasi selengkapnya, lihat Mengaktifkan pemantauan untuk kluster Kubernetes. Hal ini memungkinkan Azure monitor untuk mengumpulkan log kontainer, melacak pemanfaatan, dan sebagainya.

• Pertimbangkan untuk mengekspos metrik khusus aplikasi melalui Prometheus. Prometheus adalah kerangka kerja metrik sumber terbuka yang diadopsi secara luas di komunitas Kubernetes. Anda dapat mengonfigurasi pengikisan Metrik Prometheus di Azure Monitor alih-alih menghosting server Prometheus Anda sendiri untuk mengaktifkan agregasi metrik dari aplikasi Anda dan respons otomatis atau eskalasi kondisi yang menyimpang. Untuk informasi selengkapnya, lihat Mengaktifkan Prometheus dan Grafana.

• Merancang dan menerapkan strategi kelangsungan bisnis dan pemulihan bencana. Untuk aplikasi yang sangat penting, pertimbangkan arsitektur penyebaran multi-wilayah. Untuk informasi selengkapnya, lihat Ringkasan ketersediaan tinggi dan pemulihan bencana untuk Azure Kubernetes Service (AKS).

• Tinjau kebijakan dukungan versi Kubernetes. Anda bertanggung jawab untuk terus memperbarui kluster AKS guna memastikan bahwa kluster AKS selalu menjalankan versi yang didukung. Untuk informasi selengkapnya, lihat Opsi peningkatan untuk kluster Azure Kubernetes Service (AKS).

• Mintalah semua anggota tim yang bertanggung jawab atas administrasi kluster dan pengembangan aplikasi meninjau praktik terbaik AKS yang relevan. Untuk informasi selengkapnya, lihat Praktik terbaik operator kluster dan pengembang untuk membangun dan mengelola aplikasi di Azure Kubernetes Service (AKS).

• Pastikan file penyebaran Anda menentukan bagaimana pembaruan bergulir dilakukan. Untuk informasi selengkapnya, lihat Penyebaran Pembaruan Bergulir di dokumentasi Kubernetes.

• Siapkan penskalaan otomatis untuk menangani beban waktu puncak. Untuk informasi selengkapnya, lihat Menggunakan autoscaler kluster di Azure Kubernetes Service (AKS).

• Pertimbangkan untuk memantau ukuran cache kode dan menambahkan parameter JVM -XX:InitialCodeCacheSize dan -XX:ReservedCodeCacheSize di Dockerfile untuk mengoptimalkan performa lebih jauh. Untuk informasi selengkapnya, lihat Penyetelan Codecache dalam dokumentasi Oracle.