CloudWatch Syntheticsでロールが作れないとき

概要

AWS CloudWatch SyntheticsのcanaryをGUIで作成するとき、 「Create a new role」がグレーアウトして押下できない。 f:id:mMQnaZ7vL2DWkoU:20210304010752p:plain

原因

S3のパスを変更していたから。
IAM Roleを自動作成するとき、ポリシーの設定がデフォルトのS3パスになっている。
そのため、S3のパスを変更するときは、自分でIAM Policyを作成し、それをアタッチしたIAM Roleを作らなければならない。

下記のようなポリシーが作られる。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::cw-syn-results-<ACCOUNT_ID>-<REGION>/canary/<REGION>/<CANARY_NAME>-<HASH>/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::cw-syn-results-<HASH>-<REGION>"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:CreateLogGroup"
            ],
            "Resource": [
                "arn:aws:logs:<REGION>:<ACCOUNT_ID>:log-group:/aws/lambda/cwsyn-<CANARY_NAME>-*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "xray:PutTraceSegments"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": "*",
            "Action": "cloudwatch:PutMetricData",
            "Condition": {
                "StringEquals": {
                    "cloudwatch:namespace": "CloudWatchSynthetics"
                }
            }
        }
    ]
}

まとめ

今回、Syntheticsを利用するに当たり、本番環境のみ利用し、一度作成した後に変更が殆どないことから、GUIで作った。
関連して作られるリソースの削除などが面倒だったので、IaCしても良いかも知れない。
Terraformで作っても消してくれないので、自分で作る必要がある。 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/synthetics_canary

削除するときの手順は下記(これに加えIAM Policyも削除する必要がある。)
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/synthetics_canaries_deletion.html

GitHub Actionsで特定のディレクトリ配下が変更されたときだけワークフローを発火する

概要

GitHub Actionsで特定のディレクトリ配下のファイルが変更されたときにワークフローを発火する方法。

結論

トリガーにpathsを使用する。
下記のように書くとhogeディレクトリ配下のファイルが変更されたときのみワークフローが発火する。

on:
  push:
    paths:
    - 'hoge/**'

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths

ユースケース

  • モノレポで各ディレクトリの変更に対して個別にワークフローを発火する
  • 特定の拡張子が変更された場合のみ発火する
  • ドキュメントの更新でワークフローを走らせたくない

など

まとめ

最近モノレポプロジェクトを触っているのでまとめた。

direnvを使ってTerraformにAWSクレデンシャルを設定する

バージョン

$direnv --version
2.21.2
$tf --version
Terraform v0.13.2

方法

Terraformのホームディレクトリに下記の.envrcを追加する。

AWS_PROFILE="<PROFILE_NAME>"
AWS_DEFAULT_REGION="ap-northeast-1"

.gitignoreに.envrcを追加する。

.envrc

これで対象のディレクトリに移動すると、設定されたプロファイルでTerraformを実行できる。

未知のライブラリ、フレームワーク、サービスを使うときのキャッチアップ方法

概要

タイトルの通り

キャッチアップ方法

1. コンセプト、モチベーションを知る

トップページや上の階層に書いてあるので読む。

検索方法

why~,what is~,overview,feature,motivation,conceptなど

2.用語をざっくり知る

用語集として端的に説明されているので初学時の理解に役立つ
ツールを使い始めてから何度か参照するので用語がまとめてある場所を押さえる

検索方法

glossary,FAQなど

3.動かす

実際に動かして理解を深める

検索方法

getting started,tutorialなど

4.ベストプラクティスを調べる

ベストプラクティスやアンチパターンがないか確認する

検索方法

best practice,anti patternなど

わからない事があったとき

前提

英語で調べる

検索順番

  1. 公式ドキュメント
  2. 公式のGitHubリポジトリのISSUES,PR
  3. 公式のコミュニティ、チャット
  4. 公式のGitHubリポジトリのコード検索
  5. GitHubでツール名を調べてどのように使われているか調べる

AWS ECSの例

1. コンセプト、モチベーションを知る

2.用語をざっくり知る

https://docs.aws.amazon.com/general/latest/gr/glos-chap.html

3.動かす

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-tutorials.html

4.ベストプラクティスを調べる

下記は検索結果の一部
https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/

まとめ

いつもやっていることをまとめてみた
基本的には公式ドキュメント、リポジトリに書いてある一次情報を参考にする

2021年1月時点Next.jsのGraceful Shutdown実装状況調査

概要

Next.jsをコンテナで動かすときにGraceful Shutdownが実装されているか気になった。
12月の調査時点ではcanaryだったが、すでにリリースされていた。
本当は「2020年12月時点Next.jsのGraceful Shutdown実装状況調査」だったが、
今の状況だと「Next.jsにGraceful Shutdownが導入されたので挙動を確認する」とかでいい気がする。
ブログはすぐに書きましょう。

結果

下記リリースで導入された。
https://github.com/vercel/next.js/releases/tag/v10.0.4

Graceful Shutdown

コンテナの世界では外部からコンテナが落とされる事がよくある。
つまりdocker stop/killがよく実行される。
そのときアプリケーションにはSIGTERMやSIGKILLが送信される。
これらのシグナルを検知し、リソース(DBコネクション、FileIOなど)を開放して正常終了(exit code0)する必要がある。

c.f. https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/

(12月当時の)調査内容

  1. GitHubでSIGTERMを検索
  2. 該当コードをBLAMEしてコミットログ、PRを読む
    https://github.com/vercel/next.js/pull/19433

動作確認

v10.0.4

$./node_modules/.bin/next start
ready - started server on http://localhost:3000
# kill -15 <PID>
$echo $?
0

v10.0.3

$./node_modules/.bin/next start
ready - started server on http://localhost:3000
# kill -15 <PID>
Terminated: 15
$echo $?
143

変更に強いE2Eテストにするためにカスタムデータ属性を使う

概要

壊れやすいE2Eテストとは

E2Eテストのテストシナリオを書くときに、下記のようなセレクタの使い方をすると壊れやすくなる。

例:同じclass属性を持つ要素が増えたときにテストが通らなくなる。

例:ある要素の子の要素の子の要素のフォームにxxxを入力するなど
操作するセレクタに一つでも変更があるとテストが通らなくなる。

表示するテキストが変更されたときテストが通らなくなる。

例: <button>Sign in</button><button>Login</button>に変更されたときテストが通らなくなる。

カスタムデータ属性

それらを防ぐためにカスタムデータ属性を使う。
テスト用の属性を付与し、HTML、CSS、JSの変更から分離されたテストを書くことができる。
属性について画面と意味とユーザの行動を考えた名称をつける。
これにより、どのようなテストを実施しているかテストシナリオで表明できる。

まとめ

  • カスタムデータ属性を使って変更に強いE2Eテストを書く
  • テストシナリオはユーザの行動に即したシナリオを書いて仕様を表明する

参考

Making your UI tests resilient to change

Best Practices | Cypress Documentation

Element selectors | Playwright

data-* - HTML: HyperText Markup Language | MDN