コンテナを Cloud Run にデプロイする

デフォルトで提供されているセキュリティ強化された Linux サービスマネージャーを使用してコンテナワークロードを移行する場合は、コンテナに追加の変更を行うことなく、Cloud Run にコンテナをデプロイできます。

Cloud Run にコンテナをデプロイするには:

Migrate to Containers バージョン 1.15.0 をインストールします。
今までと同様に既存のランタイムを使用して、移行元を追加して移行を作成します。
必要に応じて、移行計画をカスタマイズします。

注: Migrate to Containers 1.10 以前では、強化された Linux サービスマネージャーの使用はデフォルトで無効になっています。Migrate to Containers 1.9 以前を使用している場合は、移行計画（my-migration.yaml）で v2kServiceManager を true に設定する必要があります。強化された Linux サービスマネージャーが無効になっている場合は、新しいランタイムで動作しない可能性があるサービスについて、services.yaml ファイルのコメントを確認してください。無効になっているサービスを含める場合は、サポートにお問い合わせください。
1. 移行計画をダウンロードします。移行計画は AppXGenerateArtifactsFlow で表されます。
  
  たとえば、「my-migration」という名前の移行の場合は、次のようになります。
```
migctl migration get my-migration
```
2. テキストエディタで、ダウンロードした移行計画（my-migration.yaml）を開きます。
3. 強化された Linux サービスマネージャーを確認します。v2kServiceManager フラグはデフォルトで true に設定されています。ただし、Migrate to Containers が、サービスマネージャーでサポートされていないシステムサービスを検出した場合はアラートが返され、v2kServiceManager フラグは false に設定されます。フラグが false の場合、移行はサービスをサポートする従来のランタイムを使用します。
  
  サポートされていないサービスとともに、次のアラートが表示されます。
```
Service is not supported by v2k service manager, therefore legacy runtime
will be used instead of v2k service manager, and migrated workload would
not fit running on Autopilot clusters of Cloudrun.
```
  サポートされていないサービスが見つかった場合は、フラグを手動で true に設定することもできます。この場合、実行されない可能性のあるサポート対象外のサービスを生成イメージで維持することも、サービスを移行計画から削除して除外することもできます。
  
  新しいサービスマネージャーを有効にするには、フラグを true にリセットします。
```
v2kServiceManager: true
```
4. 移行計画のカスタマイズに説明されているように、移行に必要なその他のカスタマイズを行います。
5. 編集が終わったら、編集したファイルを保存します。
6. 編集した移行計画をアップロードします。
```
migctl migration update my-migration --main-config my-migration.yaml
```
これまでと同様に、既存のランタイムを使用して移行アーティファクトを生成し、確認します。
新しい services-config.yaml ファイルを編集して、コンテナの初期化プロパティを構成します。ファイルを保存してコンテナイメージを再ビルドし、変更を適用します。

services.yaml ファイルの編集方法については、services-config.yaml の使用をご覧ください。
移行アーティファクトを生成したら、エディタで deployment_spec.yaml ファイルを開き、コンテナイメージの場所を確認します。たとえば、次のようになります。
```
spec:
  containers:
  - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
```
ここで、gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL は、コンテナイメージの場所を表します。
次のコマンドを使用して、Cloud Run にコンテナをデプロイします。
```
gcloud run deploy my-runtime
    --image gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
    --region REGION --platform managed
    --set-env-vars=HC_V2K_SERVICE_MANAGER=true --port PORT 
```
--set-env-vars プロパティでは、強化された Linux サービスマネージャーを有効にするために、HC_V2K_SERVICE_MANAGER 環境変数を true に設定します。

--port プロパティでは、コンテナに送信されるリクエストのポートを指定します。デフォルトのポートは、8080 です。

例: Cloud Run にクイックスタートコンテナをデプロイする

最新のクイックスタートガイドに沿って、シンプルウェブサーバーを含むコンテナを移行し、Cloud Run にデプロイします。クイックスタートプロセスには、次の変更のみを行う必要があります。

VM を移行するのステップ 3（移行計画の確認）で、移行計画の v2kServiceManager を true に設定して、計画を保存します。
```
v2kServiceManager: true
```
移行が完了したら、エディタで deployment_spec.yaml ファイルを開いてコンテナの場所を確認します。たとえば、次のようになります。
```
spec:
  containers:
  - image: gcr.io/PROJECT_NAME/quickstart-instance:LABEL
```

移行されたワークロードをデプロイするセクションで、次のコマンドを使用してコンテナイメージを Cloud Run にデプロイします。

gcloud run deploy my-runtime
    --image gcr.io/PROJECT_NAME/quickstart-instance:LABEL
    --region REGION --platform managed
    --set-env-vars=HC_V2K_SERVICE_MANAGER=true --port 80

移行されたコンテナのウェブサーバーは、ポート 80 でリクエストをリッスンするため、コンテナをデプロイする際は、必ずこのポートを指定してください。

次のレスポンスが表示されます。ここには、Cloud Run サービスの URL が含まれています。

Allow unauthenticated invocations to [my-runtime] (y/N)?  y

Deploying container to Cloud Run service [my-runtime] in project [PROJECT_NAME] region [REGION]
Deploying new service... Done.
  ✓ Creating Revision…
  ✓ Routing traffic…
    Setting IAM Policy…
Done.
Service [my-runtime] revision [my-runtime-00001-sas] has been deployed and is serving 100 percent of traffic.
Service URL: https://my-runtime-s5ahdq-uc.a.run.app

Cloud Shell からそのサービスの URL を使用してコンテナにリクエストを行い、ユーザーの認証情報でアクセスします。
```
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://my-runtime-s5ahdq-uc.a.run.app
```
これで「Hello World!」ページが表示されます。

次のステップ

services-config.yaml の使用方法を学習する。

コンテナを Cloud Run にデプロイする

例: Cloud Run にクイックスタート コンテナをデプロイする

次のステップ

例: Cloud Run にクイックスタートコンテナをデプロイする