WebLogic Server uygulamalarını Azure Kubernetes Service'te WildFly'ye geçirme

Makale
05/30/2023

Bu kılavuzda, mevcut bir WebLogic Server uygulamasını Azure Kubernetes Service kapsayıcısında WildFly üzerinde çalışacak şekilde geçirmek istediğinizde bilmeniz gerekenler açıklanmaktadır.

Geçiş öncesi

Geçişin başarılı olduğundan emin olmak için, başlamadan önce aşağıdaki bölümlerde açıklanan değerlendirme ve envanter adımlarını tamamlayın.

Geçiş öncesi gereksinimleri karşılayamazsanız yardımcı geçiş kılavuzuna bakın:

WebLogic Server uygulamalarını Azure Sanal Makineler'a geçirme

Envanter sunucusu kapasitesi

Geçerli üretim sunucularının donanımını (bellek, CPU, disk) ve ortalama ve en yüksek istek sayısını ve kaynak kullanımını belgeleyin. Seçtiğiniz geçiş yolundan bağımsız olarak bu bilgilere ihtiyaç duyacaksınız. Örneğin düğüm havuzunuzdaki VM'lerin boyutunu, kapsayıcı tarafından kullanılacak bellek miktarını ve kapsayıcının ihtiyaç duyduğu CPU paylaşımını seçmeye yardımcı olmak için yararlıdır.

AKS'de düğüm havuzlarını yeniden boyutlandırmak mümkündür. Nasıl yapılacağını öğrenmek için bkz . Azure Kubernetes Service'te (AKS) düğüm havuzlarını yeniden boyutlandırma.

Tüm gizli dizilerin envanterini çıkarma

"Hizmet olarak yapılandırma" teknolojilerindeki Azure Key Vault gibi gelişmelerden önce bile iyi tanımlanmış bir "gizli dizi" kavramı yoktu. Bunun yerine şimdi aslında “gizli dizi” olarak adlandırabileceğimiz bir işlev üstlenen ayrı bir yapılandırma ayarları kümeniz vardı. WebLogic Server gibi uygulama sunucularıyla, bu gizli diziler birçok farklı yapılandırma dosyasında ve yapılandırma deposunda yer alır. Üretim sunucularındaki tüm özellikleri ve yapılandırma dosyalarını gizli diziler ve parolalar için denetleyin. WAR dosyalarında weblogic.xml’yi denetlediğinizden emin olun. Ayrıca uygulamanızın içinde parolalar ve kimlik bilgileri içeren yapılandırma dosyaları da bulunabilir. Daha fazla bilgi için bkz. Temel Azure Key Vault kavramları.

Tüm sertifikaların envanterini çıkarma

Genel SSL uç noktaları için kullanılan tüm sertifikaları belgeleyin. Aşağıdaki komutu çalıştırarak üretim sunucularındaki tüm sertifikaları görüntüleyebilirsiniz:

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

JNDI kaynaklarının envanterini çıkarma

Tüm JNDI kaynaklarının envanterini çıkarın. Örneğin, veritabanları gibi veri kaynaklarıyla ilişkilendirilmiş bir JNDI adı vardır ve bu ad JPA’nın EntityManager örneklerini belirli bir veritabanına doğru bağlamasına olanak tanır. JNDI kaynakları ve veritabanları hakkında daha fazla bilgi için Oracle belgelerinde WebLogic Server Veri Kaynakları’na bakın. JNDI ile ilgili diğer kaynaklar, örneğin JMS ileti aracıları geçiş veya yeniden yapılandırma gerektirebilir. JMS yapılandırması hakkında daha fazla bilgi için bkz . Oracle WebLogic Server 12.2.1.4.0.

Oturum çoğaltmanın kullanılıp kullanılmadığını belirleme

Uygulamanız Oracle Coherence*Web içeren veya içermeyen oturum çoğaltmaya dayanıyorsa iki seçeneğiniz vardır:

Oturum yönetiminde bir veritabanı kullanmak için uygulamanızı yeniden düzenleyin.
Oturumu Azure Redis Hizmeti’ne dışsallaştırmak için uygulamanızı yeniden düzenleyin. Daha fazla bilgi için bkz. Redis için Azure Cache.

Belge veri kaynakları

Uygulamanızda herhangi bir veritabanı kullanılıyorsa aşağıdaki bilgileri yakalamanız gerekir:

Veri kaynağının adı nedir?
Bağlantı havuzu yapılandırması nedir?
JDBC sürücüsü JAR dosyasını nerede bulabilirim?

WebLogic’teki JDBC sürücüleri hakkında daha fazla bilgi için bkz. WebLogic Sunucusuyla JDBC Sürücülerini Kullanma.

WebLogic’in özelleştirilip özelleştirilmediğini saptama

Aşağıdaki özelleştirmelerden hangilerinin yapıldığını saptayın ve yapılmış olanları yakalayın.

Başlatma dizeleri değiştirildi mi? Bu tür dizeler setDomainEnv, commEnv, startWebLogic ve stopWebLogic içerir.
JVM’ye geçirilmiş belirli parametreler var mı?
Sunucu sınıf yoluna eklenmiş JAR’lar var mı?

Şirket içine bağlantının gerekip gerekmediğini saptama

Uygulamanızın şirket içi hizmetlerinizden birine erişmesi gerekiyorsa Azure’ın bağlantı hizmetlerinden birini sağlamalısınız. Daha fazla bilgi için bkz. Şirket içi ağını Azure'a bağlamak için bir çözüm seçme. Alternatif olarak şirket içi kaynaklarınızın kullanıma sunduğu genel kullanıma açık API’leri kullanmak için uygulamanızı yeniden düzenlemeniz gerekir.

Java Message Service (JMS) Kuyruklarının mı yoksa Konularının mı kullanıldığını saptama

Uygulamanız JMS Kuyruklarını veya Konularını kullanıyorsa, bunları dışarıda barındırılan bir JMS sunucusuna geçirmeniz gerekir. Azure Service Bus ve Gelişmiş İleti Sıraya Alma Protokolü (AMQP), JMS kullananlar için harika bir geçiş stratejisi olabilir. Daha fazla bilgi için bkz. Azure Service Bus ve AMQP 1.0 ile JMS’yi kullanma.

JMS kalıcı depoları yapılandırıldıysa, bunların yapılandırmasını yakalamalı ve geçiş sonrasında uygulamalısınız.

Özel oluşturulmuş kendi Paylaşılan Java EE Kitaplıklarınızı kullanıp kullanmadığınızı saptama

Paylaşılan Java EE kitaplığı özelliğini kullanıyorsanız iki seçeneğiniz vardır:

Kitaplıklarınızdaki tüm bağımlılıkları kaldırmak için uygulama kodunuzu yeniden düzenleyin ve bunun yerine işlevselliği doğrudan uygulamanızla birleştirin.
Kitaplıkları sunucu sınıf yoluna ekleyin.

OSGi paketlerinin kullanılıp kullanılmadığını saptama

WebLogic sunucusuna eklenmiş OSGi paketlerini kullandıysanız, eşdeğer JAR dosyalarını doğrudan web uygulamanıza eklemeniz gerekir.

Uygulamanızın işletim sistemine özgü kod içerip içermediğini saptama

Uygulamanız konak işletim sisteminde bağımlılıkları olan kod içeriyorsa, bunu yeniden düzenleyip söz konusu bağımlılıkları kaldırmanız gerekir. Örneğin dosya sistemi yollarındaki / veya \ kullanımlarını File.Separator veya Paths.get ile değiştirmeniz gerekebilir.

Oracle Service Bus’ın kullanımda olup olmadığını saptama

Uygulamanız Oracle Service Bus (OSB) kullanıyorsa OSB’nin nasıl yapılandırıldığını yakalamanız gerekir. Daha fazla bilgi için bkz. Oracle Service Bus Yüklemesi Hakkında.

Uygulamanızın birden çok WAR’dan oluşup oluşmadığını saptama

Uygulamanız birden çok WAR’dan oluşuyorsa, bu WAR dosyalarından her birini ayrı uygulama olarak değerlendirmeli ve her biri için bu kılavuzu izlemelisiniz.

Uygulamanızın EAR olarak paketlenip paketlenmediğini saptama

Uygulamanız EAR dosyası olarak paketlendiyse, application.xml ve weblogic-application.xml dosyalarını incelediğinizden ve yapılandırmalarını yakaladığınızdan emin olun.

Dekont

Azure Kubernetes Service kaynaklarınızı daha iyi kullanmak için web uygulamalarınızın her birini bağımsız olarak ölçeklendirebilmek istiyorsanız EAR'yi ayrı web uygulamalarına ayırmanız gerekir.

Üretim sunucularında çalıştırılan tüm dış işlemleri ve daemon’ları belirleme

Uygulama sunucusunun dışında çalıştırılan izleme deamon’ları gibi işlemleriniz varsa, bunları ortadan kaldırmanız veya başka bir yere geçirmeniz gerekir.

Desteklenen Java sürümünün doğru çalıştığını onaylama

Azure Kubernetes Service'te WildFly kullanmak için java'nın belirli bir sürümü gerekir, bu nedenle uygulamanızın desteklenen sürümü kullanarak doğru şekilde çalıştığını onaylamanız gerekir.

Dekont

Geçerli sunucunuz desteklenmeyen bir JDK (Oracle JDK veya IBM OpenJ9 gibi) çalıştırıyorsa bu doğrulama özellikle önemlidir.

Geçerli Java sürümünüzü öğrenmek için üretim sunucunuzda oturum açın ve şu komutu çalıştırın:

java -version

WildFly’ı çalıştırmak için kullanmanız gereken sürüm hakkında bilgi almak için Gereksinimler’e bakın.

Uygulamanızın zamanlanan işlere dayanıp dayanmadığını belirleme

Quartz Scheduler görevleri veya Unix cron işleri gibi zamanlanmış işler Azure Kubernetes Service (AKS) ile KULLANıLMAMALIDIR. Azure Kubernetes Service zamanlanan görevler içeren bir uygulamayı dahili olarak dağıtmanızı engellemez. Bununla birlikte uygulamanızın ölçeği genişletildiyse, aynı zamanlanan iş zamanlama dönemi başına birden çok kez çalıştırılabilir. Bu durum istenmeyen sonuçlar doğurabilir.

Zamanlanan işleri AKS kümenizde yürütmek için gerektiği gibi Kubernetes CronJobs tanımlayın. Daha fazla bilgi edinmek için bkz. Bir CronJob ile Otomatikleştirilmiş Görev Çalıştırma.

WebLogic Betik Aracı'nın kullanılıp kullanılmadığını belirleme

Dağıtımı gerçekleştirmek için şu anda WebLogic Betik Aracı'nı (WLST) kullanıyorsanız, ne yaptığını değerlendirmeniz gerekir. WLST dağıtım kapsamında uygulamanızın herhangi bir (çalışma zamanı) parametresini değiştiriyorsa, bu parametrelerin aşağıdaki seçeneklerden birine uydığından emin olun:

Parametreler, uygulama ayarları olarak dışlaştırılır.
Parametreler uygulamanıza eklenir.
Parametreler dağıtım sırasında JBoss CLI'yi kullanıyor.

WLST yukarıda bahsedilenden daha fazlasını yapıyorsa, geçiş sırasında yapmanız gereken bazı ek işler olacaktır.

Uygulamanızın WebLogic’e özgü API’leri kullanıp kullanmadığını belirleme

Uygulamanız WebLogic’e özgü API’leri kullanıyorsa bu bağımlılıkları kaldırmak için uygulamanızı yeniden düzenlemeniz gerekir. Örneğin Oracle WebLogic Server için Java API Başvurusu’nda bahsedilen bir sınıfı kullandıysanız, uygulamanızda WebLogic’e özgü bir API kullanmışsınızdır. Başvuruyu kaldırmak için yeniden düzenlemeniz gerekir.

Uygulamanızın Entity Beans mi yoksa EJB 2.x tarzı CMP Beans mi kullanacağına karar verme

Uygulamanız Beans veya EJB 2. x tarzı CMP Beans kullanıyorsa, bu bağımlılıkları kaldırmak için uygulamanızı yeniden düzenlemeniz gerekir.

Java EE Uygulama İstemcisi özelliğinin kullanılıp kullanılmadığını belirleme

Java EE Uygulama İstemcisi özelliğini kullanarak (sunucu) uygulamanıza bağlanan Java EE Uygulama İstemciniz varsa, hem istemci uygulamalarınızı hem de (sunucu) uygulamalarınızı HTTP API’lerini kullanacak şekilde yeniden düzenlemeniz gerekir.

Bir dağıtım planının kullanılıp kullanılmadığını belirleme

Uygulamanız bir dağıtım planı kullanılarak dağıtıldıysa, dağıtım planının ne yaptığını değerlendirin. Dağıtım planınız düz bir dağıtımsa web uygulamanızı herhangi bir değişiklik yapmadan dağıtabilirsiniz. Dağıtım planı daha ayrıntılıysa JBoss CLI kullanarak uygulamanızı dağıtımın bir parçası olarak düzgün yapılandırıp yapılandıramayacağınızı belirleyin. JBoss CLI'yi kullanmak mümkün değilse uygulamanızı bir dağıtım planına gerek kalmayacak şekilde yeniden düzenlemeniz gerekir.

EJB zamanlayıcılarının kullanımda olup olmadığını belirleme

Uygulamanız EJB zamanlayıcılarını kullanıyorsa, EJB zamanlayıcı kodunun her WildFly örneğinden bağımsız olarak tetiklenebildiğini doğrulamanız gerekir. Azure Kubernetes Service dağıtım senaryosunda her EJB zamanlayıcısı kendi WildFly örneğinde tetikleneceği için bu doğrulama gereklidir.

Dosya sisteminin kullanılıp kullanılmayacağını ve nasıl kullanıldığını belirleme

Uygulama sunucusundaki dosya sisteminin herhangi bir kullanımı için yeniden yapılandırma veya nadir durumlarda mimari değişiklikler gerekir. Dosya sistemi WebLogic paylaşılan modülleri veya uygulama kodunuz tarafından kullanılabilir. Aşağıdaki bölümlerde açıklanan senaryoların bazılarını veya tümünü tanımlayabilirsiniz.

Salt okunur statik içerik

Uygulamanız şu anda statik içerik sunuyorsa bunun için alternatif bir konumunuz olması gerekir. Statik içeriği Azure Blob Depolama’ya taşımayı ve küresel olarak ışık hızında indirme işlemleri için Azure CDN eklemeyi düşünebilirsiniz. Daha fazla bilgi için bkz. Azure Depolama'de statik web sitesi barındırma ve Hızlı Başlangıç: Azure depolama hesabını Azure CDN ile tümleştirme. Statik içeriği Azure Spring Apps Enterprise planındaki bir uygulamaya doğrudan da dağıtabilirsiniz. Daha fazla bilgi için bkz . Web statik dosyalarını dağıtma.

Dinamik olarak yayımlanan statik içerik

Uygulamanız tarafından karşıya yüklenen/üretilen ama oluşturulduktan sonra sabit hale gelen statik içeriğe uygulamanızda izin veriliyorsa, karşıya yüklemeleri ve CDN yenilemesini işlemek için Azure İşlevi’yle birlikte yukarıda açıklandığı gibi Azure Blob Depolama ve Azure CDN kullanabilirsiniz. Azure İşlevleri ile statik içeriği karşıya yükleme ve CDN’ye önceden yükleme başlığı altında kullanımınıza ilişkin örnek bir uygulama sağladık. Statik içeriği Azure Spring Apps Enterprise planındaki bir uygulamaya doğrudan da dağıtabilirsiniz. Daha fazla bilgi için bkz . Web statik dosyalarını dağıtma.

Dinamik veya dahili içerik

Uygulamanız tarafından sık sık yazılan ve okunan dosyalar (geçici veri dosyaları gibi) veya yalnızca uygulamanız tarafından görülebilen statik dosyalar için, Azure Depolama paylaşımlarını kalıcı birimler olarak bağlayabilirsiniz. Daha fazla bilgi için bkz. Azure Kubernetes Service'te Azure Dosyalar ile dinamik olarak kalıcı birim oluşturma ve kullanma.

JCA bağlayıcıların kullanılıp kullanılmayacağını belirleme

Uygulamanız JCA bağlayıcıları kullanıyorsa WildFly’da JCA bağlayıcının kullanılabildiğini doğrulamanız gerekir. JCA uygulaması WebLogic’e bağlıysa uygulamanızı yeniden düzenleyerek bu bağımlılığı kaldırmanız gerekir. JCA bağlayıcı kullanılabiliyorsa JAR’leri sunucu sınıf yoluna eklemeniz ve kullanılabilmesi için gerekli yapılandırma dosyalarını WildFly sunucu dizinlerinde doğru konuma yerleştirmeniz gerekir.

Uygulamanızın bir kaynak bağdaştırıcısı kullanıp kullanmadığını belirleme

Uygulamanız bir kaynak bağdaştırıcısına (RA) ihtiyaç duyuyorsa, bunun WildFly ile uyumlu olması gerekebilir. RA’yı sunucuya dağıtıp bunu doğru yapılandırın ve WildFly’ın tek başına örneğinde düzgün çalışıp çalışmadığını belirleyin. RA düzgün çalışıyorsa, JAR’leri Docker görüntüsünün sunucu sınıf yoluna eklemeniz ve kullanılabilmesi için gerekli yapılandırma dosyalarını WildFly sunucu dizinlerinde doğru konuma yerleştirmeniz gerekir.

JAAS’nin kullanımda olup olmadığını belirleme

Uygulamanız JAAS kullanıyorsa JAAS’nin nasıl yapılandırıldığını yakalamanız gerekir. Bir veritabanını kullanıyorsa bunu WildFly’da bir JAAS etki alanına dönüştürebilirsiniz. Bu bir özel uygulamaysa, bunun WildFly’da kullanılabileceğini doğrulamanız gerekir.

WebLogic kümelemesinin kullanılıp kullanılmadığını saptama

Yüksek kullanılabilirlik elde etmek için uygulamanızı büyük olasılıkla birden çok WebLogic sunucusunda dağıtmışsınızdır. Azure Kubernetes Service ölçeklendirme özelliğine sahiptir, ancak WebLogic Cluster API'sini kullandıysanız bu API'nin kullanımını ortadan kaldırmak için kodunuzu yeniden düzenlemeniz gerekir.

Yerinde test gerçekleştirme

Kapsayıcı görüntülerinizi oluşturmadan önce uygulamanızı AKS’de kullanmak istediğiniz JDK ve WildFly sürümlerine geçirin. Uyumluluk ve performanstan emin olmak için uygulamayı kapsamlı olarak test edin.

Geçiş

Azure Container Registry ve Azure Kubernetes Service sağlama

Kayıt defterinde Hizmet Sorumlusunun Okuyucu rolüne sahip olduğu bir kapsayıcı kayıt defteri ve bir Azure Kubernetes kümesi oluşturmak için aşağıdaki komutları kullanın. Kümenizin ağ gereksinimleri için uygun ağ modelini seçtiğinizden emin olun.

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

WildFly için Docker görüntüsü oluşturma

Dockerfile oluşturmak için aşağıdaki önkoşulları sağlamanız gerekir:

Desteklenen bir JDK.
WildFly yüklemesi.
JVM çalışma zamanı seçenekleriniz.
Ortam değişkenlerini (varsa) geçirmeye ilişkin bir yöntem.

Ardından, uygun olan yerlerde aşağıdaki bölümlerde açıklanan adımları gerçekleştirebilirsiniz. Dockerfile ve web uygulamanız için başlangıç noktası olarak WildFly Kapsayıcısı Hızlı Başlangıç deposunu kullanabilirsiniz.

KeyVault FlexVolume’ü yapılandırma
Veri kaynaklarını ayarlama
JNDI kaynaklarını ayarlama
WildFly yapılandırmasını gözden geçirme

KeyVault FlexVolume’ü yapılandırma

Azure KeyVault oluşturun ve tüm gerekli gizli dizileri doldurun. Daha fazla bilgi için bkz . Hızlı Başlangıç: Azure CLI kullanarak Azure Key Vault'tan gizli dizi ayarlama ve alma. Ardından söz konusu gizli dizileri podların erişimine açmak için KeyVault FlexVolume sürücüsünü yapılandırın.

WildFly’ı önyüklemek için kullanılan başlatma betiğini güncelleştirmeniz de gerekir. Sunucu başlatılmadan önce bu betiğin sertifikaları WildFly tarafından kullanılan anahtar deposuna içeri aktarması gerekir.

Veri kaynaklarını ayarlama

WildFly’ı bir veri kaynağına erişme amacıyla yapılandırmak için JDBC sürücüsü JAR’yi Docker görüntünüze ekleyip uygun JBoss CLI komutlarını yürütmeniz gerekir. Docker görüntünüz oluşturulurken bu komutların veri kaynağını ayarlaması gerekir.

Aşağıdaki adımlarda PostgreSQL, MySQL ve SQL Server’a yönelik yönergeler sunulur.

PostgreSQL, MySQL veya SQL Server’a yönelik JDBC sürücüsünü indirin.

Sürücü .jar dosyasını almak için indirilen arşivin paketini açın.
module.xml gibi bir adı olan bir dosya oluşturup aşağıdaki biçimlendirmeyi ekleyin. <module name> yer tutucusunu (köşeli ayraçlarla birlikte) PostgreSQL için org.postgres, MySQL için com.mysql veya SQL Server için com.microsoft ile değiştirin. Docker görüntünüzdeki (örneğin, /opt/database öğesinde) dosyayı yerleştireceğiniz konuma ilişkin tam yolu da içerecek şekilde <JDBC .jar file path> öğesini önceki adımdaki .jar dosyasının adıyla değiştirin.
```
<?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>
```

datasource-commands.cli gibi bir adı olan bir dosya oluşturup aşağıdaki kodu ekleyin. <JDBC .jar file path> öğesini önceki adımda kullandığınız değer ile değiştirin. <module file path> öğesini önceki adımdaki dosya adı ve yolu ile değiştirin (örneğin, /opt/database/module.xml).

PostgreSQL

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

MySQL

batch
module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --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=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
reload
run batch
shutdown

SQL Server

batch
module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
reload
run batch
shutdown

Uygulamanıza yönelik JTA veri kaynağı yapılandırmasını güncelleştirin:

Uygulamanıza yönelik src/main/resources/META-INF/persistence.xml dosyasını açıp <jta-data-source> öğesini bulun. İçeriklerini aşağıda gösterildiği gibi değiştirin:

PostgreSQL
```
<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
```
MySQL
```
<jta-data-source>java:jboss/datasources/mysqlDS</jta-data-source>
```
SQL Server
```
<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
```

Docker görüntünüzü oluşturduğunuzda veri kaynağınızın oluşturulması için aşağıdakini Dockerfile öğenize ekleyin

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

Her veritabanı sunucusu için değişiklik gösterdiklerinden ve Azure portalındaki değerlerden farklı olduklarından, kullanacağınız DATABASE_CONNECTION_URL değerini belirleyin. Burada gösterilen URL biçimleri WildFly’ın kullanılması için gereklidir:

PostgreSQL

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

MySQL

jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT

SQL Server

jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;

Sonraki aşamalarda dağıtım YAML’nizi oluştururken şu ortam değişkenlerini (DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME ve DATABASE_SERVER_ADMIN_PASSWORD) uygun değerlerle geçirmeniz gerekir.

WildFly ile veritabanı bağlantısını yapılandırma hakkında daha fazla bilgi edinmek için bkz. PostgreSQL, MySQL veya SQL Server.

JNDI kaynaklarını ayarlama

WildFly’da yapılandırılması gereken her JNDI kaynağını ayarlamak için genelde aşağıdaki adımlar kullanılır:

Gerekli JAR dosyalarını indirip bunları Docker görüntüsüne kopyalayın.
Bu JAR dosyalarına başvuran bir WildFly module.xml dosyası oluşturun.
Belirli JNDI kaynağının ihtiyaç duyduğu tüm yapılandırmaları oluşturun.
JNDI kaynağını kaydetmek için Docker oluşturma işlemi sırasında kullanılacak JBoss CLI betiğini oluşturun.
Her şeyi Dockerfile’a ekleyin.
Dağıtım YAML’nizdeki uygun ortam değişkenlerini geçirin.

Aşağıdaki örnekte, Azure Service Bus ile JMS bağlantısı kurulması için gerekli olan JNDI kaynağını oluşturmak için uygulanması gereken adımlar gösterilmektedir.

Apache Qpid JMS sağlayıcısını indirin

.jar dosyalarını almak için indirilen arşivin paketini açın.

module.xml gibi bir adı olan bir dosya oluşturup /opt/servicebus öğesine aşağıdaki biçimlendirmeyi ekleyin. JAR dosyalarının sürüm numaralarının önceki adımdaki JAR dosyalarının adlarıyla uyumlu olduğundan emin olun.

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

/opt/servicebus öğesinde bir jndi.properties dosyası oluşturun.

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}

servicebus-commands.cli gibi bir adı olan bir dosya oluşturup aşağıdaki kodu ekleyin.

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

Docker görüntünüzü oluşturduğunuzda JNDI kaynağınızın oluşturulması için aşağıdakini Dockerfile öğenize ekleyin

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

Sonraki aşamalarda dağıtım YAML’nizi oluştururken şu ortam değişkenlerini (MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE ve SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC ve SB_TOPIC) uygun değerlerle geçirmeniz gerekir.

WildFly yapılandırmasını gözden geçirme

Önceki kılavuzda ele alınmayan geçiş öncesi adımlarını incelemek için WildFly Yönetici Kılavuzu’nu gözden geçirin.

Docker görüntüsü oluşturun ve bunu Azure Container Registry’ye gönderin

Dockerfile dosyasını oluşturduktan sonra Docker görüntüsünü oluşturup bunu Azure Container Registry’de yayımlamanız gerekir.

WildFly Kapsayıcısı’na Hızlı Başlangıç GitHub depomuzu kullandıysanız, görüntünüzü oluşturup Azure Container Registry’ye gönderme işlemi aşağıdaki üç komutu çağırmaya denk gelir.

Bu örneklerde, MY_ACR ortam değişkeni Azure Container Registry’nizin adını, MY_APP_NAME değişkeni de Azure Container Registry’nizde kullanmak istediğiniz web uygulamasının adını taşır.

WAR dosyasını oluşturun:

mvn package

Azure Container Registry’de oturum açın:

az acr login --name ${MY_ACR}

Görüntüyü oluşturun ve gönderin:

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

Alternatif olarak, aşağıdaki komutlarda gösterildiği gibi görüntüyü yerel olarak oluşturup test etmek için Docker CLI’yı kullanabilirsiniz. Bu yaklaşım ACR’ye ilk dağıtımdan önce görüntünün test edilmesini ve geliştirilmesini basitleştirebilir. Ancak, bunun için Docker CLI’yı yüklemeniz ve Docker daemon’ın çalıştığından emin olmanız gerekir.

Görüntüyü oluşturun:

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

Görüntüyü yerel olarak çalıştırın:

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

Artık uygulamanıza http://localhost:8080 adresinde erişebilirsiniz.

Azure Container Registry’de oturum açın:

az acr login --name ${MY_ACR}

Görüntüyü Azure Container Registry’ye gönderin:

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

Azure’da kapsayıcı görüntüsü oluşturma ve bunları depolama hakkında daha ayrıntılı bilgi edinmek için şu Learn modülüne bakın: Azure Container Registry ile kapsayıcı görüntüsü oluşturma ve depolama.

Genel IP adresini sağlama

Uygulamanız iç veya sanal ağlarınızın dışından erişilebilir olacaksa, bir genel statik IP adresine ihtiyaç duyarsınız. Aşağıdaki örnekte gösterildiği gibi, bu IP adresini kümenizin düğüm kaynak grubunda sağlamanız gerekir:

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

AKS’ye dağıtma

Kubernetes YAML dosyaları oluşturma ve uygulama. Daha fazla bilgi için bkz . Hızlı Başlangıç: Azure CLI kullanarak Azure Kubernetes Service kümesi dağıtma. Dış yük dengeleyici oluşturuyorsanız (uygulamanız veya bir giriş denetleyicisi için), LoadBalancerIP olarak önceki bölümde sunulan IP adresini sağladığınızdan emin olun.

Dışsallaştırılmış parametreleri ortam değişkenleri olarak ekleyin. Daha fazla bilgi edinmek için bkz. Bir Kapsayıcı için Ortam Değişkenlerini Tanılama. Gizli dizileri (parolalar, API anahtarları ve JDBC bağlantı dizeleri gibi) eklemeyin. Bunlar aşağıdaki bölümde ele alınmıştır.

Kapsayıcılarınızın doğru şekilde boyutlandırılması için dağıtım YAML’sini oluştururken bellek ve CPU ayarlarını da eklediğinizden emin olun.

Kalıcı depolamayı yapılandırma

Uygulamanızda geçici olmayan depolama gerekiyorsa bir veya birden çok Kalıcı Birim yapılandırın.

Zamanlanan işleri geçirme

Zamanlanan işleri AKS kümenizde yürütmek için gerektiği gibi Kubernetes CronJobs tanımlayın. Daha fazla bilgi edinmek için bkz. Bir CronJob ile Otomatikleştirilmiş Görev Çalıştırma.

Geçiş sonrası

Artık uygulamanızı Azure Kubernetes Service’e geçirdiğinize göre beklendiği gibi çalıştığını doğrulamalısınız. Bunu yaptıktan sonra uygulamanızı buluta daha yerel hale getirmek için aşağıdaki önerilere bakın.

Öneriler

Giriş denetleyicinize veya uygulama yük dengeleyicisine ayrılmış IP adresine DNS adı eklemeniz faydalı olabilir. Daha fazla bilgi için bkz . AKS'de statik genel IP adresiyle giriş denetleyicisi oluşturma.
Uygulamanız için HELM grafikleri eklemeyi düşünebilirsiniz. Helm grafiği daha yüksek çeşitliliğe sahip bir müşteri kümesi tarafından kullanılmak ve özelleştirilmek üzere uygulama dağıtımınızı parametreleştirmenize olanak tanır.
DevOps stratejisini tasarlayın ve uygulayın. Güvenilirliği korurken geliştirme hızınızı da artırmak için Azure Pipelines ile dağıtımları ve testleri otomatikleştirmeyi düşünebilirsiniz. Daha fazla bilgi edinmek için bkz. AKS’de derleme ve dağıtma.
Küme için Azure İzleme’yi etkinleştirin. Daha fazla bilgi edinmek için bkz. Önceden dağıtılmış AKS kümesi için izlemeyi etkinleştirme. Bu, Azure İzleyici’nin kapsayıcı günlüklerini toplama ve kullanımı izleme gibi işlemleri gerçekleştirmesine olanak tanır.
Prometheus aracılığıyla uygulamaya özgü ölçümleri kullanıma sunmayı düşünün. Prometheus, Kubernetes topluluğunda yaygın olarak benimsenen bir açık kaynak ölçüm çerçevesidir. Uygulamalarınızdan ölçüm toplamaya ve anormal koşullara otomatik yanıta veya durumu yükseltmeye olanak tanımak için kendi Prometheus sunucunuzu barındırmak yerine Azure İzleyici’de Prometheus Metrics atığını yapılandırabilirsiniz. Daha fazla bilgi edinmek için bkz. Kapsayıcılara yönelik Azure İzleyici ile Prometheus Metrics atığını yapılandırma.
İş sürekliliği ve olağanüstü durum kurtarma stratejisini tasarlayın ve uygulayın. Görev açısından kritik uygulamalar için çok bölgeli dağıtım mimarisi uygulamayı düşünebilirsiniz. Daha fazla bilgi edinmek için bkz. AKS’de iş sürekliliği ve olağanüstü durum kurtarma için en iyi yöntemler.
Kubernetes sürüm desteği ilkesini gözden geçirin. AKS kümenizi güncelleştirmeye devam edip her zaman desteklenen sürümü çalıştırdığından emin olmak sizin sorumluluğunuzdur. Daha fazla bilgi edinmek için bkz. Bir AKS kümesini yükseltme.
Tüm ekip üyelerinin küme yönetiminden ve uygulama geliştirmeden sorumlu olmasını sağlayın, uygun AKS en iyi yöntemlerini gözden geçirin. Daha fazla bilgi edinmek için bkz. AKS’de uygulama oluşturup yönetmek için küme işleci ve geliştiricilere yönelik en iyi deneyimler.
Dağıtım dosyanızın sıralı güncelleştirmelerin nasıl gerçekleştirildiğini belirttiğinden emin olun. Daha fazla bilgi edinmek için Kubernetes belgelerinde Sıralı Güncelleştirme Dağıtımı bölümüne bakın.
Yoğun saatlerdeki yüklerin işlenmesi için otomatik ölçeklendirme özelliği ayarlayın. Daha fazla bilgi edinmek için bkz. AKS’deki uygulama taleplerini karşılamak için bir kümeyi otomatik olarak ölçeklendirme.
Performansı daha da iyileştirmek için kod önbelleği boyutunu izlemeyi ve -XX:InitialCodeCacheSize ve -XX:ReservedCodeCacheSize JVM parametrelerini Dockerfile’a eklemeyi düşünebilirsiniz. Daha fazla bilgi edinmek için Oracle belgelerinde Kod önbelleğini ayarlama bölümüne bakın.

WebLogic Server uygulamalarını Azure Kubernetes Service'te WildFly'ye geçirme

Geçiş öncesi

Envanter sunucusu kapasitesi

Tüm gizli dizilerin envanterini çıkarma

Tüm sertifikaların envanterini çıkarma

JNDI kaynaklarının envanterini çıkarma

Oturum çoğaltmanın kullanılıp kullanılmadığını belirleme

Belge veri kaynakları

WebLogic’in özelleştirilip özelleştirilmediğini saptama

Şirket içine bağlantının gerekip gerekmediğini saptama

Java Message Service (JMS) Kuyruklarının mı yoksa Konularının mı kullanıldığını saptama

Özel oluşturulmuş kendi Paylaşılan Java EE Kitaplıklarınızı kullanıp kullanmadığınızı saptama

OSGi paketlerinin kullanılıp kullanılmadığını saptama

Uygulamanızın işletim sistemine özgü kod içerip içermediğini saptama

Oracle Service Bus’ın kullanımda olup olmadığını saptama

Uygulamanızın birden çok WAR’dan oluşup oluşmadığını saptama

Uygulamanızın EAR olarak paketlenip paketlenmediğini saptama

Üretim sunucularında çalıştırılan tüm dış işlemleri ve daemon’ları belirleme

Desteklenen Java sürümünün doğru çalıştığını onaylama

Uygulamanızın zamanlanan işlere dayanıp dayanmadığını belirleme

WebLogic Betik Aracı'nın kullanılıp kullanılmadığını belirleme

Uygulamanızın WebLogic’e özgü API’leri kullanıp kullanmadığını belirleme

Uygulamanızın Entity Beans mi yoksa EJB 2.x tarzı CMP Beans mi kullanacağına karar verme

Java EE Uygulama İstemcisi özelliğinin kullanılıp kullanılmadığını belirleme

Bir dağıtım planının kullanılıp kullanılmadığını belirleme

EJB zamanlayıcılarının kullanımda olup olmadığını belirleme

Dosya sisteminin kullanılıp kullanılmayacağını ve nasıl kullanıldığını belirleme

Salt okunur statik içerik

Dinamik olarak yayımlanan statik içerik

Dinamik veya dahili içerik

JCA bağlayıcıların kullanılıp kullanılmayacağını belirleme

Uygulamanızın bir kaynak bağdaştırıcısı kullanıp kullanmadığını belirleme

JAAS’nin kullanımda olup olmadığını belirleme

WebLogic kümelemesinin kullanılıp kullanılmadığını saptama

Yerinde test gerçekleştirme

Geçiş

Azure Container Registry ve Azure Kubernetes Service sağlama

WildFly için Docker görüntüsü oluşturma

KeyVault FlexVolume’ü yapılandırma

Veri kaynaklarını ayarlama

JNDI kaynaklarını ayarlama

WildFly yapılandırmasını gözden geçirme

Docker görüntüsü oluşturun ve bunu Azure Container Registry’ye gönderin

Genel IP adresini sağlama

AKS’ye dağıtma

Kalıcı depolamayı yapılandırma

Zamanlanan işleri geçirme

Geçiş sonrası

Öneriler

Geri Bildirim

Geri Bildirim

Ek kaynaklar