데이터 저장소 정의

중요: Google Cloud 콘솔의 Migrate to Containers UI인 migctl 및 처리 클러스터를 사용하여 워크로드를 Google Cloud로 마이그레이션하는 CRD는 이제 지원 중단되었습니다. 기존 사용자는 2024년 5월까지 지원되며, 그 이후에는 더 이상 사용할 수 없습니다. Migrate to Containers를 처음 사용하는 경우 Migrate to Containers CLI를 사용하여 로컬 머신에서 마이그레이션을 수행하세요. 자세한 내용은 Migrate to Containers CLI 아키텍처를 참조하세요.

Migrate to Containers는 마이그레이션을 수행하는 동안 여러 데이터 저장소에 정보를 기록합니다.

1. Docker 레지스트리에 기록된 마이그레이션된 Linux VM을 나타내는 Docker 이미지 파일.

   이러한 Docker 이미지 파일은 마이그레이션된 Linux VM의 파일과 디렉터리를 나타냅니다. Windows 워크로드를 마이그레이션할 때는 이 저장소가 필요하지 않습니다.

2. 두 번째 저장소에 기록된 마이그레이션된 워크로드를 나타내는 마이그레이션 아티팩트.

   아티팩트에는 마이그레이션된 워크로드와 그 밖의 파일을 배포하는 데 사용할 수 있는 구성 YAML 파일이 포함됩니다. 정확한 아티팩트는 마이그레이션하는 워크로드가 Linux인지 또는 Windows인지에 따라 달라집니다.

플랫폼	Docker 이미지 파일 레지스트리*	마이그레이션 아티팩트 저장소
Google Cloud의 GKE Enterprise 클러스터	기본값은 Container Registry(GCR)입니다. 선택적으로 기본 인증을 지원하는 Docker 레지스트리를 지정합니다.	기본값은 Cloud Storage입니다. 선택적으로 Linux 마이그레이션을 위한 아티팩트 저장소로 S3를 지정합니다. S3는 Windows 워크로드를 마이그레이션하는 데 지원되지 않습니다.
베어메탈 클러스터용 Google Distributed Cloud Virtual	기본값은 Container Registry(GCR)입니다. 선택적으로 기본 인증을 지원하는 Docker 레지스트리를 지정합니다.	기본값은 Cloud Storage입니다. 선택적으로 S3를 아티팩트 저장소로 지정합니다.
* Docker 이미지 파일 레지스트리는 Windows 마이그레이션에 필요하지 않습니다. Linux VM을 마이그레이션하는 데에만 필요합니다.

저장소 상태 보기

Migrate to Containers를 설치한 후 migctl doctor 명령어를 실행하여 Migrate for Containers 설치를 확인합니다. 검증을 수행하는 동안 migctl doctor 명령어는 저장소 상태를 확인합니다.

migctl doctor

다음 migctl doctor 명령어의 예시 출력에서 체크표시는 Migrate to Containers가 성공적으로 배포되었지만 아직 필요한 데이터 저장소가 구성되지 않았음을 나타냅니다.

  [✓] Deployment
  [!] Docker Registry
  [!] Artifacts Repo
  [!] Source Status

저장소에 문제가 있는 경우 명령어를 실행할 때 migctl doctor가 해당 문제를 플래그로 표시합니다. migctl doctor를 실행하면 migctl이 모든 아티팩트 저장소를 쿼리하고 비정상 저장소를 경고합니다.

다음 migctl doctor 명령어 예시 출력에서 느낌표는 Migrate to Containers가 아티팩트 저장소에서 오류를 찾았음을 나타냅니다. 오류가 발생하여 저장소가 초기화되지 않았으며 명령어를 다시 실행하기 전에 구성을 수정해야 합니다. 기본 저장소 이외의 추가 저장소의 경우 마이그레이션을 방해할 필요는 없습니다.

기본 저장소가 비정상인 경우 X에서는 Migrate to Containers에서 오류를 발견하여 마이그레이션이 실패할 수 있음을 나타냅니다.

[✓] Deployment
[✓] Docker Registry
[!] Artifacts Repository
    [✓] example-healthy-repository [default]
    [!] example-failed-repository
        Error: Failed to initialize repository client: Retryable M4A_RepositoryFactoryMissingSecret: artifacts repository secret is configured, but not found at the designated location '/example-failed-repository'
[!] Source Status
[✓] Default storage class

저장소를 구성한 후 migctl doctor 명령어를 다시 실행하여 저장소가 올바르게 구성되었는지 확인할 수 있습니다.

  [✓] Deployment
  [✓] Docker registry
  [✓] Artifacts repo
  [!] Source Status

참고: 첫 번째 마이그레이션 소스를 정의할 때까지 소스 상태가 [!]로 표시됩니다. 마이그레이션 소스 추가(Linux) 또는 마이그레이션 소스 추가(Windows)를 참조하세요.

Google Cloud Console 지원

Google Cloud Console은 저장소 구현을 기준으로 저장소에 항목 URL을 표시합니다. 예를 들어 저장소가 S3를 사용하여 구현된 경우 Google Cloud 콘솔에 S3의 버킷에 대한 URL이 표시됩니다.

저장소 위치 옵션

데이터 저장소 위치는 마이그레이션 성능 및 비용에 영향을 줄 수 있습니다.

예를 들어 마이그레이션된 VM을 나타내는 Docker 이미지 파일은 상당히 클 수 있습니다. 온프레미스 처리 클러스터가 있지만 Google Cloud에서 GCR에 Docker 이미지 파일을 기록하면 데이터 업로드에 대한 성능 지연과 해당 데이터의 저장 비용이 발생합니다.

온프레미스 처리 클러스터의 경우 클러스터에 로컬로 Docker 레지스트리를 정의하는 것이 더 효율적일 수 있습니다. 레지스트리를 로컬로 설정함으로써 업로드 지연 시간 및 스토리지 비용을 최소화할 수 있습니다.

Google Cloud에 배포된 GKE 클러스터의 경우 기본 GCR 저장소를 사용하면 가장 높은 수준의 성능이 제공되지만 해당 스토리지에 대한 요금이 부과됩니다. 하지만 클라우드 기반 클러스터에 GCR을 사용할 필요는 없으며, 자신의 고유한 Docker 레지스트리를 사용하도록 선택할 수 있습니다.

저장소 이름 지정 요구사항

Migrate to Containers에 저장소를 추가할 때 저장소에 이름을 할당합니다. 이름은 다음 요구사항을 충족해야 합니다.

• 63자(영문 기준) 이하여야 합니다.
• 소문자 영숫자 문자 또는 '-'(하이픈)만 포함해야 합니다.
• 영숫자 문자로 시작해야 합니다.
• 영숫자 문자로 끝나야 합니다.

저장소 인증

Migrate to Containers에 사용되는 모든 저장소에는 인증이 필요합니다. 인증 메커니즘은 다음 표에 표시된 것처럼 저장소 유형에 따라 달라집니다.

저장소	구현	인증
Docker 이미지 파일 레지스트리	GCR	Google Cloud 서비스 계정의 JSON 키. 자세한 내용은 Container Registry 및 Cloud Storage에 액세스하기 위해 서비스 계정 만들기를 참조하세요.
	Docker 레지스트리	기본 인증에 사용되는 사용자 이름 및 비밀번호
마이그레이션 아티팩트 저장소	Cloud Storage	Google Cloud 서비스 계정의 JSON 키. 자세한 내용은 Container Registry 및 Cloud Storage에 액세스하기 위해 서비스 계정 만들기를 참조하세요.
	S3	액세스 키 및 보안 비밀 또는 사용자 인증 정보 파일입니다. 자세한 내용은 액세스 관리 개요를 참조하세요.

TLS 지원

일부 저장소는 HTTPS를 통해 TLS/SSL을 사용하여 액세스할 수 있습니다. 저장소에 대한 HTTPS 연결에 자체 서명된 인증서가 사용될 경우, 저장소를 구성할 때 다음 중 하나가 포함된 PEM 파일을 전달해야 합니다.

• 자체 서명된 인증서의 공개 키
• 루트 인증서 및 모든 중간 인증서부터 실제 서버 인증서까지의 연결

Docker 레지스트리 구성

migctl 명령어를 사용하여 Docker 레지스트리를 구성합니다. migctl 명령어를 사용하면 레지스트리 구성에서 다음 작업을 수행할 수 있습니다.

• 만들기
• 업데이트
• 삭제
• 목록
• 기본으로 설정

여러 구성을 정의할 수 있습니다. Migrate to Containers는 현재 기본값으로 정의된 구성을 사용합니다. migctl docker-registry list 명령어를 사용하여 기본값을 포함하여 현재 구성을 확인합니다. migctl docker-registry set-default 명령어를 사용하여 기본 구성을 설정합니다.

다음 예시에서는 Docker 레지스트리를 구성하는 방법을 보여줍니다.

• GCR

  migctl docker-registry create gcr registry-name --project project-id --json-key=m4a-install.json

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

  • registry-name은 Docker 레지스트리 구성에 대한 사용자 정의 이름입니다.

  • project-id는 Google 프로젝트 ID입니다.

  • m4a-install.json은 서비스 계정 구성의 설명대로 Container Registry 및 Cloud Storage에 액세스하기 위한 서비스 계정의 JSON 키 파일 이름입니다.

• Docker 레지스트리

  migctl docker-registry create basic-auth registry-name --registry-path url --username username --ca-pem-file ca-pem-filename

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

  • registry-name은 Docker 레지스트리 구성에 대한 사용자 정의 이름입니다.

  • url은 http:// 또는 https:// 프리픽스 없이 레지스트리의 URL을 지정합니다. 예를 들면 localhost:8080/myregistry입니다.

  • 레지스트리의 기본 인증 사용자 인증 정보에 대한 username입니다. 비밀번호를 입력하라는 메시지가 표시됩니다.

  • 레지스트리가 자체 서명된 인증서를 사용하는 경우 ca-pem-filename은 공개 키 또는 중간 CA 인증서에서 루트 인증서까지의 연결을 의미하는 전체 CA 체인을 포함하는 PEM 파일을 지정합니다. 예를 들면 다음과 같습니다.

    cat int1.pem int2.pem ... root.pem

나중에 레지스트리 구성을 업데이트하려면 구성을 생성할 때 사용한 것과 동일한 인수로 migctl docker-registry update 명령어를 실행합니다.

migctl docker-registry update gcr registry-name same-flags-as-create

Docker 레지스트리를 구성하면 기본 레지스트리가 됩니다. 하지만 여러 레지스트리를 정의할 수 있습니다. 레지스트리 현재 목록을 보려면 다음 안내를 따르세요.

migctl docker-registry list

기본 레지스트리 구성을 설정하여 마이그레이션에 현재 사용되는 항목만 구성하려면 다음 명령어를 사용합니다.

migctl docker-registry set-default registry-name

레지스트리 구성을 삭제하려면 다음 안내를 따르세요.

migctl docker-registry delete registry-name

아티팩트 저장소 구성

migctl 명령어를 사용하여 아티팩트 저장소를 구성합니다. migctl 명령어를 사용하면 저장소 구성에서 다음 작업을 수행할 수 있습니다.

• 만들기
• 업데이트
• 삭제
• 목록
• 기본으로 설정

migctl 명령어 create, update, list에는 모두 아티팩트 저장소에 대한 지속적인 상태 점검이 있습니다. 명령어가 실행되면 저장소 준비 여부를 나타내는 메시지와 관련 오류 메시지가 표시됩니다. create 또는 update에서 상태 점검을 건너뛰려면 --async 플래그와 함께 다음 명령어를 실행합니다.

여러 구성을 정의할 수 있습니다. Migrate to Containers는 현재 기본값으로 정의된 구성을 사용합니다. migctl artifacts-repo list 명령어를 사용하여 기본값을 포함하여 현재 구성을 확인합니다. migctl artifacts-repo set-default 명령어를 사용하여 기본 구성을 설정합니다.

다음 예시에서는 아티팩트 저장소를 구성하는 방법을 보여줍니다.

• Cloud Storage

  migctl artifacts-repo create gcs repository-name --bucket-name bucket-name --json-key=m4a-install.json

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

  • repository-name은 아티팩트 저장소 구성의 사용자 정의 이름입니다.

  • bucket-name은 Cloud Storage 저장소의 기존 버킷을 지정합니다. 기존 버킷이 없으면 버킷 만들기의 안내에 따라 버킷을 만듭니다.

    참고: Google Cloud의 클러스터에 Migrate for Containers를 설치하면 Migrate to Containers 설치 프로그램이 자동으로 다음 이름의 기본 버킷을 만듭니다.

    GCP_PROJECT-migration-artifacts

    여기서 GCP_PROJECT은 Google 프로젝트 ID입니다.

  • project-id는 Google 프로젝트 ID입니다.

  • m4a-install.json은 서비스 계정 구성의 설명대로 Container Registry 및 Cloud Storage에 액세스하기 위한 서비스 계정의 JSON 키 파일 이름입니다.

  migctl artifacts-repo create s3 repository-name --bucket-name bucket-name --region aws-region --access-key-id=key-id

  key-id의 보안 비밀 키를 입력하라는 메시지가 표시됩니다.

  또는 사용자 인증 정보 파일에 대한 경로를 지정합니다.

  migctl artifacts-repo create s3 repository-name --bucket-name bucket-name --region aws-region --credentials-file-path file-path

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

  • repository-name은 아티팩트 저장소 구성의 사용자 정의 이름입니다.

  • bucket-name은 S3 저장소의 기존 버킷을 지정합니다. 기존 버킷이 없으면 Amazon S3 버킷 작업의 안내에 따라 버킷을 만듭니다.

  • aws-region은 저장소의 AWS 리전을 지정합니다. 처리 클러스터 및 저장소는 클러스터에 저장소 액세스 권한이 있는 한 개별 리전에 배치될 수 있습니다.

  • key-id는 액세스 키를 지정합니다. 자세한 내용은 액세스 관리 개요를 참조하세요.

  • file-path은 사용자 인증 정보가 포함된 AWS 콘솔에서 다운로드한 CSV 파일의 경로를 지정합니다.

나중에 저장소 구성을 업데이트하려면 구성을 생성할 때 사용한 것과 동일한 인수로 migctl docker-registry update 명령어를 실행합니다.

migctl artifacts-repo update gcr repository-name same-flags-as-create

저장소 레지스트리를 구성하면 기본 저장소가 됩니다. 하지만 여러 저장소를 정의할 수 있습니다. 저장소 현재 목록을 보려면 다음 안내를 따르세요.

migctl artifacts-repo list

기본 저장소 구성을 설정하여 마이그레이션에 현재 사용되는 항목만 구성하려면 다음 명령어를 사용합니다.

migctl artifacts-repo set-default repository-name

저장소 구성을 삭제하려면 다음 안내를 따르세요.

migctl artifacts-repo delete repository-name

다음 단계

• 원격 설치를 위해 HTTPS 프록시를 구성하는 방법을 알아봅니다.