連載 [第7回] :
今日からはじめる Pulumiでカンタン インフラ運用・管理Pulumi Kubernetes Operatorを活用してPulumiのCI/CDを実現しよう
2023年9月13日(水)

第7回となる今回は、PulumiにおけるCI/CDの概要を解説し、Pulumi Kubernetes Operatorを利用してPulumi Programを自動デプロイするハンズオンを実践していきます。
・Pulumi Stack CustomResourceデプロイ
公式が用意するmanifestから適宜値を差し替えて、AWS認証用のsecretとStackを作成していきます。Stack作成前はAWS S3 Bucket(GitHubにpushした「my-bucket」)は作成されていませんが、Stackが作成されるとreconciliation-loopが実行され、自動的にBucketが作成される想定です。
- OperatorがPulumi Cloudにアクセスするためのcredential secretを作成します。「pulumi-secret.yaml」ファイルを作成して、以下のyamlを記載します。「<REDACTED: PULUMI_ACCESS_TOKEN>」の部分は、事前準備の手順「Pulumi Service Backend Access Token生成」で取得したTokenの値を入力します。
01
[cloudshell-user@ip-10-6-35-57 yaml]$ cd ~
02
03
[cloudshell-user@ip-10-6-35-57 ~]$ vi pulumi-secret.yaml
04
~~~
05
apiVersion: v1
06
kind: Secret
07
metadata:
08
name: pulumi-api-secret
09
type: Opaque
10
stringData:
11
accessToken: "<REDACTED: PULUMI_ACCESS_TOKEN>" ← 取得したPulumi AccessTokenに書き換える
- ファイルの編集を終えたら、kubectlでsecretをapplyします。
01
[cloudshell-user@ip-10-6-35-57 ~]$ kubectl apply -f pulumi-secret.yaml
02
03
secret/pulumi-api-secret created
04
05
[cloudshell-user@ip-10-6-35-57 ~]$ kubectl describe secret pulumi-api-secret
06
Name: pulumi-api-secret
07
Namespace: default
08
Labels: <none>
09
Annotations: <none>
10
11
Type: Opaque
12
13
Data
14
====
15
accessToken: 44 bytes
- 次にOperatorがAWSリソースへアクセスするためのcredential secretを作成します。「aws-secret.yaml」ファイルを作成して、以下のyamlを記載します。それぞれの「<REDACTED>」の部分は、事前準備の手順「AWS Access用 credential生成」で取得したTokenの値をそれぞれ入力します。
01
[cloudshell-user@ip-10-6-35-57 ~]$ vi aws-secret.yaml
02
~~~
03
apiVersion: v1
04
kind: Secret
05
metadata:
06
name: pulumi-aws-secrets
07
type: Opaque
08
stringData:
09
AWS_ACCESS_KEY_ID: "<REDACTED: AWS_ACCESS_KEY_ID>"
10
AWS_SECRET_ACCESS_KEY: "<REDACTED: AWS_SECRET_ACCESS_KEY>"
11
AWS_SESSION_TOKEN: "<REDACTED: AWS_SESSION_TOKEN>"
- ファイルの編集を終えたら、kubectlでsecretをapplyします。
01
[cloudshell-user@ip-10-6-35-57 ~]$ kubectl apply -f aws-secret.yaml
02
secret/pulumi-aws-secrets created
03
04
[cloudshell-user@ip-10-6-35-57 ~]$ kubectl describe secret pulumi-aws-secret
05
06
—
07
Name: pulumi-aws-secrets
08
Namespace: default
09
Labels: <none>
10
Annotations: <none>
11
12
Type: Opaque
13
14
Data
15
====
16
AWS_ACCESS_KEY_ID: 20 bytes
17
AWS_SECRET_ACCESS_KEY: 40 bytes
18
AWS_SESSION_TOKEN: 488 bytes
- Pulumi CloudおよびAWSリソース作成のcredential secretが作成できたので、いよいよStackを作成していきます。「pulumi-stack.yaml」ファイルを作成して、以下のyamlを記載します。それぞれの「<ACCOUNT_NAME>」の部分はPulumi Cloudのアカウント名を入力します。「projectRepo:」には自身で用意したGitHubレポジトリ「operator-test」のURLを記載します。reconciliation-loopの対象は「mainブランチ」を指定したブランチの同期を設定します。
01
[cloudshell-user@ip-10-6-35-57 ~]$ vi pulumi-stack.yaml
02
~~~
03
apiVersion: pulumi.com/v1
04
kind: Stack
05
metadata:
06
name: s3-bucket-stack
07
spec:
08
envRefs:
09
PULUMI_ACCESS_TOKEN:
10
type: Secret
11
secret:
12
name: pulumi-api-secret
13
key: accessToken
14
AWS_ACCESS_KEY_ID:
15
type: Secret
16
secret:
17
name: pulumi-aws-secrets
18
key: AWS_ACCESS_KEY_ID
19
AWS_SECRET_ACCESS_KEY:
20
type: Secret
21
secret:
22
name: pulumi-aws-secrets
23
key: AWS_SECRET_ACCESS_KEY
24
AWS_SESSION_TOKEN:
25
type: Secret
26
secret:
27
name: pulumi-aws-secrets
28
key: AWS_SESSION_TOKEN
29
stack: <ACCOUNT_NAME>/operator-test/dev
30
projectRepo: https://github.com/<GitHub_Account_name>/operator-test
31
branch: main
32
config:
33
aws:region: ap-northeast-1
- ファイルの編集を終えたら、kubectlでsecretをapplyします。
01
[cloudshell-user@ip-10-6-35-57 ~]$ kubectl apply -f pulumi-stack.yaml
02
03
stack.pulumi.com/s3-bucket-stack created
04
05
[cloudshell-user@ip-10-6-35-57 ~]$ kubectl describe Stack s3-bucket-stack
06
—
07
Name: s3-bucket-stack
08
Namespace: default
09
Labels: <none>
10
Annotations: <none>
11
API Version: pulumi.com/v1
12
Kind: Stack
13
Metadata:
14
Creation Timestamp: 2023-09-01T08:57:07Z
15
Generation: 1
16
Resource Version: 14456
17
UID: 29a5b0f8-1701-4d82-8238-e904c9c4304b
18
~~~
しばらく経つと、GitHubレポジトリにpushしたProgramのリソース(S3 Bucket「my-bucket」)が自動的に作成されているのが確認できます。StackControllerが自動的にGitHubのProgramを読み込み、Kubernetes内部でStackリソース(Stack CustomResource)が作成され、それに基づいて実体のリソース(S3 Bucket「my-bucket」)も作成される流れとなります。
この時点でStack CustomResourceをdescribeすると、同期したGitHubレポジトリのcommitと、その同期ステータス(succeed)を確認できます。同期でエラーなどが発生した際は、このdescribeの出力でエラーメッセージを確認できます。
01 | [cloudshell-user@ip-10-6-43-90 ~]$ kubectl describe Stack |
02 | Name: s3-bucket-stack |
03 | ~~~ |
04 | Status: |
05 | Conditions: |
06 | Last Transition Time: 2023-09-01T16:04:22Z |
07 | Message: the stack has been processed and is up to date |
08 | Reason: ProcessingCompleted |
09 | Status: True |
10 | Type: Ready |
11 | Last Update: |
12 | Last Attempted Commit: cedd9734b15c22b9314cca9c9b114d26575d51a4 |
13 | Last Resync Time: 2023-09-01T16:02:48Z |
14 | Last Successful Commit: cedd9734b15c22b9314cca9c9b114d26575d51a4 |
15 | Permalink: https://app.pulumi.com/***/operator-test/dev/updates/1 |
16 | State: succeeded |
17 | ~~~ |
連載バックナンバー
Think ITメルマガ会員登録受付中
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
全文検索エンジンによるおすすめ記事
- PulumiでAWSリソースをデプロイしよう
- Kubeflowを構築する
- SecretもPulumiで使いこなしたい! PulumiのSecurityを試してみよう
- Pulumiの最新機能「Pulumi ESC」を使ってみよう
- 「Pulumi Automation API」でPulumi CLIの機能をコード化しよう
- コンテナ上のマイクロサービスの認証強化 ~StrimziとKeycloak~
- 既に存在するリソースをPulumiで管理してみよう
- Policy as Codeでインフラのコンプライアンスを自動実現! 「Pulumi CrossGuard」を活用してみよう
- NGINX Ingress Controllerの柔軟なアプリケーション制御、具体的なユースケースと設定方法を理解する
- TerraformからPulumiへの移行