Personalize o plano de migração para servidores Tomcat

Deve rever o ficheiro do plano de migração resultante da criação de uma migração. Personalize o ficheiro antes de executar a migração. Os detalhes do seu plano de migração são usados para extrair os artefactos do contentor da carga de trabalho da origem.

Esta secção descreve o conteúdo da migração e os tipos de personalizações que pode considerar antes de executar a migração e gerar artefactos de implementação.

Antes de começar

Este tópico pressupõe que já criou uma migração e tem o ficheiro do plano de migração.

Edite o plano de migração

Depois de copiar o sistema de ficheiros e analisá-lo, pode encontrar o plano de migração no novo diretório criado no caminho de saída especificado: ANALYSIS_OUTPUT_PATH/config.yaml.

Edite o plano de migração conforme necessário e guarde as alterações.

Reveja os detalhes do plano de migração e os comentários orientadores para adicionar informações conforme necessário. Em concreto, considere fazer edições nas seguintes secções.

Especifique a imagem do Docker

No plano de migração, geramos uma etiqueta de imagem da comunidade Docker com base na versão do Tomcat, na versão do Java e no fornecedor do Java.

  • Versão do Tomcat: a versão do Tomcat é detetada e convertida numa versão principal (as versões secundárias não são suportadas). Se não detetarmos uma versão do Tomcat, baseImage.name contém uma string vazia.
  • Versão do Java: a versão do Java depende do parâmetro java-version. Por predefinição, está definido como 11.
  • Fornecedor Java: o fornecedor Java está definido como uma constante: temurin.

Por exemplo, a etiqueta de imagem da comunidade Docker gerada para a versão 9.0 do Tomcat, a versão 11 do Java e o fornecedor Java temurin é tomcat:9.0-jre11-temurin.

No plano de migração, o campo baseImage.name representa a etiqueta da imagem do Docker usada como base da imagem do contentor.

As versões originais do Tomcat e do Java detetadas na VM de origem estão contidas no elemento discovery-report.yaml gerado pela descoberta inicial.

Se quiser alterar a imagem da comunidade Docker ou fornecer a sua própria imagem Docker, pode modificar o baseImage.name no seu plano de migração com o seguinte formato:

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

Substitua BASE_IMAGE_NAME pela imagem do Docker que quer usar como base da imagem do contentor.

Atualize o caminho de instalação do Tomcat

Durante o processo de migração, se a imagem de destino tiver um caminho CATALINA_HOME não predefinido, pode especificar um caminho CATALINA_HOME personalizado. Edite o campo catalinaHomealvo diretamente no plano de migração:

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

Substitua PATH pelo caminho de instalação do Tomcat.

Personalize o utilizador e o grupo

Durante o processo de migração, se a imagem de destino for executada com um utilizador e um grupo diferentes de root:root, pode especificar um utilizador e um grupo personalizados nos quais quer que a aplicação seja executada. Edite o utilizador e o grupo diretamente no seu plano de migração:

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

Substitua o seguinte:

  • USERNAME: o nome de utilizador que quer usar
  • GROUP_NAME: o nome do grupo que quer usar

Configure o SSL

Quando cria uma nova migração do Tomcat, um processo de deteção analisa o servidor em função das diferentes aplicações detetadas.

Após a descoberta, os seguintes campos são preenchidos automaticamente no plano de migração:

  • excludeFiles: lista os ficheiros e os diretórios a excluir da migração.

    Por predefinição, todos os caminhos e certificados confidenciais localizados durante a deteção são adicionados automaticamente a este campo e são excluídos da migração. Se remover um caminho desta lista, o ficheiro ou o diretório é carregado para a imagem do contentor. Para excluir um ficheiro ou um diretório da imagem do contentor, adicione o caminho a esta lista.

  • sensitiveDataPaths: lista todos os caminhos e certificados confidenciais localizados pelo processo de deteção.

    Para carregar os certificados para o repositório, defina o campo includeSensitiveData como 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

    Quando a migração estiver concluída, os segredos são adicionados ao ficheiro de segredos secrets.yaml no repositório de artefactos.

Registo de apps Web

A migração para contentores suporta o registo com log4j v2, logback e log4j v1.x que residem no CATALINA_HOME.

A migração para contentores cria um ficheiro de arquivo adicional com as configurações de registo modificadas e converte todos os anexos de tipo de ficheiro em anexos de consola. Pode usar o conteúdo deste arquivo como referência para ativar a recolha de registos e fazer stream para uma solução de recolha de registos (como o Google Cloud Logging).

Atribuição de memória

Durante o processo de migração, pode especificar os limites de memória das aplicações migradas para contentores individuais. Edite os limites de memória diretamente no seu plano de migração através do seguinte formato:

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

O valor recomendado para limit é 200% de Xmx, que é o tamanho máximo da memória Java. O valor recomendado para requests é 150% de Xmx.

Para ver o valor de Xmx, execute o seguinte comando:

ps aux | grep catalina

Se tiverem sido definidos limites de memória no seu plano de migração, o Dockerfile gerado juntamente com outros artefactos após uma migração bem-sucedida reflete a sua declaração:

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>"

Isto define o tamanho inicial e máximo como 50% do valor limite. Isto permite que o tamanho da alocação de memória Java do Tomcat seja alterado de acordo com qualquer alteração ao limite de memória do pod.

Defina variáveis de ambiente do Tomcat

Se quiser definir CATALINA_OPTS no Dockerfile gerado juntamente com outros artefactos após uma migração bem-sucedida, pode adicioná-lo primeiro ao campo catalinaOpts no seu plano de migração. O exemplo seguinte mostra um campo catalinaOpts atualizado:

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

A ferramenta Migrate to Containers analisa os seus dados do catalinaOpts no seu Dockerfile. O exemplo seguinte mostra o resultado da análise:

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"

Também pode definir variáveis de ambiente do Tomcat através do script setenv.sh, que se encontra na pasta /bin no seu servidor Tomcat. Para mais informações sobre as variáveis de ambiente do Tomcat, consulte a documentação do Tomcat.

Se optar por usar setenv.sh para definir as variáveis do ambiente Tomcat, tem de editar o Dockerfile.

Defina sondas de funcionamento do Tomcat

Pode monitorizar o tempo de inatividade e o estado de disponibilidade dos seus contentores geridos especificando sondagens no seu plano de migração do servidor Web Tomcat. A monitorização da sondagem de saúde pode ajudar a reduzir o tempo de inatividade dos contentores migrados e oferecer uma melhor monitorização.

Os estados de funcionamento desconhecidos podem criar uma degradação da disponibilidade, uma monitorização da disponibilidade com falsos positivos e uma potencial perda de dados. Sem uma sondagem de saúde, o kubelet só pode presumir o estado de um contentor e pode enviar tráfego para uma instância de contentor que não esteja pronta. Isto pode causar perda de tráfego. O Kubelet também pode não detetar contentores que estejam num estado congelado e não os reinicia.

Uma sondagem de saúde funciona executando uma pequena declaração com script quando o contentor é iniciado. O script verifica se existem condições bem-sucedidas, que são definidas pelo tipo de teste usado, em todos os períodos. O período é definido no plano de migração por um campo periodSeconds. Pode executar ou definir estes scripts manualmente.

Para saber mais sobre as sondas kubelet, consulte o artigo Configure Liveness, Readiness and Startup Probes na documentação do Kubernetes.

Existem dois tipos de sondas disponíveis para configuração. Ambas as sondas são probe-v1-core definidas na referência probe-v1-core e partilham a mesma função que os campos correspondentes de container-v1-core

  • Sondagem de vitalidade: as sondagens de vitalidade são usadas para saber quando reiniciar um contentor.

  • Sondagem de prontidão: as sondagens de prontidão são usadas para saber quando um contentor está pronto para começar a aceitar tráfego. Para começar a enviar tráfego para um pod apenas quando uma sondagem for bem-sucedida, especifique uma sondagem de prontidão. Uma sondagem de disponibilidade pode agir de forma semelhante a uma sondagem de atividade, mas uma sondagem de disponibilidade nas especificações indica que um Pod é iniciado sem receber tráfego e só começa a receber tráfego após a sondagem ser bem-sucedida.

Após a deteção, a configuração da sondagem é adicionada ao plano de migração. As sondas podem ser usadas na respetiva configuração predefinida, conforme mostrado no exemplo seguinte. Para desativar as sondas, remova a secção probes do ficheiro YAML.

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

Pode alterar este plano de migração para usar um ponto final HTTP do Tomcat existente.

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

Existem quatro formas predefinidas de verificar um contentor através de uma sonda. Cada sonda tem de definir exatamente um destes quatro mecanismos:

  • exec: executa um comando especificado no contentor. A execução é considerada bem-sucedida se o código de estado de saída for 0.
  • grpc: Executa uma chamada de procedimento remoto através de `gRPC`. As sondagens `gRPC` são uma funcionalidade alfa.
  • httpGet: executa um pedido HTTP GET no endereço IP do pod numa porta e num caminho especificados. O pedido é considerado bem-sucedido se o código de estado for superior ou igual a 200 e inferior a 400.
  • tcpSocket: Executa uma verificação TCP no endereço IP do pod numa porta especificada. O diagnóstico é considerado bem-sucedido se a porta estiver aberta.

Por predefinição, um plano de migração ativa o método de sondagem tcpSocket. Use a configuração manual do plano de migração para usar métodos de sondagem diferentes. Também pode definir comandos e scripts personalizados através do plano de migração.

Para adicionar dependências externas para a sondagem de prontidão, enquanto usa a sondagem de atividade padrão, defina uma sondagem de prontidão exec e um script que implemente a lógica.

Valide a configuração de clustering do Tomcat

O clustering do Tomcat é usado para replicar informações de sessão em todos os nós do Tomcat, o que lhe permite chamar qualquer um dos servidores de aplicações de back-end e não perder informações de sessão do cliente. Para saber mais sobre a configuração de clustering, consulte o artigo Clustering/Session Replication How-To na documentação do Tomcat.

A classe de clustering do Tomcat chama-se SimpleTcpListener, que usa mensagens de pulsação multicast para a deteção de pares. Os ambientes de nuvem não suportam a transmissão múltipla. Por isso, tem de alterar a configuração de clustering ou removê-la, quando possível.

Quando um equilibrador de carga está configurado para executar e manter uma sessão persistente no servidor Tomcat de back-end, pode usar a propriedade jvmRoute configurada na configuração server.xml Engine.

Se o seu ambiente de origem estiver a usar uma configuração de clustering não suportada, modifique o ficheiro server.xml para desativar a configuração ou usar uma configuração suportada.

  • Tomcat v8.5 ou superior: o clustering tem de estar desativado na versão 8.5 do Tomcat. Para desativar o agrupamento, tem de comentar a secção <Cluster … /> em server.xml.

  • Tomcat v9 ou superior: na versão 9 ou posterior do Tomcat, pode ativar a classe Cluster através de KubernetesMembershipService. KubernetesMembershipService é uma classe específica do Kubernetes que usa as APIs Kubernetes para a deteção de pares.

    • Fornecedor do Kubernetes: segue-se um exemplo de configuração para um fornecedor do 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>

    • Fornecedor de DNS: use o DNSMembershipProvider para usar as APIs DNS para a deteção de pares. Segue-se um exemplo de configuração para um fornecedor de 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: quando o equilibrador de carga depende de um valor jvmRoute, o valor deve ser alterado de estático para usar o nome do POD. Isto configura o Tomcat para adicionar um sufixo ao cookie de sessão com o nome do POD. Isto pode ser usado pelo equilibrador de carga de front-end para direcionar o tráfego para o POD do Tomcat correto. Altere o valor no ficheiro server.xml para usar o seguinte:

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

Valide a configuração do proxy do Tomcat

Se o Tomcat estiver configurado para ser executado atrás de um proxy inverso ou usar várias definições de configuração de proxy na secção Connector de server.xml, tem de verificar se as mesmas configurações de proxy ainda são aplicáveis após a migração para execução no Kubernetes.

Para executar uma aplicação Tomcat funcional em contentores, escolha uma das seguintes alterações de configuração à configuração do proxy inverso:

  • Desative a configuração do proxy: se a aplicação migrada já não for executada através de um proxy inverso, pode desativar a configuração do proxy removendo proxyName e proxyPort da configuração do conetor.
  • Migre o proxy: migre a VM do proxy e mantenha todas as configurações do Tomcat existentes.

  • Configure o Ingress para substituir o proxy inverso: se não tiver sido implementada nenhuma lógica personalizada ou sofisticada para o seu proxy inverso, pode configurar um recurso Ingress para expor a sua aplicação Tomcat migrada. Este processo usa o mesmo FQDN que foi usado antes da migração. Para configurar um Ingress, tem de verificar se o seu serviço Tomcat Kubernetes é do tipo type: Nodeport. Segue-se um exemplo de configuração de um 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

  • Configure uma malha de serviços na nuvem com o Cloud Load Balancing: se estiver a usar o GKE Enterprise, pode optar por expor a sua aplicação através da malha de serviços na nuvem. Para saber como expor aplicações de malha de serviços, consulte o artigo Da extremidade à malha: expor aplicações de malha de serviços através do GKE Ingress.

Valide a configuração do proxy Java

Quando migrar para contentores, tem de validar a disponibilidade dos seus servidores proxy no novo ambiente. Quando o servidor proxy não está disponível, escolha uma das seguintes alterações de configuração ao proxy:

  • Desative o proxy: se o proxy original já não estiver a ser usado, desative a configuração do proxy. Remova todas as definições de proxy do script setenv.sh ou do ficheiro de configuração onde são mantidas no servidor Tomcat.
  • Alterar definições de proxy: se o seu ambiente Kubernetes estiver a usar um proxy de saída diferente, pode alterar as definições de proxy em setenv.sh ou noutro ficheiro para apontar para o novo proxy.

O que se segue?