Slide 1
Slide 1 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Infrastructure as Code の
静的テスト戦略
チェシャ猫 (@y_taka_23)
DevOpsDays Tokyo 2021 (16th Apr. 2021)
Slide 2
Slide 2 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
「Infrastructure as Code 辛い」
Slide 3
Slide 3 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
「デプロイしてみたら上手く動かない」
Slide 4
Slide 4 text
#DevOpsDaysTokyo
本日のアジェンダ
● なぜ IaC に静的テストが必要なのか
● AWS 上で IaC を実現する上で考えるべきこと
● IaC をテストする上での戦略とツール
Slide 5
Slide 5 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
IaC における「静的」テスト
Why Predictability Matters in IaC?
Slide 6
Slide 6 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Infrastructure as Code って何だっけ？
Slide 7
Slide 7 text
#DevOpsDaysTokyo
Infrastructure as Code って何だっけ？
● ソフトウェア開発のプラクティスをインフラの
オートメーションに活かすアプローチ
○ Git によるバージョン管理
○ Pull Request によるレビュー
○ 継続的なテスト
○ etc...
『Infrastructure as Codeクラウドにおける
サーバ管理の原則とプラクティス』
https://www.oreilly.co.jp/books/9784873117966/
Slide 8
Slide 8 text
#DevOpsDaysTokyo
Infrastructure as Code って何だっけ？
● ダイナミックインフラプラットフォーム (AWS)
○ サーバやストレージの提供
● インフラ定義ツール (CFn, Terraform)
○ サーバやストレージの構成・設定管理
● サーバ構成ツール (Ansible, Chef)
○ サーバ自身の中身の設定
● インフラサービス (CloudWatch など)
○ インフラやアプリの管理支援
Slide 9
Slide 9 text
#DevOpsDaysTokyo
Mutable Immutable
Local
Global
Slide 10
Slide 10 text
#DevOpsDaysTokyo
Local
Global
影響範囲が個々のリソースで完結する
影響範囲がリソースをまたいで全体に及ぶ
Slide 11
Slide 11 text
#DevOpsDaysTokyo
Mutable Immutable
既存のリソースに
重ねがけして更新
一度更地にして
ゼロから再構築
Slide 12
Slide 12 text
#DevOpsDaysTokyo
Mutable Immutable
Local
Global
CloudFormation Terraform
Ansible Chef Kubernetes Docker
Slide 13
Slide 13 text
#DevOpsDaysTokyo
Mutable Immutable
Local
Global
CloudFormation Terraform
Ansible Chef Kubernetes Docker
今回注目したいのは
Global + Mutable
Slide 14
Slide 14 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
なぜ Global + Mutable は辛いのか？
Slide 15
Slide 15 text
#DevOpsDaysTokyo
インフラの現状がカオス
● Global: 局所的改善の困難さ
● Mutable: 歪みの蓄積
Slide 16
Slide 16 text
#DevOpsDaysTokyo
インフラの現状がカオス
何かが壊れそうで心配
● 失敗経験
● IaC への不信
● 組織の力関係
● Global: 局所的改善の困難さ
● Mutable: 歪みの蓄積
Slide 17
Slide 17 text
#DevOpsDaysTokyo
インフラの現状がカオス
何かが壊れそうで心配
例外的な作業
● 失敗経験
● IaC への不信
● 組織の力関係
● Global: 局所的改善の困難さ
● Mutable: 歪みの蓄積
Slide 18
Slide 18 text
#DevOpsDaysTokyo
インフラの現状がカオス
何かが壊れそうで心配
例外的な作業
● 失敗経験
● IaC への不信
● 組織の力関係
● 不均一な構成
● システム疲労
● ノウハウ散逸
● Global: 局所的改善の困難さ
● Mutable: 歪みの蓄積
Slide 19
Slide 19 text
#DevOpsDaysTokyo
インフラの現状がカオス
何かが壊れそうで心配
例外的な作業
塩漬けインフラ負のサイクル
(オートメーション恐怖症)
● 失敗経験
● IaC への不信
● 組織の力関係
● 不均一な構成
● システム疲労
● ノウハウ散逸
● Global: 局所的改善の困難さ
● Mutable: 歪みの蓄積
Slide 20
Slide 20 text
#DevOpsDaysTokyo
インフラの現状がカオス
何かが壊れそうで心配
例外的な作業
塩漬けインフラ負のサイクル
(オートメーション恐怖症)
● 失敗経験
● IaC への不信
● 組織の力関係
● 不均一な構成
● システム疲労
● ノウハウ散逸
● Global: 局所的改善の困難さ
● Mutable: 歪みの蓄積
Slide 21
Slide 21 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
「何が起こるかわからない」を減らせばよい
Slide 22
Slide 22 text
#DevOpsDaysTokyo
#CODT2020
予測可能性
Predictability
Slide 23
Slide 23 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
アプリ開発と IaC を比較すると
Slide 24
Slide 24 text
#DevOpsDaysTokyo
開発の V 字モデル
要件定義
コーディング
受け入れテスト
結合テスト
単体テスト
外部設計
内部設計
Slide 25
Slide 25 text
#DevOpsDaysTokyo
開発の V 字モデル
要件定義
コーディング
受け入れテスト
結合テスト
単体テスト
外部設計
内部設計
Slide 26
Slide 26 text
#DevOpsDaysTokyo
インフラの V 字モデル？
アプリ仕様
IaC 実装
E2E テスト
Serverspec など
環境一揃い
個別リソース
Slide 27
Slide 27 text
#DevOpsDaysTokyo
インフラの V 字モデル？
アプリ仕様
IaC 実装
E2E テスト
Serverspec など
単体テストの不在
環境一揃い
個別リソース
Slide 28
Slide 28 text
#DevOpsDaysTokyo
インフラの V 字モデル？
アプリ仕様
IaC 実装
E2E テスト
Serverspec など
単体テストの不在
環境一揃い
個別リソース
デプロイの壁
Slide 29
Slide 29 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
「デプロイの壁」の手前でテストできれば
IaC もアプリ開発により近づける！
Slide 30
Slide 30 text
#DevOpsDaysTokyo
Section 1 のまとめ
● IaC = アプリ開発プラクティスのインフラへの応用
○ 今回は Global + Mutable の領域にフォーカス
● 予測可能性をいかに担保するか？
○ 実行時に「何が起こるかわからない」という恐怖の克服
● アプリに寄せたテスト戦略
○ 静的（= デプロイ前）テストで「何が起こるか」を見切る
Slide 31
Slide 31 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
AWS における予測可能性
How to Manage IaC Predictability on AWS?
Slide 32
Slide 32 text
#DevOpsDaysTokyo
予測可能性の 3 要素
● 再現性 (Reproducibility)
○ 同じ操作を誰でも、いつでも繰り返すことができる
● 純粋性 (Purity)
○ 実行前の状態によらず、結果が常に同じになる
● モジュール性 (Modularity)
○ 再利用可能な部品が記述しやすい仕組みを備える
Slide 33
Slide 33 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
純粋性？ 冪等性じゃなくて？
Slide 34
Slide 34 text
#DevOpsDaysTokyo
冪等性 vs 純粋性
● デプロイはパラメータ x と事前状態 e の関数
○ 返り値は変更後の状態：e’ = f (x, e)
● 冪等性：複数回実行しても結果が一定
○ 任意のパラメータ x と事前状態 e に対して f (x, f (x, e)) = f (x, e)
● 純粋性：実行前の状態によらず結果が一定
○ 任意のパラメータ x と事前状態 e1, e2 に対して f (x, e1) = f (x, e2)
Slide 35
Slide 35 text
#DevOpsDaysTokyo
冪等性 vs 純粋性
● デプロイはパラメータ x と事前状態 e の関数
○ 返り値は変更後の状態：e’ = f (x, e)
● 冪等性：複数回実行しても結果が一定（純粋なら冪等）
○ 任意のパラメータ x と事前状態 e に対して f (x, f (x, e)) = f (x, e)
● 純粋性：実行前の状態によらず結果が一定
○ 任意のパラメータ x と事前状態 e1, e2 に対して f (x, e1) = f (x, e2)
Slide 36
Slide 36 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
より具体的に、AWS で考えると
Slide 37
Slide 37 text
#DevOpsDaysTokyo
IaC on AWS の 4 ステップ
マネジメント
コンソール
AWS CLI
CloudFormation
CDK
(Cloud Dev. Kit)
Slide 38
Slide 38 text
#DevOpsDaysTokyo
IaC on AWS の 4 ステップ
マネジメント
コンソール
AWS CLI
CloudFormation
CDK
(Cloud Dev. Kit)
予測可能性
Slide 39
Slide 39 text
#DevOpsDaysTokyo
マネジメントコンソール
● 人間が手作業でリソースを作成
○ ナイーブだが直感的で融通も利く
● 予測可能性は最も低い
○ 再現性：なし
○ 純粋性：なし
○ モジュール性：なし
Slide 40
Slide 40 text
#DevOpsDaysTokyo
AWS CLI
● シェルスクリプトなどと組み合わせて自動化
○ 機能面では扱える API が最も多い
● 予測可能性はあまり高くない
○ 再現性：あり（繰り返し実行可）
○ 純粋性：なし
○ モジュール性：ほとんどなし
Slide 41
Slide 41 text
#DevOpsDaysTokyo
CloudFormation
● YAML による宣言的な定義
○ 必要な操作ではなく望まれる状態を記述
● 予測可能性はだいぶ改善した
○ 再現性：あり
○ 純粋性：一応あり（宣言的記述、衝突しない名前の生成）
○ モジュール性：かなり乏しい
Slide 42
Slide 42 text
#DevOpsDaysTokyo
Cloud Development Kit (CDK)
● プログラムで CloudFormation 用 YAML を生成
○ TypeScript / Python / Java / .NET / Go ライブラリ
○ IDE が使える、型があるので YAML より書くのが楽
● 現状で予測可能性は最も良好
○ 再現性：あり
○ 純粋性：一応あり（実質 CloudFormation と同等）
○ モジュール性：あり (再利用・配布可能な Construct)
Slide 43
Slide 43 text
#DevOpsDaysTokyo
SQS: MyQueue
Subscribe
SNS: MyTopic
MyStack
https://cdkworkshop.com/20-typescript/20-create-project/300-structure.html
Slide 44
Slide 44 text
#DevOpsDaysTokyo
export class MyStack extend cdk.Stack {
constructor(...) {
super(...);
const queue = new sqs.Queue(this, 'MyQueue', {
visibilityTimeout = cdk.Duration.Seconds(300)
});
const topic = new sns.Topic(this, 'MyTopic');
topic.addSubscription(new subs.SqsSubscription(queue));
}
}
SQS: MyQueue
Subscribe
SNS: MyTopic
MyStack
Slide 45
Slide 45 text
#DevOpsDaysTokyo
export class MyStack extend cdk.Stack {
constructor(...) {
super(...);
const queue = new sqs.Queue(this, 'MyQueue', {
visibilityTimeout = cdk.Duration.Seconds(300)
});
const topic = new sns.Topic(this, 'MyTopic');
topic.addSubscription(new subs.SqsSubscription(queue));
}
}
SQS: MyQueue
Subscribe
SNS: MyTopic
MyStack
scope（親要素）
Slide 46
Slide 46 text
#DevOpsDaysTokyo
cdk synth
aws cloudformation
deploy
export class MyStack extend cdk.Stack {
constructor(...) {
super(...);
const queue = new sqs.Queue(this, 'MyQueue', {
visibilityTimeout = cdk.Duration.Seconds(300)
});
const topic = new sns.Topic(this, 'MyTopic');
topic.addSubscription(new subs.SqsSubscription(queue));
}
}
Slide 47
Slide 47 text
#DevOpsDaysTokyo
cdk synth
aws cloudformation
deploy
Resources:
MyQueueXXXXXX:
Type: AWS::SQS::Queue
Properties: ...
MyQueuePolicyXXXXXX:
Type: AWS::SQS::QueuePolicy ...
MyTopicXXXXXX:
Type: AWS::SNS::Topic ...
MyQueueMyStackMyTopicXXXXXX:
Type: AWS::SNS::Subscription ...
Slide 48
Slide 48 text
#DevOpsDaysTokyo
cdk synth
aws cloudformation
deploy
Resources:
MyQueueXXXXXX:
Type: AWS::SQS::Queue
Properties: ...
MyQueuePolicyXXXXXX:
Type: AWS::SQS::QueuePolicy ...
MyTopicXXXXXX:
Type: AWS::SNS::Topic ...
MyQueueMyStackMyTopicXXXXXX:
Type: AWS::SNS::Subscription ...
CDK では明示していない
= Construct が内包
Slide 49
Slide 49 text
#DevOpsDaysTokyo
cdk diff
cdk deploy
Slide 50
Slide 50 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
再利用可能な Construct の自作も可能
Slide 51
Slide 51 text
#DevOpsDaysTokyo
API
Count Hits
Slide 52
Slide 52 text
#DevOpsDaysTokyo
Custom
Construct
API
Count Hits
https://cdkworkshop.com/20-typescript/40-hit-counter.html
Slide 53
Slide 53 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor() {
const table = new dynamodb.Table(this, 'Hits', {
partitionKey: { ... }
});
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
}
}
Slide 54
Slide 54 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor() {
const table = new dynamodb.Table(this, 'Hits', {
partitionKey: { ... }
});
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
}
}
Construct を継承したクラスを作成
Slide 55
Slide 55 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor() {
const table = new dynamodb.Table(this, 'Hits', {
partitionKey: { ... }
});
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
}
}
DynamoDB の Construct
Slide 56
Slide 56 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor() {
const table = new dynamodb.Table(this, 'Hits', {
partitionKey: { ... }
});
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
}
}
Lambda の Construct
Slide 57
Slide 57 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor() {
const table = new dynamodb.Table(this, 'Hits', {
partitionKey: { ... }
});
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
}
}
環境変数経由で参照
Slide 58
Slide 58 text
#DevOpsDaysTokyo
各管理手法の予測可能性
再現性 純粋性 モジュール性
マネコン × × ×
AWS CLI ◯ × ×
CloudFormation ◯ △ △
CDK ◯ △ ◯
Slide 59
Slide 59 text
#DevOpsDaysTokyo
各管理手法の予測可能性
再現性 純粋性 モジュール性
マネコン × × ×
AWS CLI ◯ × ×
CloudFormation ◯ △ △
CDK ◯ △ ◯
Slide 60
Slide 60 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
結局、CDK でも「そこそこ」なの？
Slide 61
Slide 61 text
#DevOpsDaysTokyo
CDK とテスト
● Snapshot Test
○ 生成される YAML が前回と同じか（CDK のアップデートなど）
● Fine-grained Assertion
○ 生成された YAML に目的のリソースが存在しているか
● Validation Test（実体は単なる例外送出のテスト）
○ 不正なパラメータを渡したときにエラーが発生するか
Slide 62
Slide 62 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Snapshot Test
Slide 63
Slide 63 text
#DevOpsDaysTokyo
export class DeadLetterQueue extends cdk.Queue {
public readonly alarm cloudwatch.IAlarm;
constructor(scope, id, props = {}) {
super(scope, id);
this.alarm = new cloudwatch.Alarm(this, 'Alarm', {
alarmDescription: 'messages in the DLQ',
evaluationPeriods: 1,
threshold: 1,
metric: this.metricApproximateNumberOfMessagesVisible(),
});
}
}
Slide 64
Slide 64 text
#DevOpsDaysTokyo
import { SynthUtils } from '@aws-cdk/assert';
test('DLQ preserves the snapshot', () => {
const stack = new Stack();
new dlq.DeadLetterQueue(stack, 'DLQ’);
expect(SynthUtils.toCloudFormation(stack)).toMatchSnapshot();
});
cdk synth に相当
Slide 65
Slide 65 text
#DevOpsDaysTokyo
Slide 66
Slide 66 text
#DevOpsDaysTokyo
その時点での YAML が
スナップショットとして
保存される
Slide 67
Slide 67 text
#DevOpsDaysTokyo
export class DeadLetterQueue extends cdk.Queue {
public readonly alarm cloudwatch.IAlarm;
constructor(scope, id, props = {}) {
super(scope, id);
this.alarm = new cloudwatch.Alarm(this, 'Alarm', {
alarmDescription: 'messages in the DLQ',
evaluationPeriods: 1,
threshold: 1,
metric: this.metricApproximateNumberOfMessagesVisible(),
period: cdk.Duration.minutes(1),
});
}
}
Slide 68
Slide 68 text
#DevOpsDaysTokyo
export class DeadLetterQueue extends cdk.Queue {
public readonly alarm cloudwatch.IAlarm;
constructor(scope, id, props = {}) {
super(scope, id);
this.alarm = new cloudwatch.Alarm(this, 'Alarm', {
alarmDescription: 'messages in the DLQ',
evaluationPeriods: 1,
threshold: 1,
metric: this.metricApproximateNumberOfMessagesVisible(),
period: cdk.Duration.minutes(1),
});
}
}
生成される YAML に影響を与える変更
Slide 69
Slide 69 text
#DevOpsDaysTokyo
Slide 70
Slide 70 text
#DevOpsDaysTokyo
- "Period": 300,
+ "Period": 60,
差分を検知してテスト失敗
Slide 71
Slide 71 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Fine-Grained Assertion
Slide 72
Slide 72 text
#DevOpsDaysTokyo
import {
expect as expectCDK,
SynthUtils,
haveResource
} from '@aws-cdk/assert';
test('DLQ has the message alarm', () => {
const stack = new Stack();
new dlq.DeadLetterQueue(stack, 'DLQ’);
expectCDK(stack).to(haveResource('AWS::CloudWatch::Alarm', {
Namespace: 'AWS/Lambda'
}));
});
Slide 73
Slide 73 text
#DevOpsDaysTokyo
import {
expect as expectCDK,
SynthUtils,
haveResource
} from '@aws-cdk/assert';
test('DLQ has the message alarm', () => {
const stack = new Stack();
new dlq.DeadLetterQueue(stack, 'DLQ’);
expectCDK(stack).to(haveResource('AWS::CloudWatch::Alarm', {
Namespace: 'AWS/Lambda'
}));
});
CDK が提供する YAML 生成結果に関する
アサーション
Slide 74
Slide 74 text
#DevOpsDaysTokyo
import {
expect as expectCDK,
SynthUtils,
haveResource
} from '@aws-cdk/assert';
test('DLQ has the message alarm', () => {
const stack = new Stack();
new dlq.DeadLetterQueue(stack, 'DLQ’);
expectCDK(stack).to(haveResource('AWS::CloudWatch::Alarm', {
Namespace: 'AWS/Lambda'
}));
});
わざと間違えてみた (AWS/SQS)
Slide 75
Slide 75 text
#DevOpsDaysTokyo
Slide 76
Slide 76 text
#DevOpsDaysTokyo
他に多数の属性があっても
実際に記述した
Namespace のみを見る
= Fine-Grained
Slide 77
Slide 77 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Validation Test
Slide 78
Slide 78 text
#DevOpsDaysTokyo
export class DeadLetterQueue extends cdk.Queue {
public readonly alarm cloudwatch.IAlarm;
constructor(scope, id, props = {}) {
if (props.retention != undefined && props.retention > 14) {
throw new Error('retention should be <= 14');
}
super(scope, id, {
retentionPeriod: cdk.Duration.days(props.retention || 14)
});
...
}
Slide 79
Slide 79 text
#DevOpsDaysTokyo
export class DeadLetterQueue extends cdk.Queue {
public readonly alarm cloudwatch.IAlarm;
constructor(scope, id, props = {}) {
if (props.retention != undefined && props.retention > 14) {
throw new Error('retention should be <= 14');
}
super(scope, id, {
retentionPeriod: cdk.Duration.days(props.retention || 14)
});
...
}
引数 (props) を確認して範囲外なら例外
Slide 80
Slide 80 text
#DevOpsDaysTokyo
test('DLQ retention should be < 14', () => {
const stack = new Stack();
expect(() => {
new dlq.DeadLetterQueue(stack, 'DLQ', {
retention: 14
});
}).toThrowError();
});
範囲内（例外は飛ばない）
Slide 81
Slide 81 text
#DevOpsDaysTokyo
Slide 82
Slide 82 text
#DevOpsDaysTokyo
通常の例外のテストと同様
Slide 83
Slide 83 text
#DevOpsDaysTokyo
Section 2 のまとめ
● デプロイ時の予測可能性のために必要な要素
○ 再現性 / 純粋性 / モジュール性
● 段階的に予測可能性を獲得
○ コンソール < CLI < CloudFormation < CDK
● CDK には静的テスト機構が備わっている
○ Snapshot / Fine-grained Assertion / Validation
Slide 84
Slide 84 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
よし、自作の Construct デプロイしよう
Slide 85
Slide 85 text
#DevOpsDaysTokyo
Custom
Construct
API
Count Hits
Slide 86
Slide 86 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor(...) {
const table = new dynamodb.Table(this, 'Hits', { ... });
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
}
}
Slide 87
Slide 87 text
#DevOpsDaysTokyo
＼エラー！／
Slide 88
Slide 88 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor(...) {
const table = new dynamodb.Table(this, 'Hits', { ... });
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
table.grantReadWriteData(this.handler);
}
}
権限つけ忘れた！
Slide 89
Slide 89 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
「何」を「どう」テストすべきなのか？
Slide 90
Slide 90 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
テスト戦略とツール
Strategies & Tactics for IaC Predictability
Slide 91
Slide 91 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装
2. YAML の生成 3. リソースの作成
Slide 92
Slide 92 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装
A. 期待する YAML
2. YAML の生成 3. リソースの作成
Slide 93
Slide 93 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装
A. 期待する YAML
2. YAML の生成
● CDK が提供する予測可能性：1 + 2 = A
3. リソースの作成
Slide 94
Slide 94 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装 B. 期待する振る舞い
A. 期待する YAML
2. YAML の生成 3. リソースの作成
● CDK が提供する予測可能性：1 + 2 = A
Slide 95
Slide 95 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装 B. 期待する振る舞い
A. 期待する YAML
2. YAML の生成 3. リソースの作成
● CDK が提供する予測可能性：1 + 2 = A
● 本当に欲しい予測可能性：1 + 2 + 3 = B
Slide 96
Slide 96 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装 B. 期待する振る舞い
A. 期待する YAML
2. YAML の生成 3. リソースの作成
● 1 + 2 = A かつ A + 3 = B なら 1 + 2 + 3 = B
Slide 97
Slide 97 text
#DevOpsDaysTokyo
CloudFormation
CDK 作成されるリソース
1. 実装 B. 期待する振る舞い
A. 期待する YAML
2. YAML の生成 3. リソースの作成
● 1 + 2 = A かつ A + 3 = B なら 1 + 2 + 3 = B
● つまり残りは右側の予測可能性が問題
Slide 98
Slide 98 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
要するに YAML の「振る舞い」をテストしたい
Slide 99
Slide 99 text
#DevOpsDaysTokyo
リソースに期待する振る舞い
● ポリシー的な性質
○ リソース・アプリをまたいで制約が掛かっているか
○ 例：0.0.0.0/0 禁止、コスト集約用のタグ必須
● 意味論的な性質
○ 複数のリソースがうまく「噛み合った」状態で動作するか
○ 例：ネットワーク疎通が可能か、権限が足りているか
Slide 100
Slide 100 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
どんなツールが使えそう？
Slide 101
Slide 101 text
#DevOpsDaysTokyo
CloudFormation のテストツール
● cfn-nag
○ CloudFormation 用、分野はセキュリティ系
● CloudFormation Guard (cfn-guard)
○ CloudFormation 用、分野は限定せず汎用
● Conftest
○ 一般の YAML 用、分野は限定せず汎用
Slide 102
Slide 102 text
#DevOpsDaysTokyo
cfn-nag
● セキュリティ系の定番ツール
○ ベストプラクティスがあらかじめ定義されている
● メリット・デメリット
○ 定義済みルール：デフォルトで豊富（必要なら抑制も可能）
○ 配布・再利用性：低い（一応 S3 Bucket 経由で共有可能）
○ 拡張性：低い（Ruby でロジックを陽に記述する必要あり）
https://github.com/stelligent/cfn_nag
Slide 103
Slide 103 text
#DevOpsDaysTokyo
CloudFormation Guard (cfn-guard)
● Rust 製の AWS 公式チェックツール (2020/10-)
○ Lambda Function 版も提供されている
● メリット・デメリット
○ 定義済みルール：サンプルのみ（既存の YAML から生成機能あり）
○ 配布・再利用性：低い（ルールファイル直接指定のみ）
○ 拡張性：あまり高くない（個別の属性をチェックするのみ）
https://github.com/aws-cloudformation/cloudformation-guard
Slide 104
Slide 104 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
複数のリソース間の関係はどうテストする？
自動生成されたリソース名の参照はどう扱う？
Slide 105
Slide 105 text
#DevOpsDaysTokyo
Conftest
● Open Policy Agent (OPA) の派生
○ Kubernetes との連携 (Gatekeeper) が人気
● メリット・デメリット
○ 定義済みルール：なし
○ 配布・再利用性：高い（OCI = Docker レジストリで配布可能）
○ 拡張性：高い（Prolog の一種 Rego を使用）
https://github.com/open-policy-agent/conftest
Slide 106
Slide 106 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Ruby や Rust はともかく Rego って何?
Slide 107
Slide 107 text
#DevOpsDaysTokyo
Rego 言語ことはじめ
is_xxxxx {
condition1
condition2
}
Rego の記述は
「xxxxxx とは yyyyyy であることである」
という定義のあつまり
Slide 108
Slide 108 text
#DevOpsDaysTokyo
Rego 言語ことはじめ
is_xxxxx {
condition1
condition2
} 定義：「xxxxx であるとは」
Rego の記述は
「xxxxxx とは yyyyyy であることである」
という定義のあつまり
Slide 109
Slide 109 text
#DevOpsDaysTokyo
Rego 言語ことはじめ
is_xxxxx {
condition1
condition2
}
内容「Conidition 1 かつ Condition-2 かつ…が成り立つことである」
Rego の記述は
「xxxxxx とは yyyyyy であることである」
という定義のあつまり
Slide 110
Slide 110 text
#DevOpsDaysTokyo
Rego 言語ことはじめ
is_xxxxx {
condition1
}
is_xxxxx {
condition2
}
内容「Conidition 1 または Condition-2 が成り立つことである」
Rego の記述は
「xxxxxx とは yyyyyy であることである」
という定義のあつまり
Slide 111
Slide 111 text
#DevOpsDaysTokyo
Rego 言語ことはじめ
is_xxxxx {
is_yyyyy
}
is_yyyyy {
is_zzzzz
}
定義の参照「xxxxx であるとは yyyyy であることで、その yyyyy であるとは…」
Rego の記述は
「xxxxxx とは yyyyyy であることである」
という定義のあつまり
Slide 112
Slide 112 text
#DevOpsDaysTokyo
Rego 言語ことはじめ
is_xxxxx {
f = functions[_]
is_good_func(f)
}
代入ではない（単一化）
配列 functions の中から全体を成り立たせるような添字 _ が存在すれば
それを任意に取って f とする。
Rego の記述は
「xxxxxx とは yyyyyy であることである」
という定義のあつまり
Slide 113
Slide 113 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
実際にどうすれば権限がテストできるか？
Slide 114
Slide 114 text
#DevOpsDaysTokyo
export class Counter extends cdk.Construct {
public readonly handler: lambda.Functions;
constructor(...) {
const table = new dynamodb.Table(this, 'Hits', { ... });
this.handler = new lambda.Handler(this, 'Handler', {
...
environment: {
...
HITS_TABLE_NAME: table.tableName
}
});
table.grantReadWriteData(this.handler);
}
}
権限の不足を発見したい
Slide 115
Slide 115 text
#DevOpsDaysTokyo
deny[msg] {
...
violations = [ [f, t] |
f := functions[_];
t := tables[_];
needs_permission(f, t);
not has_permission(f, t);
]
count(violations) > 0
...
}
warn[msg] { ... }
Slide 116
Slide 116 text
#DevOpsDaysTokyo
deny[msg] {
...
violations = [ [f, t] |
f := functions[_];
t := tables[_];
needs_permission(f, t);
not has_permission(f, t);
]
count(violations) > 0
...
}
warn[msg] { ... }
deny でエラー、warn は警告
Slide 117
Slide 117 text
#DevOpsDaysTokyo
deny[msg] {
...
violations = [ [f, t] |
f := functions[_];
t := tables[_];
needs_permission(f, t);
not has_permission(f, t);
]
count(violations) > 0
...
}
warn[msg] { ... }
権限が必要だが持っていない
Function と Table の組 > 0 ならばエラー
Slide 118
Slide 118 text
#DevOpsDaysTokyo
allows([_, policy], [table_name, _]) {
policy.Type = "AWS::IAM::Policy"
statements := policy.Properties.PolicyDocument.Statement[_]
statements.Effect = "Allow"
statements.Resource[_]["Fn::GetAtt"][0] = table_name
statements.Action[_] = "dynamodb.PutItem"
statements.Action[_] = "dynamodb.UpdateItem"
}
Slide 119
Slide 119 text
#DevOpsDaysTokyo
allows([_, policy], [table_name, _]) {
policy.Type = "AWS::IAM::Policy"
statements := policy.Properties.PolicyDocument.Statement[_]
statements.Effect = "Allow"
statements.Resource[_]["Fn::GetAtt"][0] = table_name
statements.Action[_] = "dynamodb.PutItem"
statements.Action[_] = "dynamodb.UpdateItem"
}
Statement を適切に選んで
以下を満たせるか？
Slide 120
Slide 120 text
#DevOpsDaysTokyo
allows([_, policy], [table_name, _]) {
policy.Type = "AWS::IAM::Policy"
statements := policy.Properties.PolicyDocument.Statement[_]
statements.Effect = "Allow"
statements.Resource[_]["Fn::GetAtt"][0] = table_name
statements.Action[_] = "dynamodb.PutItem"
statements.Action[_] = "dynamodb.UpdateItem"
}
Action を適切に選んで
条件全体を満たせるか？
Slide 121
Slide 121 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
慣れるまで結果を確認しつつ練習したい
Slide 122
Slide 122 text
#DevOpsDaysTokyo
https://play.openpolicyagent.org/
Slide 123
Slide 123 text
#DevOpsDaysTokyo
定義済みルール 配布・再利用 拡張性
cfn-nag ◯ × ×
cfn-guard △ × △
Conftest × ◯ ◯
各ツールの使いどころ
Slide 124
Slide 124 text
#DevOpsDaysTokyo
定義済みルール 配布・再利用 拡張性
cfn-nag ◯ × ×
cfn-guard △ × △
Conftest × ◯ ◯
各ツールの使いどころ
デフォルトで済むなら cfn-nag / 追加するなら cfn-guard
複数のリソースの関係は Conftest で記述
Slide 125
Slide 125 text
#DevOpsDaysTokyo
Section 3 のまとめ
● 何をテストしているのか意識する
○ CDK のテストあくまでも CDK から YAML への変換のテスト
● リソースに期待する振る舞い
○ ポリシー的な性質 / 意味論的な性質
● 生成された YAML をテストするコツ
○ Conftest で具体的な名前に依存せずテストできる
Slide 126
Slide 126 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
本日のまとめ
Wrap Up!
Slide 127
Slide 127 text
#DevOpsDaysTokyo
本日のまとめ
● IaC における静的テストの必要性
○ デプロイ前に予測可能性を確保したい
● AWS のリソース管理と CDK
○ 再現性 / 純粋性 / モジュール性
● YAML に対するテスト戦略とツール
○ cfn-nag or cfn-guard（ポリシ強制）/ Conftest（機能要件）
Slide 128
Slide 128 text
#DevOpsDaysTokyo
#DevOpsDaysTokyo
Make Your IaC Predictable!
Presented by チェシャ猫 (@y_taka_23)