Memigrasikan aplikasi WebLogic Server ke Azure Kubernetes Service

  • Artikel

Panduan ini menjelaskan apa yang harus Anda ketahui saat ingin memigrasikan aplikasi WebLogic Server (WLS) yang ada untuk dijalankan di Azure Kubernetes Service (AKS).

Pra-migrasi

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

Pastikan target adalah target yang sesuai untuk upaya migrasi Anda

Langkah pertama dalam migrasi aplikasi WLS yang berhasil ke Azure adalah memilih target migrasi yang paling tepat. WLS berjalan dengan baik pada komputer virtual (VM) Azure atau Azure Kubernetes Service (AKS). Target VM adalah pilihan term mudah, karena paling mirip dengan penyebaran lokal. Pengalaman administratif dan penyebaran untuk komputer virtual sangat dianalogikan dengan apa yang Anda miliki di tempat. Trade-off untuk kemudahan ini adalah biaya ekonomi. Secara umum, biaya per menit untuk solusi berbasis VM lebih tinggi dibandingkan dengan AKS. Meskipun solusi berbasis AKS lebih murah untuk dijalankan, Anda harus membatasi aplikasi Anda agar sesuai dengan persyaratan AKS. Jika meminimalkan perubahan adalah faktor terpenting untuk upaya migrasi Anda, pertimbangkan migrasi berbasis VM. Dalam hal ini, lihat Memigrasikan aplikasi WebLogic ke Azure Virtual Machines. Jika Anda dapat mentolerir konversi aplikasi agar berjalan dalam Kubernetes untuk mengurangi biaya runtime, pertimbangkan migrasi berbasis AKS. Dalam hal ini, lanjutkan dengan Memigrasikan aplikasi WebLogic Server ke Azure Kubernetes Service.

Tentukan apakah penawaran Marketplace Azure bawaan adalah titik awal yang baik

Setelah memutuskan bahwa AKS adalah target penyebaran yang sesuai, Anda harus menerima bahwa operator Oracle WLS Kubernetes (operator) adalah satu-satunya cara untuk menjalankan WLS di Kubernetes. Setelah menerima fakta ini, Anda harus memutuskan apakah penawaran Marketplace Azure bawaan adalah titik awal yang baik atau tidak. Berikut adalah beberapa hal yang perlu dipertimbangkan tentang penawaran Marketplace Azure bawaan.

  • Oracle dan Microsoft membuat penawaran ini untuk memungkinkan Anda memprovisikan WLS di AKS dengan cepat menggunakan jenis sumber beranda Model di domain Gambar . Konsep ini dijelaskan secara lebih rinci nanti dalam artikel ini.
  • Pada tingkat tinggi, penawaran mengotomatiskan langkah-langkah berikut untuk Anda.
    • Ambil penyebaran WAR atau EAR yang ada, jika diinginkan.
    • Bungkus dalam kontainer menggunakan WebLogic Image Tool (WIT). Untuk informasi selengkapnya, lihat Alat Gambar WebLogic dalam dokumentasi Oracle.
    • Instal dan konfigurasikan Operator Kubernetes WebLogic di AKS.
    • Gunakan operator untuk menjalankan semuanya. Operator memanggil WebLogic Deploy Tooling (WDT) untuk berdiri di lingkungan WebLogic dan melakukan operasi siklus hidup domain dengan cara yang dapat diulang berdasarkan model metadata. Untuk informasi selengkapnya, lihat WebLogic Deploy Tooling di dokumentasi Oracle.
  • Meskipun penawaran bawaan menyediakan banyak integrasi layanan Azure, seperti App Gateway, pengelogan Elastis, integrasi Database, dan banyak lagi, itu membuat banyak asumsi yang menyederhanakan. Asumsi ini membuat penawaran tidak fleksibel seperti menguasai dan menggunakan operator sendiri.

Jika Anda tidak menggunakan penawaran Marketplace Azure bawaan, Anda harus mempelajari cara menggunakan operator secara langsung. Menguasai operator berada di luar cakupan artikel ini. Dokumentasi lengkap untuk Operator Kubernetes WLS tersedia di Oracle.

Sisa bagian ini memberikan beberapa pertimbangan untuk memutuskan untuk menggunakan penawaran Marketplace Azure bawaan atau menggunakan operator secara langsung.

Pertama, Anda harus memahami konsep "domain" WLS. Domain adalah grup sumber daya WLS yang terkait secara logis. Untuk definisi kanonis domain WLS, lihat dokumentasi Oracle. Menjalankan WLS di AKS memerlukan keputusan bagaimana AKS berurusan dengan domain. Berbagai pilihan disebut sebagai "jenis sumber rumah domain". Operator WLS Kubernetes mendukung tiga pilihan jenis sumber rumah domain. Penawaran Marketplace Azure bawaan menggunakan yang pertama dalam tabel ini.

Jenis sumber beranda domain Deskripsi Aspek positif Aspek negatif
Model dalam Gambar WLS dan aplikasi berada dalam gambar kontainer, dan yang lainnya disimpan di luar gambar itu. Didukung oleh penawaran bawaan. Didokumenkan sebagai sampel resmi; lihat Oracle. Paling banyak menggunakan WDT. Sebagian besar opsi "cloud-native". Integrasi CI/CD paling sederhana. Kurva pembelajaran terbesar.
Domain di PV Domain berada pada volume persisten Kubernetes. Secara konseptual mirip dengan berjalan pada VM. Anda dapat menggunakan konsol WLS untuk membuat perubahan dan perubahan tersebut bertahan di seluruh mulai ulang pod AKS. Didokumenkan sebagai sampel resmi; lihat Oracle. Beberapa tantangan yang terkait dengan NFS harus dimitigasi. Untuk informasi selengkapnya, lihat Oracle. Pendekatan ini adalah teknik "cloud-native" paling sedikit; status berada sepenuhnya di luar kluster AKS.
Domain dalam Gambar Domain berada dalam gambar kontainer. Aplikasi terkandung dalam gambar kontainer yang dilapisi pada gambar domain. Lebih banyak "cloud-native" daripada Domain di PV. Lebih mudah untuk CI/CD. Tidak dapat menggunakan konsol WLS. Harus mempertahankan lebih banyak gambar kontainer.

Penting

Jika Anda memilih Domain dalam jenis sumber PV , kami sangat menyarankan NFS alih-alih SMB. NFS berevolusi dari sistem operasi UNIX, dan varian lain seperti GNU/Linux. Untuk alasan ini, saat menggunakan NFS dengan teknologi kontainer seperti Docker, kemungkinan tidak akan memiliki masalah untuk pembacaan bersamaan dan penguncian file.

Pastikan untuk mengaktifkan NFS v4.1. Versi yang lebih rendah dari v4.1 akan bermasalah.

Dokumentasi operator juga mencakup tabel yang berguna yang membandingkan berbagai opsi. Untuk informasi selengkapnya, lihat Memilih jenis sumber beranda domain.

Untuk merasakan penawaran Marketplace Azure bawaan, lihat Mulai Cepat: Menyebarkan WebLogic Server di Azure Kubernetes Service menggunakan portal Azure. Untuk dokumentasi referensi tentang penawaran Marketplace Azure bawaan, lihat Oracle.

Untuk merasakan penggunaan operator secara langsung, coba sampel dalam dokumentasi operator.

Sekarang setelah Anda diperkenalkan ke berbagai cara untuk menangani domain WLS di AKS, Anda lebih dapat memilih apakah akan menggunakan penawaran Marketplace Azure bawaan atau melakukannya sendiri menggunakan operator secara langsung.

Menentukan apakah versi WebLogic kompatibel

Versi WLS Anda yang ada harus menjadi salah satu versi yang didukung oleh operator. Oracle mempertahankan versi ini di Oracle Container Registry (OCR). Gunakan langkah-langkah berikut untuk melihat daftar versi yang didukung.

  1. Kunjungi situs web Oracle Container Registry dan masuk. Untuk informasi selengkapnya, lihat https://container-registry.oracle.com/ .
  2. Jika Anda memiliki pemberian dukungan, pilih Middleware, lalu cari weblogic_cpu. Pilih weblogic_cpu.
  3. Jika Anda tidak memiliki pemberian dukungan dari Oracle, pilih Middleware, lalu cari weblogic. Pilih weblogic.

Catatan

Dapatkan pemberian dukungan dari Oracle sebelum pergi ke produksi. Kegagalan untuk melakukannya mengakibatkan berjalannya gambar yang tidak aman yang tidak di-patch untuk kelemahan keamanan penting. Untuk informasi selengkapnya tentang pembaruan patch penting Oracle, lihat Pembaruan Patch Penting, Pemberitahuan Keamanan, dan Buletin.

Penawaran Marketplace Azure bawaan memungkinkan Anda memilih gambar WLS dari OCR dan Azure Container Registry (ACR), dan dengan demikian secara implisit mendukung semua versi yang tersedia dari OCR. Jika Anda mengarahkan penawaran untuk menarik gambar dari ACR, pastikan itu berasal dari salah satu versi yang didukung yang tercantum di OCR.

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

Sebelum muncul teknologi "konfigurasi sebagai layanan" seperti Azure Key Vault, tidak ada konsep "rahasia" yang terdefinisi dengan baik. Sebaliknya, Anda memiliki serangkaian pengaturan konfigurasi yang berbeda yang secara efektif berfungsi sebagai apa yang sekarang kita sebut "rahasia". Dengan server aplikasi seperti WebLogic Server, rahasia ini ada di banyak file konfigurasi dan penyimpanan konfigurasi yang berbeda. Periksa semua properti dan file konfigurasi di server produksi untuk rahasia dan kata sandi apa pun. Pastikan untuk memeriksa weblogic.xml di WAR Anda. File konfigurasi yang berisi kata sandi atau kredensial juga dapat ditemukan di dalam aplikasi Anda. Untuk informasi selengkapnya, kunjungi konsep dasar Azure Key Vault.

Setelah Anda memiliki inventaris rahasia yang solid, konsultasikan dengan dokumentasi operator mengenai rahasia. Untuk informasi selengkapnya, lihat Rahasia.

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>

Setelah Anda memiliki inventaris sertifikat yang solid, Anda dapat menginstalnya langsung dengan penawaran Marketplace Azure bawaan. Untuk informasi selengkapnya, lihat Konfigurasi TLS/SSL. Jika Anda menggunakan operator secara langsung, lihat Memperbarui sertifikat eksternal operator.

Memvalidasi bahwa versi Java yang didukung berfungsi dengan benar

Semua jalur migrasi untuk WebLogic ke Azure memerlukan versi Java tertentu, yang bervariasi untuk setiap jalur. Anda harus memvalidasi bahwa aplikasi Anda dapat 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

Catatan

Saat bermigrasi ke WLS di komputer virtual Azure, persyaratan untuk versi Java tertentu ditentukan oleh Java yang telah diinstal sebelumnya pada komputer virtual. Saat bermigrasi ke WLS di AKS, versi Java tertentu ditentukan oleh gambar kontainer yang dipilih. Ada berbagai pilihan, tetapi semuanya menggunakan Oracle JDK.

Inventaris sumber daya JNDI

Inventarisasikan semua sumber daya JNDI. Misalnya, sumber data seperti database mungkin memiliki nama JNDI terkait yang memungkinkan JPA untuk mengikat instans dengan benar EntityManager ke database tertentu. Untuk informasi selengkapnya tentang sumber daya dan database JNDI, lihat Sumber Data WebLogic Server di dokumentasi Oracle. Sumber daya terkait JNDI lainnya, seperti perantara pesan JMS, mungkin memerlukan migrasi atau konfigurasi ulang. Untuk informasi selengkapnya tentang konfigurasi JMS, lihat Oracle WebLogic Server 12.2.1.4.0.

Jika Anda menggunakan penawaran Marketplace Azure bawaan, set sumber daya JNDI yang dapat Anda sesuaikan pada waktu penyebaran terbatas pada apa yang didukung penawaran. Cari JNDI dalam dokumentasi penawaran. Jika Anda menggunakan operator secara langsung, sumber daya JDNI dapat ditentukan tergantung pada jenis sumber rumah domain yang Anda pilih. Untuk Domain di PV, Anda dapat mengaturnya dengan cara yang biasa, dengan WLST atau dengan konsol admin. Untuk Domain dalam Gambar atau Model dalam Gambar, lihat Penimpaan umum.

Memeriksa konfigurasi domain Anda

Unit konfigurasi utama di WebLogic Server adalah domain. Dengan demikian, file config.xml berisi banyak konfigurasi yang harus Anda pertimbangkan dengan saksama untuk migrasi. File tersebut mencakup referensi ke file XML tambahan yang disimpan di subdirektori. Oracle menyarankan agar Anda biasanya menggunakan Konsol Administrasi untuk mengonfigurasi objek dan layanan yang dapat dikelola WebLogic Server serta mengizinkan WebLogic Server mempertahankan file config.xml. Untuk informasi selengkapnya, lihat File Konfigurasi Domain.

Di dalam aplikasi Anda

Periksa file WEB-INF/weblogic.xml dan/atau file WEB-INF/web.xml.

Penawaran Marketplace Azure bawaan secara otomatis membuat sumber daya domain. Jika Anda menggunakan operator secara langsung, Anda dapat sepenuhnya menyesuaikan bagaimana domain Anda diwakili. Untuk informasi lengkapnya, lihat Sumber daya domain.

Menentukan apakah replikasi sesi digunakan

Jika aplikasi Anda bergantung pada replikasi sesi, dengan atau tanpa Oracle Coherence*Web, Anda memiliki tiga opsi:

  • Coherence*Web dapat berjalan bersama WebLogic Server di mesin virtual Azure, tetapi Anda harus mengonfigurasi opsi ini secara manual setelah menyediakan penawaran. Jika menggunakan Coherence saja, Anda juga dapat menjalankannya di mesin virtual Azure, tetapi Anda harus mengonfigurasi opsi ini secara manual setelah menyediakan penawaran.
  • Refaktor aplikasi Anda untuk menggunakan database untuk manajemen sesi.
  • Refaktor aplikasi Anda untuk mengeksternalisasi sesi ke Azure Redis Service. Untuk informasi selengkapnya, lihat Azure Cache for Redis.

Untuk semua opsi ini, ada baiknya Anda menguasai bagaimana Weblogic melakukan Replikasi Keadaan Sesi HTTP. Untuk informasi selengkapnya, lihat Replikasi Keadaan Sesi HTTP di dokumentasi Oracle.

Penawaran Marketplace Azure bawaan mendukung afinitas sesi melalui pengontrol ingress Application Gateway. Saat menyebarkan penawaran, pilih Aktifkan afinitas berbasis cookie. Cari afinitas berbasis cookie dalam dokumentasi untuk penawaran.

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 tentang driver JDBC di WebLogic, lihat Menggunakan Driver JDBC dengan WebLogic Server.

Penawaran Marketplace Azure bawaan memiliki dukungan untuk database paling populer. Untuk informasi selengkapnya, lihat Database. Untuk Domain di PV, Anda dapat mengaturnya dengan cara yang biasa, dengan WLST atau dengan konsol admin. Untuk Domain dalam Gambar atau Model dalam Gambar, lihat Penimpaan umum.

Tentukan apakah WebLogic telah dikustomisasikan

Tentukan kustomisasi mana yang telah dibuat, dan tangkap apa yang telah dilakukan.

  • Apakah skrip penyalaan telah diubah? Skrip tersebut mencakup setDomainEnv, commEnv, startWebLogic, dan stopWebLogic.
  • Apakah ada parameter khusus yang diteruskan ke JVM?
  • Apakah ada JAR yang ditambahkan ke classpath server?

Anda perlu mengambil kustomisasi ini dalam gambar kontainer yang dijalankan oleh AKS. Untuk penawaran Marketplace Azure bawaan, penyesuaian tersebut paling baik ditangani dengan membuat gambar kontainer kustom dan membuatnya tersedia di Azure Container Registry, lalu menunjuk ke registri tersebut pada waktu penyebaran. Untuk informasi selengkapnya, lihat Pemilihan gambar. Jika Anda menggunakan operator secara langsung, lihat memori JVM dan variabel lingkungan opsi Java.

Menentukan apakah Manajemen atas REST digunakan

Jika siklus hidup aplikasi Anda meliputi penggunaan Manajemen atas REST, Anda perlu menangkap port mana yang digunakan untuk mengakses REST API dan menentukan bagaimana port diautentikasi dan diekspos. Setelah migrasi, Anda harus memastikan bahwa port dan mekanisme autentikasi yang sama ini terekspos sehingga siklus hidup aplikasi Anda dapat beroperasi dengan cara yang sama seperti sebelum migrasi. Untuk informasi selengkapnya, lihat Mengelola Oracle WebLogic Server dengan RESTful Management Services.

Satu-satunya jenis sumber rumah domain di mana masuk akal untuk terus menggunakan manajemen melalui REST adalah Domain di PV. Dimungkinkan untuk menggunakannya dengan jenis sumber beranda domain lainnya, tetapi perubahan yang dilakukan bersifat ephemeral dan tidak bertahan di seluruh restart pod.

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 Memilih solusi untuk 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 Antrean atau Topik JMS, Anda harus memigrasikannya ke server JMS yang dihosting secara eksternal. Azure Service Bus dan Advanced Message Queuing Protocol dapat menjadi strategi migrasi yang baik bagi mereka yang menggunakan JMS. Untuk informasi selengkapnya, lihat Menggunakan JMS dengan Azure Service Bus dan AMQP 1.0.

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

Jika menggunakan Oracle Message Broker, Anda dapat memigrasikan perangkat lunak ini ke mesin virtual Azure dan menggunakannya apa adanya.

Tentukan Apakah Anda menggunakan Pustaka Java EE Bersama yang Anda buat sendiri

Jika menggunakan fitur pustaka Java EE Bersama, Anda memiliki dua opsi:

  • Refaktor kode aplikasi Anda untuk menghapus semua dependensi di pustaka Anda, dan sebagai gantinya gabungkan fungsionalitas langsung ke dalam aplikasi Anda.
  • Tambahkan pustaka tersebut ke classpath server.

Pustaka ini dapat ditangani menggunakan teknik yang sama seperti yang dijelaskan dalam Menentukan apakah WebLogic telah disesuaikan.

Tentukan apakah bundel OSGi digunakan

Jika menggunakan bundel OSGi yang ditambahkan ke server WebLogic, Anda harus menambahkan file JAR yang setara langsung ke aplikasi web Anda.

Anda dapat menyertakannya dalam WAR atau EAR yang disediakan ke penawaran Marketplace Azure bawaan atau menggunakan operator secara langsung.

Tentukan apakah aplikasi Anda berisi kode khusus OS

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

WLS pada AKS berjalan di Oracle Linux. Kode khusus OS apa pun harus kompatibel dengan Oracle Linux. Untuk mempelajari cara menemukan informasi OS tertentu, ikuti langkah-langkah dalam Menentukan apakah versi WebLogic kompatibel.

Menentukan apakah Oracle Service Bus sedang digunakan

Jika aplikasi Anda menggunakan Oracle Service Bus (OSB), Anda harus menangkap cara OSB dikonfigurasi. Untuk informasi selengkapnya, lihat Tentang Penginstalan Oracle Service Bus.

OSB tidak didukung secara langsung dalam penawaran Marketplace Azure bawaan. Jika Anda harus menggunakan OSB, Anda harus menggunakan operator secara langsung.

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 weblogic-application.xml serta menangkap konfigurasinya.

Penawaran Marketplace Azure bawaan mendukung WAR dan EAR. Menggunakan operator secara langsung juga mendukung WAR dan EAR.

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.

Menentukan apakah WebLogic Scripting Tool (WLST) digunakan

Jika saat ini Anda menggunakan WLST untuk melakukan penyebaran, Anda perlu menilai apa yang dilakukannya. Jika WLST mengubah parameter (runtime) aplikasi Anda sebagai bagian dari penyebaran, Anda harus memastikan bahwa perilaku ini terus berfungsi saat menguji aplikasi Anda setelah migrasi.

Satu-satunya jenis sumber beranda domain yang kompatibel dengan penggunaan WLST adalah Domain di PV. Untuk informasi selengkapnya, lihat Beranda domain di PV.

Menentukan apakah dan bagaimana sistem berkas digunakan

Kubernetes menangani sistem file dengan volume persisten (PV). Memasang volume persisten didukung dalam penawaran Marketplace Azure bawaan, dan saat menggunakan operator secara langsung. Jika Anda menggunakan Domain di PV, sistem file adalah aspek konfigurasi terpusat.

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. Anda juga dapat langsung menyebarkan konten statis ke aplikasi dalam paket Azure Spring Apps Enterprise. Untuk informasi selengkapnya, lihat Menyebarkan file statis web.

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. Anda juga dapat langsung menyebarkan konten statis ke aplikasi dalam paket Azure Spring Apps Enterprise. Untuk informasi selengkapnya, lihat Menyebarkan file statis web.

Menentukan topologi jaringan

Kumpulan penawaran Marketplace Azure saat ini adalah titik awal untuk migrasi Anda. Jika penawaran tidak mencakup aspek arsitektur yang perlu dimigrasi, Anda harus menangkap topologi jaringan dari penyebaran yang ada dan memproduksinya ulang di Azure, bahkan setelah menyiapkan penawaran dasar dengan salah satu templat solusi.

Ini adalah topik yang sangat luas, tetapi referensi berikut dapat memberikan beberapa arahan untuk upaya migrasi Anda:

Akun untuk penggunaan Adaptor JCA dan Adaptor Sumber Daya

Jika penyebaran Anda bergantung pada adaptor sumber daya, opsi yang paling didukung adalah Beranda domain pada PV.

Akun untuk penggunaan penyedia keamanan kustom dan JAAS

Jika aplikasi Anda menggunakan JAAS, Anda perlu memastikan konfigurasi penyedia keamanan dimigrasikan dengan benar. Untuk informasi selengkapnya, lihat Tentang Mengonfigurasi Penyedia Keamanan WebLogic di dokumentasi Oracle.

Jika penyebaran Anda bergantung pada penyedia keamanan, opsi yang paling didukung adalah Beranda domain pada PV.

Menentukan apakah pengklusteran WebLogic digunakan

Operator menangani pengklusteran untuk semua kemungkinan cara menjalankan WLS di AKS.

Memeriksa pengklusteran EJB Anda

Jika aplikasi Anda menggunakan EJB lokal, Anda perlu memigrasikannya ke EJB terkluster. Untuk informasi selengkapnya, lihat Kluster versus EJB lokal.

Akun untuk persyaratan penyeimbangan beban

Cara terbaik untuk memperhitungkan penyeimbangan beban adalah dengan menggunakan integrasi App Gateway yang disediakan oleh penawaran Marketplace Azure bawaan. Untuk informasi selengkapnya, lihat Tutorial: Memigrasikan kluster WebLogic Server ke Azure dengan Azure Application Gateway sebagai load balancer.

Tentukan apakah fitur Klien Aplikasi Java EE digunakan

Jika penyebaran Anda bergantung pada klien aplikasi Java EE, sebaiknya gunakan operator secara langsung. Untuk informasi selengkapnya, lihat Klien Eksternal.

Menentukan apakah beberapa gambar kontainer diperlukan

Domain WebLogic Server dapat berisi beberapa kluster. Misalnya, aplikasi multi-tingkat dapat diwakili dalam satu domain, tetapi memiliki dua kluster, misalnya "frontend" dan "backend". Ini berguna untuk dapat memperbarui frontend, tanpa memperbarui backend, dan sebaliknya. Namun, dengan model di jenis sumber beranda domain Gambar , seluruh domain diwakili dalam satu gambar kontainer. Untuk mengakomodasi kasus penggunaan ini, Anda harus memisahkan kluster ke domain mereka sendiri, masing-masing dengan gambar kontainer mereka sendiri. Operator dapat mengelola beberapa domain di beberapa namespace layanan. Untuk informasi selengkapnya, lihat Memilih strategi pemilihan namespace domain

Mengadopsi beberapa domain dapat menyebabkan masalah akses T3 antar domain. Untuk mengatasi masalah ini, aktifkan saluran kustom seperti yang dijelaskan dalam Menentukan apakah mengaktifkan akses host yang tidak diketahui diperlukan.

Menentukan apakah mengaktifkan akses host yang tidak diketahui diperlukan

Anda mungkin perlu mengaktifkan akses host yang tidak diketahui dengan menerapkan patch ke WebLogic untuk skenario berikut:

  • Izinkan akses T3 dari klien eksternal di luar AKS ke kluster WLS di AKS melalui saluran kustom.
  • Izinkan akses T3 antara domain WLS yang berbeda di AKS melalui saluran kustom.

Untuk detail patch, ikuti panduan dalam Cara Menggunakan Pencarian Patch di Dukungan Oracle Saya (MOS) dan cari patch 30656708.

Setelah patch diterapkan, lihat Mengaktifkan akses host yang tidak diketahui.

Migration

Langkah-langkah di bagian ini mengasumsikan bahwa analisis Anda telah mengarahkan Anda untuk memutuskan untuk menggunakan penawaran Marketplace Azure bawaan.

Menyediakan penawaran

Untuk membuka penawaran di portal Azure, lihat https://aka.ms/wlsaks. Pilih Buat, lalu ikuti instruksi dalam dokumentasi untuk penawaran. Gunakan informasi yang Anda kumpulkan dalam langkah-langkah sebelumnya untuk membantu mengisi bidang penawaran.

Memigrasikan domain

Setelah Anda menyediakan penawaran, keluarkan domain dengan mengikuti langkah-langkah ini.

Jika Anda menavigasi jauh dari halaman Penyebaran sedang berlangsung , langkah-langkah berikut menunjukkan kepada Anda cara kembali ke halaman tersebut. Jika Anda masih berada di halaman yang memperlihatkan Penyebaran Anda selesai, Anda dapat melompat ke langkah 5.

  1. Di bagian kiri atas halaman portal mana pun, pilih menu hamburger dan pilih Grup sumber daya.

  2. Dalam kotak dengan teks Filter untuk bidang apa pun, masukkan beberapa karakter pertama grup sumber daya yang Anda buat sebelumnya. Apabila Anda mengikuti konvensi yang direkomendasikan, masukkan inisial Anda, kemudian pilih grup sumber daya yang sesuai.

  3. Di panel navigasi kiri, di bagian Pengaturan, pilih Penyebaran untuk melihat daftar penyebaran yang diurutkan ke grup sumber daya ini, dengan yang terbaru terlebih dahulu.

  4. Gulir ke entri terlama dalam daftar ini. Entri ini sesuai dengan penyebaran yang Anda mulai di bagian sebelumnya. Pilih penyebaran terlama, seperti yang ditunjukkan pada cuplikan layar berikut.

    Screenshot of Azure portal showing the resource group deployments list.

  5. Di panel kiri, pilih Output. Daftar ini memperlihatkan nilai output dari penyebaran. Informasi yang berguna disertakan dalam output. Kami tertarik dengan output yang memungkinkan kami memeriksa domain dan berinteraksi dengan operator. Nilai lain dalam output dijelaskan secara rinci dalam panduan pengguna WebLogic di AKS.

  6. Temukan output bernama shellCmdtoConnectAks. Tempelkan nilai output dalam shell Bash dan jalankan perintah . Perintah ini memungkinkan Anda untuk menggunakan kubectl seperti yang dijelaskan dalam Koneksi ke kluster.

  7. Temukan output bernama shellCmdtoOutputWlsDomainYaml. Tempelkan nilai output dalam shell Bash dan jalankan perintah . Perintah ini menghasilkan sumber daya domain sebagai file YAML.

  8. Sekarang setelah Anda memiliki YAML domain dari penyebaran saat ini, Anda dapat menerapkan pengetahuan dalam Menyebarkan file YAML sumber daya domain dan meninjau panduan ini untuk petunjuk lebih lanjut tentang cara memigrasikan domain. Panduan ini memerlukan adaptasi untuk diterapkan pada cara Kubernetes melakukan sesuatu, tetapi masih berguna untuk diketahui.

Akun untuk KeyStores

Anda harus memperhitungkan migrasi setiap KeyStores SSL yang digunakan oleh aplikasi Anda. Untuk informasi selengkapnya, lihat Mengonfigurasi Keystores.

Menyambungkan sumber JMS

Setelah menyambungkan database, anda dapat mengonfigurasi JMS dengan mengikuti instruksi di Pengelolaan Sumber Daya JMS Fusion Middleware untuk Oracle WebLogic Server dalam dokumentasi WebLogic.

Akun untuk pengelogan

Anda tidak dapat melakukan cloud tanpa menguasai pengelogan. Operator menyediakan sampel untuk menggunakan Elasticsearch dan Kibana. Untuk informasi selengkapnya, lihat dokumentasi operator. Azure memberikan dukungan besar untuk Elastic. Untuk detail selengkapnya, lihat Apa itu integrasi Elastic dengan Azure?. Anda dapat menggabungkan pengetahuan dalam kedua sumber daya ini untuk mencapai solusi pengelogan yang dioptimalkan Azure untuk WLS di AKS.

Memigrasikan aplikasi Anda

Apakah Anda memilih untuk menyediakan file WAR atau EAR pada waktu penyebaran, Anda perlu memperbarui aplikasi melalui CI/CD. Dokumentasi operator memiliki sampel yang menunjukkan cara melakukan pembaruan ini. Untuk informasi selengkapnya, lihat Pembaruan 3. Sampel pembaruan lainnya relevan dengan migrasi dan layak dijelajahi.

Pengujian

Setiap pengujian dalam kontainer terhadap aplikasi harus dikonfigurasi untuk mengakses server baru yang berjalan dalam Azure. Seperti halnya masalah CI /CD, Anda harus memastikan aturan keamanan jaringan yang diperlukan memungkinkan pengujian Anda mengakses aplikasi yang disebarkan ke Azure. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Pasca-migrasi

Setelah mencapai sasaran migrasi yang ditentukan dalam langkah pramigrasi, lakukan beberapa pengujian penerimaan end-to-end untuk memverifikasi bahwa semuanya berfungsi seperti yang diharapkan. Untuk panduan tentang beberapa potensi peningkatan pascamigrasi, lihat rekomendasi berikut: