WebSphere uygulamalarını Azure Red Hat OpenShift'e geçirme

  • Makale

Bu kılavuzda, mevcut bir WebSphere Application Server (WAS) iş yükünü Azure Red Hat OpenShift üzerinde çalışan IBM WebSphere Liberty veya Open Liberty'ye 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.

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

WAS uygulamasının Azure'a başarılı bir şekilde geçirilmesinin ilk adımı en uygun geçiş hedefini seçmektir.

WAS geleneksel azure Sanal Makineler iyi çalışır. Sanal makine (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 benzer.

Bir diğer seçenek de WAS geleneksel iş yükünü uygulama kapsayıcılarına dönüştürerek kapsayıcılara geçiş yapmaktır. Kapsayıcı hedefini Azure Kubernetes Service (AKS) ve Azure Red Hat OpenShift üzerinde çalıştırabilirsiniz. Bu kolaylığın dezavantajı ekonomik maliyettir.

Genel olarak bakıldığında, VM tabanlı bir çözümün dakika başına maliyeti kapsayıcılarla karşılaştırıldığında daha yüksektir. Kapsayıcı tabanlı çözümün çalıştırılması daha düşük maliyetli olsa da, uygulamanızı kapsayıcı düzenleme platformunun 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. WebSphere uygulamalarını Azure Sanal Makineler geçirme.

Çalışma zamanı maliyetini azaltmak için uygulamanızı kapsayıcılar içinde çalışacak şekilde dönüştürmeyi tolere edebilirseniz AKS tabanlı veya Azure Red Hat OpenShift tabanlı bir geçişi göz önünde bulundurun.

AKS tabanlı geçiş için Ücretsiz katmanını kullanmaya başlayabilirsiniz. Ücretsiz küme yönetimi alın ve yalnızca kullanılan sanal makineler, ilişkili depolama alanı ve ağ kaynakları için ödeme alın. Bu durumda bkz . WebSphere uygulamalarını Azure Kubernetes Service'e geçirme.

Azure Red Hat OpenShift tabanlı geçiş için işlem ve altyapı maliyetlerine ek olarak, uygulama düğümlerinin OpenShift lisans bileşeni için başka bir maliyeti vardır. Bu maliyet, uygulama düğümlerinin sayısına ve örnek türüne göre faturalandırılır. İş yükünüzün ve işletmenizin gereksinimlerini en iyi karşılayan isteğe bağlı fiyatlandırmayı veya ayrılmış örnekleri kullanın. Bu durumda bkz . WebSphere uygulamalarını Azure Red Hat OpenShift'e geçirme.

Azure Red Hat OpenShift belgelerindeki nasıl yapılır kılavuzları, geçişle ilgili bazı yönleri kapsar. Nasıl yapılır kılavuzlarının tam listesi için Azure Red Hat OpenShift belgelerine bakın.

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

Azure Red Hat OpenShift'in uygun dağıtım hedefi olduğuna karar verdikten sonra, Kubernetes'te Liberty'yi çalıştırmanın tek yolunun IBM WebSphere Liberty operatörü veya Open Liberty Operator (operatör) olduğunu kabul etmeniz gerekir. Bu olguyu kabul ettikten sonra, önceden oluşturulmuş Azure Market teklifinin iyi bir başlangıç noktası olup olmadığına karar vermelisiniz. Önceden oluşturulmuş Azure Market teklifi hakkında dikkate alınması gereken bazı şeyler şunlardır:

  • IBM ve Microsoft, Azure Red Hat OpenShift'te Hızlı Bir Şekilde Liberty sağlamanızı sağlamak için bu teklifi oluşturmuştur. Bu kavram aşağıdaki içerikte daha ayrıntılı olarak açıklanmıştır.
  • Yüksek düzeyde, teklif sizin için aşağıdaki adımları otomatikleştirir.
    • İsterseniz mevcut bir uygulama görüntüsünü alın.
    • İsterseniz bir Azure Red Hat OpenShift kümesi sağlayın.
    • Azure Red Hat OpenShift'te IBM WebSphere Liberty operatörünü veya Open Liberty operatörünü yükleyin ve yapılandırın.
    • Tüm işlemi çalıştırmak için işlecini kullanın. Operatör, Azure Red Hat OpenShift'te kapsayıcılı Liberty uygulamalarını dağıtır ve yönetir. Başvuru belgelerini IBM WebSphere Liberty operatörü ve Open Liberty operatöründebulabilirsiniz.

Önceden oluşturulmuş Azure Market teklifini kullanmıyorsanız doğrudan işleci kullanmayı öğrenmeniz gerekir. İşleçte ustalık yapmak bu makalenin kapsamının dışındadır. Operatörün tüm belgeleri IBM WebSphere Liberty operatöründe ve Open Liberty operatöründe mevcuttur.

Artık Azure Red Hat OpenShift'te Liberty'yi işlemenin çeşitli yolları ile tanıştırıldığınıza göre, önceden oluşturulmuş Azure Market teklifini mi kullanacağınızı yoksa doğrudan operatörü kullanarak kendiniz mi yapacağınızı daha iyi seçebilirsiniz.

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

Kubernetes tabanlı kümelerde uygulama dağıtmak ve yönetmek için Open Liberty Operatörüne veya WebSphere Liberty operatörüne ihtiyacınız vardır. Mevcut Liberty sürümünüzün operatör tarafından desteklenen sürümlerden biri olduğundan emin olun. Open Liberty sürümleri GitHub OpenLiberty/open-liberty'de tutulur. IBM, IBM WebSphere Application Server Liberty sürümlerini korur. Daha fazla bilgi için bkz . WebSphere Application Server Liberty.

Önceden oluşturulmuş Azure Market teklifi, uygulama görüntülerinizi genel kayıt defterinden seçmenize olanak tanır ve bu nedenle tüm sürümleri örtük olarak destekler.

Lisans gerekip gerekmediğini belirleme

IBM WebSphere Liberty için, uygulama kapsayıcısında IBM Programı sürümüne karşılık gelen lisans sözleşmesindeki koşulları kabul etmeniz gerekir. Bu IBM Programı için geçerli lisans sözleşmesi için bkz . WebSphere Liberty operatörü için lisans bilgilerini görüntüleme. Daha fazla bilgi için bkz . Microsoft Azure'da WebSphere Liberty'yi çalıştırma.

Ürün sürümünüz varsayılan IBM WebSphere Application Server (temel) .spec.license.edition value dışında bir sürümse, ürün sürümünüzü belirtmelidir. Diğer kullanılabilir değerler IBM WebSphere Application Server Liberty Core ve IBM WebSphere Application Server Ağ Dağıtımı'dır. Önceden oluşturulmuş Azure Market teklifi, desteklenen ürün sürümünü seçmenize olanak tanır.

IBM geçiş araçlarını kullanarak envanter farklılıkları

Uygulamalarınızı WebSphere Application Server Liberty veya Open Liberty'ye taşımak için geçişinizi planlamanız, uygulamalarınızı analiz etmeniz ve kaynak kodunuzu güncelleştirmeniz gerekir. IBM, java EE 7 veya Java EE 8 ve Java SE 8 veya Java SE 11 gibi geçerli ortamınızla yeni Liberty ortamınızdaki teknolojiler arasındaki farkları belirlemenize yardımcı olacak geçiş araçları sağlar. Daha fazla bilgi için bkz . Uygulamaları Liberty'ye 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ı belgeleyebilirsiniz. Seçtiğiniz geçiş yolundan bağımsız olarak bu bilgilere ihtiyacınız vardır. Bu bilgiler, örneğin düğümünüzdeki VM'lerin boyutunu, kapsayıcı tarafından kullanılacak bellek miktarını ve kapsayıcının kaç CPU paylaşımına ihtiyaç duyacağını seçmeye yardımcı olmak için yararlıdır.

Kullanılmayan kapasiteden önemli bir maliyet tasarrufuyla yararlanmak için Azure Red Hat OpenShift'te Azure Spot Sanal Makineler kullanmak mümkündür. Nasıl yapılacağını öğrenmek için bkz. Azure Red Hat OpenShift kümesinde Azure Spot Sanal Makineler kullanma.

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ı. WAS gibi uygulama sunucularında bu gizli diziler birçok farklı yapılandırma dosyasında ve yapılandırma deposunda bulunur. Üretim sunucularındaki tüm özellikleri ve yapılandırma dosyalarını gizli diziler ve parolalar için denetleyin. Ayrıca uygulamanızın içinde parolalar ve kimlik bilgileri içeren yapılandırma dosyaları da bulunabilir. WAS, yapılandırma verilerini birkaç belgede basamaklı dizin hiyerarşisinde depolar. Yapılandırma belgelerinin çoğunda XML içeriği vardır. Daha fazla bilgi için bkz . Yapılandırma belgeleri ve Azure Key Vault temel kavramları.

Gizli dizilerden oluşan sağlam bir envantere sahip olduktan sonra gizli diziler ile ilgili operatör belgelerine başvurun. Daha fazla bilgi için aşağıdaki makaleleri inceleyin:

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>

Sertifikaların sağlam bir envanterini aldıktan sonra, aşağıdaki makaleleri kullanarak bunları yapılandırın:

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

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

WebSphere Application Server Liberty çalışma zamanı, Java Çalışma Zamanı Ortamı'nın (JRE) en düşük düzeyi için belirli gereksinimlere sahiptir. Daha fazla bilgi için bkz . Özellikler için Java sürüm bağımlılıkları.

Open Liberty için Java SE çalışma zamanı gerekir. Java Çalışma Zamanı Ortamı (JRE) veya Java SE Geliştirme Seti (JDK) dağıtımı kullanarak çalıştırılabilir. Daha fazla bilgi için bkz . Desteklenen Java SE sürümleri.

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 IBM belgelerindeki WebSphere 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 . JMS kaynaklarını kullanma.

Önceden oluşturulmuş Azure Market teklifini kullanıyorsanız, dağıtım zamanında özelleştirebileceğiniz JNDI kaynakları kümesi teklifin desteklediğiyle sınırlıdır. AKS üzerinde WebSphere Liberty için bir nesneyi varsayılan Java Adlandırma ve Dizin Arabirimi (JNDI) ad alanında kullanılabilir hale getirebilirsiniz. Daha fazla bilgi için bkz . Liberty özelliğinde JNDI varsayılan ad alanıyla geliştirme. Open Liberty için bkz . Java Adlandırma ve Dizin Arabirimi.

Profil yapılandırmanızı inceleme

WAS'deki ana yapılandırma birimi profildir. Bu nedenle, resources.xml dosyası geçiş için dikkatle dikkate almanız gereken zengin bir yapılandırma içerir. Dosya, alt dizinlerde depolanan diğer XML dosyalarına başvurular içerir. Daha fazla bilgi için bkz . Dağıtılmış ve IBM i işletim sistemlerinde profilleri yönetme.

Uygulamanızın içinde

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

Azure Red Hat OpenShift'in çalıştığı kapsayıcı görüntüsünde bu özelleştirmeleri yakalamanız gerekir. Önceden oluşturulmuş Azure Market teklifini kullandığınızda, bu özelleştirmeler en iyi şekilde özel bir kapsayıcı görüntüsü oluşturup bunu genel kayıt defterinde kullanılabilir hale getirerek ve dağıtım zamanında söz konusu kayıt defterine işaret ederek işlenir.

WebSphere Uygulama Sunucusu Ağ Dağıtımı hücresi kullanıyorsanız, her küme üyesi geleneksel WAS yüklemesinde çalışır. Liberty, WebSphere Uygulama Sunucusu'nun basit profilidir. WAS'nin esnek ve dinamik bir profilidir ve WAS sunucusunun büyük bir kullanılabilir JEE bileşeni kümesi dağıtmak yerine yalnızca gerekli özel özellikleri dağıtmasını sağlar.

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

Uygulamanız oturum çoğaltmayı kullanıyorsa aşağıdaki seçenekleriniz vardır:

  • HTTP oturumlarında, oturum yönetimi düzeyine göre oturum verilerini toplamak için önbelleği veya veritabanını kullanabilirsiniz.
  • Dağıtılmış oturumlar için, veritabanı oturumu kalıcılığını kullanarak oturumları bir veritabanına kaydedebilirsiniz.
  • Dinamik önbellek için önbellekteki veya veritabanındaki oturum verilerini yönetebilirsiniz.
  • Oturum yönetimi için veritabanı kullanmak üzere uygulamanızı yeniden düzenleyebilirsiniz.
  • Oturumu Azure Redis Service'e harici hale getirmek için uygulamanızı yeniden düzenleyebilirsiniz. Daha fazla bilgi için bkz. Redis için Azure Cache.

Bu seçeneklerin tümü için Liberty'nin HTTP Oturum Durumu Çoğaltması'nı nasıl yaptığını öğrenmek iyi bir fikirdir. Aşağıdaki belgeler, Liberty'de HTTP Oturumlarının nasıl yönetileceğini anlamanıza yardımcı olur:

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?

WAS'deki JDBC sürücüleri hakkında daha fazla bilgi için bkz . WebSphere Uygulama Sunucusu ile JDBC Sürücülerini Kullanma.

JDBC yapılandırması, Liberty'de temel sunucu yapılandırmasıdır. Daha fazla bilgi için bkz . JDBC Sürücüsü.

Önceden oluşturulmuş Azure Market teklifi veritabanları için sınırlı desteğe sahiptir. Uygulama görüntülerinde yapılandırmayı işleyebilir ve teklifi dağıtırken görüntüyü kullanabilirsiniz.

WAS'nin özelleştirilip özelleştirilmemiş olduğunu belirleme

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 betikler arasında wsadmin, Yönetici Control, Yönetici Config, Yönetici App ve Yönetici Task bulunur.
  • JVM’ye geçirilmiş belirli parametreler var mı?
  • Sunucu sınıf yoluna eklenmiş JAR’lar var mı?
  • Sunucu yeniden başlatıldıktan sonra WAS bileşenlerinin otomatik olarak başlatılmasına neden olmak için kullanılan işletim systemd sistemi düzeyindeki olanaklar var mı?

Bu soruların yanıtlarına bağlı olarak geçişle ilgili dikkat edilmesi gereken noktaları dikkate almanız gerekir.

Azure Red Hat OpenShift'in çalıştığı kapsayıcı görüntüsünde bu özelleştirmeleri yakalamanız gerekir. Önceden oluşturulmuş Azure Market teklifini kullandığınızda, bu özelleştirmeler en iyi şekilde özel bir kapsayıcı görüntüsü oluşturup bunu genel kayıt defterinde kullanılabilir hale getirerek ve dağıtım zamanında söz konusu kayıt defterine işaret ederek işlenir.

Ş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ı veya Konuları kullanıyorsa, bunları dışarıda barındırılan bir JMS sunucusuna geçirmeniz gerekir. JMS kullananlar için bir strateji, Azure Service Bus ve Gelişmiş Message Queuing Protokolü'dür. Daha fazla bilgi için bkz. Azure Service Bus ve AMQP 1.0 ile JMS’yi kullanma.

JMS kalıcı depolarını yapılandırdıysanız, bunların yapılandırmasını yakalamanız ve geçiş sonrasında uygulamanız gerekir.

IBM MQ kullanıyorsanız bu yazılımı Azure Sanal Makineler'a geçirip olduğu gibi kullanabilirsiniz.

Microsoft, IBM MQ'yi Logic Apps ile tümleştirmek için bir çözüme sahiptir. Daha fazla bilgi için bkz. Azure Logic Apps'te bir iş akışından IBM MQ sunucusuna Bağlan.

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

Bu kitaplıkları, Java EE uygulamasından üçüncü taraf API'lere erişme başlığında açıklandığı gibi aynı teknikleri kullanarak işleyebilirsiniz.

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

WAS'ye eklenen OSGi paketlerini kullandıysanız, eşdeğer JAR dosyalarını doğrudan web uygulamanıza eklemeniz gerekir.

Paketleri önceden oluşturulmuş Azure Market teklifine sağlanan görüntüye ekleyebilirsiniz. Daha fazla bilgi için bkz . OSGi uygulamaları için kitaplıkları yapılandırma.

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.

Azure Red Hat OpenShift üzerinde Liberty, Linux x86_64 üzerinde çalışır. İşletim sistemine özgü tüm kodlar Linux ile uyumlu olmalıdır. Belirli işletim sistemi bilgilerini bulmayı öğrenmek için Liberty sürümünün uyumlu olup olmadığını belirleme bölümündeki adımları izleyin.

IBM Integration Bus'ın kullanımda olup olmadığını belirleme

Uygulamanız IBM Integration Bus kullanıyorsa IBM Integration Bus'ın nasıl yapılandırıldığını yakalamanız gerekir. Daha fazla bilgi için IBM Integration Bus belgelerine bakın.

IBM Integration Bus, önceden oluşturulmuş Azure Market teklifinde doğrudan desteklenmez. Özelliği etkinleştirmek için IBM belgelerindeki Liberty'de JMS uygulamasının hizmet tümleştirme veriyoluna bağlanmasını etkinleştirme başlığındaki yönergeleri izleyin.

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 paketlenmişse application.xml, ibm-application-bnd.xmi ve ibm-application-ext.xmi dosyalarını incelemeyi ve yapılandırmalarını yakalamayı unutmayın. Daha fazla bilgi için bkz . WebSphere'de kurumsal arşiv (EAR) paketi oluşturma.

Önceden oluşturulmuş Azure Market teklifi, mevcut bir kapsayıcı görüntüsünü kullanmanıza olanak tanır. Uygulamayı iş gereksinimlerinize göre hazırlayabilirsiniz.

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

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

Kubernetes, kalıcı birimlere (PV) sahip dosya sistemleriyle ilgilenir. Kalıcı birimleri bağlama, önceden oluşturulmuş Azure Market teklifinde desteklenmez. Azure Dosyalar Depolama Class oluşturmak için Azure Red Hat OpenShift 4'te Azure Dosyalar Depolama Class oluşturma başlığı altındaki yönergeleri izleyin.

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çirmeniz gereken yönlerini kapsamazsa, mevcut dağıtımınızın ağ topolojisini yakalamanız gerekir. Ardından, çözüm şablonlarından biriyle temel teklifi oluşturduktan sonra bile bu topolojiyi Azure'da yeniden oluşturmanız gerekir.

Ağ topolojisi geniş bir konu başlığıdır, ancak aşağıdaki başvurular geçiş çalışmalarınız için bazı yönler verebilir:

JCA bağdaştırıcılarının ve kaynak bağdaştırıcılarının kullanımına yönelik hesap

Mevcut uygulamanız diğer kurumsal sistemlere bağlanmak için JCA bağdaştırıcıları veya kaynak bağdaştırıcıları kullanıyorsa bu yapıtların yapılandırmasını AKS üzerinde çalışan Liberty sunucusuna uyguladığınızdan emin olun. Daha fazla bilgi için bkz. JCA yapılandırma öğelerine genel bakış ve Java Bağlan or Mimarisi.

Kümelemenin kullanılıp kullanılmadığını belirleme

operatör, Azure Red Hat OpenShift'te WAS iş yükünü çalıştırmanın tüm olası yolları için kümeleme işlemini işler.

EJB kümelemenizi inceleme

Uygulamanız yerel Enterprise Java Beans (EJB) kullanıyorsa bunları kümelenmiş bir EJB'ye geçirmeniz gerekebilir. Daha fazla bilgi için bkz . Liberty'de EJB uygulamaları geliştirme.

Yük dengeleme gereksinimleri için hesap

Önceden oluşturulmuş Azure Market teklifi, uygulamayı genel URL'de ve yük dengeleme hesabında barındırmak için OpenShift yerleşik yolunu kullanır. Daha fazla bilgi için bkz . OpenShift Route yapılandırması.

Geçiş

Bu bölümdeki adımlarda, analizinizin önceden oluşturulmuş Azure Market teklifini kullanmaya karar vermenize neden olduğu varsayılır.

Teklifi sağlama

Teklifi Azure portalında açmak için bkz . Azure Red Hat OpenShift üzerinde IBM WebSphere Liberty ve Open Liberty. Oluştur'u seçin, ardından teklifin alanlarını doldurmaya yardımcı olmak için önceki adımlarda topladığınız bilgileri kullanın.

KeyStores bilgileri

Uygulamanız tarafından kullanılan tüm SSL/TLS KeyStore'ların geçişini hesaba bağlamanız gerekir. Daha fazla bilgi için bkz. KeyStores yapılandırması.

JMS kaynaklarını bağlama

Veritabanlarını bağladıktan sonra, IBM belgelerindeki JCA yapılandırma öğelerine genel bakış başlığındaki yönergeleri izleyerek JMS'yi yapılandırabilirsiniz.

Günlüğe kaydetme

Günlüğe kaydetmeden bulut yapamazsınız. işleci izleme için farklı yaklaşımlar sağlar. Daha fazla bilgi için bkz . Liberty sunucusu çalışma zamanı ortamını izleme. Red Hat OpenShift'te günlüğe kaydetme ve izleme sisteminde ustalık yapmak yararlı olur. Daha fazla bilgi için bkz . Red Hat OpenShift için günlüğe kaydetme alt sistemini anlama ve OpenShift Kapsayıcı Platformu izleme hakkında. Azure Red Hat OpenShift için Azure İzleyici kapsayıcı içgörülerini yapılandırabilirsiniz. Daha fazla bilgi için bkz . Azure Red Hat OpenShift için Azure İzleyici kapsayıcı içgörülerini yapılandırma. Elastik Yığın kullanmayı tercih ediyorsanız Azure, Elastik için harika destek sağlar. Tüm ayrıntılar için bkz . Azure ile elastik tümleştirme nedir? Azure Red Hat OpenShift'te Liberty için Azure için iyileştirilmiş bir günlük çözümü elde etmek için bu kaynaklardaki bilgileri birleştirebilirsiniz.

Uygulamalarınızı geçirin

Dağıtım zamanında uygulama görüntüsü sağlamayı seçseniz de seçmeseniz de, uygulamayı CI/CD aracılığıyla güncelleştirmeniz gerekir. OpenShift belgelerinde bu güncelleştirmenin nasıl yapıldığını gösteren örnekler bulunur. Daha fazla bilgi için bkz . OpenShift Kapsayıcı Platformu CI/CD'ye genel bakış.

Testleri yapılandırma

Azure'da çalışan yeni sunuculara erişmek için uygulamalara karşı kapsayıcı içi testleri yapılandırmanız gerekir. CI/CD konusunda olduğu gibi, gerekli ağ güvenlik kurallarının testlerinizin Azure'a dağıtılan uygulamalara erişmesine olanak sağladığından emin olmanı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. Aşağıdaki makaleler geçiş sonrası geliştirmeler hakkında bilgi sağlar: