Tomcat uygulamalarını Azure App Service üzerinde Tomcat'e geçirme

  • Makale

Bu kılavuzda mevcut Tomcat uygulamasını, Tomcat 9.0 kullanarak Azure App Service üzerinde çalışacak şekilde geçirmek istediğinizde nelerin farkında olmanız gerektiği açıklanı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.

Bu geçiş öncesi gereksinimlerin hiçbirini karşılayamazsanız aşağıdaki yardımcı geçiş kılavuzlarını inceleyin:

Desteklenen platforma geçme

App Service, belirli Java sürümleri üzerinde belirli Tomcat sürümlerini sunar. Uyumluluğu sağlamak için, kalan adımlardan herhangi birine devam etmeden önce uygulamanızı geçerli ortamında desteklenen Tomcat ve Java sürümlerinden birine geçirin. Sonuçta elde edilen yapılandırmayı tümüyle test edin. Bu tür testlerde Linux dağıtımınızın en son kararlı sürümünü kullanın.

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

Azure Uygulaması Service'te Java 8 ikili dosyaları Eclipse Temurin'den sağlanır. Java 11, 17 ve Java'nın gelecekteki tüm LTS sürümleri için App Service, OpenJDK'nin Microsoft Derlemesini sağlar. Bu ikili dosyalar aşağıdaki sitelerden ücretsiz olarak indirilebilir:

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

${CATALINA_HOME}/bin/version.sh

Azure App Service tarafından kullanılan güncel sürümü almak için Azure App Service’te kullanmayı planladığınız Tomcat 9 sürümünü indirin.

Dış kaynakların envanterini çıkarma

Veri kaynakları ve JMS ileti aracıları gibi dış kaynaklar Java Adlandırma ve Dizin Arabirimi (JNDI) aracılığıyla eklenir. Bunlara benzer kaynakların geçirilmesi veya yeniden yapılandırılması gerekebilir.

Uygulamanızın içinde

META-INF/context.xml dosyasını inceleyin. <Context> öğesi içindeki <Resource> öğelerini arayın.

Uygulama sunucularında

$CATALINA_BASE/conf/context.xml ve $CATALINA_BASE/conf/server.xml dosyalarının yanı sıra $CATALINA_BASE/conf/[engine-name]/[host-name] dizinlerinde bulunan .xml dosyalarını da inceleyin.

context.xml dosyalarında JNDI kaynakları, üst düzey <Context> öğesindeki <Resource> öğesi tarafından açıklanır.

server.xml dosyalarında JNDI kaynakları, üst düzey <GlobalNamingResources> öğesindeki <Resource> öğesi tarafından açıklanır.

Veri kaynakları

Veri kaynakları, type özniteliği javax.sql.DataSource olarak ayarlanmış JNDI kaynaklarıdır. Aşağıdaki bilgileri her veri kaynağı için belgeleyin:

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

Ek veri kaynağı yönergeleri için Tomcat belgelerindeki JNDI Veri Kaynağı, Nasıl Yapılır? sayfasına göz atın.

Diğer tüm dış kaynaklar

Bu kılavuzda olası tüm dış bağımlılıkları belgelemek uygulanabilir bir yöntem değildir. Geçişten sonra uygulamanızın tüm dış bağımlılıklarının karşılandığını doğrulamak ekibinizin sorumluluğundadır.

Gizli dizilerin envanterini çıkarma

Parolalar ve güveli dizeler

Üretim sunucularındaki tüm özellikleri ve yapılandırma dosyalarını gizli dizeler ve parolalar için denetleyin. $CATALINA_BASE/conf altındaki server.xml ve context.xml dosyalarını denetlediğinizden emin olun. Ayrıca uygulamanızın içinde parolalar ve kimlik bilgileri içeren yapılandırma dosyaları da bulabilirsiniz. Bunlar META-INF/context.xml dosyası ve Spring Boot uygulamaları için application.properties ile application.yml dosyaları olabilir.

Sertifikaların envanterini çıkarma

Genel SSL uç noktaları için veya arka uç veritabanları ve diğer sistemlerle iletişim 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>

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

Uygulama sunucusundaki dosya sisteminin her kullanımı yeniden yapılandırma veya nadir durumlarda mimari değişiklikleri gerektirir. Aşağıdaki senaryolardan birini veya tümünü belirleyebilirsiniz.

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 Depolamayı App Service dosya sistemine bağlayabilirsiniz. Daha fazla bilgi için bkz. Linux üzerinde App Service'te Azure Depolama'dan içerik sunma.

Oturum kalıcılığı mekanizmasını tanımlama

Kullanımdaki oturum kalıcılığı yöneticisi tanımlamak için, uygulamanızdaki ve Tomcat yapılandırmasındaki context.xml dosyalarını inceleyin. <Manager> öğelerini bulun ve className özniteliğinin değerini not alın.

Tomcat'in yerleşik PersistentManager uygulamaları (örneğin StandardManager veya FileStore) App Service gibi dağıtılmış, ölçeklendirilmiş bir platformda kullanım için tasarlanmamıştır. App Service birkaç örnek arasında yük dengelemesi yapabildiği ve herhangi bir örneği herhangi bir anda saydam olarak yeniden başlatabildiği için dosya sisteminde değişebilir durumun kalıcı hale getirilmesi önerilmez.

Oturum kalıcılığı gerekiyorsa, Redis Cache ile VMware Tanzu Oturum Yöneticisi gibi bir dış veri deposuna yazacak alternatif PersistentManager bir uygulama kullanmanız gerekir. Daha fazla bilgi için bkz. Tomcat’le Redis’i oturum önbelleği olarak kullanma.

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

Özel durumlar

Bazı üretim senaryolarında ek değişiklikler gerektirebilir veya ek sınırlamalar uygulanabilir. Bu tür senaryolar seyrek olsa da, uygulamanıza uygulanamaz veya doğru çözümlendiklerinden emin olmak önemlidir.

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

Quartz Scheduler görevleri veya cron işleri gibi zamanlanan işler App Service ile kullanılamaz. App Service, zamanlanmış görevleri 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.

Uygulama sunucusunun içindeki veya dışındaki tüm zamanlanan işlerin envanterini çıkarın.

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.

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

Azure App Service'te Tomcat kümelemesi desteklenmez. Bunun yerine Azure App Service'te ölçeklendirmeyi ve yük dengelemeyi Tomcat'e özgü işlevler olmadan yapılandırabilir ve yönetebilirsiniz. Oturum durumunu çoğaltmalar arasında kullanılabilir hale getirmek için alternatif bir konumda kalıcı hale getirebilirsiniz. Daha fazla bilgi için bkz. Oturum kalıcılığı mekanizmasını tanımlama.

Uygulamanızın kümeleme kullanıp kullanmadığını saptamak için server.xml dosyasındaki <Host> veya <Engine> öğelerinin içinde <Cluster> öğesini arayın.

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

App Service yalnızca tek bir HTTP bağlayıcısını destekler. Uygulamanız AJP Bağlayıcısı gibi ek bağlayıcılar gerektiriyorsa App Service'i kullanmayın.

Uygulamanız tarafından kullanılan HTTP bağlayıcılarını belirlemek için Tomcat yapılandırmanızın server.xml dosyası içinde <Connector> öğesi olup olmadığına bakın.

MemoryRealm’ın kullanılıp kullanılmadığını saptama

MemoryRealm kalıcı bir XML dosyası gerektirir. Azure Uygulaması Service'te bu dosyayı /home dizinine veya alt dizinlerinden birine ya da bağlı depolama alanına yüklemeniz gerekir. Ardından parametresini pathName buna göre değiştirmeniz gerekir.

MemoryRealm sınıfının şu anda kullanılıp kullanılmadığını saptamak için server.xml ile context.xml dosyalarınızı inceleyin ve className özniteliğinin org.apache.catalina.realm.MemoryRealm olarak ayarlandığı <Realm> öğelerini arayın.

SSL oturum izlemesinin kullanılıp kullanılmayacağını saptama

App Service, Oturum boşaltma işlemini Tomcat çalışma zamanının dışında gerçekleştirir, bu nedenle SSL oturumu izlemeyi kullanamazsınız. Bunun yerine farklı bir oturum izleme modu (COOKIE veya URL) kullanın. SSL oturum izleme özelliğine ihtiyacınız varsa App Service'i kullanmayın.

AccessLogValve sınıfının kullanılıp kullanılmadığını saptama

AccessLogValve kullanıyorsanız, parametresini directory/home/LogFiles veya alt dizinlerinden birini ayarlamanız gerekir.

Geçiş

Yapılandırmayı parametreleştirme

Geçiş öncesi adımlarda büyük olasılıkla server.xml ve context.xml dosyalarında veri kaynakları gibi bazı gizli dizileri ve dış bağımlılıkları tanımlamışsınızdır. Tanımladığınız her öğe için herhangi bir kullanıcı adını, parolayı, bağlantı dizesi veya URL'yi bir ortam değişkeniyle değiştirin.

Örneğin context.xml dosyasının aşağıdaki öğeyi içerdiğini düşünün:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

Bu durumda aşağıdaki örnekte gösterildiği gibi değiştirebilirsiniz:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Parametre değiştirme işleminin dağıtılan bir .war dosyasının içindeki META-INF klasöründeki herhangi bir context.xml dosyasında gerçekleştiğinden emin olmak için, aşağıdaki örnekte gösterildiği gibi ortam değişkenini ayarladığınızdan CATALINA_OPTS emin olun:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

App Service planını sağlama

App Service fiyatlandırması sayfasındaki kullanılabilir hizmet planları listesinde, belirtimleri geçerli üretim donanımını karşılayan veya onu aşan planı seçin.

Dekont

Hazırlama/kanarya dağıtımları çalıştırmayı veya dağıtım yuvaları kullanmayı planlıyorsanız, App Service planı bu ek kapasiteyi içermelidir. Java uygulamaları için Premium veya daha yüksek planlar kullanmanızı öneririz. Daha fazla bilgi için bkz. Azure App Service’te hazırlık ortamları ayarlama.

Ardından App Service planını oluşturun. Daha fazla bilgi için bkz. Azure'da App Service planı yönetme.

Web Uygulamalarını oluşturma ve dağıtma

Tomcat sunucunuza dağıtılan her yürütülebilir WAR dosyası için App Service planınızda bir Web Uygulaması oluşturmalısınız (çalışma zamanı yığını olarak Tomcat sürümünü seçerek).

Dekont

Tek bir web uygulamasına birden fazla WAR dosyası dağıtmak mümkündür ancak kesinlikle önerilmez. Tek bir web uygulamasına birden fazla WAR dosyasının dağıtılması, uygulamaların kendi kullanım taleplerine göre ölçeklendirilmesini önler. Ayrıca bağlı dağıtım işlem hatlarını daha karmaşık hale getirir. Tek bir URL'de birden fazla uygulamanın kullanılabilir olması gerekiyorsa Azure Application Gateway gibi bir yönlendirme çözümü kullanabilirsiniz.

Maven uygulamaları

Uygulamanız bir Maven POM dosyasından derleniyorsa, Web Uygulamasını oluşturmak ve uygulamanızı dağıtmak için Maven için Webapp eklentisini kullanın.

Maven dışı uygulamalar

Maven eklentisini kullanmıyorsanız, Web Uygulamasını aşağıdakiler gibi başka mekanizmalar kullanarak sağlamalısınız:

Web Uygulaması oluşturulduktan sonra, kullanılabilir dağıtım mekanizmalarından birini kullanarak uygulamanızı dağıtın.

JVM çalışma zamanı seçeneklerini geçirme

Uygulamanıza belirli çalışma zamanı seçenekleri gerekiyorsa, en uygun mekanizmayı kullanarak bunları belirtin.

Gizli dizileri doldurma

Uygulamanıza özgü gizli dizileri depolamak için Uygulama Ayarları sayfasını kullanın. Aynı gizli dizileri farklı uygulamalarda kullanmayı planlıyorsanız veya ayrıntılı ilkelere ve denetim özelliklerine ihtiyacınız varsa Azure Key Vault'u kullanın.

Özel etki alanını ve SSL’yi yapılandırma

Uygulamanız özel bir etki alanında görünür olacaksa web uygulamanızı bu etki alanına eşlemeniz gerekir. Daha fazla bilgi için bkz. Öğretici: Mevcut özel DNS adını Azure Uygulaması Hizmeti ile eşleme.

Ardından söz konusu etki alanı için SSL sertifikasını App Service Web Uygulamanıza bağlamalısınız. Daha fazla bilgi için bkz. Azure App Service'de SSL bağlamasıyla özel DNS adının güvenliğini sağlama.

Arka uç sertifikalarını dışarı aktarma

Arka uç sistemleriyle, örneğin veritabanlarıyla iletişim kurmaya yönelik tüm sertifikalar App Service’in kullanımına sunulmalıdır. Daha fazla bilgi için bkz. App Service’te SSL sertifikası ekleme.

Veri kaynaklarını, kitaplıkları ve JNDI kaynaklarını geçirme

Veri kaynağı yapılandırma adımları için Azure App Service için Linux Java uygulaması yapılandırma sayfasındaki Veri kaynakları bölümüne göz atın.

Ek veri kaynağı yönergeleri için Tomcat belgelerindeki JNDI Veri Kaynağı, Nasıl Yapılır? sayfasının şu bölümlerine göz atın:

Sunucu düzeyindeki sınıf yolu bağımlılıklarını geçirmek için kaynak JAR dosyalarıyla aynı adımları uygulayın.

Ek sunucu düzeyindeki paylaşılan JDNI kaynaklarını geçirin.

Dekont

Web uygulamasına başına tek bir WAR kullanılan önerilen mimariyi uyguluyorsanız sunucu düzeyindeki sınıf yolu kitaplıklarını ve JNDI kaynaklarını uygulamanıza geçirebilirsiniz. Bu durum, bileşen idaresi ve değişiklik yönetimi süreçlerini önemli ölçüde kolaylaştıracaktır.

Yapılandırmanın kalan kısmını geçirme

Yukarıdaki bölümü tamamladıktan sonra özelleştirilebilir sunucu yapılandırmanızın /home/tomcat/conf dizininde bulunması gerekir.

Geçişi tamamlamak için ek yapılandırma öğelerini (bölgeler ve JASPIC gibi) kopyalayın

Zamanlanan işleri geçirme

Azure’da zamanlanan işleri yürütmek için Azure İşlevleri için zamanlayıcı tetikleyicisi kullanmayı düşünün. İş kodunun kendisini işleve geçirmeniz gerekmez. Bu işlev, uygulamanızda bir URL çağırarak işi tetikleyebilir. Buna benzer iş yürütmeleri dinamik olarak çağrılıyor ve/veya merkezi olarak izleniyorsa Spring Batch kullanmayı göz önünde bulundurun.

Alternatif olarak uygulamanız dışında kod yazmadan URL’yi çağırmak için Yineleme tetikleyicisiyle bir Mantıksal uygulama oluşturabilirsiniz. Daha fazla bilgi için bkz. Genel Bakış - Azure Logic Apps Nedir? ve Azure Logic Apps’de Yineleme tetikleyicisiyle yinelenen görevler ve iş akışları oluşturma, zamanlama ve çalıştırma.

Dekont

Kötü amaçlı kullanımı önlemek için iş çağrı uç noktasının kimlik bilgileri gerektirdiğinden emin olmanız gerekir. Bu durumda tetikleme işlevinin kimlik bilgilerini sağlaması gerekir.

Yeniden başlatma ve duman testi

Son olarak tüm yapılandırma değişikliklerini uygulamak için Web Uygulamanızı yeniden başlatmalısınız. Yeniden başlatma tamamlandıktan sonra uygulamanızın doğru çalıştığından emin olun.

Geçiş sonrası

Artık uygulamanızın Azure App Service’e geçirdiğinize göre beklediğiniz gibi çalıştığını doğrulamalısınız. Bunu yaptıktan sonra uygulamanızı daha bulutta yerel hale getirmenizi sağlayabilecek bazı önerilerimiz var.

Öneriler