배포용 Linux 클러스터 준비

이 페이지에서는 배포할 대상 클러스터를 준비하는 방법을 설명합니다.

시작하기 전에

이 문서에서는 이미 마이그레이션이 완료되었고 그 결과 아티팩트가 생성되었다고 가정합니다.

대상 클러스터에 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 레지스트리에 적합한 방법을 사용해야 합니다.

다음 단계