Tomcat 서버의 마이그레이션 계획 맞춤설정
마이그레이션을 만들 때 생성된 마이그레이션 계획 파일을 검토해야 합니다. 마이그레이션을 실행하기 전에 파일을 맞춤설정합니다. 마이그레이션 계획의 세부정보는 소스에서 워크로드 컨테이너 아티팩트를 추출하는 데 사용됩니다.
이 섹션에서는 마이그레이션을 실행하고 배포 아티팩트를 생성하기 전에 고려할 수 있는 마이그레이션 콘텐츠 및 맞춤설정의 종류를 설명합니다.
시작하기 전에
- 이 주제에서는 개발자가 이미 마이그레이션을 만들었고 마이그레이션 계획 파일이 있다고 가정합니다.
마이그레이션 계획 수정
migctl 도구나 Google Cloud 콘솔을 사용하여 마이그레이션 계획을 수정할 수 있습니다.
migctl
수정하려면 먼저 마이그레이션 계획을 다운로드해야 합니다.
마이그레이션 계획을 다운로드합니다.
migctl migration get my-migration
다운로드한 마이그레이션 계획
my-migration.yaml을 텍스트 편집기에서 수정합니다.수정이 완료되면 수정된 마이그레이션 계획을 저장하고 업로드합니다.
migctl migration update my-migration --main-config my-migration.yaml
추가 수정이 필요하면 이 단계를 반복합니다.
콘솔
YAML 편집기를 사용하여 Google Cloud 콘솔에서 마이그레이션 계획을 수정합니다.
Google Cloud 콘솔에서 Migrate to Containers 페이지를 엽니다.
마이그레이션 탭을 클릭하여 사용 가능한 마이그레이션이 포함된 테이블을 표시합니다.
원하는 마이그레이션 행에서 마이그레이션 이름을 선택하여 세부정보 탭을 엽니다.
YAML 탭을 선택합니다.
필요에 따라 마이그레이션 계획을 수정합니다.
수정이 완료되면 다음을 수행할 수 있습니다.
마이그레이션 계획을 저장합니다. 그런 다음 마이그레이션을 수동으로 실행하여 마이그레이션 아티팩트를 생성해야 합니다. 마이그레이션 실행에 표시된 절차를 사용합니다.
아티팩트를 저장 및 생성합니다. 수정 사항을 사용해서 마이그레이션을 실행하여 마이그레이션 아티팩트를 생성합니다. 프로세스는 마이그레이션 실행에 설명된 것과 동일합니다. 그런 후 마이그레이션 모니터링에 설명된 대로 마이그레이션을 모니터링할 수 있습니다.
CRD
마이그레이션 계획을 다운로드하여 수정한 다음 적용해야 합니다.
마이그레이션 계획은 AppXGenerateArtifactsFlowSpec CRD의 appXGenerateArtifactsConfig 필드 내에 저장됩니다.
AppXGenerateArtifactsFlow이름을 가져옵니다.kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration이름 지정 패턴은
appx-generateartifactsflow-id형식으로 반환됩니다.이름을 기준으로 마이그레이션 계획을 가져오고
my-plan.yaml파일에 기록합니다.kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml필요에 따라 마이그레이션 계획을 수정합니다.
파일을 적용합니다.
kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id
마이그레이션 계획의 세부정보와 안내를 검토하여 필요에 따라 정보를 추가합니다. 특히 다음 섹션을 수정하는 것이 좋습니다.
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: 사용할 그룹 이름
SSL 구성
새 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로 로깅할 수 있습니다.
Migrate to Containers는 수정된 로그 구성을 사용하여 추가 보관 파일을 만들고 모든 파일 형식 어펜더를 콘솔 어펜더로 변환합니다. 이 보관 파일의 콘텐츠를 참조로 사용하여 로그 수집을 사용 설정하고 로그 수집 솔루션(예: Google Cloud Logging)에 스트리밍할 수 있습니다.
메모리 할당
마이그레이션 프로세스 중에 개별 컨테이너로 마이그레이션된 애플리케이션의 메모리 한도를 지정할 수 있습니다. 다음 형식을 사용하여 마이그레이션 계획에서 직접 메모리 한도를 수정합니다.
tomcatServers:
- name: latest
. . .
images:
- name: tomcat-latest
. . .
resources:
memory:
limit: 2048M
requests: 1280M
limit에 권장되는 값은 최대 Java 힙 크기인 Xmx의 200%입니다. 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 힙 할당 크기가 변경될 수 있습니다.
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"
Tomcat 서버의 /bin 폴더에 있는 setenv.sh 스크립트를 사용하여 Tomcat 환경 변수를 설정할 수도 있습니다. Tomcat 환경 변수에 대한 자세한 내용은 Tomcat 문서를 참조하세요.
setenv.sh를 사용해서 Tomcat 환경 변수를 설정하도록 선택한 경우 Dockerfile을 수정해야 합니다.
Tomcat 상태 프로브 설정
Tomcat 웹 서버의 마이그레이션 계획에 프로브를 지정하여 관리형 컨테이너의 다운타임 및 준비 상태를 모니터링할 수 있습니다. 상태 프로브 모니터링은 마이그레이션된 컨테이너의 다운타임을 줄이고 더 나은 모니터링을 제공하는 데 도움이 될 수 있습니다.
알 수 없는 상태에서는 가용성 저하, 거짓양성 가용성 모니터링, 잠재적인 데이터 손실이 발생할 수 있습니다. 상태 프로브가 없으면 kubelet은 컨테이너 상태만 가정할 수 있으며, 준비되지 않은 컨테이너 인스턴스로 트래픽을 전송할 수 있습니다. 이로 인해 트래픽이 손실될 수 있습니다. Kubelet은 고정된 상태의 컨테이너를 감지하지 못할 수도 있으며, 이로 인해 컨테이너를 다시 시작하지 않습니다.
상태 프로브는 컨테이너가 시작될 때 작은 스크립트 문을 실행하여 작동합니다. 이 스크립트는 모든 기간에 사용된 프로브 유형으로 정의된 성공적인 조건을 확인합니다. 기간은 마이그레이션 계획에서 periodSeconds 필드로 정의됩니다. 이러한 스크립트를 수동으로 실행하거나 정의할 수 있습니다.
kubelet 프로브에 대한 자세한 내용은 Kubernetes 문서의 활성, 준비, 시작 프로브 구성을 참조하세요.
구성할 수 있는 프로브에는 두 가지 유형이 있습니다. 두 프로브 모두 probe-v1-core 참조에 정의된 probe-v1-core이며 container-v1-core의 해당 필드와 동일한 함수를 공유합니다.
- 활성 프로브 - 활성 프로브는 컨테이너를 다시 시작할 시점을 파악하는 데 사용됩니다.
- 준비 프로브 - 준비 프로브는 컨테이너가 트래픽을 수락할 준비가 된 시점을 파악하는 데 사용됩니다. 프로브가 성공한 경우에만 포드에 트래픽 전송을 시작하려면 준비 프로브를 지정합니다. 준비 프로브는 활성 프로브와 유사하게 작동할 수 있지만 이 사양의 준비 프로브에서는 포드가 트래픽을 수신하지 않고 시작하며 프로브가 성공한 후에만 트래픽을 수신하기 시작함을 나타냅니다.
검색 후에는 프로브 구성이 마이그레이션 계획에 추가됩니다. 다음 예시와 같이 프로브를 기본 구성에서 사용할 수 있습니다. 프로브를 사용 중지하려면 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
프로브를 사용하여 컨테이너를 확인하는 사전 정의된 방법에는 4가지가 있습니다. 각 프로브에서 다음 4가지 메커니즘 중 하나를 정확히 정의해야 합니다.
exec- 컨테이너 내에서 지정된 명령어를 실행합니다. 종료 상태 코드가 0이면 실행이 성공한 것으로 간주됩니다.grpc- `gRPC`를 사용하여 리모트 프로시져 콜을 수행합니다. `gRPC` 프로브는 알파 기능입니다.httpGet- 지정된 포트 및 경로에서 포드의 IP 주소에 대해 HTTP GET 요청을 수행합니다. 상태 코드가 200에서 400 사이인 경우 요청이 성공한 것으로 간주됩니다.tcpSocket- 지정된 포트에서 포드의 IP 주소에 대해 TCP 확인을 수행합니다. 포트가 열려 있는 경우 진단이 성공한 것으로 간주됩니다.
기본적으로 마이그레이션 계획은 tcpSocket 프로빙 메서드를 사용 설정합니다. 다른 프로브 방법을 사용하려면 마이그레이션 계획의 수동 구성을 사용합니다.
마이그레이션 계획을 통해 커스텀 명령어와 스크립트를 정의할 수도 있습니다.
준비 프로브의 외부 종속 항목을 추가하려면 기본 활성 프로브를 사용하는 동안 실행 준비 프로브와 로직을 구현하는 스크립트를 정의합니다.
Tomcat 클러스터링 구성 확인
Tomcat 클러스터링은 모든 Tomcat 노드 간의 세션 정보를 복제하는 데 사용됩니다. 이를 통해 백엔드 애플리케이션 서버를 호출하고 클라이언트 세션 정보가 사라지지 않게 합니다. 클러스터링 구성에 대한 자세한 내용은 Tomcat 문서에서 클러스터링/세션 복제 방법을 참조하세요.
Tomcat 클러스터링 클래스는 SimpleTcpListener라고 하며 멀티캐스트 하트비트 메시지를 사용하여 동종 앱을 검색합니다. 클라우드 환경에서는 멀티캐스트가 지원되지 않으므로 가능한 경우 클러스터링 구성을 변경하거나 삭제해야 합니다.
백엔드 Tomcat 서버에 대한 고정 세션을 실행하고 유지하도록 부하 분산기가 구성된 경우 Engine 구성에서 구성한 jvmRoute 속성을 사용할 수 있습니다.
원본 환경이 지원되지 않는 클러스터링 구성을 사용하는 경우 구성을 사용 중지하거나 지원되는 구성을 사용하도록 server.xml 파일을 수정합니다.
- Tomcat v8.5 이상: Tomcat 버전 8.5에서는 클러스터링을 사용 중지해야 합니다.
클러스터링을 사용 중지하려면
server.xml의<Cluster … />섹션을 주석 처리해야 합니다. Tomcat v9 이상: Tomcat 버전 9 이상에서는
KubernetesMembershipService를 사용하여Cluster클래스를 사용 설정할 수 있습니다.KubernetesMembershipService는 동종 앱 검색을 위해 Kubernetes API를 사용하는 Kubernetes 특정 클래스입니다.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 값에 의존하는 경우 값을 고정에서 포드 이름 사용으로 변경해야 합니다. 이렇게 하면 Tomcat이 POD 이름으로 세션 쿠키에 서픽스를 추가합니다. 프런트엔드 부하 분산기에서 트래픽을 올바른 Tomcat 포드로 전달하는 데 사용할 수 있습니다. 다음을 사용하도록
server.xml파일의 값을 변경합니다.<Engine name="Catalina" defaultHost="localhost" jvmRoute="${HOSTNAME}">
Tomcat 프록시 구성 확인
Tomcat이 리버스 프록식 환경에서 실행되도록 구성되었거나 server.xml의 Connector 섹션에서 여러 프록시 구성 설정을 사용하는 경우 Kubernetes에서 실행하도록 마이그레이션한 후에도 동일한 프록시 구성을 계속 적용할 수 있는지 확인해야 합니다.
정상 작동하는 컨테이너화된 Tomcat 애플리케이션을 실행하려면 다음 구성 변경사항 중 하나를 리버스 프록시 구성으로 선택합니다.
- 프록시 구성 사용 중지 — 마이그레이션된 애플리케이션이 더 이상 리버스 프록시 환경에서 실행되지 않으면 커넥터 구성에서
proxyName과proxyPort를 삭제하여 프록시 구성을 사용 중지할 수 있습니다. - 프록시 마이그레이션 — 프록시 VM을 마이그레이션하고 기존 Tomcat 구성을 모두 유지합니다.
인그레스가 리버스 프록시를 대체하도록 구성 — 리버스 프록시에 대해 커스텀 또는 정교한 로직이 구현되지 않았으면 마이그레이션한 Tomcat 애플리케이션을 노출하도록 인그레스 리소스를 구성할 수 있습니다. 이 프로세스는 마이그레이션 전에 사용된 것과 동일한 FQDN을 사용합니다. 인그레스를 구성하려면 Tomcat Kubernetes 서비스가
type: Nodeport인지 확인해야 합니다. 다음은 인그레스의 샘플 구성입니다.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-portCloud Load Balancing을 사용하여 Anthos Service Mesh 구성: GKE Enterprise를 사용하는 경우 Anthos Service Mesh를 사용하여 애플리케이션을 노출할 수 있습니다. 서비스 메시 애플리케이션 노출에 대한 자세한 내용은 에지에서 메시로: GKE 인그레스를 통해 서비스 메시 애플리케이션 노출을 참조하세요.
Java 프록시 구성 확인
컨테이너로 마이그레이션할 때는 새 환경에서 프록시 서버의 가용성을 확인해야 합니다. 프록시 서버를 사용할 수 없는 경우 프록시에 대해 다음 구성 변경 중 하나를 선택합니다.
- 프록시 사용 중지: 원본 프록시가 더 이상 사용되지 않는 경우 프록시 구성을 사용 중지합니다.
setenv.sh스크립트 또는 Tomcat 서버에서 유지보수되는 구성 파일에서 모든 프록시 설정을 삭제합니다. - 프록시 설정 변경: Kubernetes 환경이 다른 이그레스 프록시를 사용하는 경우
setenv.sh또는 다른 파일의 프록시 설정이 새 프록시를 가리키도록 변경할 수 있습니다.
다음 단계
- 마이그레이션 실행 방법 알아보기