2025/2/21 JAWS-UG CDK支部#19 クラスメソッドコラボ回

https://jawsug-cdk.connpass.com/event/343974/

Contents

• CDKを使ったPagerDuty連携インフラのテンプレート化
  • 資料| Speaker Deck
  • 記事| DevelopersIO
• CDKのコードを書く環境を作りました with Amazon Q
  • 資料| Speaker Deck
• コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」とは
  • 資料| Speaker Deck
• CDKでカスタムランタイムを作成して、Lambdaをnode.js23+TypeScriptで動かしてみた
  • 資料| Speaker Deck
• CDK開発におけるコーディング規約の運用
  • 資料| Speaker Deck

CDKを使ったPagerDuty連携インフラのテンプレート化

• 背景
  • 保守している環境にPagerDutyを導入したい
  • 既存のSNSトピックに通知用のLambdaを追加してPagerDutyに連携したい
  • CDKでインフラ管理しているプロジェクトの保守を複数担当しており、すべてに対応する必要がある
• 課題
  • 各プロジェクトのCDKをすべて直すのは煩雑で、現実的ではない
  • 保守するプロジェクトが増えるたびに追加作業が必要になる
• 解決策
  • SNSトピックにLambda追加用のCDKプロジェクトを１つ作成
    • CDKプロジェクトからCloudFormationテンプレートを生成し、S3に配置
      • ソース管理が1か所に。
  • クイック作成リンクを使用して、複数環境に適用する
    • 新規スタックなので既存環境に影響を与えない
• ※クイック作成リンクとは？
  • あらかじめS3に配置しておいたCloudFormationテンプレートを指定したリンクから、スタック作成のページに遷移することができる

CDKのコードを書く環境を作りました with Amazon Q

• 背景
  • Windows 11でCDKのコードを書く環境を作りたい
  • ただ、追加でアプリインストールなどは避けたい
  • 既存のVS Codeを使いたい
  • Amazon Qを使いたい
  • ほかの人でも再現可能な方法にしたい
• 必要な環境
  • VS Codeに以下の拡張機能
    • Remote Development
    • Dev Containers
  • WSL2(Ubuntu) on Windows 11
    • Docker, Docker Composeインストール
  • クラウドプロキシを使う場合はルート証明書をインストール

    sudo apt-get install -y ca-certificates
    sudo cp proxy.crt /usr/local/share/ca-certificates
    sudo update-ca-certificates
    

    
• 手順概要
  • WSL2で作業ディレクトリを作成し、code .でVS Codeを起動する。VS Code で以下を作成
    • .devcontainer
      • devcontainer.json
        • extensionsでAmazonQをインストール
    • docker-compose.yml
    • Dockerfile
      • ここでクラウドプロキシ用のルート証明書を/usr/local/share/ca-certificatesにコピー
    • proxy.crt

コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」とは

• 「Open Constructs Library」とは
  • コミュニティ駆動のAWS CDK Constructライブラリ→GitHub
  • Open Construct Foundation（OCF）により2024年2月発足
    • CDKエコシステム拡充のために設立された非営利団体
• 背景
  • AWS CDK（本家）はOSS
  • AWS CDKチームがメンテナー
  • コミュニティからのコントリビュートが多く、CDKチームのレビュー負荷が高くなっている
  • 今後、L3 Constructsは作らない可能性がある
    • とはいえ、CDKエコシステムには高レベルConstruct（L3）が必要！
    • Construct Hubがあるが、すべて信頼性が高いとはいえない
• 現在のConstructは６つ
  • aws-codeartifact
  • aws-cur
  • aws-ec2
  • aws-elasticache
  • aws-fsx
  • aws-redshiftserverless
• 今後の方針
  • CDK本家にないL2 Constructsを充実
  • その後、L3
  • よいConstructはCDK本家にも提供
• コントリビューター募集
  • 15人中7人が日本人
  • PRのレビューは隅々まで丁寧に行うのでCDKスキルアップします

CDKでカスタムランタイムを作成して、Lambdaをnode.js23+TypeScriptで動かしてみた

• 背景
  • Node.jsがv23.6.0からTypeScriptのネイティブ実行がサポート
  • Lambdaでは未サポートのバージョンも「カスタムランタイム」として動作可能
    • LambdaをTypeScriptで実行できるのでは？
• CDKでカスタムランタイムを作成するには？
  • 通常のLambdaレイヤーと同様でOK
  • ただし、Node.js v23.6.0のバイナリを含める必要がある
  • TypeScriptをそのままデプロイするので、aws_lambda.Functionを使用
    • aws_lambda_nodejs.NodejsFunctionではトランスパイルされる

CDK開発におけるコーディング規約の運用

• コーディング規約とは？
  • コーディングにおけるルール
  • 保守性が高く、一貫性のあるコードを保つのに必要
• 自前で運用するのはミスも発生しやすいので、LinterやFormatterなどのツールで自動化を推奨
• Linterの特徴を理解して選定する
  • ESLint
    • JSのLinter
    • eslint.config.jsの記述が必要
    • プラグインが豊富、自前のカスタムルール作成可能
    • 型情報のLintルールあり（typescript-eslint）
  • Biome
    • Rust製のLinter
    • JS/TS/CSS/JSONをサポート
    • ESLintより高速（15倍）
    • 設定ファイルなしでも動作可能
    • 型情報のLintルールなし
  • Oxlint
    • Rust製のLinter
    • JS/TS
    • ESLintより高速（50～100倍）
    • 設定ファイルなしでも動作可能
    • ESLintなど互換性あり
• 結局どれを採用？
  • ESLintがおすすめ。理由は下記。
    • 型情報Lintルールがほしい
    • プラグインの豊富さ
    • カスタムルール作成可能
• JSDoc
  • CDKでは、interfaceやConstructで公開するプロパティにはJSDocを必須にする
  • オプショナルなプロパティには必ず@defaultを記述
  • CDK独自ルールは、eslint-cdk-pluginを利用するのがおすすめ！

https://zenn.dev/yamaren/articles/87c7d2f0e817d9