배포용 Windows 클러스터 준비

이 페이지에서는 마이그레이션 아티팩트를 맞춤설정해야 할 수 있는 몇 가지 시나리오를 설명합니다.

시작하기 전에

이 문서에서는 마이그레이션을 완료했다고 가정합니다.

대상 클러스터에 Docker 레지스트리에 대한 읽기 액세스 권한이 있는지 확인

Migrate to Containers는 마이그레이션을 수행할 때 마이그레이션된 VM을 나타내는 Docker 이미지를 Docker 레지스트리에 업로드합니다. 이러한 Docker 이미지는 마이그레이션하는 VM의 파일과 디렉터리를 나타냅니다.

Docker 레지스트리의 경우 다음을 사용할 수 있습니다.

자세한 내용은 데이터 저장소 정의를 참조하세요.

마이그레이션에 사용되는 Google Cloud 프로젝트가 아닌 다른 Google Cloud 프로젝트에 워크로드 배포

환경에 여러 Google Cloud 프로젝트가 있는 경우가 많습니다. 하나의 Google Cloud 프로젝트에서 마이그레이션을 수행한 다음 마이그레이션된 워크로드를 다른 프로젝트의 클러스터에 배포하려는 경우 권한이 올바르게 구성되어 있는지 확인해야 합니다.

예를 들어 프로젝트 A에서 마이그레이션을 수행합니다. 이 경우 마이그레이션된 워크로드가 프로젝트 A의 Container Registry 버킷에 복사됩니다. 예를 들면 다음과 같습니다.

gcr.io/project-a/image_name:image_tag

그런 다음 프로젝트 B의 클러스터에 워크로드를 배포합니다. 권한을 올바르게 구성하지 않으면 프로젝트 B의 클러스터에 프로젝트 A에 대한 이미지 가져오기 액세스 권한이 없으므로 워크로드 포드가 실행되지 않습니다. 그러면 포드에 다음과 같은 형식의 메시지가 포함된 이벤트가 나타납니다.

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Compute Engine API를 사용 설정한 모든 프로젝트에는 다음 이메일 주소가 있는 Compute Engine 기본 서비스 계정이 있습니다.

PROJECT_NUMBER-compute@developer.gserviceaccount.com

여기서 PROJECT_NUMBER는 프로젝트 B의 프로젝트 번호입니다.

이 문제를 해결하려면 프로젝트 B의 Compute Engine 기본 서비스 계정에 Container Registry 버킷에 액세스하는 데 필요한 권한이 있는지 확인합니다. 예를 들어 다음 gsutil 명령어를 사용하여 액세스 권한을 사용 설정할 수 있습니다.

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

처리 클러스터에 워크로드 배포

마이그레이션을 수행하는 데 사용한 것과 동일한 클러스터에 마이그레이션된 워크로드를 배포할 수 있습니다. 이를 Migrate to Containers 처리 클러스터라고 합니다. 대부분의 경우 클러스터에는 이미 마이그레이션을 수행하기 위해 Docker 레지스트리에 대한 읽기 또는 쓰기 액세스 권한이 필요하므로 처리 클러스터에서 추가 구성을 수행할 필요가 없습니다.

Container Registry를 Docker 레지스트리로 사용하여 대상 클러스터에 배포

대상 클러스터에 Container Registry에 대한 액세스 권한이 있는지 확인하려면 Container Registry에 액세스하는 데 필요한 사용자 인증 정보가 포함된 Kubernetes 보안 비밀을 만듭니다.

  1. Container Registry 및 Cloud Storage에 액세스하기 위한 서비스 계정 만들기에 설명된 대로 마이그레이션 배포용 서비스 계정을 만듭니다.

    이 과정에서 m4a-install.json이라는 JSON 키 파일을 다운로드했습니다.

  2. Container Registry에 액세스하는 데 필요한 사용자 인증 정보가 포함된 Kubernetes 보안 비밀을 만듭니다.

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    각 항목의 의미는 다음과 같습니다.

    • docker-registry는 Kubernetes 보안 비밀 이름(이 예시에서 gcr-json-key)을 지정합니다.
    • docker-server=gcr.io는 Container Registry를 서버로 지정합니다.
    • docker-username=_json_key는 사용자 이름이 JSON 키 파일에 포함되어 있음을 지정합니다.
    • docker-password는 JSON 키 파일의 비밀번호를 사용하도록 지정합니다.
    • docker-email은 서비스 계정의 이메일 주소를 지정합니다.

  3. 다음 방법 중 하나를 통해 Kubernetes 보안 비밀을 설정합니다.

    • imagePullSecrets 기본값을 변경합니다.

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • deployment_spec.yaml 파일을 수정하여 spec.template.spec 정의에 imagePullSecrets 값을 추가합니다. Websphere Traditional 사용 시 배포 yaml 이름은 대상에 따라 twas_deployment_spec.yaml, liberty_deployment_spec.yaml 또는 openliberty_deployment_spec.yaml으로 지정됩니다.

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

      PROJECT_ID를 프로젝트 ID로 바꿉니다.

  4. secrets.yaml이 있는 경우 워크로드 보안 비밀을 배포합니다. Tomcat 기반 워크로드와 Liberty를 사용하는 Websphere Traditional 기반 워크로드의 보안 정보 파일이 존재합니다. Liberty 파일 이름은 liberty-secrets.yaml입니다.

    kubectl apply -f secrets.yaml

기본 인증을 지원하는 Docker 레지스트리를 사용하여 대상 클러스터에 배포

Docker 레지스트리를 사용하여 마이그레이션 이미지를 저장하는 경우 레지스트리는 사용자 이름과 비밀번호를 사용하여 기본 인증을 지원해야 합니다. Docker 레지스트리에 대한 읽기 전용 연결을 구성하는 방법은 다양하므로 클러스터 플랫폼 및 Docker 레지스트리에 적합한 방법을 사용해야 합니다.

마이그레이션된 워크로드가 gMSA를 사용하도록 구성

Windows IIS 애플리케이션 워크로드는 종종 Active Directory(AD)가 조인되고 도메인 ID를 사용하여 작동합니다. 이러한 VM을 컨테이너로 마이그레이션할 때 컨테이너 자체는 도메인 조인되지 않고 호스트 Kubernetes 클러스터 노드가 도메인 조인될 수 있습니다.

마이그레이션된 컨테이너를 클러스터에 배포할 때 그룹 관리 서비스 계정(gMSA)을 사용할 수 있습니다. gMSA를 사용하여 특정 서비스 계정 ID 내에서 컨테이너를 실행합니다. 컨테이너 이미지 내에서 정적 ID 구성이 아닌 포드 구성의 일부로 gMSA를 Kubernetes 클러스터에서 연결합니다.

Migrate to Containers는 워크로드 변환 프로세스를 도와줍니다. Migrate to Containers는 IIS 애플리케이션 풀 구성을 자동으로 탐색하고 권장사항을 생성된 마이그레이션 계획에 추가합니다. 그런 후 이러한 권장사항을 평가하고 특정 환경 및 요구사항에 맞게 수정할 수 있습니다.

Migrate to Containers에서 애플리케이션 풀 구성에 gMSA가 필요하지 않다고 결정한 경우 원래 애플리케이션 풀 구성이 유지됩니다. 예를 들면 ApplicationPoolIdentity, NetworkService, LocalSystem, LocalService 등의 기본 제공 계정 유형을 사용하는 경우입니다.

마이그레이션된 Windows 컨테이너에서 gMSA를 지원하려면 다음을 수행해야 합니다.

  1. 마이그레이션 계획을 수정해서 필요한 속성을 설정하여 gMSA를 사용하도록 마이그레이션된 컨테이너를 구성합니다.

  2. 배포된 컨테이너를 호스팅하는 대상 클러스터를 구성합니다.

gMSA를 지원하도록 대상 클러스터 구성

컨테이너 이미지 내에서 정적 ID 구성이 아닌 포드 구성의 일부로 gMSA를 Kubernetes 클러스터에서 연결합니다.

마이그레이션된 Windows 컨테이너를 호스팅하는 클러스터가 gMSA를 지원하도록 구성하려면 다음을 수행해야 합니다.

  1. VM이 도메인에 자동 조인되도록 Active Directory 구성

  2. Windows 포드 및 컨테이너에 맞게 gMSA를 구성합니다.

자세한 내용은 다음을 참조하세요.

SSL 인증서를 Kubernetes 보안 비밀로 저장할 때 컨테이너 배포

배포된 컨테이너에 대한 외부 액세스의 보안을 위해 Cloud Load Balancing, 인그레스 또는 Cloud Service Mesh를 HTTPS 프런트엔드로 사용하는 것이 좋습니다. 이 옵션을 사용하면 클러스터 내부에 인증서를 포함하지 않고도 외부 통신을 보호할 수 있습니다. 자세한 내용은 마이그레이션 계획 만들기를 참조하세요.

또한 보안 소켓 레이어(SSL) 인증서를 Kubernetes 보안 비밀로 저장하고 런타임에 컨테이너에 마운트할 수 있습니다.

Kubernetes 보안 비밀을 사용하려면 다음 안내를 따르세요.

  1. 인증서 및 비밀번호로 PFX 파일을 만듭니다.

  2. 사이트 액세스를 정의하는 구성 YAML 파일을 만듭니다.

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    각 항목의 의미는 다음과 같습니다.

    • sitename은 SSL을 사용하도록 구성된 사이트의 이름을 지정합니다. sites 속성에는 여러 sitename 항목이 포함될 수 있습니다.

    • sslport는 SSL 연결을 위해 리슨할 포트를 지정합니다(일반적으로 443).

    • pfxpath는 PFX 파일의 경로를 지정합니다. 포드 배포의 volumeMounts에 포함하여 구성합니다.

    • password는 PFX 파일의 비밀번호를 지정합니다.

    • thumbprint는 PowerShell 명령어를 사용하여 검색할 수 있는 PFX 파일의 SHA-1 지문을 지정합니다.

      Get-PfxCertificate -FilePath "path to pfx"

      또는 Windows 인증서 관리자에서 확인할 수 있습니다.

  3. Kubernetes 보안 비밀을 만듭니다.

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

  4. 이미지 배포에 볼륨 및 볼륨 마운트를 만듭니다.

    apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

    각 항목의 의미는 다음과 같습니다.

    • mountPath는 2단계에서 만든 구성 파일의 pfxpath에서 지정한 경로와 동일합니다.
    • M4A_CERT_YAML은 2단계에서 만든 구성 YAML 파일의 전체 경로로 설정된 환경 변수입니다.
    • secret-name은 3단계에서 만든 보안 비밀의 이름입니다.

SSL 구성

이미지를 읽는 모든 사용자가 액세스할 수 있으므로 컨테이너 이미지 내에 SSL 인증서 비공개 키를 저장하지 않는 것이 좋습니다. Migrate to Containers에서는 Windows용 SSL을 처리하는 여러 가지 방법을 제공합니다.

자체 서명 자동 생성 인증서 사용

기본적으로 HTTPS 바인딩이 포함된 Windows 컨테이너에는 Docker 컨테이너 초기화 시 생성되는 자체 서명 자동 생성 인증서가 할당됩니다. 이 구성을 사용하면 마이그레이션된 워크로드를 테스트할 수 있지만 프로덕션 환경에서는 사용할 수 없습니다. 컨테이너가 실행될 때마다 인증서가 자체 서명되고 다시 생성됩니다.

권장 - Cloud Load Balancing, 인그레스 또는 Cloud Service Mesh를 사용

HTTP를 사용하도록 마이그레이션 계획에서 바인딩을 맞춤설정할 수 있습니다. 그런 다음 Cloud Load Balancing, 인그레스 또는 Cloud Service Mesh를 HTTPS 프런트엔드로 사용하여 외부 액세스를 보호합니다. 이 옵션을 사용하면 클러스터 내부에 인증서를 포함하지 않고도 외부 통신을 보호할 수 있습니다.

  • 바인딩을 맞춤설정하려면 마이그레이션을 나타내는 마이그레이션 계획에서 site 정의를 수정하여 protocol을 http로 설정합니다.

    sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

그런 다음 HTTPS 프런트엔드의 요청을 Windows 워크로드의 HTTP 경로와 포트로 전달할 수 있습니다.

SSL 인증서를 Kubernetes 보안 비밀로 저장

외부 액세스의 보안을 위해 Cloud Load Balancing, 인그레스 또는 Cloud Service Mesh를 HTTPS 프런트엔드로 사용하는 것이 좋습니다. 그러나 SSL 인증서를 Kubernetes 보안 비밀로 저장하고 런타임 시 컨테이너에 마운트할 수도 있습니다.

Kubernetes 보안 비밀로 저장된 SSL 인증서를 사용하려면 컨테이너의 배포 이미지를 수정해야 합니다. 자세한 내용은 SSL 인증서를 Kubernetes 보안 비밀로 저장할 때 컨테이너 배포를 참조하세요.

Cloud Logging에 로깅 구성

Migrate to Containers는 LogMonitor 도구를 사용해서 Windows 컨테이너에서 로그를 추출하고 이를 GKE 클러스터로 전달합니다. 그런 후 이러한 로그가 Cloud Logging으로 전달되어 컨테이너 모니터링을 위한 도구 모음을 제공합니다.

기본적으로 Migrate to Containers는 IIS 로깅이 IIS 로그를 모니터링하고 애플리케이션 또는 시스템 이벤트 로그를 Cloud Logging으로 전달할 수 있게 해줍니다.

로깅 구성

생성된 artifacts.zip 파일을 확장하면 m4a 디렉터리를 포함하여 여러 디렉터리가 생성됩니다. 디렉터리에는 모든 이미지에 대한 폴더가 포함됩니다. m4a 디렉터리에는 로깅 제어를 위해 수정할 수 있는 LogMonitorConfig.json 파일이 포함되어 있습니다.

LogMonitorConfig.json 수정에 대한 자세한 내용은 구성 파일 작성을 참조하세요.

ACL 설정

일부 IIS 애플리케이션에서는 애플리케이션의 올바른 작동을 위해 파일 및 폴더에 특정 액세스 제어 목록(ACL) 권한을 설정해야 합니다. Migrate to Containers는 마이그레이션된 모든 IIS 애플리케이션을 스캔하고 IIS 계정(IUSR 계정 및 IIS_IUSRS 그룹)에 적용되는 소스 VM에 정의된 특정 권한을 추가하고, 이를 생성된 컨테이너 이미지의 복사된 파일 및 디렉터리에 적용합니다.

Windows 컨테이너 이미지가 Docker COPY 명령어의 일부로 ACL 설정을 지원하지 않기 때문에 ACL이 set_acls.bat라는 스크립트에 설정됩니다. Migrate to Containers는 특정 Windows 애플리케이션에 대해 생성된 이미지 디렉터리에 set_acls.bat를 자동으로 만듭니다. 그런 후 docker build 명령어를 실행할 때 Migrate to Containers가 set_acls.bat를 호출합니다.

set_acls.bat를 수정해서 커스텀 권한을 추가 또는 삭제하거나, 특정 IIS 사용자와 관련이 없어서 Migrate to Containers에서 검색되지 않은 권한을 수정합니다.

이 스크립트는 Windows 기본 제공 icacls 도구를 사용하여 권한을 설정합니다.

.NET 전역 어셈블리 캐시 정보

Migrate to Containers는 소스 머신에 설치되었고 공식 이미지의 일부로 제공되지 않는 .NET 리소스에 대해 소스 이미지 .NET 전역 어셈블리 캐시(GAC)를 스캔합니다. 검색된 모든 DLL은 Docker 컨텍스트에 복사되며 유틸리티 스크립트 install_gac.ps1이 대상 이미지를 빌드할 때 설치됩니다.

모든 .NET 어셈블리는 m4a\gac 디렉터리 아래의 Docker 컨텍스트에 복사됩니다. 이미지에서 어셈블리를 삭제하려면 m4a\gac 디렉터리에서 삭제합니다.

COM 객체 DLL 등록

COM 객체를 노출하는 DLL은 자동으로 스캔되고 등록됩니다. 추출 단계 중에 복사된 파일은 COM 객체로 등록된 DLL이 있는지 검사된 후 컨테이너에 등록됩니다.

이 프로세스는 사용자 입력 없이 수행됩니다. 그러나 복사할 DLL을 추가하여 이 프로세스에 영향을 줄 수 있습니다. 필요한 경우 이러한 DLL을 차례로 확인하고 등록합니다.

다음 단계