배포용 Windows 클러스터 준비
이 페이지에서는 배포를 위해 Windows 클러스터를 준비하는 방법을 설명합니다.
시작하기 전에
- 마이그레이션을 완료하고 그 결과 생성된 아티팩트를 가져옵니다.
- 워크로드를 배포할 클러스터를 만듭니다. 자세한 내용은 Windows 클러스터 만들기를 참고하세요.
kubectl를 설정하고 클러스터에 연결합니다.
Docker 레지스트리 선택 및 설정
배포의 일환으로 컨테이너의 Docker 이미지를 빌드하고 Docker 레지스트리에 업로드합니다.
Docker 레지스트리의 경우 다음을 사용할 수 있습니다.
Artifact Registry
기본 인증을 지원하는 모든 Docker 레지스트리
배포 클러스터와 동일한 프로젝트에서 Artifact Registry를 사용하는 것이 좋습니다. GKE는 기본적으로 레지스트리에 액세스할 수 있습니다. 자세한 내용은 GKE와 통합하기 위한 요구사항을 참고하세요.
비공개 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를 지원하려면 다음을 수행해야 합니다.
마이그레이션 계획을 수정해서 필요한 속성을 설정하여 gMSA를 사용하도록 마이그레이션된 컨테이너를 구성합니다.
gMSA를 지원하도록 대상 클러스터 구성
컨테이너 이미지 내에서 정적 ID 구성이 아닌 포드 구성의 일부로 gMSA를 Kubernetes 클러스터에서 연결합니다.
마이그레이션된 Windows 컨테이너를 호스팅하는 클러스터가 gMSA를 지원하도록 구성하려면 다음을 수행해야 합니다.
자세한 내용은 다음을 참조하세요.
- Windows 컨테이너용 gMSA 만들기
- 그룹 관리형 서비스 계정 만들기
- Google Cloud 문서의 gMSA 사용
- Microsoft 문서의 gMSA를 사용하도록 앱 구성
SSL 인증서를 Kubernetes 보안 비밀로 저장할 때 컨테이너 배포
배포된 컨테이너에 대한 외부 액세스의 보안을 위해 Cloud Load Balancing, 인그레스 또는 Cloud Service Mesh를 HTTPS 프런트엔드로 사용하는 것이 좋습니다. 이 옵션을 사용하면 클러스터 내부에 인증서를 포함하지 않고도 외부 통신을 보호할 수 있습니다. 자세한 내용은 마이그레이션 계획 만들기를 참조하세요.
또한 보안 소켓 레이어(SSL) 인증서를 Kubernetes 보안 비밀로 저장하고 런타임에 컨테이너에 마운트할 수 있습니다.
Kubernetes 보안 비밀을 사용하려면 다음 안내를 따르세요.
인증서 및 비밀번호로 PFX 파일을 만듭니다.
사이트 액세스를 정의하는 구성 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 인증서 관리자에서 확인할 수 있습니다.
Kubernetes 보안 비밀을 만듭니다.
kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config
이미지 배포에 볼륨 및 볼륨 마운트를 만듭니다.
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을 차례로 확인하고 등록합니다.
다음 단계
- Windows IIS 워크로드 빌드 및 배포 방법 알아보기