fbpx

【ACM】Anthos Config Managementを利用したGCPリソース管理 #1 Config Controllerを用いたリソース作成

GCP

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

皆さんは、GCP(Google Cloud Platform)のリソースをIaC(Infrastructure as Code)
で管理すると聞いて何を想像するでしょうか。
現在、Terraform, Ansible,Pulumi, ...などの様々なIaCソリューションがリリースされておりますが、本記事ではKubernetesクラスタで動作するAnthos Config Management(以下ACM)について、その導入方法と実際のリソースの作成手順について紹介したいと思います。

 

ACMとは？

参考：Anthos Config Management

具体的な導入手順の前に、まずACMの概要について説明します。
ACMはGoogle Anthos(オンプレミス・異なるクラウド環境をまたいでアプリケーションの実行環境を
構成できるプラットフォーム)のプロダクトの一つで、

  1. Policy Controller
    - セキュリティやコンプライアンスに沿ったポリシーを事前定義する
    - ポリシーに合致しないAPIリクエストをブロックできる
  2. Config Sync
    - Gitリポジトリに格納されている構成をKubernetesクラスタに継続的に反映、調整する
    - 各種Gitプラットフォームのパイプライン機能と組み合わせることで、CI/CDが可能になる
  3. Config Controller (本記事にて導入)
    - Google Cloud, Anthosのリソースのプロビジョニングとオーケストレーションを行う
    - yaml形式のファイル(kubernetesマニフェスト)によるリソース管理ができる

の3つのコンポーネントから構成されています。

上記のコンポーネントを組み合わせることで安全かつ効率的なリソース管理ができるようになる、
というのがACM導入の主なメリットです。
本記事ではその第一歩としてConfig Controllerが動作するクラスタを作成し、
実際にyamlファイル(マニフェスト)からGCPリソースを作成するまでを見ていきます。

 

Config Controllerの導入

参考：クイックスタート：Config Controller でリソースを管理する
それでは、実際にGCPリソースを作成してみましょう。

1.作業概要

- Config Controllerが動作するGKEクラスタを作成する
- Config Controller に必要な権限を付与する
- Cloud Shellからkubectlコマンドでマニフェストを読み込ませ、GCPリソースの作成を確認する

2.Config Controllerが動作するGKEクラスタを作成する

以下、Cloud Shellより操作を実施します。(また、一部のジョブID等はXXXXXと伏字としております)

2-1．プロジェクトを作成する(既存のプロジェクトに作成する場合は省略)
まず、Cloud Shellよりプロジェクト(ここでは、プロジェクト名:acm-test-1234)を作成します。

acm_test@cloudshell:~$ gcloud projects create acm-test-1234
Create in progress for [https://cloudresourcemanager.googleapis.com/v1/projects/acm-test-1234].
Waiting for [operations/cp.XXXXX] to finish...done. 
Enabling service [cloudapis.googleapis.com] on project [acm-test-1234]...
Operation "operations/acat.XXXXX" finished successfully.
acm_test@cloudshell:~$

2-2．プロジェクトを指定する

acm_test@cloudshell:~$ gcloud config set project acm-test-1234
Updated property [core/project].
acm_test@cloudshell:~ (acm-test-1234)$

ユーザー名@cloudshell:~ の後に黄色の文字で(プロジェクト名)が出力されれば準備完了です。

2-3．課金が有効となっていることを確認する

「お支払い」 >「マイ プロジェクト」タブ > 作成したプロジェクトの右側のメニューより、課金アカウントの設定ができるので、有効な課金アカウントを設定します。

2-4．KRM、GKE API、Resource Manager、Service Usage API を有効にする

続いて、プロジェクトにてAPIの有効化を実施します。
これには数分かかることがあります。

acm_test@cloudshell:~ (acm-test-1234)$ gcloud services enable krmapihosting.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com serviceusage.googleapis.com
Operation "operations/acf.XXXXX" finished successfully.
acm_test@cloudshell:~ (acm-test-1234)$

2-5．Config Controller インスタンスを作成する

ここまで準備を整えたところで、いよいよConfig Controller インスタンスの作成が可能になります。
下記の例ではクラスタ名をcc-example、リソースの作成先のリージョンはasia-northeast1(東京)と指定しております。

acm_test@cloudshell:~ (acm-test-1234)$ gcloud anthos config controller create cc-example --location=asia-northeast1 --full-management 
Create request issued for: [cc-example]
Waiting for operation [projects/acm-test-1234/locations/asia-northeast1/operations/operation-XXXXX] to complete...working.. 
<code translate="no" dir="ltr">Created instance [cc-example].
Fetching cluster endpoint and auth data.
kubeconfig entry generated for krmapihost-cc-example.

クラスタ作成の進捗状況については、GCPコンソールの「kubernetes」>「クラスタ」より各クラスタを選択することでも確認できます。
「クラスタの作成には5分以上かかります」という注記の通り、コマンドを打ってからクラスタが有効となるまでは少々時間がかかります。
(私が実行した際は10分前後でした。公式ドキュメントでは最大15分程度と記載があります)

また、実際に作成されるクラスタ名は krmapihost-(指定したクラスタ名)となります。

2-6．Config Controller エンドポイントと通信するようにkubectlを構成するため、必要な認証情報とエンドポイント情報を取得

本手順により、Cloud Shellから対象のクラスタに対してのkubectlコマンドが有効になります。

acm_test@cloudshell:~ (acm-test-1234)$ gcloud anthos config controller get-credentials cc-example  --location asia-northeast1
Fetching cluster endpoint and auth data.
kubeconfig entry generated for krmapihost-cc-example.
acm_test@cloudshell:~ (acm-test-1234)$

2-7．Config Controller インスタンスの一覧を表示して、インスタンスが作成されたことを確認

作成したクラスタはGCPコンソールからも確認可能ですが、下記コマンドにより対象のリージョンのクラスタをCloud Shellに出力させることができます。

acm_test@cloudshell:~ (acm-test-1234)$ gcloud anthos config controller list --location=asia-northeast1
NAME: cc-example
LOCATION: asia-northeast1
STATE: RUNNING
acm_test@cloudshell:~ (acm-test-1234)$

3．Config Controller に必要な権限を付与する

続いて、Config Controllerの実行に必要な権限を付与します。
3-1．サービス アカウントのメールアドレスを格納する環境変数を設定

acm_test@cloudshell:~ (acm-test-1234)$ export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control  -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
acm_test@cloudshell:~ (acm-test-1234)$

3-2．ポリシー バインディングを作成
出力は下記のようになります。

acm_test@cloudshell:~ (acm-test-1234)$ gcloud projects add-iam-policy-binding acm-test-1234 --member "serviceAccount:${SA_EMAIL}" --role "roles/owner" --project acm-test-1234
Updated IAM policy for project [acm-test-1234].
bindings:
- members:
  - serviceAccount:service-XXXXX@compute-system.iam.gserviceaccount.com
  role: roles/compute.serviceAgent
- members:
  - serviceAccount:service-XXXXX@container-engine-robot.iam.gserviceaccount.com
  role: roles/container.serviceAgent
- members:
  - serviceAccount:service-XXXXX@containerregistry.iam.gserviceaccount.com
  role: roles/containerregistry.ServiceAgent
- members:
  - serviceAccount:XXXXX-compute@developer.gserviceaccount.com
  - serviceAccount:XXXXX@cloudservices.gserviceaccount.com
  role: roles/editor
- members:
  - serviceAccount:service-XXXXX@gcp-sa-krmapihosting.iam.gserviceaccount.com
  role: roles/krmapihosting.serviceAgent
- members:
  - serviceAccount:service-XXXXX@gcp-sa-yakima.iam.gserviceaccount.com
  - user:XXXXX
  role: roles/owner
- members:
  - serviceAccount:service-XXXXX@gcp-sa-pubsub.iam.gserviceaccount.com
  role: roles/pubsub.serviceAgent
etag: XXXXX
version: 1
acm_test@cloudshell:~ (acm-test-1234)$

以上で権限の設定は完了です。

4．Cloud Shellからkubectlコマンドでマニフェストを読み込ませ、GCPリソースの作成を確認する

それでは、実際にマニフェストからGCPリソースの作成を実施してみます。

4-1．マニフェストを作成する
Cloud Shellに作業用ディレクトリを作成し、以下にyamlファイル(以降マニフェストと記載)を作成していきます。

acm_test@cloudshell:~ (acm-test-1234)$ mkdir ACM-test
acm_test@cloudshell:~ (acm-test-1234)$ cd ACM-test/
acm_test@cloudshell:~/ACM-test (acm-test-1234)$

公式ドキュメントの例の通り、Pub/Subトピック(Config Managementリソース名:PubSubTopic)のマニフェストを作成します。

下記2つのファイルについて、任意のテキストエディタで作成してください。

enable-pubsub.yaml(Pub/Sub APIを有効化)

# enable-pubsub.yaml
apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  name: pubsub.googleapis.com
  namespace: config-control
spec:
  projectRef:
    external: projects/acm-test-1234

pubsub-topic.yaml(Pub/Sub トピックを作成)

# pubsub-topic.yaml
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: acm-test-1234
  labels:
    label-one: "value-one"
  name: example-topic
  namespace: config-control

 

4-2．マニフェストを適用してリソースを作成する
作成したマニフェストをkubectl applyコマンドで適用することで、それぞれAPIの有効化とリソースの作成が始まります。
Cloud Shell上ではenable-pubsub.yamlのapplyはすぐに終わります(kubernetesのリソースとして作成された状態)が、そこから実際にPub/Sub APIの有効化処理が完了する(GCP側での処理が完了した状態)までは数分程度かかります。
Pub/Sub APIが有効化されない限りはPub/Sub トピックの作成もできないので、APIの有効化を確認してからPub/Sub トピックの作成に移ります。

・Pub/Sub APIを有効化するマニフェストのkubectl applyを実施

acm_test@cloudshell:~/ACM-test (acm-test-1234)$ kubectl apply -f enable-pubsub.yaml
service.serviceusage.cnrm.cloud.google.com/pubsub.googleapis.com created
acm_test@cloudshell:~/ACM-test (acm-test-1234)$

・Pub/Sub APIが有効化されていることを確認

・Pub/Sub トピックを作成するマニフェストのkubectl applyを実施

acm_test@cloudshell:~/ACM-test (acm-test-1234)$ kubectl apply -f pubsub-topic.yaml
pubsubtopic.pubsub.cnrm.cloud.google.com/example-topic created
acm_test@cloudshell:~/ACM-test (acm-test-1234)$

・PubSub トピック作成確認
下記の通り、マニフェストに記載した通りのPubSub トピックが作成されました。

4-3．マニフェストを削除してリソースを削除する

マニフェストから作成したリソースについては、他のリソースとの間に特段の依存関係が無ければkubectl deleteコマンドで削除できます。

acm_test@cloudshell:~/ACM-test (acm-test-1234)$ kubectl delete -f pubsub-topic.yaml
pubsubtopic.pubsub.cnrm.cloud.google.com "example-topic" deleted
acm_test@cloudshell:~/ACM-test (acm-test-1234)$

ここまで正常に実行できることが確認できれば、Config ConnectorでサポートされているGCPリソース(リファレンスを参照)であれば、所定の形式のマニフェストをapply,deleteすることで作成・削除することができます。

さらに、helmやkustomizeを導入することでより高度かつ効率的なリソース管理が可能になる…のですが、それはまたの機会に紹介とさせていただきたいです。

 

クリエーションラインでは、クラウドインフラの設計~構築~運用を幅広くカバーするクラウドエンジニアリングサービスを提供しています。導入を検討されている方はお気軽にお問い合わせください。

 

 

新規CTA