20220409 AWS BLEA 開発にあたって検討したこと

© 2022, Amazon Web Services, Inc. or its affiliates.
Baseline Environment on AWS (BLEA)
開発にあたって検討したこと
AWS CDK Conference Japan
大村幸敬
Amazon Web Services Japan
Senior Solutions Architect
2022/04/09

大村幸敬（おおむらゆきたか）
部長 / シニアソリューションアーキテクト
• これからクラウドを使いはじめる
エンタープライズ企業をサポート
• 運用系サービス & DevOps 系サービスをリード
• Baseline Environment on AWS (BLEA) 開発者
好きなAWSのサービス：
AWS Command Line Interface (CLI)
AWS Cloud Development Kit (CDK)
AWS Systems Manager Incident Manager
@yktko
2

私とCDK
https://qiita.com/advent-calendar/2021/aws-cdk
3

アジェンダ
1. Baseline Environment on AWS 開発の方向性
1. What is BLEA
2. BLEAの開発方針
2. これから CDK を使う方へのナレッジ
1. CDKを使うのは難しそう
2. CDKのL2 Constructがない / CFnを使いたい
3. やっぱりYAMLがいい
4. 手でやった方が楽
3. すでに CDK を使っている方へのナレッジ
1. cdk deploy の認証情報を持ちたくない
2. パラメータを切り替えて使うには
3. パイプラインをどうデザインするか
4. 複数のCDKプロジェクトをどう管理するか
4

本日の内容
話すこと
• BLEA 開発中に検討した、AWS CDK 開発における
設計方針、実装方式、開発者が知っておくべきこと
• これは BLEA 開発の目的で検討した内容であり
一般的なベストプラクティスはありません
考え方を共有することで
皆さんがよりよい選択をする一助になればと思っています
話さないこと
• AWS CDKそのものの詳しい解説
• BLEAそのものについての解説
5

Baseline Environment on AWS
開発の方向性
6

Baseline Environment on AWS (BLEA)
AWSのセキュリティベストプラクティスを実装した
オープンソースのサンプルテンプレート
特徴
• 基本的なセキュリティを設定するテンプレートと
ゲストシステムのサンプルテンプレートを提供
• AWSのセキュリティベストプラクティスに準拠
• AWS Cloud Development Kit (CDK) コード
参考となるスニペット、コメント、リファレンスを豊富に記載
• チームによる長期的な利用を想定
CDK標準ライブラリのみを使ったシンプルな実装
利用者が理解しやすいよう過度な作り込みを避ける
https://github.com/aws-samples/baseline-environment-on-aws
ガバナンスベース
（基本的なセキュリティ）
ゲストシステムサンプル
AWS
Account
BLEAが提供するテンプレート
CDK
CDK
7

Q: なぜ BLEA は AWS CDK を使うのか？
• 記述量が少なくシンプルで理解しやすいコード（CloudFormation 比）
• 長期にわたる安全な運用には引き継ぎしやすいコードが必要
• テンプレートをブラックボックスにしない
• 開発上の利点が多い
• AWSのベストプラクティスがライブラリに含まれておりコードの記述量が少なく済む
• 一般のプログラミング言語（TypeScript）であるためオブジェクト参照が明快
• エディタによる強力なサジェストがあるため実装中の誤り混入を少なくできる
• 実績のある CloudFormation によりデプロイされる
• CDKの学習コンテンツとしての利用
• インフラエンジニアは TypeScript 開発未経験者であることも多いため、
環境構築も含めた 1st step ガイドやドキュメントを提供する
• よく利用する CDK コードの書き方やコメントやリファレンスを多く記載
• BLEA 独自クラスは極力作らず、CDK の基礎知識と標準 API リファレンスを読めば、
必要な部分をコピペしつつ開発を開始できるように実装
8

コードサンプル (ALB アクセスログの設定）
ALB のアクセスログ設定（やや特殊な書き方）
特殊な設定の理由（security best practice準拠）、
一般的な設定のやり方、およびリファレンス
ログ出力に必要な特殊権限とその書き方
(RegionInfo の使い方）
9

これからCDKを使う方へのナレッジ
10

課題: CDKを使うのは難しそう
BLEAでの解決策:
• 開発環境を用意するまでの障壁をできるだけ小さくする
• 想定開発環境をVisualStudio Codeに限定
• 開発環境設定ファイルや初期手順を提供する
実際にいただいたユーザーの声:
• TypeScriptやPythonのコードを書いたことがない
• npmやlintなどアプリ開発系の知識がよくわからない
• なんか強い開発環境の整備が必要で複雑そう
• メモ帳とか、さ○○エディタとか、秀○でやりたい
https://bit.ly/3CUIxQY 11

参考: BLEAでのVSCode Extensions利用
VSCode
EditorConfig
Prettier
ESLint
VSCode
Extensions
BLEA での推奨テキストエディタ
各種ツールとの連携機能を有する
関連ファイル .vscode/extensions.json
テキストエディタの
インデントや改行コードなどを自動設定
関連ファイル .editorconfig
JavaScript, TypeScript などの
コードフォーマッター
関連ファイル .prettierrc.json
JavaScript, TypeScript に対し
静的チェック (Lint) を実行
関連ファイル .eslintrc.json
開発者間の設定差異による
無用な差分の発生を抑制
かっこの前後のスペースや改行位置など
開発者ごとの書き方の差異を吸収。
手動でフォーマットを調整する手間を削減
静的チェック (コードを実行しない構文解析)
により潜在的なバグを予防し
ベストプラクティスを適用
※ VSCode 以外のテキストエディタを使用する場合は、下記ツールとの連携をサポートするものをご選択ください
12

課題: CDKの L2 Construct がない / CFnを使いたい
• L1 Constructを積極的に使う
• CFnをインポートする
考え方
• CFnリソースがある = L1 Construct がある
• L1 Construct のコードでサジェストが使える
• ＝ CFnをYAMLで書くよりエラー訂正が強力 / リファレンス参照が減る
• L1 Constructでコード書いてCFnテンプレートを生成して使うとか
• cloudformation-includeモジュールでCFnテンプレートや既存の環境を変更
せずCDKで管理できる
https://bit.ly/3LJERW2
https://bit.ly/3Jf77yg
13

課題: やっぱりYAMLがいい
• ロジックを書かずコンストラクタとメソッドだけ使う
• 独自の Construct を作らず標準ライブラリのみ使う
考え方
• CDKのコードはリソースの生成と相互参照がほとんど
• ロジックや継承などを使わなければYAMLと同様
• そのうえ、文字列だけで相互参照するYAMLに対し
メソッドやプロパティでアクセスする方が
見通しがよい
• そもそもロジックが複雑なコードは構成管理には不向き
（コードと実体の対応がわかりにくい）
14

課題: 手でやった方が楽
• 実施回数が少なく、手順がシンプルいなら手でやる
• 過度なカスタムリソースコード (Lambda) 作成はしない
考え方
• Organizations全体での有効化が簡易なサービス
• SecurityHub / GuardDuty / SystemsManager QuickSetup etc.
• Organizationsやアカウントにつき1回しかない操作
• カスタムリソースを作ってLambdaとAPIで実装してもよいが
メンテナンス負荷のほうが大きい
https://bit.ly/3jgsvbJ
15

すでにCDKを使っている方へのナレッジ
16

課題: cdk deploy の認証情報を持ちたくない
• AWS SSOを使う(credentials fileでなく)
設定方法
1. ~/.aws/configにSSOログイン用プロファイルを設定
2. aws sso login コマンドで AWS SSO画面でID/PW/MFAトークン
を入力してログイン
3. 以後cdkコマンドが利用可能
注: 2022年3月の v2.18.0 で、AWS SSOの認証情報が、CDKから直接利用可能になりました！
$ aws sso login
$ cdk deploy
GitHub
Local
Permanent
API Key
Target Account Target Account
AWS SSO
SSOを使うパターン creedentials fileを
使うパターン
$ cdk deploy
[profile mytarget]
sso_start_url = https://d-deadbeef00.awsapps.com/start
sso_region = ap-northeast-1
sso_account_id = 012345678912
sso_role_name = AWSAdministratorAccess
region = ap-northeast-1
~/.aws/config
$ cd usecases/base-ct-guest
$ npm run build
$ aws sso login --profile mytarget
（ここでブラウザが開くのでログイン）
$ npx cdk deploy -c environment=myenv --profile mytarget
Stack BLEA-BASE-ConfigRule (略)
実行例
https://bit.ly/3NXZcJ0 17

課題: パラメータを切り替えて使うには
1. cdk.json の contextに設定値グループを保持
2. cdk コマンドの –c (--context) オプションでグループを指定
3. CDK コードでパラメータを取得して利用
cdk.jsonの例
https://bit.ly/3JkMWyX
18

パラメータ挿入: BLEAでの考え方
Context
• デプロイ対象に紐づくパラメータ情報。これをメインで使う
• アカウントとリージョンを指定しない場合は環境変数に従う
• 開発環境などデプロイ先を限定したくない場合に使用
• デプロイ先アカウントとリージョン(env)を指定可能
• コンテキスト値とそのデプロイ先のセットを記録
• --profile のアカウントxリージョンと一致しない場合はエラーになる (fool proof)
環境変数 (Process.env)
• profileで指定したアカウントとリージョンの取得に使う
Parameters
• CFnテンプレートに渡すパラメータ
Synth後、デプロイ時に値を変えるのに使えるが通常は使わない
https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/parameters.html
cdk.jsonの例
19

検討: パラメータについてあれこれ
• そもそもパラメータで切り替えるのがよいのか？
• コードの中に複雑な条件分岐が発生する可能性
• コード自体を環境ごとに分けてパラメータを埋め込む方が良い？
• パブリックに公開するコードにパラメータを載せられない
• BLEA開発環境用のパラメータをどこに置くか？
• cdk.context.json, ${HOME}/.cdk.json, SSM ParameterStore, S3...
• パラメータの型チェックができない & JSONは面倒
• 独自の設定ファイルを読み込む方式にするか？
• しかし実装が複雑に...
• CDKのデフォルトライブラリには（まだ）存在しない
https://bit.ly/3LOH1Ur
20

課題: パイプラインをどうデザインするか
BLEAでの考え方 (with CDKPipelines)
21

課題: パイプラインをどうデザインするか
BLEAでの考え方（まとめ）
• CI/CD実現のため手元PCからでなくパイプラインからデプロイ
• Dev環境は手元PCを使って任意のアカウントへ気軽にデプロイ
• Staging、Prod環境は既定アカウントへパイプラインでデプロイ
• ターゲットスタックの検証はDev環境で
パイプライン自体の検証はStaging環境のデプロイで行う
• そのためstagingとprodのパイプラインは同じものを別に構成
• CDKPipelineを使う（サンプル実装として）
• GitHubからStagingやProdへ直デプロイしない
• GitHubはパイプラインアカウントにのみ接続 (CodeStar Connection)
22

検討: パイプラインをどうデザインするか
取りうる選択肢
• ターゲットスタックのどんなテストをどこで行うのか
• Dev環境 / Staging環境
• Ownerは誰か（アカウント分割に影響）
• GitHub（リポジトリ） / パイプライン / ターゲットアカウント
• どこで cdk deploy を実行するか
• 手元PC / GitHub / パイプラインアカウント / ターゲットアカウント
• どこで CI (npm run test) を実行するか
• 手元PC / GitHub / パイプライン
• どこでパイプラインスタックのテストを行うのか
• Dev環境 / Staging環境
23

課題: 複数のCDKプロジェクトをどう管理するか
• リポジトリは1つでサブディレクトリでユースケースごとに分ける
• パッケージ管理は NPM workspaces を使う
考え方:
• BLEAは1つのリポジトリで多様なパターンを提供したい
• 個々のユースケースは独立して使うのでCDKプロジェクトは別
• ユースケース内のバリエーションは異なるAppを用意
• node_moduleを1つだけにしたい（容量爆発対策）
検討:
• アプリコードインフラ系コードをどう分けるか問題
• チーム編成 / ライフサイクル / CI/CDと品質検証の仕組み
• 多くのCDKツールキットはルート直下に1プロジェクトを置くことを想定
24

その他の検討
• セキュリティグループやIAM Policyの循環参照
• スナップショットテストはやるとして、他に何をテストするか
• ALBが勝手にSecurityGroupを設定するのをやめさせたい
• Route53とACMはCDKで管理した方がいいのか
• CloudFrontとWAFはus-east-1で設定しないと
• etc…
25

Next step...
BLEA GitHub リポジトリ
https://github.com/aws-samples/baseline-environment-on-aws/blob/main/README_ja.md
AWS環境にセキュアなベースラインを提供するテンプレート
「Baseline Environment on AWS」のご紹介（解説ブログ）
https://aws.amazon.com/jp/blogs/news/announcing-baseline-environment-on-aws/
HowTo にいろいろ情報あります
手元環境構築から導入まで
詳しい手順あります
26

まとめ
27
1. Baseline Environment on AWS 開発の方向性
1. What is BLEA
2. BLEAの開発方針
2. これから CDK を使う方へのナレッジ
1. CDKを使うのは難しそう
2. CDKのL2 Constructがない / CFnを使いたい
3. やっぱりYAMLがいい
4. 手でやった方が楽
3. すでに CDK を使っている方へのナレッジ
1. cdk deploy の認証情報を持ちたくない
2. パラメータを切り替えて使うには
3. パイプラインをどうデザインするか
4. 複数のCDKプロジェクトをどう管理するか

Thank you!
大村幸敬 (Yukitaka Ohmura)
ご質問がありましたら、Twitterで！
@yktko または #jawsug #cdkconf へ

20220409 AWS BLEA 開発にあたって検討したこと

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20220409 AWS BLEA 開発にあたって検討したこと

Similaire à 20220409 AWS BLEA 開発にあたって検討したこと (20)

Plus de Amazon Web Services Japan

Plus de Amazon Web Services Japan (20)

Dernier

Dernier (7)

20220409 AWS BLEA 開発にあたって検討したこと

Notes de l'éditeur