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

  • Makale

Bu kılavuzda mevcut WebLogic uygulamasını Azure Sanal Makineler üzerinde çalıştırmak için geçirmek istediğinizde nelerin farkında olmanız gerektiği açıklanır. Azure Market'daki kullanılabilir WebLogic Server çözümlerine genel bakış için bkz. Azure Sanal Makineler'de Oracle WebLogic Server çalıştırmaya yönelik çözümler nelerdir?

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ş tamamlandı" ifadesinin tanımını yapma

Bu kılavuz ve ilgili Azure Market teklifleri, WebLogic Server iş yüklerinizi Azure'a geçirme sürecini hızlandırmak için kullanabileceğiniz başlangıç noktalarıdır. Geçiş çabalarınızın kapsamını tanımlamak önemlidir. Örneğin mevcut altyapınızdan Azure Sanal Makineler'e "lift and shift" yöntemiyle mi geçiş yapıyorsunuz? Bu durumda geçiş sırasında bazı aşamalarda "lift and improve" yaklaşımını benimsemeniz gerekebilir.

Bu kılavuzda ayrıntılı bir şekilde anlatılan değişiklikleri dikkate alarak mümkün olduğunca "lift and shift" yaklaşımıyla ilerlemeniz önerilir. "Geçiş tamamlandı" ifadesinin tanımını yaparak bu kilometre taşına ulaştığınızda durumun farkına varabilirsiniz. "Geçiş tamamlandı" noktasına ulaştığınızda Anlık görüntü oluşturma bölümünde açıklandığı gibi sanal makinelerinizin anlık görüntüsünü alabilirsiniz. Anlık görüntünüzden başarıyla geri yükleyebileceğinizi doğruladıktan sonra, şimdiye kadar başardığınız geçiş ilerlemesini kaybetme korkusu olmadan iyileştirmeleri yapabilirsiniz.

Hedefin geçiş çabanız için uygun hedef olduğundan emin olun

WLS uygulamasının Azure'a başarılı bir şekilde geçirilmesinin ilk adımı en uygun geçiş hedefini seçmektir. WLS, Azure sanal makinelerinde (VM) veya Azure Kubernetes Service'te (AKS) iyi çalışır. Vm hedefi, şirket içi dağıtıma en çok benzediğinden en kolay seçenektir. Sanal makineler için yönetim ve dağıtım deneyimi, şirket içi ortamınıza çok benzer. Bu kolaylığın dezavantajı ekonomik maliyettir. Genel olarak bakıldığında, VM tabanlı bir çözümün dakika başına maliyeti AKS ile karşılaştırıldığında daha yüksektir. AKS tabanlı çözümün çalıştırılması daha düşük maliyetli olsa da uygulamanızı AKS gereksinimlerine uyacak şekilde kısıtlamanız gerekir. Geçiş çabanız için en önemli faktör değişikliği en aza indirmekse VM tabanlı geçişi göz önünde bulundurun. Bu durumda bkz. WebLogic uygulamalarını Azure Sanal Makineler geçirme. Çalışma zamanı maliyetini azaltmak için uygulamanızı Kubernetes içinde çalışacak şekilde dönüştürmeyi tolere edebilirseniz AKS tabanlı geçiş yapmayı göz önünde bulundurun. Bu durumda, WebLogic Server uygulamalarını Azure Kubernetes Service'e geçirme ile devam edin.

Önceden oluşturulmuş Azure Market tekliflerinin iyi bir başlangıç noktası olup olmadığını belirleme

Oracle ve Microsoft, Azure'a geçiş için sağlam bir başlangıç noktası sağlamak üzere bir dizi Azure çözüm şablonunu Azure Market getirmek için iş birliği yaptı. Teklif listesi için Oracle Fusion Middleware belgelerine başvurun ve mevcut dağıtımınıza en yakın olan şablonu seçin. Tekliflerin listesini Azure'da Oracle WebLogic Server nedir? genel bakış makalesinde görebilirsiniz.

Mevcut tekliflerden hiçbiri iyi bir başlangıç noktası değilse, Azure Sanal Makine kaynaklarını kullanarak dağıtımı el ile yeniden oluşturmanız gerekir. Oracle WebLogic Server'ı Azure'a el ile yükleme Sanal Makineler adım adım yönergeleri bulabilirsiniz. Daha fazla bilgi için bkz. IaaS nedir?

WebLogic sürümünün uyumlu olup olmadığını belirleme

Mevcut WebLogic sürümünüz IaaS tekliflerindeki sürümle uyumlu olmalıdır. WebLogic sürüm 12.2.1.3 tekliflerini görmek için Oracle WebLogic 12.2.1.3 için sorgu Azure Market. Mevcut WebLogic sürümünüz bu sürümle uyumlu değilse, Azure IaaS kaynaklarını kullanarak dağıtımı el ile yeniden oluşturmanız gerekir. Daha fazla bilgi edinmek için Azure belgelerine bakın.

Envanter sunucusu kapasitesi

Hem geçerli üretim sunucularının donanımını (bellek, CPU, disk) hem de ortalama ve en yüksek istek sayılarını ve kaynak kullanımını belgeleyin. Bu bilgiler VM boyutu seçimini bildirmelidir. Daha fazla bilgi için bkz. Bulut Hizmetlerinin Boyutları.

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>

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

WebLogic için Azure’a tüm geçiş yolları belirli bir Java sürümü gerektirir ve bu sürüm her yolda değişiktir. Uygulamanızın bu desteklenen sürümü kullanarak doğru çalıştırılabildiğini 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

Dekont

Azure sanal makinelerinde WLS'ye geçiş yaparken, belirli Java sürümlerine yönelik gereksinimler sanal makinelerde önceden yüklenmiş Java tarafından belirlenir. AKS üzerinde WLS'ye geçiş yaparken, belirli Java sürümü seçilen kapsayıcı görüntüsü tarafından belirlenir. Çok çeşitli seçenekler vardır, ancak bunların tümü Oracle JDK kullanır.

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.

Etki alanı yapılandırmanızı inceleme

WebLogic Server’da ana yapılandırma birimi etki alanıdır. Bu nedenle config.xml dosyası, geçiş sırasında dikkatle gözden geçirmeniz gereken birçok yapılandırma içerir. Dosyada, alt dizinlerde depolanan ek XML dosyalarının başvuruları vardır. Oracle normalde WebLogic Server’ın yönetilebilir nesneleri ve hizmetleri yapılandırmak için Yönetim Konsolu’nu kullanmanızı ve config.xml dosyasının bakımını WebLogic Server’a bırakmanızı önerir. Daha fazla bilgi için bkz. Etki Alanı Yapılandırma Dosyaları.

Uygulamanızın içinde

WEB-INF/weblogic.xml dosyasını ve/veya WEB-INF/web.xml dosyasını inceleyin.

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 üç seçeneğiniz vardır:

  • Coherence*Web, Azure sanal makinelerinde WebLogic Server ile birlikte çalışabilir ama teklifi sağladıktan sonra bu seçeneği el ile yapılandırmanız gerekir. Tek başına Coherence kullanıyorsanız, bunu bir Azure sanal makinesinde de çalıştırabilirsiniz ama teklifi sağladıktan sonra bu seçeneği el ile yapılandırmanız gerekir.
  • 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.

Tüm bu seçenekler için WebLogic’in HTTP Oturum Durumu Çoğaltması’nı nasıl yaptığı iyice anlaşılmalıdır. Daha fazla bilgi için Oracle belgelerinde HTTP Oturum Durumu Çoğaltması’na bakın.

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

REST üzerinde Yönetimin kullanılıp kullanılmadığını saptama

Uygulamanızın yaşam döngüsü REST üzerinde Yönetim kullanmayı içeriyorsa, REST API’ye erişmek için kullanılan bağlantı noktalarını yakalamalı, bunların nasıl kimlik doğrulaması yaptığını ve kullanıma sunulduğunu saptamalısınız. Geçiş sonrasında aynı bağlantı noktalarının ve kimlik doğrulama mekanizmalarının kullanıma sunulduğundan emin olmanız gerekir. Böylelikle uygulama yaşam döngünüz geçiş öncesine benzer şekilde çalışabilir. Daha fazla bilgi için bkz. RESTful Management Services ile Oracle WebLogic Server’ı yönetme.

Ş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ü, 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.

Oracle Message Broker kullanıyorsanız bu yazılımı Azure sanal makinelerine geçirip olduğu gibi kullanabilirsiniz.

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

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

WebLogic Scripting Tool’un (WLST) kullanılıp kullanılmadığını saptama

Şu anda dağıtımınızı gerçekleştirmek için WLST kullanıyorsanız, neler yaptığını değerlendirmeniz gerekir. WLST dağıtımınız kapsamında uygulamanızın herhangi bir (çalışma zamanı) parametresini değiştiriyorsa, geçiş sonrasında uygulamanızı test ederken bu davranışın devam ettiğinden emin olmalısınız.

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

VM dosya sistemleri kalıcılık, başlatma ve kapatma bakımından şirket içi dosya sistemleriyle aynı biçimde çalışır. Yine de, dosya sistemi gereksinimlerinizin farkında olup VM’nin yeterli depolama boyutuna ve performansa sahip olduğundan emin olmanız önemlidir.

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.

Ağ topolojisi belirleme

Geçerli Azure Market teklifleri kümesi geçişiniz için bir başlangıç noktasıdır. Teklif, mimarinizin geçirmek istediğiniz yönlerini kapsamıyorsa temel teklifi çözüm şablonlarından biriyle destekledikten sonra mevcut dağıtımınızın ağ topolojisini yakalayıp Azure’da yeniden oluşturmanız gerekir.

Bu çok kapsamlı bir konudur ama aşağıdaki başvurular geçiş işlemlerinizi yönlendirmenize yardımcı olabilir:

  • Bu başvuru, ağ topolojisinin Azure'a geçişiyle ilgili üst düzey konuları numaralandırır: Hızlı İzleme Dağıtım Kılavuzu.
  • Bu başvuru, ağ topolojisi üzerinde etkisi olan kümelemeyle ilgili önemli endişeleri açıklar: WebLogic Server Kümelemesi.
  • Veri kaynakları bir WebLogic sisteminde bulunan ayrı sunucular olduğundan onları ağ topolojisi analizinin bir parçası olarak düşünmeniz gerekir. WebLogic Server Veri Kaynakları.
  • Mesajlaşma kaynakları da ayrı sunuculardır. WebLogic Server Mesajlaşma
  • Yük dengeleme temel bir gereksinimdir. Bu başvuru, yük dengelemenin WebLogic Server tarafını kapsar: Kümede Yük Dengeleme.

JCA Bağdaştırıcılarının ve Kaynak Bağdaştırıcılarının kullanımı için hesap

Mevcut uygulamanız diğer kurumsal sistemlere bağlanmak için JCA Bağdaştırıcılarını ve/veya Kaynak Bağdaştırıcılarını kullanıyorsa, bu yapıtların yapılandırmasının Azure Sanal Makineler üzerinde çalıştırılan WebLogic Server’a uygulandığından emin olmalısınız. Daha fazla bilgi için bkz. Kaynak Bağdaştırıcılarını Oluşturma ve Yapılandırma

Özel güvenlik sağlayıcılarının ve JAAS'nin kullanımına yönelik hesap

Uygulamanız JAAS kullanıyorsa, güvenlik sağlayıcıları yapılandırmasının doğru geçirildiğinden emin olmalısınız. Daha fazla bilgi için Oracle belgelerinde WebLogic Güvenlik Sağlayıcılarını Yapılandırma Hakkında konusuna bakın.

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. Bu kümeleri şirket içi yüklemenizden doğrudan Azure Sanal Makineler’de çalışan WebLogic’e geçirebilirsiniz. Daha fazla bilgi için Oracle belgelerinde Etki Alanı Yapılandırma Dosyaları’na bakın.

Yük dengeleme gereksinimleri için hesap

Yük dengeleme, Oracle WebLogic Server kümenizi Azure'a geçirmenin önemli bir parçasıdır. En kolay çözüm, Oracle WebLogic Server kümesi için Azure Market teklifinde sağlanan Azure Uygulaması Lication Gateway için yerleşik desteği kullanmaktır. Bu konudaki bir öğretici için bkz. Öğretici: Azure Uygulaması lication Gateway ile WebLogic Server kümesini yük dengeleyici olarak Azure'a geçirme.

Azure Uygulaması Lication Gateway'in diğer Azure yük dengeleme çözümleriyle karşılaştırıldığında özelliklerinin özeti için bkz. Azure'da yük dengeleme seçeneklerine genel bakış.

Java EE Uygulaması İstemci özelliğinin kullanılıp kullanılmadığını saptama

Uygulamanız Java EE Uygulaması İstemci özelliğini kullanıyorsa, Azure Sanal Makineler’e geçirildikten sonra değişmeden çalışmaya devam etmesi gerekir. Daha fazla bilgi için bkz. Java EE İstemci Uygulaması Modülleri.

Geçiş

Azure Sanal Makineler üzerinde WebLogic teklifi seçme

Azure Sanal Makineler üzerinde WebLogic için aşağıdaki teklifler kullanılabilir.

Bir teklifin dağıtımı sırasında, WebLogic sunucu düğümleriniz için Sanal Makine boyutunu seçmeniz istenir. VM boyutunu seçerken tüm boyut etkenlerini (bellek, işlemci, disk) dikkate almanız önemlidir. Daha fazla bilgi için bkz . Sanal makine boyutlandırma için Azure Belgeleri

Yönetici Sunucusu Olmadan Tek Düğümlü WebLogic Server

Bu teklif tek bir VM oluşturur ve üzerine WebLogic yükler ancak etki alanı yapılandırmaz. Bu seçenek, üst düzeyde özelleştirilmiş bir etki alanı yapılandırmasına sahip olduğunuz senaryolar için kullanışlıdır.

Yönetici Sunucusu ile Tek Düğümlü WebLogic Server

Bu teklif tek bir VM sağlar ve üzerine WebLogic Server yükler. Bir etki alanı oluşturur ve yönetici sunucusunu başlatır.

WebLogic Server N Düğümlü Küme

Bu teklif, WebLogic Server VM'lerinden oluşan yüksek düzeyde kullanılabilir bir küme oluşturur.

WebLogic Server N Düğümlü Dinamik Küme

Bu teklif, WebLogic Server VM'lerinden oluşan yüksek düzeyde kullanılabilir ve ölçeklenebilir dinamik bir küme oluşturur.

Teklifi sağlama

Başlangıç noktası olarak kullanacağınız teklifi seçtikten sonra teklif belgelerindeki yönergeleri izleyerek ilgili teklifi sağlayın. Mevcut etki alanı adınızla eşleşen etki alanı adını seçtiğinizden emin olun. Etki alanı parolasını da mevcut etki alanı parolanızla aynı yapabilirsiniz.

Etki alanlarını geçirme

Teklifi sağladıktan sonra etki alanı yapılandırmasını inceleyebilir ve etki alanı geçirme adımları için bu kılavuzu izleyebilirsiniz.

Veritabanlarını bağlama

Etki alanlarını geçirdikten sonra, teklif belgelerindeki yönergeleri izleyerek veritabanlarını bağlayabilirsiniz. Bu yönergeler, dahil olan tüm veritabanı gizli dizilerini ve erişim dizelerini hesaba katar.

KeyStores bilgileri

Geçiş sırasında uygulamanız tarafından kullanılan tüm SSL KeyStores bilgilerini de dikkate almanız gerekir. Daha fazla bilgi için bkz. KeyStores yapılandırması.

JMS kaynaklarını bağlama

Veritabanlarını bağladıktan sonra JMS'yi yapılandırabilirsiniz. Daha fazla bilgi için WebLogic belgelerindeki Fusion Ara Yazılımı Yönetici Oracle WebLogic Server için JMS Kaynaklarını listeleme bölümüne bakın.

Kimlik doğrulaması ve yetkilendirme hesabı

Çoğu uygulamanın bir tür kimlik doğrulaması ve yetkilendirmesi vardır. Kimlik doğrulaması için LDAP kullanıyorsanız, Microsoft Entra Domain Services'ı güvenli LDAP ile ayarlayabilir ve WebLogic Server'da LDAP bağlantılarını yapılandırabilirsiniz. Daha fazla bilgi için bkz. Microsoft Entra Domain Services yönetilen etki alanı oluşturma ve yapılandırma ve Microsoft Entra Domain Services yönetilen etki alanı için güvenli LDAP yapılandırma.

Günlüğe kaydetme

Oracle WebLogic Server market çözüm şablonları tarafından sağlanan Azure'da Elastic ile tümleştirmeyi kullanın. Bu yaklaşım, günlüğe kaydetmeyi hesaba eklemenin en kolay yoludur. Azure Sanal Makineler'da Oracle WebLogic Server çalıştırmaya yönelik çözümler nelerdir? genel bakış makalesinde tekliflerin listesini görebilirsiniz. Elastik'i yapılandırmaya yönelik eksiksiz öğreticiler şu şekilde sağlanır:

Elastik tümleştirme uygun değilse, etki alanını geçirirken mevcut günlük yapılandırmasını taşımanız gerekir. Daha fazla bilgi için Oracle belgelerindeki Java.util.logging günlükçü düzeylerini yapılandırma ve Günlük Dosyalarını Yapılandırma ve Oracle WebLogic Server için Günlük İletilerini Filtreleme konularını inceleyin.

Uygulamalarınızı geçirme

Uygulamaları geliştirme ekibinden test, hazırlama ve üretim sunucularına dağıtmak için kullanılan teknikler duruma göre değişiklik gösterir. Bazı durumlarda, uygulamaların WebLogic Server'a dağıtılmasıyla sonuçlanan yüksek oranda gelişmiş bir CI/CD platformu vardır. Diğer durumlarda süreç el ile sürdürülebilir. WebLogic uygulamalarını buluta geçirmek için Azure Sanal Makineler kullanmanın avantajlarından biri, mevcut süreçlerinizin çalışmaya devam etmesidir.

Teklifin CI/CD işlem hattınızdan veya el ile dağıtım sisteminizden erişime izin vermek için sağladığı Ağ Güvenlik Grubunu yapılandırmanız gerekir. Daha fazla bilgi için bkz . Ağ güvenlik grupları.

Test Etme

Uygulamalarda yapılan kapsayıcı içi testlerin Azure'da çalışan yeni sunuculara erişecek şekilde yapılandırılması gerekir. CI/CD konusunda olduğu gibi, testlerinizin Azure'a dağıtılan uygulamalara erişmesine izin veren gerekli ağ güvenlik kurallarını sağlamanız gerekir. Daha fazla bilgi için bkz . Ağ güvenlik grupları.

Geçiş sonrası

Geçiş öncesi adımında tanımladığınız geçiş hedeflerine ulaştıktan sonra her şeyin beklendiği gibi çalıştığından emin olmak için birkaç uçtan uca onay testi gerçekleştirmeniz gerekir. Geçiş sonrası bazı olası geliştirmelerle ilgili yönergeler için aşağıdaki önerilere bakın: