WebSphere uygulamalarını Azure Sanal Makineler geçirme

  • Makale

Bu kılavuzda, mevcut bir WebSphere Uygulama Sunucusu (WAS) geleneksel uygulamasını Azure Sanal Makineler'da çalışacak şekilde geçirmek istediğinizde bilmeniz gerekenler açıklanmaktadır. Azure Market'daki kullanılabilir WAS geleneksel çözümlerine genel bakış için bkz. IBM WebSphere ürün ailesini Azure'da ç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, WAS geleneksel iş yüklerinizin Azure'a geçişini hızlandırmaya yönelik bir başlangıç noktası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ı" işleminize ulaştığınızda, sanal sabit diskin anlık görüntüsünü oluşturma bölümünde açıklandığı gibi Sanal Makineler 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

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 tekliflerinin iyi bir başlangıç noktası olup olmadığını belirleme

IBM 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ş ortaklığı kurdu. Teklif listesi için bkz . Microsoft Azure'da WebSphere ürün ailesini ve Liberty'yi çalıştırma ve ardından mevcut dağıtımınızla en yakın eşleşen ürünü seçme. Teklif listesini, IBM WebSphere ürün ailesini Azure'da çalıştırmaya yönelik çözümler nelerdir? 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. Öğretici: Azure Sanal Makineler'de geleneksel olarak IBM WebSphere Application Server Ağ Dağıtımı'nı el ile yükleme makalesinde adım adım yönergeleri bulabilirsiniz. Daha fazla bilgi için bkz. IaaS nedir?

WAS geleneksel sürümünün uyumlu olup olmadığını belirleme

Mevcut WAS geleneksel sürümünüz, IaaS tekliflerindeki sürümle uyumlu olmalıdır. Sürüm bilgilerini Azure VM'de IBM WebSphere Application Server Tek Örneği ve Azure VM'lerinde IBM WebSphere Application Server Kümesi'nin genel bakış sayfasında bulabilirsiniz. Mevcut WAS geleneksel 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 için bkz. IaaS nedir?

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

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>

Daha fazla bilgi için bkz. SSL'de IBM belgesi Sertifika yönetimi

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

Azure Sanal Makineler'da WAS 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.

IBM Java 8, WAS9 dağıtımıyla birlikte gelir. IBM tarafından sağlanan Java JRE'yi kullanmanızı öneririz. Daha fazla bilgi için bkz . WebSphere Application Server geleneksel V9'da Java SE 8.

Farklı bir Java SDK'sına geçmek istiyorsanız Ibm'in WebSphere Uygulama Sunucusu'nda Java SDK'sını değiştirme belgesini izleyin.

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.

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 daha fazla XML dosyasına başvurular içerir. IBM normalde WAS'nin yönetilebilir nesnelerini ve hizmetlerini yapılandırmak için IBM Konsolu'nu kullanmanız ve WAS'nin profiller/profil-adı klasörünü korumasına izin vermenizi önerir. 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.

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ı için, oturum yönetimi düzeyine göre, oturum verilerini toplamak için belleğ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, oturum verilerini bellekten belleğe çoğaltmada veya veritabanında yönetebilirsiniz.
  • 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.

Bu seçeneklerin tümü için, HTTP Oturum Durumu Çoğaltması'nın nasıl yapıldığını öğrenmek iyi bir fikirdir. Daha fazla bilgi için IBM belgelerindeki oturum çekirdeklerini Yönetici kaydetme bölümüne 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?

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.

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.

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

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.

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.

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.

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.

Ü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

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ç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 Azure'da bu ağ topolojisini 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 başka kaynak bağdaştırıcıları kullanıyorsa, bu yapıtların yapılandırmasını Azure Sanal Makineler'de çalışan WAS'ye uyguladığınızdan emin olun. Daha fazla bilgi için IBM belgelerindeki İlişkisel kaynak bağdaştırıcıları ve JCA'ya 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 OpenID kullanıyorsanız, OpenID connect kimlik doğrulamasını Microsoft Entra ID ile yapılandırabilirsiniz. Daha fazla bilgi için bkz. Microsoft Entra Id ile OpenID Bağlan kimlik doğrulaması.

WAS kümelemenin kullanılıp kullanılmadığını belirleme

Büyük olasılıkla, yüksek kullanılabilirlik elde etmek için uygulamanızı birden çok WAS sunucusuna dağıtmışsınızdır. Bu kümeleri doğrudan şirket içi yüklemenizden Azure Sanal Makineler'de çalışan WAS'ye geçirebilirsiniz. Daha fazla bilgi için IBM belgelerindeki WebSphere Application Server Ağ Dağıtımı'na bakın.

Yük dengeleme gereksinimleri için hesap

Yük dengeleme, WAS kümenizi Azure'a geçirmenin önemli bir parçasıdır. En kolay çözüm, IBM WebSphere Application Server Kümesi için Azure Market teklifinde sağlanan Azure Uygulaması Lication Gateway veya IBM HTTP Server için yerleşik desteği kullanmaktır.

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

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'da geleneksel WAS Sanal Makineler teklifi seçme

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

Bir teklifin dağıtımı sırasında WAS 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 . Cloud Services için boyutlar (klasik).

Teklifi sağlama

Başlangıç olarak hangi teklifi seçtikten sonra, Azure Sanal Makineler'de WebSphere Uygulama Sunucusu (geleneksel) Kümesini Dağıtma başlığındaki yönergeleri izleyerek teklifi sağlayın.

Profilleri geçirme

Teklifi sağladıktan sonra profil yapılandırmasını inceleyebilirsiniz. Daha fazla bilgi için IBM belgelerindeki Profil kavramları bölümüne bakın.

Veritabanlarını bağlama

Profilleri geçirdikten sonra, IBM belgelerindeki WebSphere Application Server veri kaynağını yapılandırma başlığındaki yönergeleri izleyerek veritabanlarını bağlayabilirsiniz.

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 IBM belgelerindeki SSL için Keystore yapılandırmaları bölümüne bakın.

JMS kaynaklarını bağlama

Veritabanlarını bağladıktan sonra, IBM belgelerindeki IBM WebSphere Application Server'da JMS'yi ayarlama yönergelerini izleyerek JMS'yi yapılandırabilirsiniz.

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 OpenID kullanıyorsanız, OpenID connect kimlik doğrulamasını Microsoft Entra ID ile yapılandırabilirsiniz. Daha fazla bilgi için bkz. Microsoft Entra Id ile OpenID Bağlan kimlik doğrulaması.

Günlüğe kaydetme

IBM belgelerindeki Elastic Stack ile WebSphere Uygulama Sunucusu günlüklerini analiz etme başlığı altında yer alan yönergeleri izleyerek Elastic Stack'i yapılandırabilirsiniz. Azure, Elastik için destek sağlar. Daha fazla bilgi için bkz. Azure ile elastik tümleştirme nedir? VM'lerde WAS için Azure için iyileştirilmiş günlük çözümü elde etmek için bu iki kaynaktaki bilgileri birleştirebilirsiniz.

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 WebSphere Uygulama Sunucusuna 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. WAS geleneksel 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

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