デプロイする Linux クラスタを準備する

このページでは、デプロイするターゲット クラスタの準備方法について説明します。

始める前に

このドキュメントは、すでに移行を完了し、生成されたアーティファクトがあることを前提としています。

ターゲット クラスタに Docker レジストリへの読み取りアクセス権が付与されていることを確認する

移行処理の中で、Migrate to Containers は移行された VM を表す Docker イメージを Docker レジストリにアップロードします。こうした Docker イメージは、移行する VM のファイルとディレクトリを表します。

Docker レジストリには、次のものを使用できます。

詳細については、データ リポジトリの定義をご覧ください。

移行に使用していない Google Cloud プロジェクトにワークロードをデプロイする

多くの場合、環境には複数の Google Cloud プロジェクトがあります。1 つの Google Cloud プロジェクトで移行を実行した後、移行したワークロードを別のプロジェクトのクラスタにデプロイする場合は、権限が正しく構成されていることを確認する必要があります。

たとえば、プロジェクト A で移行を行います。この場合、移行したワークロードはプロジェクト A の Container Registry バケットにコピーされます。例:

gcr.io/project-a/image_name:image_tag

次に、プロジェクト B のクラスタにワークロードをデプロイします。プロジェクト B のクラスタにはプロジェクト A にイメージを pull する権限がないため、権限を正しく構成しないと、ワークロード Pod の実行に失敗します。次の形式のメッセージを含むイベントが Pod に表示されます。

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 バケットへのアクセスに必要な権限を設定します。たとえば、次の gcloud storage コマンドを使用してアクセスを有効にします。

gcloud storage buckets add-iam-policy-binding gs://artifacts.project-a.appspot.com --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer

ターゲット クラスタへのデプロイで Container Registry を Docker レジストリとして使用する

ターゲット クラスタが Container Registry にアクセスできるようにするには、Container Registry へのアクセスに必要な認証情報を含む Kubernetes Secret を作成します。

  1. Container Registry と Cloud Storage にアクセスするためのサービス アカウントを作成するで説明されているように、移行をデプロイするためのサービス アカウントを作成します。

    このプロセスでは、m4a-install.json という名前の JSON キーファイルをダウンロードする必要があります。

  2. Container Registry にアクセスするために必要な認証情報を含む Kubernetes Secret を作成します。

    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 Secret の名前（この例では gcr-json-key）を指定します。
    • docker-server=gcr.io には、サーバーとして Container Registry を指定します。
    • docker-username=_json_key は、ユーザー名が JSON キーファイルに含まれていることを指定します。
    • docker-password は、JSON キーファイルからパスワードを使用する場合に指定します。
    • docker-email には、サービス アカウントのメールアドレスを指定します。

  3. 次のいずれかの方法で、Kubernetes Secret を設定します。

    • デフォルトの imagePullSecrets 値を次のように変更します。

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

    • deployment_spec.yaml ファイルを編集して、spec.template.spec 定義に imagePullSecrets 値を追加します。WebSphere traditional を使用する場合、Deployment 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 が存在する場合、ワークロード シークレットをデプロイします。Liberty を使用して、Tomcat ベースのワークロードと WebSphere traditional ベースのワークロード用に Secrets ファイルが作成されます。Liberty ファイルの名前は liberty-secrets.yaml です。

    kubectl apply -f secrets.yaml

Docker レジストリを使用してターゲット クラスタに基本認証でデプロイする

Docker レジストリを使用して移行イメージを保存する場合は、レジストリでユーザー名とパスワードを使用した基本認証がサポートされている必要があります。Docker レジストリへの読み取り専用接続を構成する方法は多数あるため、クラスタ プラットフォームと Docker レジストリに適した方法を使用する必要があります。

次のステップ