Tomcat uygulamalarını Azure Kubernetes Service'te (AKS) kapsayıcılara geçirme

Bu kılavuzda mevcut Tomcat uygulamasını Azure Kubernetes Service’te (AKS) çalıştırmak için 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.

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.

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'da statik web sitesi barındırma ve Hızlı Başlangıç: Azure depolama hesabını Azure CDN ile tümleştirme.

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.

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 (AKS) Azure Dosyalar ile birim oluşturma ve kullanma.

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) Kubernetes gibi dağıtılmış, ölçeklendirilmiş bir platformda kullanım için tasarlanmamıştır. AKS birkaç pod arasında yük dengelemesi yapabilir, herhangi bir podu herhangi bir anda saydam olarak yeniden başlatabilir; 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.

Özel durumlar

Bazı üretim senaryolarında ek değişiklikler gerektirebilir veya ek sınırlamalar uygulanabilir. Bu tür senaryolarla sık karşılaşılmasa da, bunların uygulamanızda uygulanabilir olmadığından veya doğru çözüldüğünden 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 kapsayıcılı hale getirilmiş Tomcat dağıtımlarıyla kullanılamaz. Uygulamanızın ölçeği genişletildiyse, zamanlanan işlerden biri 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 üzerinde çalıştırıldığı işletim sistemini barındıran kod içeriyorsa, bu durumda uygulamanızın temel işletim sistemine dayanmayacak şekilde yeniden düzenlenmesi gerekir. Örneğin dosya sistemi yollarındaki tüm / veya \ kullanımları File.Separator veya Path.get ile değiştirilmelidir.

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

MemoryRealm kalıcı bir XML dosyası gerektirir. Kubernetes’te, bu dosyanın kapsayıcı görüntüsüne eklenmesi veya kapsayıcıların kullanımına sunulan paylaşılan depolamaya yüklenmesi gerekir. pathName parametresi de buna uygun olarak değiştirilmelidir.

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

Kapsayıcılı dağıtımlarda SSL oturumları normalde, genellikle giriş denetleyicisi tarafından uygulama kapsayıcısının dışına yük boşaltır. Uygulamanız için SSL oturum izlemesi gerekiyorsa, SSL trafiğinin doğrudan uygulama kapsayıcısına geçirildiğinden emin olun.

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

AccessLogValve sınıfı kullanıyorsa directory parametresi bağlanan Azure Dosyalar paylaşımına veya onun alt dizinlerinden birine ayarlanmalıdır.

Yerinde test etme

Kapsayıcı görüntülerini oluşturmadan önce uygulamanızı AKS’de kullanmayı planladığınız JDK’ye ve Tomcat’e geçirin. Uyumluluk ve performanstan emin olmak için uygulamanızı kapsamlı olarak test edin.

Yapılandırmayı parametreleştirme

Büyük olasılıkla geçiş öncesinde server.xml ve context.xml dosyalarında gizli dizileri ve veri kaynakları gibi dış bağımlılıkları tanımlamış olmalısınız. Tanımlanan her öğe için kullanıcı adı, parola, bağlantı dizesi veya URL’leri 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}"
/>

Geçiş

İlk adım ("Kapsayıcı kayıt defterini ve AKS’yi sağlama") dışında, geçirmek istediğiniz her uygulama (WAR dosyası) için aşağıdaki adımları ayrı ayrı izlemenizi öneririz.

Kapsayıcı kayıt defterini ve AKS’yi sağlama

Bir kapsayıcı kayıt defteri ve Hizmet Sorumlusunun kayıt defterinde Okuyucu rolüne sahip olduğu bir Azure Kubernetes kümesi oluşturun. 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

Dağıtım yapıtlarını hazırlama

Tomcat On Containers Quickstart GitHub deposunu kopyalayın. Bir dizi önerilen iyileştirmeyle bir Dockerfile ve Tomcat yapılandırma dosyaları içerir. Aşağıdaki adımlarda, kapsayıcı görüntüsünü oluşturup AKS’ye dağıtmadan önce bu dosyalarda yapmanız gerekebilecek değişiklikleri gösterdik.

Gerekirse kümeleme için bağlantı noktalarını açma

AKS üzerinde Tomcat Kümeleme kullanmayı planlıyorsanız, Dockerfile içinde gerekli bağlantı noktası aralıklarının kullanıma sunulduğundan emin olun. Server.xml dosyasında, podun IP adresinde kapsayıcıyı başlatma sırasında başlatılan bir değişkenin değerini kullanmaya dikkat edin.

Alternatif olarak, oturum durumu çoğaltmalar arasında kullanılabilir olacak şekilde alternatif bir konumda kalıcı hale getirilebilir.

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.

JNDI kaynaklarını ekleme

Geçiş öncesi adımlarında hazırladığınız kaynakları (örneğin Veri Kaynaklarını) eklemek üzere server.xml dosyasını düzenleyin.

Örneğin:

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

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:

• MySQL
• PostgreSQL
• SQL Server

Görüntüyü derleme ve gönderme

Görüntüyü derlemenin ve AKS tarafından kullanılmak üzere Azure Container Registry’ye (ACR) yüklemenin en basit yolu az acr build komutunu kullanmaktır. Bu komut için bilgisayarınızda Docker’ın yüklü olması gerekmez. Örneğin geçerli dizinde yukarıdaki Dockerfile ve petclinic.war uygulama paketiniz varsa ACR’de kapsayıcı görüntüsünü tek adımda derleyebilirsiniz:

az acr build \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" \
    --registry $acrName \
    --build-arg APP_FILE=petclinic.war \
    --build-arg=prod.server.xml .

WAR dosyanız ROOT.war olarak adlandırılmışsa --build-arg APP_FILE... parametresini atlayabilirsiniz. Sunucu XML dosyanız server.xml olarak adlandırılmışsa --build-arg SERVER_XML... parametresini atlayabilirsiniz. Her iki dosya da Dockerfile ile aynı dizinde yer almalıdır.

Alternatif olarak, görüntüyü yerel olarak derlemek için Docker CLI’yı da kullanabilirsiniz. Bu yaklaşım ACR’ye ilk dağıtımdan önce görüntünün test edilmesini ve geliştirilmesini basitleştirebilir. Öte yandan Docker CLI’nın yüklenmiş ve Docker daemon’ın çalışıyor olmasını gerektirir.

# Build the image locally
sudo docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally
sudo docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# Your application can now be accessed with a browser at http://localhost:8080.

# Log into ACR
sudo az acr login --name $acrName

# Push the image to ACR
sudo docker push "${acrName}.azurecr.io/petclinic:1"

Daha fazla bilgi için bkz. Azure'da kapsayıcı görüntüleri oluşturma ve depolamaya yönelik Learn modülü.

Genel IP adresini sağlama

Uygulamanız iç veya sanal ağlarınızın dışından erişilebilir olacaksa, bir genel statik IP adresi gerekir. Bu IP adresi, kümenin düğüm kaynak grubu içinde sağlanmalıdır.

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ınızı oluşturma ve uygulama. Dış yük dengeleyici oluşturuyorsanız (uygulamanıza veya giriş denetleyicisine), LoadBalancerIP olarak önceki bölümde sağlanan IP adresini kullandığınızdan emin olun.

Dışsallaştırılmış parametreleri ortam değişkenleri olarak ekleyin. Gizli dizileri (parolalar, API anahtarları ve JDBC bağlantı dizeleri gibi) eklemeyin. Gizli diziler KeyVault FlexVolume sürücüsünü yapılandırma bölümünde açıklanmıştır.

Kalıcı depolamayı yapılandırma

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

Kalıcı Birimi, günlükleri merkezi olarak saklamak amacıyla Tomcat günlükleri dizinine (/tomcat_logs) bağlanmış olan Azure Dosyalar’ı kullanarak oluşturmak isteyebilirsiniz. Daha fazla bilgi için bkz. Azure Kubernetes Service'te (AKS) Azure Dosyalar ile dinamik olarak kalıcı birim oluşturma ve kullanma.

KeyVault FlexVolume’ü yapılandırma

Azure KeyVault oluşturun ve tüm gerekli gizli dizileri doldurun. 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.

Sertifikaları kapsayıcıdaki yerel anahtar deposuna aktarmak için başlatma betiğini (Kapsayıcılar üzerinde Tomcat GitHub deposunda startup.sh) değiştirmeniz gerekir.

Zamanlanan işleri geçirme

AKS kümenizde zamanlanan işleri yürütmek için gereken Cron İşlerini tanımlayın.

Geçiş sonrası

Artık uygulamanızı AKS’ye geçirdiğinize göre beklendiği 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.

• Giriş denetleyicinize veya uygulama yük dengeleyicisine ayrılmış IP adresine DNS adı eklemeniz faydalı olabilir. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) giriş denetleyicisiyle TLS kullanma.

• 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üşünün.

• Kapsayıcı günlüklerini toplama ve izleme kullanımı gibi işlemlere olanak tanımak üzere küme için Azure İzleme’yi etkinleştirin.

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

• İş sürekliliği ve olağanüstü durum kurtarma stratejisini tasarlayın ve uygulayın. Görev açısından kritik uygulamalarda çok bölgeli dağıtım mimarisini düşünün.

• Kubernetes Sürüm Desteği ilkesini gözden geçirin. AKS kümenizi güncelleştimeye devam edip her zaman desteklenen sürümü çalıştırdığından emin olmak sizin sorumluluğunuzdadır.

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

• logging.properties dosyasındaki öğeleri değerlendirin. Performansı geliştirmek için günlük çıkışından bir bölümünü ortadan kaldırmayı veya azaltmayı düşünün.

• Performansı daha da iyileştirmek için kod önbelleği boyutunu izlemeyi ve Dockerfile’da JAVA_OPTS değişkenine -XX:InitialCodeCacheSize ve -XX:ReservedCodeCacheSize parametrelerini eklemeyi düşünün.