自訂 Tomcat 伺服器的遷移計畫

您應查看建立遷移作業後產生的遷移計畫檔案。請先自訂檔案再執行遷移作業。遷移計畫的詳細資料會用來從來源擷取工作負載容器構件。

本節將說明遷移作業的內容，以及在執行遷移作業並產生部署構件之前，您可能會考慮的客製化類型。

事前準備

本主題假設您已建立遷移作業，並擁有遷移計畫檔案。

編輯遷移計畫

複製及分析檔案系統後，您可以在指定輸出路徑 ANALYSIS_OUTPUT_PATH/config.yaml 中建立的新目錄中找到遷移計畫。

視需要編輯遷移計畫並儲存變更。

查看遷移計畫的詳細資料和指引性註解，視需要新增資訊。具體來說，請考慮針對下列部分進行編輯：

指定 Docker 映像檔

在遷移計畫中，我們會根據 Tomcat 版本、Java 版本和 Java 供應商，產生 Docker 社群映像檔標記。

• Tomcat 版本：偵測 Tomcat 版本並轉換為主要版本 (不支援次要版本)。如果我們無法偵測 Tomcat 版本，baseImage.name 就會包含空字串。
• Java 版本：Java 版本取決於 java-version 參數。預設為 11。
• Java 供應商：Java 供應商設為常數：temurin。

舉例來說，針對 Tomcat 9.0 版、Java 11 版和 Java 供應商 temurin 產生的 Docker 社群映像檔標記為 tomcat:9.0-jre11-temurin。

在遷移計畫中，baseImage.name 欄位代表用於容器映像檔基礎的 Docker 映像檔標記。

在來源 VM 上偵測到的原始 Tomcat 和 Java 版本，會包含在初始探索作業產生的 discovery-report.yaml 中。

如果您想變更 Docker 社群映像檔，或提供自己的 Docker 映像檔，可以使用下列格式修改遷移計畫中的 baseImage.name：

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

將 BASE_IMAGE_NAME 替換為要用於容器映像檔的 Docker 映像檔。

更新 Tomcat 安裝路徑

在遷移程序期間，如果目標映像檔具有非預設的 CATALINA_HOME 路徑，您可以指定自訂 CATALINA_HOME 路徑。直接在遷移計畫中編輯目標 catalinaHome 欄位：

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

將 PATH 替換為 Tomcat 安裝路徑。

自訂使用者和群組

在遷移過程中，如果目標映像檔使用與 root:root 不同的使用者和群組，您可以指定要讓應用程式在其中執行的自訂使用者和群組。直接在遷移計畫中編輯使用者和群組：

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

更改下列內容：

• USERNAME：您要使用的使用者名稱
• GROUP_NAME：要使用的群組名稱

設定安全資料傳輸層

建立新的 Tomcat 遷移作業時，探索程序會根據所發現的不同應用程式掃描伺服器。

偵測完成後，系統會自動在遷移計畫中填入下列欄位：

• excludeFiles：列出要從遷移作業中排除的檔案和目錄。

  根據預設，在探索期間找到的所有敏感路徑和憑證都會自動加入這個欄位，並從遷移作業中排除。如果您從這份清單中移除路徑，檔案或目錄就會上傳至容器映像檔。如要從容器映像檔中排除檔案或目錄，請將路徑新增至這份清單。

• sensitiveDataPaths：列出探索程序找到的所有機密路徑和憑證。

  如要將憑證上傳至存放區，請將 includeSensitiveData 欄位設為 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
  

  遷移完成後，系統會將機密資料新增至構件存放區中的機密資料檔案 secrets.yaml。

網路應用程式記錄

Migrate to Containers 支援使用位於 CATALINA_HOME 中的 log4j v2、logback 和 log4j v1.x 進行記錄。

遷移至容器會建立其他封存檔案，並使用經過修改的記錄設定，將所有檔案類型附加元件轉換為控制台附加元件。您可以使用這個封存檔的內容做為參考，啟用記錄收集功能，並將記錄串流傳送至記錄收集解決方案 (例如 Google Cloud Logging)。

記憶體配置

在遷移程序期間，您可以指定遷移至個別容器的應用程式記憶體限制。請使用下列格式，直接在遷移計畫中編輯記憶體限制：

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

limit 的建議值為 Xmx 的 200%，也就是 Java 堆積區的最大大小。requests 的建議值為 Xmx 的 150%。

如要查看 Xmx 的值，請執行下列指令：

ps aux | grep catalina

如果在遷移計畫中已定義記憶體限制，則在遷移成功後，與其他構件一併產生的 Dockerfile 會反映您的宣告：

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

這會將初始和最大大小定義為限制值的 50%。這樣一來，Tomcat Java 堆積配置大小就能根據 Pod 記憶體限制的任何變更而變更。

設定 Tomcat 環境變數

如果您想在遷移成功後，在與其他構件一併產生的 Dockerfile 中設定 CATALINA_OPTS，請先在遷移計畫中新增 catalinaOpts 欄位。以下範例顯示已更新的 catalinaOpts 欄位：

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

Migrate to Containers 會將您的 catalinaOpts 資料剖析至 Dockerfile。以下範例顯示剖析的輸出內容：

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"

您也可以使用 setenv.sh 指令碼設定 Tomcat 環境變數，該指令碼位於 Tomcat 伺服器的 /bin 資料夾中。如要進一步瞭解 Tomcat 環境變數，請參閱 Tomcat 說明文件。

如果您選擇使用 setenv.sh 設定 Tomcat 環境變數，則需要編輯 Dockerfile。

設定 Tomcat 健康探測

您可以在 Tomcat 網路伺服器遷移計畫中指定探針，監控受管理容器的停機時間和就緒狀態。健康探針監控功能可減少遷移容器的停機時間，並提供更完善的監控功能。

不明的健康狀態可能會導致可用性降低、可用性監控出現誤報，以及潛在的資料遺失。如果沒有健康檢查，kubelet 只能假設容器的健康狀態，並可能將流量傳送至尚未就緒的容器執行個體。這可能會導致流量流失。Kubelet 也可能不會偵測到處於凍結狀態的容器，並不會重新啟動這些容器。

健康檢查探針會在容器啟動時執行小型指令碼陳述式。指令碼會在每個週期檢查成功的條件，這些條件由所用探針類型定義。在遷移計畫中，使用 periodSeconds 欄位定義期間。您可以手動執行或定義這些指令碼。

如要進一步瞭解 kubelet 探測功能，請參閱 Kubernetes 說明文件中的「Configure Liveness, Readiness and Startup Probes」一文。

您可以設定兩種類型的探針，兩者都是在 probe-v1-core 參照資料中定義的 probe-v1-core，並與 container-v1-core 的對應欄位共用相同函式。

• 有效性探測：有效性探測可用於瞭解何時要重新啟動容器。

• Readiness 探測：Readiness 探測可用於瞭解容器何時可開始接受流量。如要只在探測成功時開始將流量傳送至 Pod，請指定 readiness 探測。完備性探測可能會與有效性探測類似，但規格中的完備性探測表示 Pod 會在未接收任何流量下啟動，並在探測成功後才開始接收流量。

探索完成後，探針設定會新增至遷移計畫。探針可用於預設設定，如以下範例所示。如要關閉探針，請從 YAML 檔案中移除 probes 區段。

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

您可以變更這項遷移計畫，改用現有的 Tomcat HTTP 端點。

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

您可以使用探針檢查容器，共有四種預先定義的方式。每個探針都必須定義下列四種機制之一：

• exec：在容器內執行指定指令。如果結束狀態碼為 0，則視為執行成功。
• grpc：使用 `gRPC` 執行遠端程序呼叫。`gRPC` 探針是 Alpha 版功能。
• httpGet：針對 Pod 的 IP 位址，在指定的連接埠和路徑上執行 HTTP GET 要求。如果狀態碼大於或等於 200，且小於 400，則系統會將要求視為成功。
• tcpSocket：針對指定通訊埠的 Pod IP 位址執行 TCP 檢查。如果連接埠已開啟，系統會將診斷視為成功。

根據預設，遷移計畫會啟用 tcpSocket 探測方法。請使用遷移計畫的手動設定，使用其他探測方法。您也可以透過遷移計畫定義自訂指令和指令碼。

如要為就緒探針新增外部依附元件，同時使用預設的活動探針，請定義執行就緒探針和實作邏輯的指令碼。

驗證 Tomcat 分群設定

Tomcat 叢集可用於在所有 Tomcat 節點之間複製工作階段資訊，讓您呼叫任何後端應用程式伺服器，且不會遺失用戶端工作階段資訊。如要進一步瞭解叢集設定，請參閱 Tomcat 說明文件中的「叢集/工作階段複製操作說明」。

Tomcat 叢集類別稱為 SimpleTcpListener，會使用多播心跳訊息來探索同盟網域。雲端環境不支援多播，因此您必須盡可能變更或移除叢集設定。

當負載平衡器設定為執行並維護後端 Tomcat 伺服器的固定式工作階段時，可以使用 server.xml Engine 設定中設定的 jvmRoute 屬性。

如果來源環境使用不支援的叢集設定，請修改 server.xml 檔案，以便停用該設定，或使用支援的設定。

• Tomcat 8.5 以上版本：Tomcat 8.5 以上版本必須停用叢集功能。如要停用叢集功能，請在 server.xml 中將 <Cluster … /> 部分註解掉。

• Tomcat 9 以上版本：在 Tomcat 9 以上版本中，您可以使用 KubernetesMembershipService 啟用 Cluster 類別。KubernetesMembershipService 是 Kubernetes 專屬類別，會使用 Kubernetes API 來探索對等端。

  • Kubernetes 供應器：以下是 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>
    

  • DNS 供應商：使用 DNSMembershipProvider 來使用 DNS API 進行同盟探索。以下是 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：如果負載平衡器依賴 jvmRoute 值，則應將值從靜態變更為使用 POD 名稱。這會設定 Tomcat，讓其在工作階段 Cookie 中加入 POD 名稱的後置字串。前端負載平衡器可使用這項資訊，將流量導向正確的 Tomcat POD。變更 server.xml 檔案中的值，以便使用下列值：

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

驗證 Tomcat Proxy 設定

如果 Tomcat 已設定為在反向 Proxy 後方執行，或使用 server.xml 的 Connector 部分中的多個 Proxy 設定，您必須確認在遷移至 Kubernetes 執行環境後，仍可使用相同的 Proxy 設定。

如要執行功能完整的容器化 Tomcat 應用程式，請選擇下列任一設定變更，套用至反向 Proxy 設定：

• 停用 Proxy 設定：如果已遷移的應用程式不再透過反向 Proxy 執行，您可以從連接器設定中移除 proxyName 和 proxyPort，藉此停用 Proxy 設定。
• 遷移 Proxy：遷移 Proxy VM，並保留所有現有的 Tomcat 設定。

• 設定 Ingress 取代反向 Proxy：如果您尚未為反向 Proxy 實作自訂或複雜的邏輯，可以設定 Ingress 資源，公開已遷移的 Tomcat 應用程式。這個程序會使用遷移前使用的 FQDN。如要設定 Ingress，您必須確認 Tomcat Kubernetes 服務為 type: Nodeport。以下是 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
  

• 使用 Cloud Load Balancing 設定 Cloud Service Mesh：如果您使用的是 GKE Enterprise，可以選擇使用 Cloud Service Mesh 公開應用程式。如要進一步瞭解如何公開服務網格應用程式，請參閱「從邊緣到網格：透過 GKE Ingress 公開服務網格應用程式」。

驗證 Java Proxy 設定

遷移至容器時，您必須確認新環境中的 Proxy 伺服器是否可用。如果無法使用 Proxy 伺服器，請選擇下列任一 Proxy 設定變更：

• 停用 Proxy：如果不再使用原始 Proxy，請停用 Proxy 設定。從 setenv.sh 指令碼或 Tomcat 伺服器上維護設定檔中，移除所有 Proxy 設定。
• 變更 Proxy 設定：如果 Kubernetes 環境使用不同的出口 Proxy，您可以變更 setenv.sh 或其他檔案中的 Proxy 設定，以便指向新的 Proxy。

後續步驟

• 瞭解如何執行遷移作業。