Personnaliser le plan de migration pour les serveurs Tomcat

Vous devez examiner le fichier de plan de migration résultant de la création d'une migration. Personnalisez le fichier avant d'exécuter la migration. Les détails de votre plan de migration sont utilisés pour extraire les artefacts de conteneur de charge de travail de la source.

Cette section décrit le contenu de la migration et les types de personnalisations que vous pouvez envisager avant d'exécuter la migration et de générer des artefacts de déploiement.

Avant de commencer

Cet article suppose que vous avez déjà créé une migration et que vous disposez du fichier de plan de migration.

Modifier le plan de migration

Une fois le système de fichiers copié et analysé, vous trouverez le plan de migration dans le nouveau répertoire qui est créé dans le chemin de sortie spécifié : ANALYSIS_OUTPUT_PATH/config.yaml.

Modifiez le plan de migration si nécessaire et enregistrez les modifications.

Passez en revue les détails de votre plan de migration et les commentaires d'orientation, et ajoutez des informations si nécessaire. Vous pouvez plus précisément envisager des modifications telles qu'elles sont décrites dans les sections suivantes.

Spécifier l'image Docker

Dans le plan de migration, nous générons un tag d'image de la communauté Docker basé sur la version Tomcat, la version Java et le fournisseur Java.

  • Version Tomcat : la version Tomcat est détectée et convertie en version majeure (les versions mineures ne sont pas compatibles). Si nous ne parvenons pas à détecter une version Tomcat, le fichier baseImage.name contient une chaîne vide.
  • Version Java : la version de Java dépend du paramètre java-version. Il est défini par défaut sur 11.
  • Fournisseur Java : le fournisseur Java est défini sur une constante : temurin.

Par exemple, le tag d'image de la communauté Docker généré pour Tomcat version 9.0, Java version 11 et le fournisseur Java temurin est tomcat:9.0-jre11-temurin.

Sur le plan de migration, le champ baseImage.name représente le tag d'image Docker utilisé comme base de l'image du conteneur.

Les versions d'origine Tomcat et Java détectées sur la VM source sont contenues dans le fichier discovery-report.yaml, généré par la découverte initiale.

Si vous souhaitez modifier l'image de la communauté Docker ou fournir votre propre image Docker, vous pouvez modifier le tag baseImage.name dans votre plan de migration au format suivant :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          baseImage:
            name: BASE_IMAGE_NAME

Remplacez BASE_IMAGE_NAME par l'image Docker que vous souhaitez utiliser comme base de l'image du conteneur.

Mettre à jour le chemin d'installation Tomcat

Au cours du processus de migration, si votre image cible comporte un chemin d'accès CATALINA_HOME autre que celui par défaut, vous pouvez spécifier un chemin d'accès CATALINA_HOME personnalisé. Modifiez le champ catalinaHome cible directement dans votre plan de migration :

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        baseImage:
          name: BASE_IMAGE_NAME
          catalinaHome: PATH

Remplacez PATH par le chemin d'installation Tomcat.

Personnaliser l'utilisateur et le groupe

Au cours du processus de migration, si votre image cible s'exécute avec un utilisateur et un groupe différents de root:root, vous pouvez spécifier un utilisateur et un groupe personnalisés sous lesquels vous souhaitez exécuter l'application. Modifiez l'utilisateur et le groupe directement dans votre plan de migration :

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        userName: USERNAME
        groupName: GROUP_NAME

Remplacez les éléments suivants :

  • USERNAME : nom d'utilisateur que vous souhaitez utiliser
  • GROUP_NAME : nom du groupe que vous souhaitez utiliser

Configurer SSL

Lorsque vous créez une migration Tomcat, un processus de découverte analyse le serveur par rapport aux différentes applications détectées.

Après la découverte, les champs suivants sont automatiquement renseignés dans le plan de migration :

  • excludeFiles : répertorie les fichiers et répertoires à exclure de la migration.

    Par défaut, tous les chemins et certificats sensibles situés lors de la découverte sont automatiquement ajoutés à ce champ et sont exclus de la migration. Si vous supprimez un chemin d'accès à partir de cette liste, le fichier ou le répertoire est importé dans l'image de conteneur. Pour exclure un fichier ou un répertoire de l'image du conteneur, ajoutez le chemin d'accès à cette liste.

  • sensitiveDataPaths : répertorie tous les chemins d'accès et certificats sensibles situés par le processus de découverte.

    Pour importer les certificats dans le dépôt, définissez le champ includeSensitiveData sur true :

    # Sensitive data which will be filtered out of the container image.
# If includeSensitiveData is set to true the sensitive data will be mounted on the container.

includeSensitiveData: true
tomcatServers:
- name: latest
  catalinaBase: /opt/tomcat/latest
  catalinaHome: /opt/tomcat/latest
  # Exclude files from migration.
  excludeFiles:
  - /usr/local/ssl/server.pem
  - /usr/home/tomcat/keystore
  - /usr/home/tomcat/truststore
  images:
  - name: tomcat-latest
    ...
    # If set to true, sensitive data specified in sensitiveDataPaths will be uploaded to the artifacts repository.
    sensitiveDataPaths:
    - /usr/local/ssl/server.pem
    - /usr/home/tomcat/keystore
    - /usr/home/tomcat/truststore

    Une fois la migration terminée, les secrets sont ajoutés au fichier de secrets secrets.yaml dans le dépôt d'artefacts.

Journalisation des applications Web

Migrate to Containers accepte la journalisation avec log4j v2, logback et log4j v1.x qui résident dans CATALINA_HOME.

Migrate to Containers crée un fichier d'archive supplémentaire avec des configurations de journal modifiées et convertit tous les avenants de type de fichier en appenders de console. Vous pouvez utiliser le contenu de cette archive comme référence pour activer la collecte de journaux et la diffusion vers une solution de collecte de journaux (telle que Google Cloud Logging).

Allocation de mémoire

Au cours du processus de migration, vous pouvez spécifier les limites de mémoire des applications migrées vers des conteneurs individuels. Modifiez les limites de mémoire directement dans votre plan de migration au format suivant :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limit: 2048M
              requests: 1280M

La valeur recommandée pour limit est de 200 % de Xmx, qui est la taille maximale du tas de mémoire Java. La valeur recommandée pour requests est de 150 % de Xmx.

Pour afficher la valeur de Xmx, exécutez la commande suivante :

ps aux | grep catalina

Si des limites de mémoire ont été définies dans votre plan de migration, le fichier Dockerfile généré avec d'autres artefacts après une migration réussie reflète votre déclaration :

FROM tomcat:8.5-jdk11-openjdk

# Add JVM environment variables for tomcat
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50.0 -XX:InitialRAMPercentage=50.0 -XX:+UseContainerSupport <additional variables>"

Ce fichier définit la taille initiale et la taille maximale à 50 % de la valeur limite. La taille d'allocation de segments de mémoire Java Tomcat peut ainsi évoluer en fonction de modifications qui seraient apportées à la limite de mémoire du pod.

Définir des variables d'environnement Tomcat

Si vous souhaitez définir CATALINA_OPTS dans votre fichier Dockerfile généré avec d'autres artefacts après une migration réussie, vous pouvez d'abord ajouter le champ catalinaOpts à votre plan de migration : L'exemple suivant montre un champ catalinaOpts mis à jour :

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xss10M"

Migrate to Containers analyse vos données catalinaOpts vers votre fichier Dockerfile. L'exemple suivant montre le résultat de l'analyse :

FROM 8.5-jdk11-openjdk-slim

## setenv.sh script detected.
## Modify env variables on the script and add definitions to the migrated
## tomcat server, if needed (less recommended than adding env variables directly
## to CATALINA_OPTS) by uncomment the line below
#ADD --chown=root:root setenv.sh /usr/local/tomcat/bin/setenv.sh

# Add JVM environment variables for the tomcat server
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50.0 -XX:InitialRAMPercentage=50.0 -Xss10M"

Vous pouvez également définir des variables d'environnement Tomcat à l'aide du script setenv.sh (situé dans le dossier /bin de votre serveur Tomcat). Pour en savoir plus sur les variables d'environnement Tomcat, consultez la documentation Tomcat.

Si vous choisissez d'utiliser setenv.sh pour définir vos variables d'environnement Tomcat, vous devez modifier le fichier Dockerfile.

Définir des vérifications d'état Tomcat

Vous pouvez surveiller l'état d'arrêt et l'état de préparation de vos conteneurs gérés en spécifiant des vérifications dans le plan de migration de votre serveur Web Tomcat. La surveillance de l'état peut réduire les temps d'arrêt des conteneurs migrés et améliorer la surveillance.

Des états de santé inconnus peuvent entraîner une dégradation des disponibilités, une surveillance des disponibilités suggérant un faux positif et une perte potentielle de données. Sans vérification d'état, kubelet ne peut supposer que l'état d'un conteneur et peut envoyer du trafic vers une instance de conteneur qui n'est pas prête. Cela peut entraîner une perte de trafic. Kubelet peut également ne pas détecter les conteneurs dans un état figé et ne les redémarre pas.

Une vérification de l'état fonctionne en exécutant une petite instruction scriptée au démarrage du conteneur. Le script recherche les conditions de réussite, qui sont définies par le type de vérification utilisé, à chaque période. La période est définie dans le plan de migration par un champ periodSeconds. Vous pouvez exécuter ou définir ces scripts manuellement.

Pour en savoir plus sur les vérifications de kubelet, consultez la section Configurer des vérifications d'activité, d'aptitude et de démarrage dans la documentation de Kubernetes.

Vous pouvez configurer deux types de vérifications. Les deux vérifications sont définies par probe-v1-core dans la documentation de référence de probe-v1-core et partagent la même fonction que les champs correspondants de container-v1-core.

  • Vérification d'activité : les vérifications d'activité permettent de savoir quand redémarrer un conteneur.

  • Vérification d'aptitude : les vérifications d'aptitude permettent de savoir quand un conteneur est prêt à accepter du trafic. Pour commencer à envoyer du trafic à un pod uniquement lorsqu'une vérification réussit, spécifiez une vérification d'aptitude. Une vérification d'aptitude peut agir de la même manière qu'une vérification d'activité, mais une vérification d'aptitude indiquée dans les spécifications indique qu'un pod démarre sans recevoir de trafic et ne commence à recevoir du trafic qu'une fois la vérification réussie.

Une fois la détection effectuée, la configuration de la vérification est ajoutée au plan de migration. Les vérifications peuvent être utilisées dans leur configuration par défaut, comme indiqué dans l'exemple suivant. Pour désactiver les vérifications, supprimez la section probes du fichier YAML.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
        tcpSocket:
          port: 8080
      readinessProbe:
        tcpSocket:
          port: 8080

Vous pouvez modifier ce plan de migration pour utiliser un point de terminaison HTTP Tomcat existant.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
       httpGet:
          path: /healthz
          port: 8080
          httpHeaders:
          - name: Custom-Header
            value: Awesome
        initialDelaySeconds: 3
        periodSeconds: 3
      readinessProbe:
        httpGet:
        tcpSocket:
          port: 8080

Il existe quatre méthodes prédéfinies pour vérifier un conteneur à l'aide d'une vérification. Chaque vérification doit définir exactement l'un de ces quatre mécanismes :

  • exec : exécute une commande spécifiée dans le conteneur. L'exécution est considérée comme réussie si le code d'état de sortie est 0.
  • grpc : effectue un appel de procédure à distance à l'aide de gRPC. Les vérifications gRPC sont une fonctionnalité alpha.
  • httpGet : exécute une requête HTTP GET sur l'adresse IP du pod sur un port et un chemin d'accès spécifiés. La requête est considérée comme réussie si le code d'état est supérieur ou égal à 200 et inférieur à 400.
  • tcpSocket : effectue une vérification TCP sur l'adresse IP du pod sur un port spécifié. Le diagnostic est considéré comme réussi si le port est ouvert.

Par défaut, un plan de migration active la méthode de vérification tcpSocket. Utilisez la configuration manuelle de votre plan de migration pour utiliser différentes méthodes de vérification. Vous pouvez également définir des commandes et des scripts personnalisés via le plan de migration.

Pour ajouter des dépendances externes pour la vérification d'aptitude tout en utilisant la vérification d'activité par défaut, définissez une vérification d'aptitude d'exécution et un script qui met en œuvre la logique.

Vérifier la configuration du clustering Tomcat

Le clustering Tomcat est utilisé pour répliquer les informations de session sur tous les nœuds Tomcat, ce qui vous permet d'appeler n'importe quel serveur d'applications backend sans perdre les informations de session client. Pour en savoir plus sur la configuration du clustering, consultez le guide d'utilisation du clustering/de la réplication de session dans la documentation Tomcat.

La classe de clustering de Tomcat est appelée SimpleTcpListener. Elle utilise des messages de pulsation de multidiffusion pour la découverte de pairs. Les environnements cloud ne sont pas compatibles avec la multidiffusion. Vous devez donc modifier la configuration du clustering ou la supprimer, lorsque cela est possible.

Lorsqu'un équilibreur de charge est configuré pour s'exécuter et conserver une session persistante sur le serveur backend Tomcat, il peut utiliser la propriété jvmRoute configurée dans la configuration Engine server.xml.

Si votre environnement source utilise une configuration de clustering non compatible, modifiez le fichier server.xml pour désactiver la configuration ou utiliser une configuration compatible.

  • Tomcat v8.5 ou version ultérieure : le clustering doit être désactivé sur Tomcat version 8.5. Pour désactiver le clustering, vous devez commenter la section <Cluster … /> dans server.xml.

  • Tomcat v9 ou version ultérieure : dans Tomcat version 9 ou ultérieure, vous pouvez activer la classe Cluster à l'aide de KubernetesMembershipService. KubernetesMembershipService est une classe spécifique à Kubernetes qui utilise les API Kubernetes pour la découverte de pairs.

    • Fournisseur Kubernetes : voici un exemple de configuration pour un fournisseur Kubernetes :

      <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider"/>
</Channel>
</Cluster>

    • Fournisseur DNS : utilisez DNSMembershipProvider pour utiliser les API DNS pour la découverte de pairs. Voici un exemple de configuration pour un fournisseur DNS :

      <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.DNSMembershipProvider"/>
</Channel>
</Cluster>

    • jvmRoute : lorsque votre équilibreur de charge repose sur une valeur jvmRoute, la valeur statique doit être remplacée par l'utilisation du nom du pod. Cela configure Tomcat pour ajouter un suffixe au cookie de session avec le nom du POD. L'équilibreur de charge frontal peut utiliser ce code pour diriger le trafic vers le pod Tomcat approprié. Modifiez la valeur du fichier server.xml pour utiliser ce qui suit :

      <Engine name="Catalina" defaultHost="localhost" jvmRoute="${HOSTNAME}">

Vérifier la configuration du proxy Tomcat

Si Tomcat est configuré pour s'exécuter derrière un proxy inverse ou en utilisant plusieurs paramètres de configuration de proxy dans la section Connector du fichier server.xml, vous devez vérifier que les mêmes configurations de proxy sont toujours applicables après la migration pour une exécution dans Kubernetes.

Pour exécuter une application Tomcat en conteneur fonctionnelle, choisissez l'une des modifications de configuration suivante pour la configuration du proxy inverse :

  • Désactiver la configuration du proxy : si l'application migrée ne s'exécute plus derrière un proxy inverse, vous pouvez désactiver la configuration du proxy en supprimant proxyName et proxyPort de la configuration du connecteur.
  • Migrer le proxy : migrez la VM proxy et conservez toutes les configurations Tomcat existantes.

  • Configurer Ingress pour remplacer le proxy inverse : si aucune logique personnalisée ni sophistiquée n'a été mise en œuvre pour votre proxy inverse, vous pouvez configurer une ressource Ingress pour exposer votre application Tomcat migrée. Ce processus utilise le même nom de domaine complet que celui utilisé avant la migration. Pour configurer un objet Ingress, vous devez vérifier que votre service Kubernetes Tomcat est de type: Nodeport. Voici un exemple de configuration d'un objet Ingress :

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-tomcat-ingress
spec:
  rules:
  - host: APP_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-tomcat-service
            port:
              name: my-tomcat-port

  • Configurer un service Anthos Service Mesh avec Cloud Load Balancing : si vous utilisez GKE Enterprise, vous pouvez choisir d'exposer votre application à l'aide d'Anthos Service Mesh. Pour en savoir plus sur l'exposition d'applications de maillage de services, consultez la page De la périphérie au réseau : Exposer les applications de maillage de services via GKE Ingress.

Vérifier la configuration du proxy Java

Lors de la migration vers des conteneurs, vous devez vérifier la disponibilité des serveurs proxy dans votre nouvel environnement. Lorsque le serveur proxy n'est pas disponible, choisissez l'une des modifications de configuration suivantes pour le proxy :

  • Désactiver le proxy : si le proxy d'origine n'est plus utilisé, désactivez la configuration du proxy. Supprimez tous les paramètres de proxy du script setenv.sh ou du fichier de configuration où ils sont gérés sur votre serveur Tomcat.
  • Modifier les paramètres de proxy : si votre environnement Kubernetes utilise un proxy de sortie différent, vous pouvez modifier vos paramètres de proxy dans setenv.sh, ou un autre fichier, pour qu'il pointe vers le nouveau proxy.

Étapes suivantes