
## 困ったこと

AWS マネジメントコンソールから 別の AWS アカウントの Lambda 関数を AppSync のデータソースとして設定する方法がわからなかった。

## AWS AppSync のデータソースとして Lambda 関数の ARN を入力するには？

解決は至って簡単でした。

AppSync のデータソースとして Lambda 関数を選択する際は以下のような画面となります。

![ドロップダウン](/images/posts/tech-posts/1639899963/dropdown.png)

上記画面の 「関数の ARN」項目の下部に「関数が表示されませんか？」というリンクが表示されています。
そのリンクをクリックすると、以下のように「関数の ARN」の入力フォームがドロップダウンからテキストボックスに切り替わり、Lambda 関数の ARN を直接入力できるようになります。

![テキストボックス](/images/posts/tech-posts/1639899963/input.png)

ARN を直接入力できるので、別の AWS アカウントの Lambda 関数だけでなく、Lambda 関数のバージョンやエイリアスも使用できるます。
エイリアスを指定できるので、もちろん Provisioned Concurrency が適応された Lambda 関数もデータソースとして利用できます。
自分はこのリンクをクリックしたら AWS ドキュメントにでも飛ばされるのとかと思っていました。。。


AWS AppSync のデータソースとして Lambda 関数の ARN を入力するには


Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングと境界値分析してみました。

## Amazon Connect の「オペレーション時間を確認する」ブロックで疑問だったこと

- 「オペレーション時間を確認する」ブロックの判定タイミングは「オペレーション時間を確認する」ブロックを通過したタイミングなのか
- オペレーション時間は時間と分(例: 12:00 AM)を設定できますが、秒までの設定できません。仮に終了時間が 06:00 PM だった場合、06:00:01 PM は終了なのか。秒を含めた開始時間と終了時間はどう判定されるのか。

## Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングの検証環境

検証は以下の問い合わせフローを利用します。

![問い合わせフロー](/images/posts/tech-posts/1639648205/contact_flow.png)

:::info

- オペレーション時間は全日開始時間 09:00 AM の終了時間 06:00 PM に設定しています。
- 着信時間と「オペレーション時間を確認する」ブロックを通過させる時間帯を区別及び、微調整するために「顧客の入力を取得する」ブロックを設置してます。
- 「顧客の入力を取得する」ブロックにてタイムアウト の設定を 60 秒 に設定してます。

:::

### Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングの検証方法

検証したい時間の 30 秒くらい前に電話をかけ、「顧客の入力を取得する」ブロックで検証したい時間直前まで待った後に入力を行います。
「オペレーション時間を確認する」を通過した時間は CloudWatch Logs から確認します。

```json fn=CloudWatch Logs
{
  "ContactFlowModuleType": "CheckHoursOfOperation",
  "Timestamp": "2021-12-12T05:39:59.167Z"
}
```

## Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングの判定タイミングは？

結論を先に書くと、「オペレーション時間を確認する」ブロックを通過したタイミングが判定タイミングとなります。

### Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングを検証

- 08:58:30 AM くらいに電話をかけ、「顧客の入力を取得する」ブロックで 50 秒ほど待ち、 08:59:20 AM に 2 を入力する。
  - 結果: CCP で着信を確認でず通話終了。
- 08:59:30 AM くらいに電話をかけ、「顧客の入力を取得する」ブロックで 50 秒ほど待ち、 09:00:20 AM に 2 を入力する。
  - 結果: CCP で着信を確認できた。

## Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングの境界値分析してみた結果

オペレーション時間の開始時間と終了時間それぞれ以下のような動作を確認できました。
さすがにミリ妙単位の検証まではできなかったです。

- 08:59:59.794 は時間外と判断されました。
- 09:00:00.178 は時間内と判断されました。
- 17:59:59.062 は時間内と判断されました。
- 18:00:00.147 は時間外と判断されました。
- 18:00:01.436 は時間外と判断されました。


Amazon Connect の「オペレーション時間を確認する」ブロックの判定タイミングと境界値分析してみた


## AWS CLI で CloudWatch の FILL 関数により自動生成される各メトリクスの色を任意の色にしたい

AWS CLI で `put-dashboard` コマンドを使用して CloudWatch ダッシュボードとグラフウィジェットの作成を行なっていました。
グラフウィジェット内では FILL 関数 [`FILL(METRICS(), 0)`] を使用していたのですが、この FILL 関数は第一引数の配列の数だけグラフを生成します。
その自動生成する複数のグラフそれぞれに色を指定しようとしました。
しかし、メトリクスの色は `color` プロパティで指定できるのですが、どうやら配列で指定できず、単一値のみでした。

```json fn=問題のjson
{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 6,
      "height": 6,
      "properties": {
        "view": "timeSeries",
        "stacked": false,
        "metrics": [
          [
            "AWS/EC2",
            "CPUUtilization",
            "InstanceId",
            "i-xxxxxxxxxxxxxxxxx",
            {
              "id": "m1",
              "color": "#FF80AB"
            }
          ],
          [
            "AWS/EC2",
            "CPUUtilization",
            "InstanceId",
            "i-yyyyyyyyyyyyyyyyy",
            {
              "id": "m2",
              "color": "#EA80FC"
            }
          ],
          [
            {
              "expression": "FILL(METRICS(), 0)",
              "id": "e1",
              "label": "FILL",
              "visible": true,
              "color": "#82B1FF",
              "yAxis": "left"
            }
          ]
        ],
        "region": "ap-northeast-1"
      }
    }
  ]
}
```

AWS マネジメントコンソールから確認すると指定された色が一つのグラフのみ適用され他はランダムな色になっているのが確認できます。

![分割前のグラフ](/images/posts/tech-posts/1639476900/not_split.png)

## AWS CLI で CloudWatch の FILL 関数により自動生成される各グラフの色を任意の色にする方法

### 対象となるメトリクスの数だけ数式のメトリクス(FILL 関数)を定義する

**対象となるメトリクスの数だけ数式のメトリクス(FILL 関数)を定義して、それぞれに対して色を指定することにしました。**

そもそも、FILL 関数は第一引数に予備値として使用する値を指定するのですが、今回使用している METRICS() 関数は、リクエストのすべての CloudWatch メトリクス(単一の時系列または時系列の配列)を返します。
METRICS() 関数を FILL 関数の予備値として使用すると、FILL 関数は METRICS() 関数の返り値が時系列の配列のため、その配列の数だけグラフが生成します。
以下の AWS のドキュメントを確認すると、現状 FILL 関数のように 1 つの式により、グラフの時系列の配列が作成される場合、これらの各時系列に使用される色を変更することはできないと明記されていました。

[Metric Math を使用する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/using-metric-math.html)

> 1 つの式により、グラフの時系列の配列が作成される場合、これらの各時系列に使用される色を変更することはできません。

そのため、METRICS() 関数ではなく、メトリクスの ID を用いて単一の時系列を指定することで、色を変更することができることができるのではと考え試したところ問題なく色の指定ができました。
しかし、結果として対象となるメトリクスの数だけ数式のメトリクス(FILL 関数)を定義する必要はあります。

```json fn=完成したjson
{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 6,
      "height": 6,
      "properties": {
        "view": "timeSeries",
        "stacked": false,
        "metrics": [
          [
            "AWS/EC2",
            "CPUUtilization",
            "InstanceId",
            "i-xxxxxxxxxxxxxxxxx",
            {
              "id": "m1",
              "color": "#FF80AB"
            }
          ],
          [
            "AWS/EC2",
            "CPUUtilization",
            "InstanceId",
            "i-yyyyyyyyyyyyyyyyy",
            {
              "id": "m2",
              "color": "#EA80FC"
            }
          ],
          [
            {
              "expression": "FILL(m1, 0)",
              "id": "e1",
              "label": "M1_FILL",
              "visible": true,
              "color": "#82B1FF",
              "yAxis": "left"
            }
          ],
          [
            {
              "expression": "FILL(m2, 0)",
              "id": "e2",
              "label": "M2_FILL",
              "visible": true,
              "color": "#00BFA5",
              "yAxis": "left"
            }
          ]
        ],
        "region": "ap-northeast-1"
      }
    }
  ]
}
```

AWS マネジメントコンソールから確認すると指定された色が適用されているのが確認できます。
見た目も分割する前と変わっていません。

![分割後のグラフ](/images/posts/tech-posts/1639476900/split.png)

## 参考文献

<https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/using-metric-math.html>


AWS CLI で CloudWatch の FILL 関数により自動生成される各メトリクスの色を任意の色にしたい時の方法


## AWS CLI で、IAM ポリシーがアタッチされた IAM ロールと、IAM ロールがアタッチされた AWS サービスを確認する方法はあるのか

- 特定の IAM ポリシーがアタッチされた IAM ロールを確認できる AWS CLI コマンドがあるか。
- 特定の IAM ロールがアタッチされた AWS サービスを確認できる AWS CLI コマンドがあるか。

## AWS CLI で、IAM ポリシーがアタッチされた IAM ロールと、IAM ロールがアタッチされた AWS サービスを確認する方法

### 特定の IAM ポリシーがアタッチされた IAM ロールを確認する方法

list-entities-for-policy コマンドの実行結果内の PolicyRoles の値からご確認することができました。

```bash
aws iam list-entities-for-policy --policy-arn <IAN ポリシーの arn>
{
    "PolicyGroups": [],
    "PolicyUsers": [],
    "PolicyRoles": [
        {
            "RoleName": "SmapleRoleName",
            "RoleId": "AAAAAAAAAAAAAAAAAAAAA"
        },
    ]
}
```

### 特定の IAM ロールがアタッチされた AWS サービスを確認する方法

一方で、特定の IAM ロールがアタッチされた AWS サービスを確認できる AWS CLI コマンドは見つかりませんでした。
ただ、get-role コマンドの実行結果内の AssumeRolePolicyDocument 内の Service の値から推測することは可能ではあるかなと思ったのですが、以下の懸念ともあり、実用性には欠けます。
・AWS サービス単位であって機能単位( 実際にアタッチされている EC2 インスタンスなど )での確認ができない。
・実際にその IAM ロールが AWS サービスにアタッチされているかは確認できない。
・IAM ポリシーの内容は変更が可能なため、確認したタイミング時に IAM ポリシーに記載の AWS サービスとは別の AWS サービスが登録された結果、一致しない可能性がある。

現状、適宜 IAM ロールの使用状況を個別に確認・管理していく必要があるという結論です。
IAM ロールの使用状況に関しては CloudTrail のログから確認できるようなので、こうゆうのを使っていく感じになのかな。

```bash
aws iam get-role --role-name <IAM ロール名>
{
  "Role": {
      ...
      "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                      "Service": "ec2.amazonaws.com"
                  },
                  "Action": "sts:AssumeRole"
              }
          ]
      },
      ...
  }
}
```

## 参考文献

<https://docs.aws.amazon.com/ja_jp/cli/latest/reference/iam/list-entities-for-policy.html>

<https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html>

<https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html>

<https://aws.amazon.com/jp/premiumsupport/knowledge-center/view-iam-history/>


AWS CLI で、IAM ポリシーがアタッチされた IAM ロールと、IAM ロールがアタッチされた AWS サービスを確認する方法はあるのか


## S3 バケットへのリクエスト毎の TLS バージョンを確認したい

外部公開している S3 バケットへのリクエストに利用可能な TLS のバージョンを 1.2 のみに制限したい場合に、既存ユーザーにどれくらい影響が出るかわからないので、TLS バージョンの利用状況を確認したい。

## S3 バケットへのリクエスト毎の TLS バージョンを確認するにはどうすればいいの？

### サーバーアクセスのログ記録機能を使う

S3 バケットの「プロパティ」に「サーバーアクセスのログ記録」という設定項目があります。

![サーバーアクセスのログ記録](/images/posts/tech-posts/1639303169/server_access_log.png)

こちらを有効にすることで S3 バケットに対するリクエストの詳細が記録されるようになります。
このサーバーアクセスログから TLS のバージョンを確認することができます。
以下のように TLS バージョンはログの末尾に出力されます。

```log fn=サンプルログ(長いので前半省略)
... TLSV1.1
```

[ベストエフォート型のサーバーログ配信](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/ServerLogs.htmll)

> サーバーアクセスログレコードの配信は、ベストエフォートで行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。
> サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。
> サーバーのログ作成機能はベストエフォート型であるため、AWS ポータルで利用できる使用状況レポート (AWSManagement Console でレポートされる請求およびコスト管理レポート) には、サーバーログに記録されていないアクセスリクエストが含まれる場合があります。

一方で、上記の記述のように、サーバーアクセスログレコードの配信は、ベストエフォートで行われ、完全性や適時性は保証されません。
つまり、リクエストが実際に処理されてからかなり後に配信される可能性があるので、実際にログが確認できるまで数時間かかる
可能性があります。
また、そもそもサーバーアクセスログレコードが配信されていない可能性もあります。

> ログの保存先のバケットとして、ソースバケットと同じリージョンにあるユーザー所有のバケットを指定できます。これにはソースバケット自体も含まれます。ただし、ログを管理しやすくするため、アクセスログは別のバケットに保存することをお勧めします。

また、上記の記述のように、アクセスログの書き込み先のバケットには、サーバーアクセスログを有効にしたバケットと異なるバケットを指定することを推奨しているようです。

## 参考文献

<https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/ServerLogs.html>

<https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/LogFormat.html>


S3 バケットへのリクエスト毎の TLS バージョンを確認したい時の方法


AWS Lambda から cx_Oracle という Python モジュールを使用して RDS(OracleDB) へ接続してみたので、その手順をまとめました。

## Lambda から Python で RDS (OracleDB) へ接続する (cx_Oracle 編)

Lambda 関数から `cx_Oracle` を利用するための Lambda レイヤーを作成します。
`cx_Oracle` のドキュメントでは以下のように記載しています。

[Introduction to cx_Oracle — cx_Oracle 8\.3\.0 documentation](https://cx-oracle.readthedocs.io/en/latest/user_guide/introduction.html)

> Python programs call cx_Oracle functions. Internally cx_Oracle dynamically loads Oracle Client libraries to access OracleDB.
> ...
> On Linux, the libaio (sometimes called libaio1) package is needed.

上記の記述のように、`cx_Oracle` は内部的に `Oracle Client libraries` を動的にロードして、Oracle データベースにアクセスまた、`libaio(libaio1)` パッケージも必要です。
そのため、Lambda レイヤーには `cx_Oracle` と `Oracle Client libraries` と `libaio(libaio1)` を含める必要があります。

## Lambda から Python で RDS (OracleDB) へ cx_Oracle を使って接続する手順

### 前提条件

- 動作確認環境
  - Lambda Runtime: Python3.7, Python3.8, Python3.9
  - RDS(OracleDB): Oracle 19.0.0.0.ru-2021-07.rur-2021-07.r1
- 作業環境
  - EC2 (Amazon Linux2)
    - Python 3.7 と `libaio1` がすでにインストールされているためお勧めです。
- cx_Oracle 8.3
- Oracle Client libraries 19.13

### 作業ディレクトリの作成

```bash fn=~
mkdir ~/oracle_layer
cd ~/oracle_layer
mkdir python/ lib/
```

### cx_Oracle モジュールのインストール

pip コマンドに -t オプションを指定して python ディレクトリに `cx_Oracle` モジュールをインストールします。

```bash fn=~/oracle_layer
pip install cx_Oracle -t python/
```

### Oracle Client libraries のインストール

Oracle Client libraries をダウンロードして lib ディレクトリに展開します。
Oracle Client libraries は[ここから](https://www.oracle.com/jp/database/technologies/instant-client/linux-x86-64-downloads.html)ダウンロードします。

```bash fn=~/oracle_layer
wget https://download.oracle.com/otn_software/linux/instantclient/1913000/instantclient-basic-linux.x64-19.13.0.0.0dbru.zip -O oracle_client_lib.zip
unzip -j oracle_client_lib.zip -d lib/
```

### libaio1 を lib ディレクトリにコピーする

```bash fn=~/oracle_layer
cp /lib64/libaio.so.1 lib/libaio.so.1
```

### デプロイパッケージを作成する

```bash fn=~/oracle_layer
zip -r -y layer.zip python/ lib/
```

:::warning
lib ディレクトリ内の Oracle Client libraries は一部のファイルがシンボリックリンクです。
シンボリックリンクのまま格納する必要があるため、-y オプションを忘れずに。
-y オプションの替わりに --symlinks オプションでもいいです。
:::

### Lambda レイヤーの作成

#### Lambda レイヤーの作成パターンその 1: デプロイパッケージを S3 にアップロードしてそれを使用する

```bash fn=~/oracle_layer
aws s3 cp oracle_layer.zip s3://lambda_layer/oracle_layer.zip
aws lambda publish-layer-version \
    --layer-name cx_Oracle \
    --description "cx_Oracle layer" \
    --content S3Bucket=lambda_layer,S3Key=oracle_layer.zip \
    --compatible-runtimes python3.7 python3.8 python3.9
```

#### Lambda レイヤーの作成パターンその 2: ローカルにあるデプロイパッケージを使用する

```bash fn=~/oracle_layer
aws lambda publish-layer-version \
    --layer-name cx_Oracle \
    --description "cx_Oracle layer" \
    --zip-file fileb://oracle_layer.zip \
    --compatible-runtimes python3.7 python3.8 python3.9
```

### 接続確認

作成した Lambda レイヤーを使用する Lambda 関数を作成し、テスト実行して接続確認してみます。
特にエラーが発生しなければ成功です。

```py
import cx_Oracle

def lambda_handler(event, context):
    connection = cx_Oracle.connect(<username>, <password>, <hostname>)
```

## 参考文献

<https://cx-oracle.readthedocs.io/en/latest/user_guide/introduction.html>

<https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html>


AWS Lambda から Python で RDS (OracleDB) へ接続する (cx_Oracle 編)


CircleCI に「セットアップ・ワークフロー」という新機能を触ってみたので、確認した内容をメモ。
因みに CircleCI2.1 の新機能です。

## サンプルリポジトリ

サンプルとなるソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。

<https://github.com/grasswake/circleci-setup-workflow-sample>

## セットアップ・ワークフロー

セットアップ・ワークフローに関しては以下のサイトを参照。

<https://discuss.circleci.com/t/topic/39578>

> セットアップ・ワークフローとは、パイプラインを「セットアップ」するために実行されるワークフローです。CircleCI のジョブが、パイプラインのコンフィグやパラメータを生成、あるいは設定することで「セットアップ」を行います。
> セットアップ・ワークフローが有効であることが期待される領域の一つに、モノリポ(モノレポ)を活用いただいているお客様のサポートが挙げられます。Bazel のようなビルドツールを利用して、git コマンドを実行して、変更のあったファイルを検出し、複雑な依存関係を分析した上で、複数あるコンフィグファイルを組み合わせて実行しているといった、さまざまなモノリポのユースケースにおいて、それぞれ異なるジョブを利用することが可能になります。

以上のようにモノリポ(モノレポ)のための機能のようです。

## プロジェクトの設定

セットアップ・ワークフローを利用するために、
対象のプロジェクトの `Project Settings` → `Advanced` の中にある `Run Setup Workflows (PREVIEW)` を有効にしときます。

![workflowの有効化](/images/posts/tech-posts/1617548400/run_setup_workflows.png)

## サンプルのディレクトリ構成

src ディレクトリ配下にはモノリポ(モノレポ)っぽくクライアントとサーバーのソース分けてあります。

```text fn=ディレクトリ構成
$ tree
.
├── .circleci
│   ├── config.yml
│   └── sample.yml
├── README.md
└── src
    ├── client
    │   └── index.js
    └── server
        └── index.js
```

## ファイルの中身

```yaml fn=.circleci/config.yml
version: 2.1

setup: true

orbs:
  path-filtering: circleci/path-filtering@0.0.2

executors:
  default:
    docker:
      - environment:
          TZ: Asia/Tokyo
        image: circleci/node:14.15.5

workflows:
  generate-config:
    jobs:
      - path-filtering/filter:
          base-revision: origin/main
          config-path: .circleci/sample.yml
          mapping: |
            src/server/.* build-server true
            src/client/.* build-client true
```

- `setup: true`
  - セットアップ・ワークフローの有効化(必須です)
- `config-path`
  - job や workflow などメインの処理が定義された config ファイルを指定します。
  - サンプルでは `sample.yml` というファイルですが、読み込むファイルのファイル名を `continue_config.yml` にすればこの設定は必要なく、自動読み込みされます。
- `mapping`
  - 変更されたファイルのファイル名がここで定義された正規表現にマッチしている場合、定義してた「パイプライン パラメータ」を指定した値で明け渡すための定義です。今回のサンプルでは、src/server/配下のファイルが変更されていた場合は`build-server` を `true` で明け渡すといった感じです。

```yaml fn=.circleci/sample.yml
version: 2.1

parameters:
  build-client:
    default: false
    type: boolean
  build-server:
    default: false
    type: boolean

executors:
  default:
    docker:
      - environment:
          TZ: Asia/Tokyo
        image: circleci/node:14.15.5
    working_directory: ~/repo

jobs:
  build-client:
    executor: default
    steps:
      - checkout
      - run:
          name: build-client
          command: |
            echo 'run build-client'

  build-server:
    executor: default
    steps:
      - checkout
      - run:
          name: build-server
          command: |
            echo 'run build-server'
  echo:
    executor: default
    steps:
      - run:
          name: Echo
          command: |
            echo '何もやることないとエラーになるよ'

workflows:
  version: 2
  build-client:
    jobs:
      - build-client
    when: << pipeline.parameters.build-client >>
  build-server:
    jobs:
      - build-server
    when: << pipeline.parameters.build-server >>
  echo:
    jobs:
      - echo
    when:
      and:
        - not: << pipeline.parameters.build-client >>
        - not: << pipeline.parameters.build-server >>
```

- `parameters`
  - ここで、config.yml から渡されるパラメータを定義しておきます。デフォルト値も基本設定しておきましょう。
- `workflows`
  - `when` で `parameter` 別で実行する workflow を切り替えています。例えば、src/server/ 配下のファイルのみが変更されていた場合は `build-server` が `true` で渡ってくるので、`build-server` という `workflow` が実行され、`build-client` は実行されません。

## サンプルまとめ

かなり簡素なサンプルですが、ここで CircleCI のパイプラインに付いて復習です。

> パイプラインとは、CircleCI を使用するプロジェクトで作業をトリガーするときに実行される構成全体を指す言葉です。 .circleci/config.yml ファイルの全体が 1 つのパイプラインによって実行されます。

そして、セットアップワークフローの説明です。

> セットアップ・ワークフローとは、パイプラインを「セットアップ」するために実行されるワークフローです。

セットアップワークフローを有効化した config.yml でパイプラインを生成または読み込んで実行するだけというイメージでいいと思います。
そのパイプライン呼び出し時に任意のパラメータを「どのファイルが変更されたのかに応じて変更したり」して渡したりすることで、パイプライン上でそのパラメータを利用することも可能です。

## 注意点

- `No Jobs have been run.All Workflows have been filtered from this Pipeline.` - 最後に `echo` だけしていますが、これがなかった場合に今回のサンプルで例えばトップディレクトリにある `README.md` ファイルだけを変更した場合、`mapping` に引っかからないので、全てのパラメータは `default` の `false` となってパイプラインは動きます。その結果、実行する `workflow` がない場合、エラーとなリます。そのため、`sample.yml` では最後に `echo` だけしてます。
  ![エラー画面](/images/posts/tech-posts/1617548400/no_jobs_have_been_run.png)

- `path-filtering/filter` は何度も呼べない
  - 以下のように `path-filtering/filter` を複数回呼ぶのはできませんでした。
    - `{"message":"Pipeline is not in setup state."}` というエラーがでており、恐らく上述したパイプラインはプロジェクトで一つというのが関係あるのかなと思ってます。

```yaml fn=.circleci/config.yml
workflows:
  client:
    jobs:
      - path-filtering/filter:
          base-revision: origin/main
          config-path: .circleci/client.yml
          mapping: |
            src/client/.* build-client true
  server:
    jobs:
      - path-filtering/filter:
          base-revision: origin/main
          config-path: .circleci/server.yml
          mapping: |
            src/server/.* build-server true
```

## 動的なコンフィグの生成

サンプルでは、`circleci/path-filtering` で事前に用意しておいた config を呼び出していますが、
`circleci/continuation` を利用することで、動的に生成した config の呼び出しも可能です。

```yaml
version: 2.1

setup: true

orbs:
  continuation: circleci/continuation:0.1.2

jobs:
  setup:
    executor: continuation/default
    steps:
      - checkout
      - run:
          name: Generate config
          command: |
            ./generate-config.sh > generated_config.yml
      - continuation/continue:
          configuration_path: generated_config.yml

workflows:
  setup:
    jobs:
      - setup
```

ポイントは `generate-config.sh` で config を動的に生成するスクリプトなどを用意してそれを実行し、生成された config ファイルを `continuation/continue` で読み込み実行しています。


CircleCI のセットアップ・ワークフロープレビューに参加してみた

circleci config pack で分割した yml から設定ファイル (config.yml) を作成してみた


Terraform で Vue.js や Rect などで作られた SPA サイトを独自ドメインで HTTPS 配信するためのインフラを構築していきます。
サンプルソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。

:::info

- terafform のバージョンを 1.0.11 から 1.1.6 に変更
- aws provider のバージョンを 3.68.0 から 4.2.0 に変更
- aws provider のバージョンが 3.68.0 の場合のソースはサンプルリポジトリにて [tag(aws-provider-3.68.0)](https://github.com/grasswake/terraform_aws_static_site/tree/aws-provider-3.68.0) 付けしてるのでそちらを参照してください。

:::

## サンプルリポジトリ

サンプルとなるソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。

<https://github.com/grasswake/terraform_aws_static_site>

※本記事の内容と基本的に一緒ですが、一気に作るのでなく Route53 と ACM、CloudFront の３ディレクトリに分けてます。
その為 remote state を使用した構成になっています。因みに リソース名の定義が下手だったり、access_key などの扱いが雑ですので使ってみる場合は使いやすい形に直してください。

## 前提

- 独自ドメインでのアクセスを行うために、お名前.com などでドメインを購入してください。
  - この記事ではお名前.com で `example.com` というドメインを購入していると想定でいます
- アクセス URL は `example.com` になります。`www.example.com` でのアクセスは想定していません。

## Terraform

### Terraform の Provider 定義

基本的には `region` は `ap-northeast-1` ですが、一部のリソース(ACM, CloudFunctions)の作成は `us-east-1` で行うので、以下のように定義している想定です。

```hcl
provider "aws" {
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
  region     = var.region
}

provider "aws" {
  alias      = "us_east"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
  region     = "us-east-1"
}
```

## Route53 に Terraform で ホストゾーンを作成

まず Route53 でホストゾーンを作成します。
作成するホストゾーン名はパラメータで指定します。

```hcl
resource "aws_route53_zone" "main" {
  name = var.zone_name
}
```

`terraform apply` を実行し、AWS マネジメントコンソールなどでホストゾーンが作成されていることと、NS レコードが作成されていることを確認しましょう。
もし、ドメインを Route53 で購入または Route 53 に移管していないようであれば、この NS レコードをお名前.com などのドメインを購入したところで、Route53 に追加された NS レコードの値を使い、そのドメインに対する NS(ネームサーバー)の変更をしましょう。

## Terraform で ACM による SSL 証明書を発行

Route53 へのホストゾーンの作成と必要であれば NS 変更が終わったら、ACM で SSL 証明書を発行します。

```hcl
resource "aws_acm_certificate" "main_cert" {
  provider                  = aws.us_east
  domain_name               = data.terraform_remote_state.route53.outputs.main_zone_name
  # wwwありのドメインも対象にしたい場合は以下を追加、使用予定はないけどリダイレクトしやすい環境に移行などした時のことを考え一応入れとく
  subject_alternative_names = ["www.${data.terraform_remote_state.route53.outputs.main_zone_name}"]
  # DNSを使ったドメイン認証
  validation_method         = "DNS"
}

# DNSを使ったドメイン認証のためにRoute53にcnameレコードを作成
resource "aws_route53_record" "main_cnames" {
  for_each = {
    for dvo in aws_acm_certificate.main_cert.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }
  zone_id = data.terraform_remote_state.route53.outputs.main_zone_id
  name    = each.value.name
  records = [each.value.record]
  type    = each.value.type
  ttl     = 60
}

resource "aws_acm_certificate_validation" "main_cert_validation" {
  provider                = aws.us_east
  certificate_arn         = aws_acm_certificate.main_cert.arn
  validation_record_fqdns = [for record in aws_route53_record.main_cnames : record.fqdn]
}
```

## Terraform で CloudFront と OAI と S3 　を作成

ここから一気に色々作成していきます。

### Terraform で S3 を作成

```hcl
# vueなど配信コンテンツ用のバケット
resource "aws_s3_bucket" "origin_bucket" {
  bucket = local.domain_name
  force_destroy = true
}

#  CloudFront 以外からアクセスできる必要はないので、ACL をプライベートにします
resource "aws_s3_bucket_acl" "origin_bucket_acl" {
  bucket = aws_s3_bucket.origin_bucket.id
  acl    = "private"
}

# CloudFront 以外からアクセスできる必要はないので、パブリックアクセスを全てオフにします
resource "aws_s3_bucket_public_access_block" "origin_bucket" {
  bucket                  = aws_s3_bucket.origin_bucket.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# CloudFrontのアクセスログ用のバケット
resource "aws_s3_bucket" "logging_bucket" {
  bucket = "cloudfront-logs.${local.domain_name}"
  force_destroy = true
}

# パブリックアクセスを全てオフにします
resource "aws_s3_bucket_public_access_block" "logging_bucket" {
  bucket                  = aws_s3_bucket.logging_bucket.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# ログのバケットのライフサイクルを設定します
# この辺はお好みで変更してください
resource "aws_s3_bucket_lifecycle_configuration" "logging_bucket_lifecycle_config" {
  bucket = aws_s3_bucket.logging_bucket.bucket

  rule {
    id      = "s3-cloudfront-logs-transitions"
    status = "Enabled"

    expiration {
      days = 365
    }

    transition {
      days          = 90
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 180
      storage_class = "GLACIER"
    }
  }
}
```

### Terraform で OAI (Origin Access Identity)　を作成

パブリックアクセスでない S3 に CloudFront がアクセスできるようにするために、OAI を作成します

```hcl
# OAIの作成
resource "aws_cloudfront_origin_access_identity" "oai" {
  comment = "access-identity-ap-northeast-1-cloudfront-resource-periosprint-dev"
}

data "aws_iam_policy_document" "origin_access_identity_policy" {
  statement {
    sid       = "OriginAccessIdentity"
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.origin_bucket.arn}/*"]

    principals {
      type        = "AWS"
      identifiers = [aws_cloudfront_origin_access_identity.oai.iam_arn]
    }
  }
}

# OAIを利用したCloudFrontからのアクセスを許可するポリシーをS3のバケットに設定
resource "aws_s3_bucket_policy" "origin_bucket_policy" {
  bucket = aws_s3_bucket.origin_bucket.id
  policy = data.aws_iam_policy_document.origin_access_identity_policy.json
}
```

### Terraform で CloudFront を作成

```hcl
# キャッシュポリシーの作成
resource "aws_cloudfront_cache_policy" "this" {
  name        = local.uppercase_domain_name
  comment     = local.uppercase_domain_name
  # default_ttl と max_ttl min_ttl は開発環境なら0にしてキャッシュしない方が開発しやすいです
  default_ttl = 86400
  max_ttl     = 31536000
  min_ttl     = 1
  parameters_in_cache_key_and_forwarded_to_origin {
    cookies_config {
      cookie_behavior = "none"
    }
    headers_config {
      header_behavior = "none"
    }
    query_strings_config {
      query_string_behavior = "none"
    }
    enable_accept_encoding_brotli = true
    enable_accept_encoding_gzip = true
  }
}

# オリジンリクエストポリシーの作成
resource "aws_cloudfront_origin_request_policy" "this" {
  name    = local.uppercase_domain_name
  comment = local.uppercase_domain_name
  cookies_config {
    cookie_behavior = "none"
  }
  headers_config {
    header_behavior = "none"
  }
  query_strings_config {
    query_string_behavior = "none"
  }
}

resource "aws_cloudfront_distribution" "cfd" {
  aliases = [local.domain_name]

  comment             = local.domain_name
  enabled             = true
  is_ipv6_enabled     = true
  price_class         = "PriceClass_200"
  default_root_object = "index.html"

  origin {
    domain_name = aws_s3_bucket.origin_bucket.bucket_regional_domain_name
    origin_id   = local.domain_name

    s3_origin_config {
      origin_access_identity = aws_cloudfront_origin_access_identity.oai.cloudfront_access_identity_path
    }
  }

  logging_config {
    include_cookies = false
    bucket          = aws_s3_bucket.logging_bucket.bucket_domain_name
  }

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = local.domain_name
    # httpでアクセスされた場合、httpsにリダイレクト
    viewer_protocol_policy = "redirect-to-https"
    compress               = true
    cache_policy_id = aws_cloudfront_cache_policy.this.id
    origin_request_policy_id = aws_cloudfront_origin_request_policy.this.id
  }

  custom_error_response {
    error_caching_min_ttl = "300"
    error_code            = "403"
    response_code         = "200"
    # Nuxt や Next.js で SSG を用いていて 404.html など専用ページがあれば置き換えてください。
    response_page_path    = "/index.html"
  }

  custom_error_response {
    error_caching_min_ttl = "300"
    error_code            = "404"
    response_code         = "200"
    # Nuxt や Next.js で SSG を用いていて 404.html など専用ページがあれば置き換えてください。
    response_page_path    = "/index.html"
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    acm_certificate_arn      = data.terraform_remote_state.acm.outputs.acm_main_cert_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2019"
  }
}

```

### Terraform で Route53 (A レコード) を作成

Route53 に A レコードを追加して、独自ドメインにアクセスされた場合、CloudFront にアクセスされるようにします

```hcl
resource "aws_route53_record" "www" {
  zone_id = local.zone_id
  name    = local.domain_name
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.cfd.domain_name
    zone_id                = aws_cloudfront_distribution.cfd.hosted_zone_id
    evaluate_target_health = false
  }
}
```

## おまけ (Basic 認証と URL の書き換え）

開発環境などアクセスされたくない場合に便利

### Terraform で CloudFront Functions (Basic 認証用の処理) を作成

```js fn=basic_auth/function.js
function handler(event) {
  var request = event.request
  var uri = request.uri
  var headers = request.headers

  // Basic 認証に用いる文字列(dXNlcjpwYXNzd29yZA==)の部分は shell などで以下のコマンドで生成します。
  // echo -n user:password | base64
  var basicAuth = 'Basic dXNlcjpwYXNzd29yZA=='

  if (
    typeof headers.authorization === 'undefined' ||
    headers.authorization.value !== basicAuth
  ) {
    return {
      statusCode: 401,
      statusDescription: 'Unauthorized',
      headers: { 'www-authenticate': { value: 'Basic' } },
    }
  }

  if (uri === '/') {
    return request
  }

  if (uri.endsWith('/')) {
    // リクエスト URL が https://hogehoge.com/foo/ の様に "/" で終わる場合は、この分岐に入ります。
    // その際の扱いは要件によって変えてください。

    // パターン1: Nuxt の例ですが、pages/bar/index.vue のような構成の場合は、
    // リクエスト URL が https://hogehoge.com/bar/ であれば、
    // https://hogehoge.com/bar/index.html にルーティングして欲しいので request.uri の末尾に index.html を付与します。
    request.uri = request.uri.concat('index.html')
    return request

    // パターン2: "/" で終わる場合は "/" を削ってリダイレクト
    return {
      statusCode: 302,
      statusDescription: 'Found',
      headers: {
        location: {
          value: request.uri.slice(0, -1),
        },
      },
    }
  } else if (!uri.includes('.')) {
    // ファイル名に "." が含まれていない = 拡張子がない場合、request.uri の末尾に  ".html" をつける
    request.uri = request.uri.concat('.html')
  }

  return request
}
```

### Terraform で CloudFront Functions を CloudFront に設定

```hcl
resource "aws_cloudfront_function" "basic_auth" {
  name    = "basic_auth"
  runtime = "cloudfront-js-1.0"
  comment = "basic_auth function"
  publish = true
  code    = file("${path.module}/basic_auth/function.js")
}

resource "aws_cloudfront_distribution" "cfd" {
  default_cache_behavior {
    function_association {
      event_type = "viewer-request"
      function_arn = aws_cloudfront_function.basic_auth.arn
    }
  }
}
```


Terraform で SPA を配信する HTTPS 静的サイトのインフラを構築する[Route53 + ACM + CloudFront + S3 + CloudFront Functions(Basic 認証 + α)]


## Docker-Selenium を使って印刷プレビューを介しての PDF 保存をやってみた背景

会社で利用している監視サービスで一々 Web ブラウザを使って監視対象分のサーバーの監視レポートを毎月ダウンロードして顧客に提出ということをしてたので、今まで興味はあったけど手が出せてなかった Python と Selenium に入門したついでにこの課題を解決してみたのですが、思った以上に詰まったので内容をメモします。

## Docker-Selenium を使って印刷プレビューを介しての PDF 保存を自動化する前の手作業

1. ログイン画面
   - id, pass を入力してログインする
2. ダッシュボード画面
   - 監視対象のサーバーの一覧が表示されている
   - サーバー名をクリックして詳細画面に遷移する
3. 詳細画面
   - 月毎の監視レポートのリンクの一覧が降順表示されている
   - 一覧上の最新の月のリンクをクリックして監視レポート画面に遷移する
4. 監視レポート画面
   - 印刷ボタンがあるので、それをクリックして印刷プレビューを介して PDF を保存
5. 2〜4 をサーバーの数だけ繰り返す

## ファイル構成

```text fn=ディレクト構成
workspace
    └─ dev
        └─ shm               ← ファイルの保存先
    └─ docker-compose.yml    ← docker-selenium用のdocker-composeファイル
    └─ main.py               ← Selenium実行ファイル
```

## Mac に Selenium をインストール

```bash
pip3 install selenium
```

## Selenium Grid の準備

オーバースペックみたいですが Selenium Grid を使ってみます。
利用するイメージは `selenium/standalone-chrome` です。

```yaml fn=docker-compose.yml
version: '3'

services:
  chrome:
    image: selenium/standalone-chrome
    ports:
      - 4444:4444
    volumes:
      - $PWD/dev/shm:/dev/shm
```

## Docker-Selenium を使って印刷プレビューを介しての PDF 保存処理の作成

```py fn=main.py
import sys
import time
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities


def search_and_download(driver):
    driver.get('https://hogehoge/ligin')

    # idとパスワードを入力してログイン
    id = driver.find_element_by_id("id_username")
    id.send_keys("ID")
    password = driver.find_element_by_id("id_password")
    password.send_keys("パスワード")

    login_button = driver.find_element_by_xpath('//*[@type="submit"]')
    login_button.click()

    # ダッシュボード画面で監視対象のサーバーの詳細画面へのリンクを全て取得し、アドレスだけ別変数に退避
    list_items = driver.find_elements_by_xpath('//a[starts-with(@href,"/reports")]')
    links = [list_item.get_attribute('href') for list_item in list_items]

    for link in links:
        try:
            # 詳細画面へ遷移し、最新の監視レポートリンクを取得
            driver.get(link)
            detail = driver.find_element_by_xpath('//a[starts-with(@href,"/reports/report/detail/")]')

            # 監視レポート画面へ遷移し、印刷ボタンをクリックすると自動でPDF保存されます
            driver.get(detail.get_attribute("href"))
            print_button = driver.find_element_by_xpath('//button[starts-with(@onclick,"window")]')
            print_button.click()
            time.sleep(3)
        except:
            print('監視レポートなし')
            continue

if __name__ == '__main__':
    query = ' '.join(sys.argv[1:])

    caps = DesiredCapabilities.CHROME.copy()
    caps['chromeOptions'] = {
        'args': [
            '--kiosk-printing',
        ],
        'prefs': {
            'savefile': {
                'default_directory': '/dev/shm'
            },
            'printing': {
                'print_preview_sticky_settings':{
                    'appState': {
                        'recentDestinations': [{
                            'id': 'Save as PDF',
                            'origin': 'local',
                            'account': '',
                        }],
                        'selectedDestinationId': 'Save as PDF',
                        'version': 2
                    }
                }
            }
        }
    }

    options = {
        'command_executor': 'http://localhost:4444/wd/hub',
        'desired_capabilities': caps
    }

    with webdriver.Remote(**options) as driver:
        driver.implicitly_wait(1)
        search_and_download(driver)

```

## Docker-Selenium を使って印刷プレビューを介しての PDF 保存処理の内容

```py
caps['chromeOptions'] = {
    'args': [
        '--kiosk-printing',
    ],
    'prefs': {
        'savefile': {
            'default_directory': '/dev/shm'
        },
        'printing': {
            'print_preview_sticky_settings':{
                'appState': {
                    'recentDestinations': [{
                        'id': 'Save as PDF',
                        'origin': 'local',
                        'account': '',
                    }],
                    'selectedDestinationId': 'Save as PDF',
                    'version': 2
                }
            }
        }
    }
}
```

`chromeOptions` で chrome の webdriver の細かな設定を行えます。

- `--kiosk-printing`

  - このオプションを指定すると、window.print()を実行し印刷しようとすると、印刷プレビューがすぐに閉じられ、Chrome に事前に設定した設定が自動的に使用されます。
  - 因みにこのオプションは `--headless` とは併用できないようです。その為、`--headless` をつけると PDF がダウンロードされませんでした。

- `prefs.savefile.default_directory`

  - 今回一番はまったところです。印刷プレビューを介したファイル保存で使用するファイル保存先の設定です。selenium でファイル保存関連を検索すると `download.default_directory` といった `download` を使用した記事が多いのですが、それでは保存できませんでした。やっとたどり着いたのがこのプロパティで無事保存ができました。

- `printing`
  - このオプションで印刷プレビューの設定ができます。今回は PDF での保存が目的なのでそれを選択するようにしています。

## Docker-Selenium を使って印刷プレビューを介しての PDF 保存をやってみた　まとめ

目的は達成しましたがまだまだわからないことだらけでした。
本当は main 処理の最後に後始末として `driver.quit()` を入れたのですが、
`selenium.common.exceptions.WebDriverException: Message: No active session with ID ~` というエラーが出て結局解決できませんでした。
あと作ってる最中ずっと、公式リファレンスはどこかにないの？と思っていました。
特に `ChromeOptions` の `savefile` は色々ググってやっと見つけたのが個人ブログでした。
その後、`ChromeOptions savefile` でぐぐりましたが全く情報がなく、
`savefile` といったプロパティの存在はを知るにはどうしたらいいのかと今でも悶々としています。
