Google CloudのMigrate for Anthos and GKEは、オンプレミス環境や他のクラウド環境からGoogle Kubernetes Engine（GKE）へのアプリケーション移行を簡単に実現するためのサービスです。

この記事ではMigrate for Anthos and GKEの概要や実際に利用検証をした内容をご紹介します。（全4回）

• ・１：概要編
• ・２：「評価」
• ・３：「計画」前半
• ・４：「計画」後半～「デプロイ」 ★本記事

• ・計画（Plan）- 後半
• ・Migrate to Containersの準備
• ・デプロイ（Deploy）
• ・全体のまとめ

ここでは Migrate to Containersの準備を行います。

Migrate to Containersの準備をします。

APIの有効化とサービス アカウントの構成

（参考：Google サービスの有効化とサービス アカウントの構成）

公式ドキュメントを参照し、足りないAPIを有効化しておきます。手順は省略します。

サービスアカウントを作成します。

Migrate to Containersのインストール（移行先の追加）

（参考：Migrate to Containers のインストール）

Migrate to Containersの構築を行います。今回はCloud Consoleから実施します。

Anthos > Migrate to Containersで「ソースを追加」を選択し、「処理クラスタを追加」します。

「新しい処理クラスタの追加」ページでワークロードOSの種類、対象GKEクラスタ、アーティファクトリポジトリ（GCSバケット）、イメージリポジトリ（Container Registoryプロジェクト）名を入力します。

サービス アカウントは先ほど作成したものを指定します。そして「デプロイ」します。

移行元の追加

Anthos > Migrate to Containersで「ソースを追加」します。

処理クラスタを選択します。

ソースの名称を入力し、ソースにCompute Engineを選択します。

移行対象のGCEが存在するプロジェクトを選択し、事前に作成したサービスアカウント（m4a-ce-src@bs-gcp-dev.iam.gserviceaccount.com）を指定します。

設定内容を確認して「ソースを追加」します。

移行元と移行先の確認

追加したソースを確認してみます。

「ソースを管理」を押下すると、遷移先のページで「Migrate to Containersのインストール」で追加したソースが確認できます。

また、「移行先と候補」タブで追加したソースを選択すると、移行元としてCompute Engineのインスタンスを確認できます。

移行計画の作成

（参考：移行計画を作成する > Linux ワークロードと Windows ワークロード）

Anthos > Migrate to Containersで「移行の作成」を押下し、次の内容（カッコ内は今回の設定値）を指定して「移行を作成」します。

• ・移行名（migrate-apatch-server）
• ・ソース（migrate-to-container01 – cluster-anthos）
• ・ワークロードタイプ（ Linux system container ）
• ・VM ID（anthos01）

移行計画の作成が完了しました。

GKEデプロイを行います。

モニタリングタブで「アーティファクトの生成」を押下します。

アーティファクトが生成できました。

生成が完了すると、GCSバケットに各種ファイルが生成されます。

上記で生成されたアーティファクトのうち、deployment_spec.yamlをダウンロードして、Podを公開するためにを設定を追加します。一番下にサービスをLoadBalancerタイプのサービスを追加しています。

# Stateless application specification
        # The Deployment creates a single replicated Pod, indicated by the 'replicas' field
        apiVersion: apps/v1
        kind: Deployment
        metadata:
        creationTimestamp: null
        labels:
        anthos-migrate.cloud.google.com/type: linux-container
        app: anthos01
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: v1.14.0
        name: anthos01
        spec:
        replicas: 1
        selector:
        matchLabels:
        anthos-migrate.cloud.google.com/type: linux-container
        app: anthos01
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: v1.14.0
        strategy: {}
        template:
        metadata:
        creationTimestamp: null
        labels:
        anthos-migrate.cloud.google.com/type: linux-container
        app: anthos01
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: v1.14.0
        spec:
        containers:
        - env:
        - name: HC_V2K_SERVICE_MANAGER
        value: "true"
        image: gcr.io/bs-gcp-dev/anthos01:4-5-2023--11-9-45
        imagePullPolicy: IfNotPresent
        livenessProbe:
        exec:
        command:
        - /gamma
        - probe
        name: anthos01
        readinessProbe:
        exec:
        command:
        - /gamma
        - probe
        resources: {}
        ---
        # Headless Service specification -
        # No load-balancing, and a single cluster internal IP, only reachable from within the cluster
        # The Kubernetes endpoints controller will modify the DNS configuration to return records (addresses) that point to the Pods, which are labeled with "app": "anthos01"
        apiVersion: v1
        kind: Service
        metadata:
        creationTimestamp: null
        labels:
        anthos-migrate.cloud.google.com/type: linux-container
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: v1.14.0
        name: anthos01
        spec:
        clusterIP: None
        selector:
        app: anthos01
        type: ClusterIP
        ---
        apiVersion: v1
        kind: Service
        metadata:
        name: test-service
        spec:
        selector:
        app: anthos01
        ports:
        - protocol: TCP
        port: 80
        targetPort: 80
        type: LoadBalancer
        ---
        

必要に応じてkubectlをインストールします。（参考：kubectl をインストールし、クラスタ アクセスを構成する）

変更したdeployment_spec.yamlをもってkubectl applyします。

k_shiga@cloudshell:~ (bs-gcp-dev)$ kubectl apply -f deployment_spec.yaml
        deployment.apps/anthos01 created
        service/anthos01 created
        service/test-service created
        k_shiga@cloudshell:~ (bs-gcp-dev)$ kubectl get service test-service
        NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
        test-service LoadBalancer 10.112.13.253 <pending> 80:31755/TCP 19s
        k_shiga@cloudshell:~ (bs-gcp-dev)$ kubectl get service
        NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
        anthos01 ClusterIP None <none> <none> 35s
        kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 2d3h
        test-service LoadBalancer 10.112.13.253 <pending> 80:31755/TCP 35s
        k_shiga@cloudshell:~ (bs-gcp-dev)$ kubectl get service
        NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
        anthos01 ClusterIP None <none> <none> 29m
        kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 2d3h
        test-service LoadBalancer 10.112.13.253 34.84.161.69 80:31755/TCP 29m
        

最後の行を見ると、追加したサービス（test-service）による EXTERNAL-IP が割り当てられていることがわかります。

動作確認

ブラウザからアクセスを確認してみると、正常にページが表示できました。

以上、Migrate for Anthos and GKEをで実際にシンプルなWebサーバを移行してみました。実際の検証を通して次のメリットを感じました。

• ・適合性評価ツールの実行で着手前に問題点を洗い出せること
• ・手動での再構築と比べてかかる工数が少ないこと
• ・豊富な公式ドキュメントを参照しながら作業できること

実務上の厳しい要件の中で利用するとなると、もっと多くの検討事項が出てくるかもしれませんが、適合性評価ツールの利用だけでも移行の工数を削減できるかもしれません。マッチしそうなケースに当たったらぜひ一度利用してみてください。