AWS on ゲンゾウ用ポストイット

OIDCを使ってGithub ActionsからAWSにアクセスする仕組みについて理解を整理してみた

Wed, 16 Aug 2023 17:47:45 +0900

はじめに

Github Actions から AWS クラウドリソースを操作するためにACCESS_KEY、SECRET_ACCESS_KEYを使う方法はもう古い、OIDCを使うのが一般的といわれましたが理解していなかったため整理しました。

検証環境

今回取り上げる CI/CD ( ビルド ) パイプライン は Github Actions に限定しています。

クラウドプロバイダー に関しても、 AWS に限定しています。

ただしアーキテクチャはCI/CDパイプラインがCircleCIやCloudBuild、クラウドプロバイダーがGCPやAzureに置き換えられたとしても適用可能なものと考えられます。

パスワードやアクセストークンを使ってGithub Actionsからクラウドへ認証する方法の問題点

Github ActionsのようなCI/CDパイプラインから、クラウド環境 ( AWS、Azure、GCP… ) にアクセスするケースは多いはずです。

ビルドされたソフトウェアやコンテナイメージはいずれデプロイされますし、デプロイ環境としてクラウド環境 ( ex: AWS ) が利用されることが多いからです。

Github Actionsがクラウド上のリソースにアクセスするために、事前にパスワードやアクセストークンといった認証情報を取得しておく必要があります。

これらの認証情報はGithubの secrets に保存することが多いでしょう。 Github Actionsワークフローは実行のたびに secrets から認証情報を取り出し、これを使ってクラウド環境へのアクセスを可能にします。

しかし、このような secrets を使う方法には問題があります。以下のような手間が発生します。

クラウド上のIAMサービスで認証情報を生成する
生成した認証情報をGithubのsecretsに登録する

つまり、認証情報が二重管理されることになります 。

OIDC ( OpenID Connect ) を使うメリット

そこで登場するのがOIDC ( OpenID Connect ) です。

OIDCを使うと、Github Actionsワークフローがクラウドプロバイダーに対して要求するアクセストークンは、有効期限の短いものとなります。

もちろんOIDC認証による認証をサポートされているクラウドプロバイダーでしか利用できない方式ではありますが、現在はほとんどのクラウドプロバイダー ( AWS、Azune、GCP、HashiCorp Vault… ) がOIDCをサポートしています。

AWS CodeWhispererを使うためにセットアップを進めたがVimから利用できないことがわかり諦める

Sun, 16 Apr 2023 07:23:20 +0900

はじめに

きっかけは以下の記事を見たことです。

[AWS 版 GitHub Copilot となる「Amazon CodeWhisperer」が正式版に。個人ユーザーは無料、VSCode に対応－ Publickey] ( https://www.publickey1.jp/blog/23/awsgithub_copilotamazon_codewhisperervscode.html )

正式版となった上に、個人ユーザーは無料。 OpenAI 様にはそこそこのお金を払っているわけですが、無料のものが利用できるとなれば乗っかりたいところです。またビジネス版でも $19 とまあまあ許容範囲かと思いました。 Github Copilot との違いも把握しておきたいです。

となれば早速使ってみなければ。

作業の流れ ( 作業ログ )

いつものように AWS Console にログインし、上部の検索エリアから検索してみました。

whisper と入力しようとしたらすでに候補が上がってきました。見つかったページをクリックしました。

メニューをクリックすると以下のようなページが表示されました。

Get started をクリック。

残念。利用のためには事前準備が必要とのこと。

IAM Identity Center が有効になっていないので、事前に有効にしなければなりません。

IAM Identity Center 有効化

以下のページを参考に、 IAM Identity Center を有効にします。

はじめに - AWS IAM Identity Center ( successor to AWS Single Sign-On )

Active Directory のような LDAP データベースとつないで ID 管理を容易にするサービスのようです。自分個人で利用するので当然そんな DB は持ち合わせていませんが、必要だということなので有効化しておきましょう。

MySQLのMAX_EXECUTION_TIMEを使って長時間実行中のクエリを強制的に中断させる

Sat, 04 Feb 2023 09:00:07 +0900

はじめに

多くのサービスでは、MySQL データベースを利用しています。

まれに実行時間の長いクエリが発生します。いくつか上がった対策の 1 つに実行時間の長い SELECT クエリを強制的に終了させるという案がありました。案を実現するために MAX_EXECUTION_TIME の設定を利用できます。

ここで挙がった MAX_EXECUTION_TIME とはどのような設定であり、どのように変更するのがよいかを紹介します。

MySQL の `MAX_EXECUTION_TIME` とはなにか？

MAX_EXECUTION_TIME とはどんな設定項目なのでしょうか。

MySQL 5.7 の公式ドキュメントには以下のように書かれています。

MySQL 5.7 から利用できる設定項目である
読み取り専用の SELECT 文にだけ適用される
- 読み取り専用じゃない SELECT 文とは、更新を行うファンクションを呼び出している SELECT 文のこと ( ex: select my_stored_func_to update )
ファンクションの中の SELECT 文には適用されない
デフォルト値は 0 であり、この状態では実行タイムアウトは無効 ( 結果が取得できるまで実行される )

検証環境

検証は Docker Compose を使って行います。

1
2
3
4


$ docker-compose --version

$ docker --version
Docker version 20.10.21, build baeda1f

利用する MySQL の Docker イメージは MAX_EXECUTION_TIME の設定が利用できる MySQL 5.7 を使用します。

AWSの設定(プロファイル)をコマンドで簡単に切り替える方法

Fri, 03 Sep 2021 21:26:10 +0900

はじめに

管理するクラウド上のシステムが増えてくると、AWS の設定(プロファイル)の切り替えが頻発してきます。

aws では、設定情報+認証情報をそれぞれ以下のファイルで管理しています。

`~/.aws/config
~/.aws/credentials

僕の Mac の設定ファイルはそれぞれ以下のようになっています。 ( セキュアな情報のため、一部マスキング OR 変換しています。 )

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


$ cat ~/.aws/config
[default]
region = ap-southeast-1
output = json
[profile project-production]
region = ap-northeast-1
output = json
[profile project-staging]
region = ap-northeast-1
output = json
[profile project-development]
region = ap-northeast-1
output = json

$ cat ~/.aws/credentials
[default]
aws_access_key_id = ********************
aws_secret_access_key = ****************************************
[project-production]
aws_access_key_id = ********************
aws_secret_access_key = ****************************************
[project-staging]
aws_access_key_id = ********************
aws_secret_access_key = ****************************************
[project-development]
aws_access_key_id = ********************
aws_secret_access_key = ****************************************

僕の Mac には AWS 接続用のプロファイルが 4 つ 存在していることになります。

「Amazon Cognito」で提供するログインページを自作してみる（`aws-cli`で構築）

Thu, 06 Jun 2019 23:41:17 +0900

はじめに

「Amazon Cognito」を使って既存のWebサービスのログイン認証機能を一部置き直す方法について、何パターンか検討してみました。

今まで検討してみた方法ですが、いずれも「Amazon Cognito」が提供するログインページをそのまま利用する、というものでした。

どうしてもログインページを既存のWebシステムのデザインに合わせたい、という場合にはログインページも既存のWebページのものを使う方法もあります。既存のWebページのものを流用する方法についてまとめてみました。

準備

今回はなるべくAWSの「マネージメントコンソール」からの操作を行わずに「Cognito」を使ったログイン機能を実装してみます。

そのため、以下のコマンドを利用することを前提としています。

aws コマンド
jq コマンド
npm コマンド

検証環境

1
2
3
4
5
6
7
8


$ aws --version
aws-cli/1.16.170 Python/3.7.3 Darwin/18.6.0 botocore/1.12.160

$ jq --version
jq-1.6

$ npm --version
6.9.0

作業開始

今回作成したプログラムは以下のGithubリポジトリにコミット済みです。試行錯誤した結果作成されたプログラムを負いながら手順を説明します。

GitHub - genzouw/aws-cognito-example-custom-page

圧縮されたソースファイルをダウンロードするか、 git コマンドで clone しておいてください。（Githubリポジトリページのソースコードを見ても良いです。）

1

$ git clone git@github.com:genzouw/aws-cognito-example-custom-page.git

※(2019-06-06) 便宜上、当エントリにGithubリポジトリ上のコードと同じ内容を貼り付けておきますが、メンテナンスはGithubリポジトリの方だけとする予定です。乖離する可能性があることをご了承ください。

既存のWebアプリで「Amazon Cognito」認証を利用する（その２:PHPのサンプルプログラムの実装）

Fri, 24 May 2019 01:29:26 +0900

はじめに

既存の Web アプリで「Amazon Cognito」認証を利用する（その１:処理フローの整理） | ゲンゾウ用ポストイットで「Cognito」の認証の流れを整理しました。

ここからは、PHP のサンプルプログラムを実装してより具体的に理解を深めていきたいと思います。

早速進めて行こうと思います。

ちなみに、 PHPのサンプルプログラムはGithubで公開しているので、参考にしていただければと思います。

( 実行するだけであれば、 「Docker Compose」 がインストールされていれば動きます。 )

GitHub - genzouw/aws-cognito-example

AWS Cognito の作成、設定

まずは AWS 側の設定を行っていきたいと思います。

1. 「Cognito」のユーザープールの作成

初めて Cognito にアクセスした場合、以下のようなページが表示されるはずです。

ユーザープールの管理 を選択して先に進みます。

ユーザープールを作成する をクリックします。

作成するユーザープール名を入力し、次に進みます。

ここでは g-user-pool というユーザープール名にしました。

後は次へ次へと進むだけです。

2.「Cognito」に新しい「アプリクライアント」の登録

「Cognito」のユーザープール設定ページから アプリクライアントの追加 をクリックします。

以下のように設定します。

アプリクライアント名 : aws-cognito-example ( ※こちらは好きな名前をつけましょう )
トークンの有効期限を更新 (日) : 1 ( 特にこだわりは有りませんでした。デフォルトの30日のままでも構いません。 )
クライアントシークレットを生成 : チェックを外す

3.「アプリクライアントの設定」

今度は左のタブから「アプリクライアントの設定」を開きます。以下のように設定します。

既存のWebアプリで「Amazon Cognito」認証を利用する（その１:処理フローの整理）

Wed, 22 May 2019 16:32:32 +0900

はじめに

以前、「Amazon Cognito」を使ってログイン機能を作成する（SNS 認証あり） | ゲンゾウ用ポストイットで「Amazon Cognito」のユーザ認証機能を利用してログインページを構築しました。

しかし、やりたかったことは既存の Web アプリケーションのログイン機能を「Cognito」を利用した仕組みに置き直すということだったため、完全ではありませんでした。

「Cognito」のユーザ認証が完了した後、既存のアプリケーションでそれを引き継ぐための仕組みを構築すべく、追加で調査をしました。（今回は整理にとどめて次回のエントリでサンプルコードの実装・公開をしたいと思います。）

改めて OAuth2 または OpenID Connect の処理フローについて

「Congito」を使ったユーザ認証は「OpenID Connect」という方式になります。「OAuth2」方式をベースとした後発の認証方式です。したがって「OAuth2」の理解を深めることが「OpenID Connect」の理解を深めることにつながると思いました。

僕が説明するより以下の記事を読むほうが圧倒的にわかりやすいです。

とはいえ、自分の頭の中を整理するため、自分なりにまとめてみます。

めっちゃ汚いですが、手書きの処理フローになります。（一部字が潰れたり上塗りされていたりしていますが（汗））

処理フローを箇条書きで文字起こし

登場人物は 3 つ、 “Browser” / “AppServer” / “Cognito” です。（“Browser"は人の形で表現しています。）

“Browser” は “AppServer” にアクセス
“AppServer” はログイン済みかを判定します。未ログイン状態の場合には “Cognito” に “redirect”（“redirect"の URL に対して事前に「Cognito」から払い出された「アプリケーション ID」などを付与）
“Cognito” は “login page” を返却
“Browser” は “login” を行う
“Cognito” は受け取った認証情報が正しければ “redirect” 。 “redirect” の URL の後方にはクエリ文字列形式で Authentication code と呼ばれるものを付与（ex: https://hoge.com/callback.html&code=xxxx ）
“AppServer” は受け取った Authentication code を使って Cognito にリクエスト
ID Token を取得
JavaScript では、ページの URL からフラグメントを切り出し、(5)で受け取った ID Token を抜き出すロジックが書かれている。
“AppServer” は HTML/JavaScript/ ID Token を返却。

取得できた 「ID Token」 ですが、「SPA」の場合は “Broser” の 「LocalStorage」 機能を使って保存しておき、以降の通信時に「HTTP Header」に付与して “AppServer” と通信を行うことで認証済みであることを証明します。

AWS-CLIを実行したら `CERTIFICATE_VERIFY_FAILED` というエラーメッセージが表示されてハマってしまった

Tue, 07 May 2019 08:53:27 +0900

背景

GWの10連休に入る直前に実行したところ、突然エラーメッセージが表示され正常に動作しなくなってしまいました。

どのようなエラーメッセージが表示された？

1

SSL validation failed for https://ec2.ap-southeast-1.amazonaws.com/ [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed

実行環境

1
2
3
4
5
6
7
8


$ uname -moi
x86_64 MacBookPro11,4 Darwin

$ bash -version
GNU bash, バージョン 5.0.7(1)-release (x86_64-apple-darwin18.5.0)

$ aws --version
aws-cli/1.16.140 Python/3.7.3 Darwin/18.5.0 botocore/1.12.130

どのように `aws-cl` を利用していたか？

EC2 環境を構築するための簡易なシェルスクリプトを作成し、その中で何度か aws コマンドを実行していました。
シェルスクリプトは Bash で動作するようにシバンを設定していました。
- #!/usr/bin/env bash

試してみたこと

`aws` コマンドのバージョンアップ

はじめは aws-cli のバージョンアップが原因かと思い、バージョンアップしてみたが、問題は解決しませんでした。

`aws` コマンドのオプション追加

以下のエントリを見つけました。

aws-cliでCERTIFICATE_VERIFY_FAILEDが出た時の対処 - hatunina’s blog

aws コマンドに --no-verify というオプションを付与すればエラーを無視できるということですが、、以下の理由により他の方法で対処することにしました。

Amazon DynamoDBのプライマリーキーの２つのタイプについて理解できたことをまとめました

Sun, 28 Apr 2019 10:35:24 +0900

はじめに

Amazon DynamoDBの構成要素について理解できたことをまとめました | ゲンゾウ用ポストイットで「テーブル」、「項目」、「属性」、「プライマリーキー」について整理しましたが、今回は「プライマリーキー」についてもう少しわかったことをまとめてみました。

プライマリーキーのタイプとデータの保存方法

プライマリーキーを構成する「属性」の数が1つか複数かで用途や考えないといけないことが異なるようです。

単一「属性」で構成されるプライマリーキー : 「パーティションキー」タイプ
複数「属性」で構成されるプライマリーキー : 「パーティションキー+ソートキー」タイプ

データの保存方法にも違いがあります。両者はどう違うのでしょう？

「パーティションキー」タイプ

1つの属性で構成されたシンプルなプライマリーキーとなっています。

キーの値を「ハッシュ関数」という特殊な関数を使って変換します。変換後の値で、「項目」を配置するデータ格納場所がきまります。つまり「ハッシュ関数」とは、データ置き場を決めるための関数なのです。

「ハッシュ関数」を使ったデータ配置のメリットは、データの検索が高速であることです。データが一箇所に集まってしまうと検索が遅くなってしまいます。データが整理されないまま入れ物にごった煮にされている状態を想像してください。「ハッシュ関数」を使ってデータの配置場所を決められれば、データの検索が高速にできるわけです。

「ハッシュ関数」の結果はできる限りバラバラになるように考えられています。（このあたりはハッシュ関数の実装次第なのでおそらくそうなっているはずです。）もしバラバラにならなかったとすると、特定のデータ配置場所にだけデータが集まってしまい、やはり検索が遅くなってしまうからです。

「パーティションキー+ソートキー」タイプ

2つの属性で構成されたプライマリーキーは、属性のうち一つがパーティションキーとなり他方がソートキーとなります。 ( 複合プライマリーキーと呼ばれたりもします。 )

パーティションキーのメリットはデータ配置場所が分散することでスキャンが高速になることでした。プライマリーキーが2つの属性で構成された場合、当然のことながら1つの属性でしか構成できないパーティションキーの値は重複する可能性があります。

これではハッシュ関数を利用したデータ分散のメリットが薄れてしまいます。ハッシュ関数で計算したデータ配置場所にデータが集まる傾向が高くなるためフルスキャンの問題と同様のことが発生します。

そこでソートキーです。データがバラバラに並んでいる場合にはフルスキャンを行わなければデータを見つけることができません。しかし、データがソートされていれば高速な探索アルゴリズムを使うことができます。 ( 僕は高速な探索アルゴリズムを知っているわけじゃないのですが二分探索の速さぐらいはイメージできます。 )

図鑑で探しものをする場合を例に上げましょう。分からない単語は一番後ろの索引を使って掲載ページを特定します。掲載ページが特定できたら、ページをペラペラ送りながら該当ページを探していきます。該当ページを用意に探す事が出来るのもページ番号が小さい値から大きな値に正しく並んでくれてるからこそです。

パーティションキーは1つしか設定できず、他方はソートキーになることにはメリットもあります。ソートキーを構成する「属性」は範囲を指定して検索することができます。

※ユーザのアクセス履歴情報(未ソート)に対して12:00〜14:00のデータを検索する場合

※ユーザのアクセス履歴情報(ソート済)に対して12:00〜14:00のデータを検索する場合

「パーティションキー+ソートキー」タイプの注意点

「パーティション+ソートキー」タイプを利用場合には、注意しないといけないケースがあります。 ホットパーティション問題 と呼ばれる事象です。

パーティションキーの偏りにより発生する問題です。

以下の手書きのメモを例に取り上げます。

プライマリーキーは2つの属性から構成されているものとします。

パーティションキー	ソートキー	ハッシュ関数で算出されたデータ配置場所
001	x	A
001	y	A
001	z	A
001	a	A
001	b	A
——————–	————	—————————————-
002	x	B
——————–	————	—————————————-
003	y	C

このとき、パーティションキー属性の値が 001 であるデータが非常に多いため、A のパーティションのみデータ量が増加することとなります。当然アクセス数もこのパーティションだけ多くなることでしょう。

Amazon DynamoDBの構成要素について理解できたことをまとめました

Sat, 27 Apr 2019 23:10:11 +0900

はじめに

AWS-CLIを使ってDynamoDBを操作してみるで「AWS CLI」から「DynamoDB」を操作してみました。

ただし、しっかり「DynamoDB」の仕組みについて理解できていなかったので、改めてドキュメントを読み進めて理解できたことを整理したいと思います。

※誤りが多分にあるかと思いますので指摘を喜んでお待ちしております。

ちなみに、プライマリーキーについて更に整理した内容は以下のエントリにまとめています。

Amazon DynamoDBのプライマリーキーの２つのタイプについて理解できたことをまとめました | ゲンゾウ用ポストイット

参考資料

DynamoDB コアコンポーネント - Amazon DynamoDB

DynamoDBの構成要素

DynamoDBの構成要素は多くの点でリレーショナルデータベース（以下RDB）によく似ています。 RDBを理解していれば理解しやすいと思います。

概念	説明
テーブル	RDBでいうテーブル。「項目」の集合。
項目	RDBでいうレコード（行）。「属性」の集合。
属性	RDSでいうカラム（列）。
プライマリーキー	RDSでいうプライマリーキー。1つあるいは2つの属性の組み合わせでテーブルの全「項目」で一意でなければならない。

AWSのマニュアルでは、具体例として People というテーブルとそのデータ構造について触れています。

先に触れた構成要素と上記のサンプルデータの対応は以下のようになります。

概念	説明
テーブル	People
項目	3項目。
属性	PersonId, LastName, FirstName, Phone(1項目目のみ), Address(2項目目のみ), FavoriteColor(3項目目のみ)
プライマリーキー	PersonId だけで構成される単一プライマリーキー

プライマリーキーの「属性」の特徴・制約

プライマリーキーは1つ以上の「属性」で構成しなければならない

先に触れたとおり、プライマリーキーは単一の属性だけで構築しても良いですし、複数の属性で構成することもできます。

具体的な例を上げると、以下のようになります。

単一「属性」で構成されるプライマリーキー : 銀行テーブルに対する銀行コード
複数「属性」で構成されるプライマリーキー : 銀行支店テーブルに対する銀行コード+支店コード

「テーブル」にはプライマリーキーは必須となりますので、当然「テーブル」内の「項目」は最低でも1つの「属性」を持つことになります。

プライマリーキーは一意な値でなければならない

DynamoDBのプライマリーキー属性値は重複を許しません。

銀行テーブルには銀行コードの重複はありえません
銀行支店テーブルには銀行コード+支店コードの重複はありえません

プライマリーキーはスカラー値でなければならない

プライマリーキーはスカラー値でなければいけません。以下のいずれかでなければなりません。

AWS-CLIを使ってDynamoDBを操作してみる

Sat, 27 Apr 2019 00:18:37 +0900

LambdaからDynamoDBを操作する必要があったのだけれども、 DynamoDBにあまり触れる機会もなく今まで来ました。

コマンドラインからテーブルの作成やデータ投入を行ってみることにしました。

操作するためのツールとして AWS CLI を使ってみます。

ちなみに、DynamoDBの構成要素や概念を整理した内容は以下のエントリにまとめました。

Amazon DynamoDBの構成要素について理解できたことをまとめました | ゲンゾウ用ポストイット

検証環境

1
2
3
4
5


$ uname -moi
x86_64 MacBookPro10,1 Darwin

$ aws --version
aws-cli/1.16.140 Python/3.7.3 Darwin/18.5.0 botocore/1.12.130

DynamoDBの概念・コンセプトを整理してみる

Amazon DynamoDBの構成要素・コンセプト

「Amazon DynamoDB」を構成する要素については、別のエントリで整理しておきました。

Amazon DynamoDBの構成要素について理解できたことをまとめました | ゲンゾウ用ポストイット

上記エントリでまとめましたが、抑えておく用語は以下の４つです。

テーブル
項目
属性
プライマリーキー

コンセプト

DynamoDBではデータを抽出する方法は大きく２つとなります。

プライマリーキー で検索し項目を受け取る
全項目を受け取りプログラムで絞り込む

データ量が増えた場合は (2) の方法は現実的ではなくなるため、 (1) でデータを取得できるように設計する必要があります。

検証用のテーブル定義

上記の概念やコンセプトを理解した上で、今回検証用に作成したいテーブルの定義を整理しておきます。

検証用のtable名

ユーザ情報を管理する users というtableを作成します。

検証用の属性名

users テーブルは以下のような属性（RDSでいうところの列情報）を保持します。

Name	Type	プライマリーキー?
email	String	Y
first_name	String
last_name	String
age	Number

「属性」には型を設定する必要があります。連想配列や配列などを指定できますが、最もよく利用するのは「文字列」と「数値」となるでしょう。

「Amazon Cognito」を使ってログイン機能を作成する（SNS認証あり）

Sun, 21 Apr 2019 08:56:27 +0900

はじめに

ログイン認証機能を実装するための方法をいくつか調査中。

候補として上がっているのは大きく２つ。

“Amazon Cognito”
“Firebase”

まずは Cognito の調査からすることにしました。

マニュアルを読みながら設定を進めて見ましたが、文章が多く初見殺しのイメージがあったので、設定時のスクリーンショットを残しておきました。そちらを共有したいと思います。

Cognito の設定で躓いた方の参考になれば幸いです。

準備

僕はさっと AWS のマニュアルを読みました。実際に行った作業も以下のマニュアルを元に進めました。

( 書かれている内容通りに進められる方は当エントリを参考にする必要はないかと思います。 )

Amazon Cognito の使用開始 - Amazon Cognito

Cognito アーキテクチャ

概念として認証・認可情報を管理する “ユーザープール” と “ID プール” というものを理解する必要があります。

いずれの概念もまだ掴みきれていないのですが、マニュアルを読みつつ、触りつつ理解していこうと思います。今回触るのは “ユーザープール” のみになります。

設定方法

早速設定を進めていきましょう。

先にも述べたとおり、 AWS が提供してくれているマニュアル通りに進めていきます。

ステップ 1.ユーザープールを使用してユーザーディレクトリを作成する

ステップ 1.ユーザープールを使用してユーザーディレクトリを作成する - Amazon Cognito を参考に作業を進めます。

Amazon Cognito コンソールを開きます。

[ユーザープールの管理] を選択します。

ページの右上にある [ユーザープールを作成する] を選択します。

ユーザープールの名前を入力し、[デフォルトを確認する] を選択して、名前を保存します。

[属性] ページで、[E メールアドレスおよび電話番号] および [E メールアドレスを許可] を選択します。

設定ができたら、ページの下部にある [次のステップ] を選択して属性を保存します。

S3にファイルが作成されたことを検知してLambda関数でファイルを読み込む( `aws-cli` で構築)

Sat, 23 Mar 2019 09:25:12 +0900

はじめに

「S3にファイルがSFTPアップロードされたことを検知してLambdaを起動する（ aws-cli で構築）」で、S3にファイルがアップロードされたことをフック条件にしてLambdaファンクションを実行させてみました。

ただ、上記のエントリではLambdaファンクションがCloudWatchLogにログを出力させるまでの実装にとどまっていました。フック条件となったS3のファイルを読み込むロジックは作成していません。

そこで、今回はフック条件となったS3内のファイル読み込みを試してみました。

ゴールとする構成

ファイルがアップロードされる
アップロードを検知してLambdaファンクションを呼び出し
S3のファイルを読み込む
CloudWatchLogにログ出力

必要なもの

aws コマンドが使えること
jq コマンドが使えること
npm コマンドが使えること

検証環境

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


$ uname -moi
x86_64 MacBookPro10,1 Darwin

$ bash -version
GNU bash, バージョン 5.0.3(1)-release (x86_64-apple-darwin18.2.0)

$ aws --version
aws-cli/1.16.120 Python/3.7.2 Darwin/18.2.0 botocore/1.12.110

$ npm --version
6.7.0

作業開始

以下のエントリから今回必要な部分のみピックアップして検証していきます。

「Amazon API Gateway」から「Lambda」を通さずに「S3」へアクセスできるようにしてみる（ `aws-cli` で構築）

Fri, 15 Mar 2019 16:59:49 +0900

はじめに

AWSを利用したサーバレスな事例が増えてきました。例えば以下のような構成の事例がWeb上で掲載されています。

「API Gateway」 から 「Lambda」 を経由して 「DynamoDB」あるいは「S3」 にアクセスする例は、様々な方がWeb上に掲載しています。 「API Gateway」 から 「S3」 へ直接アクセスするための例はあまり見つからず、またあったとしても AWS-CLI を使って設定している例が見つからなかったため、整理してみました。

ちなみに設定した内容はAmazonが提供している以下のドキュメントを参考にしています。こちらのドキュメントは「AWS マネージメントコンソール」からポチポチ操作していく内容となっています。

API Gateway で Amazon S3 プロキシとして REST API を作成する - Amazon API Gateway

作成する「API」概要

S3にアクセスできる。（今回は読み取りのみ）
アクセス用URLは https://<host>/<S3-BUCKET-NAME>/<S3-OBJECT-KEY> の形式とする。

準備

aws-cli コマンドが利用できる
jq コマンドが利用できる

ja はなくてもよいのですが、今回各AWS構成要素を作成した際のJSONレスポンスをパースしてできる限りコマンドラインのみの操作としたかったので利用してみました。

検証環境

1
2
3
4
5
6
7
8


$ bash -version
GNU bash, バージョン 5.0.2(1)-release (x86_64-apple-darwin18.2.0)

$ aws --version
aws-cli/1.16.120 Python/3.7.2 Darwin/18.2.0 botocore/1.12.110

$ jq --version
jq-1.6

手順

デプロイ直前までの流れは以下の通り。（デプロイは次回実施してみる。）

AWS-CLIでhelpを入力するのが煩わしい場合の対処としてスクリプトを作ってみた。

Thu, 14 Mar 2019 12:40:24 +0900

AWS-CLI を叩きながら AWS の各種サービスを構築する上で必要な情報を学習中です。

僕は画面を見ていくよりもコマンドのヘルプを見ながら試行錯誤していくほうが理解が進めやすいようです。

「AWS-CLI」のヘルプを引くのが面倒

ただ、ヘルプを引くのが面倒なのです。具体的に言うと help コマンドを入力するのが面倒。

例えば作業中に以下のような状況になることが多い。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# どんなコマンドがあったっけ？
aws --help

# コマンド間違えた
aws help

# 内容を確認したので実行
aws s3

# ヘルプを見るか
aws s3 --help

# くっ...
aws s3 help

# わかった！実行する！
aws s3 mb my-butket-name

# なんかエラー出るし！
aws s3 mb help

ちょっとした改善として、helpを打ち込まなくてもhelpが表示されるようにしてみた

help と入力する手間だけでも減らそうと思って短いスクリプトを作ってみた。 aws コマンドは多くのコマンドが aws <サブコマンド> <オプション> といった構成となるので、2つの引数が必要になります。引数が1つ以下の場合は、自動的に help というオプション付きで呼び出すようにしています。

goofysを使ってEC2上のLinuxにS3をマウントする

Thu, 07 Mar 2019 08:05:00 +0900

はじめに

S3をファイルシステムとしてマウントするための方法を整理してみました。

AWSを利用していて、S3をサーバーマウントする技術として s3fs が有名
- s3fs は遅い
代替策として goofys がある
- goofys は速い

goofys の方が評判が良いようなのでgoofysを検証しました。

ちなみに goofys のGithubページにベンチマークが掲載されています。

(引用) Using –stat-cache-ttl 1s –type-cache-ttl 1s for goofys -ostat_cache_expire=1 for s3fs to simulate cold runs. Detail for the benchmark can be found in bench.sh. Raw data is available as well. The test was run on an EC2 m4.16xlarge in us-west-2a connected to a bucket in us-west-2. Units are seconds.

今回のゴール

起動時にS3バケットが所定のディレクトリに自動マウントされるようになるまで設定します。

※ちなみに、Dockerが利用できる場合にはgoofysを手軽に利用できるDockerイメージを公開していますのでお使いください。

`aws-cli` を使ってコマンドラインからAWS EC2とVPCを構築する

Mon, 04 Mar 2019 12:35:33 +0900

はじめに

AWS Transfer for SFTP の価格があまりにも高すぎたため、 EC2 上に SFTP サーバを構築することにしました。

今までは VPC や インターネットゲートウェイ を使わずに EC2 作成をしていたため、これらを導入した場合の手順を整理してみました。

準備

aws-cli コマンドが利用できること
jq コマンドが利用できること

ja はなくてもいいが、今回各AWS構成要素を作成した際のJSONレスポンスをパースしてできる限りコマンドラインのみの操作としたかったので利用しました。

検証環境

1
2
3
4
5
6
7
8


$ uname -moi
x86_64 MacBookPro10,1 Darwin

$ bash -version
GNU bash, バージョン 5.0.2(1)-release (x86_64-apple-darwin18.2.0)

$ aws --version
aws-cli/1.16.110 Python/3.7.2 Darwin/18.2.0 botocore/1.12.100

ネットワーク周りの設定

VPCの作成

1
2
3
4
5
6
7
8
9


# VPCの新規作成 => 作成されたVPCのIDを保存
$ EC2_VPC_ID=$(
 aws ec2 create-vpc \
 --cidr-block '172.20.0.0/16' \
 | jq -r '.Vpc.VpcId'
)

## 確認
$ echo "${EC2_VPC_ID}"

Subnetの作成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Subnetの新規作成 => 作成されたSubnetのIDを保存
$ EC2_SUBNET_ID=$(
 aws ec2 create-subnet \
 --cidr-block '172.20.0.0/16' \
 --vpc-id "${EC2_VPC_ID}" \
 | jq -r '.Subnet.SubnetId'
)

## 確認
$ echo "${EC2_SUBNET_ID}"

インターネットゲートウェイの作成

1
2
3
4
5
6
7
8


# インターネットゲートウェイの新規作成 => 作成されたインターネットゲートウェイのIDを保存
$ EC2_INTERNET_GATEWAY_ID=$(
 aws ec2 create-internet-gateway \
 | jq -r '.InternetGateway.InternetGatewayId'
)

## 確認
$ echo "${EC2_INTERNET_GATEWAY_ID}"

VPCへインターネットゲートウェイを割り当てる

1
2
3


$ aws ec2 attach-internet-gateway \
 --internet-gateway-id "${EC2_INTERNET_GATEWAY_ID}" \
 --vpc-id "${EC2_VPC_ID}"

ルートテーブルの設定

インターネットゲートウェイ経由でVPCへアクセスできるようにします。

S3にファイルがSFTPアップロードされたことを検知してLambdaを起動する（ `aws-cli` で構築）

Thu, 28 Feb 2019 08:29:40 +0900

以下のような仕組みを作る必要がありました。

ユーザにSFTPプロトコルを使って、S3にファイルをアップロードしてもらう。
S3にファイルがアップロードされたことを検知して、何らかの処理を行う。

AWSのサービスを組みわせて、かつできる限り aws-cli のみを使ってコマンドラインで仕組みを構築してみました。

今回は、 「何らかの処理」 として Lambdaファンクションを使ってCloudWatchLogにログを書き出させてみます 。

※注意：IAM周りの設定はかなり大雑把に設定しているので、参考する場合にはもっと考慮が必要！

簡易構成図

設定パラメータを整理

AWSの各種サービス設定時に必要となる情報を事前にまとめておきました。

設定項目	設定値
AWS Transfer 実行ユーザ名(SFTPログインユーザ)	g-trigger-bucket-transfer-user
AWS Transfer 実行ロール名	g-trigger-bucket-transfer-role
S3 バケット名	g-trigger-bucket
S3 バケットイベント名	g-trigger-bucket-event
Lambda ファンクション名	g-trigger-function
Lambda 実行ロール名	g-trigger-function-role

事前準備

`aws-cli` (AWSコマンドの利用可能な環境づくり)

aws-cli の利用可能環境は、以下のエントリを参考に構築済み。

AWSコマンドを使うための環境をDockerを使って構築(Mac/Linux/WindowsでもPythonなしで動くよ) | ゲンゾウ用ポストイット

AWSサービスの設定開始

AWS S3バケットの作成

S3バケットの作成やファイルのアップロードをコマンドラインから操作する方法は、以下のエントリで整理済み。

AWSのS3バケットの作成、削除、タグ付与、ポリシー設定をコマンドラインから実行する | ゲンゾウ用ポストイット

参考にしながら設定を進める。

1
2
3
4
5
6


# バケットを作成
$ aws s3 mb s3://g-trigger-bucket

# バケットができたかを確認
$ aws s3 ls
2019-02-25 07:32:57 g-trigger-bucket

AWS Lambdaファンクションの作成

AWS Lambda ファンクションの作成や呼び出しをコマンドラインから操作する方法は、以下のエントリで整理済み。

AWSのLambdaファンクションの作成、実行、削除をコマンドラインから操作する

Tue, 26 Feb 2019 07:59:59 +0900

S3にファイルがアップロードされたことを検知して、処理を行うような仕組みを作り必要がありました。

処理の部分のロジックはまだ未決定事項が多いため、とりあえずは Lambdaファンクション呼び出しからCloudWatchLogへログを吐き出すところまでの仕組みを作成してみることにしました。

※作成したLambdaファンクションをS3へのファイルアップロードのつなぎこみは次回調査

`aws-cli` (AWSコマンドの利用可能な環境づくり)

AWSコマンドを使うための環境をDockerを使って構築(Mac/Linux/WindowsでもPythonなしで動くよ) | ゲンゾウ用ポストイットで環境構築済み。

AWS Lambdaファンクションの作成

AWS Lambda については以下の記事がわかりやすかった。

初めてのAWS Lambda　～AWS Lambdaで始めるイベントドリブンアプリケーション (1/5)：CodeZine（コードジン）

Lambda作成にあたってやらないといけないことは以下の2つ。

Lambdaファンクションの実行ロールを作成する
Lambdaファンクションを作成する

実行ロールの作成

まずは初期ポリシーファイルを作成します。 Lambdaファンクションの実行に関するフル権限を与えました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# ファイル名は何でも良い
$ cat <<EOF >logging-function-role-policy.json
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Service": "lambda.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}
EOF

作成したポリシーファイルを元に、ロールを作成。

AWSのS3バケットの作成、削除、タグ付与、ポリシー設定をコマンドラインから操作する

Sun, 24 Feb 2019 10:00:22 +0900

S3のバケット作成、削除、ポリシー設定をWeb上から操作することが多いです。 Web操作の解説も多いです。

でも、コマンドラインからの実行を解説しているケースはさほど多くないですね。。

S3はバックアップデータ置き場、ログ置き場として使うことが多いが、特に検証時に作っては消し、また作るを繰り返す… 繰り返しが疲れてきたのでコマンドラインでのやり方をまとめてみました。

ここではよく使用される aws s3 コマンドではなく aws s3api コマンドについてできるだけ触れてみます。

`aws-cli` (AWSコマンドの利用可能な環境づくり)

AWSコマンドを使うための環境をDockerを使って構築(Mac/Linux/WindowsでもPythonなしで動くよ) | ゲンゾウ用ポストイットを参照。

上記記事では Mac、Linux、Windowsの環境の差異を無視できるよう、またPythonなしでも動作するように Docker を利用しました。

S3バケットの作成 ( `aws s3api create-bucket` / `aws s3 mb` )

aws s3api create-bucket コマンドを使う。

create-bucket — AWS CLI 1.16.111 Command Reference

ここでは genzouw-test-bucket というバケット名で作成してみます。

1
2
3
4
5
6
7
8


$ aws s3api create-bucket \
 --bucket genzouw-test-bucket \
 --create-bucket-configuration "LocationConstraint=ap-northeast-1"

# 環境変数 AWS_DEFAULT_REGION が設定されていれば、以下のコマンドでも良い。
## aws s3api create-bucket \
## --bucket genzouw-test-bucket \
## --create-bucket-configuration "LocationConstraint=${AWS_DEFAULT_REGION}"

何度か --create-bucket-configuration オプション無しで実行してみたが、以下のようなエラーが発生しました。
AWS_DEFAULT_REGION の設定があったとしても指定が必要な模様。

AWSコマンドを使うための環境をDockerを使って構築(Mac/Linux/WindowsでもPythonなしで動くよ)

Sat, 23 Feb 2019 13:36:26 +0900

AWSコマンドを実行するための環境づくりをしたいが、自前のMac環境だけでなく、Windows環境のことも考慮して構築したいですよね。

Dcokerを作って実現するための手順をまとめてみました。

Dockerを使えれば、MacだろうがWindowsだろうがLinuxだろうが同じ手順で aws-cli 実行の環境が構築可能です。

事前にDockerのインストールが必要

こめんなさい。事前にDockerのインストールはされていることが前提です。
こちらはネット上に情報が転がっているので独力で頑張ってみてください。

“Docker Hub"から適当なコンテナを探す

Docker Hub から適当な既存のコンテナを探しました。

以下のコンテナがダンロード数も多く、比較的頻繁に更新されてそうでした。

mesosphere/aws-cli

Dockerを使った `aws-cli` を早速試してみる

実行のためには、以下の３つの情報が必要。

1
2
3


export AWS_ACCESS_KEY_ID="<id>"
export AWS_SECRET_ACCESS_KEY="<key>"
export AWS_DEFAULT_REGION="<region>"

環境変数として定義して export すれば利用可能ということで早速試してみます。

IAM管理コンソールページから、キー情報を取得

IAM Management Console のページを開く。
左サイドのメニューから「ユーザー」を選択すれば、現在登録されているIAMユーザの一覧が表示されます。
既存のものを使いたい 場合はそれをクリック。 新しいものを使いたい 場合は「ユーザーを追加」ボタンをクリック。

今回は既存のものを利用したいので、クリックしました。

「アクセスキー」 は最大2つまで登録できます。今回は既存のものがすでに登録してあったが 忘れてしまったため 新しく作成。

ボタンを押すと即座に新しいアクセスキーが作成されます。このタイミングでしっかりメモしておかないと2度と シークレットアクセスキー は確認できないので、メモしておきます。

環境変数を設定

Bash（ Windowsの方はコマンドプロンプトかPowerShell ）を開いて、以下の環境変数を設定します。

1
2
3


$ export AWS_ACCESS_KEY_ID="<先程のページのアクセスキーID>"
$ export AWS_SECRET_ACCESS_KEY="<先程のページのシークレットアクセスキー>"
$ export AWS_DEFAULT_REGION="ap-northeast-1"

AWS_DEFAULT_REGION は一番良く使うデフォルトのリージョンを指定する必要があります。（ 僕の場合は東京リージョン ） AWSの以下のページから自分がよく使うものを１つ選んで設定すればよいです。

https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html

Bash起動時に自動的に環境変数が設定されるように、 ~/.bashrc ファイルに追記しておくとよいでしょう。

AWS on ゲンゾウ用ポストイット

OIDCを使ってGithub ActionsからAWSにアクセスする仕組みについて理解を整理してみた

はじめに

検証環境

パスワードやアクセストークンを使ってGithub Actionsからクラウドへ認証する方法の問題点

OIDC ( OpenID Connect ) を使うメリット

AWS CodeWhispererを使うためにセットアップを進めたがVimから利用できないことがわかり諦める

はじめに

作業の流れ ( 作業ログ )

IAM Identity Center 有効化

MySQLのMAX_EXECUTION_TIMEを使って長時間実行中のクエリを強制的に中断させる

はじめに

MySQL の MAX_EXECUTION_TIME とはなにか？

検証環境

AWSの設定(プロファイル)をコマンドで簡単に切り替える方法

はじめに

「Amazon Cognito」で提供するログインページを自作してみる（`aws-cli`で構築）

はじめに

準備

検証環境

作業開始

既存のWebアプリで「Amazon Cognito」認証を利用する（その２:PHPのサンプルプログラムの実装）

はじめに

AWS Cognito の作成、設定

1. 「Cognito」のユーザープールの作成

2.「Cognito」に新しい「アプリクライアント」の登録

3.「アプリクライアントの設定」

既存のWebアプリで「Amazon Cognito」認証を利用する（その１:処理フローの整理）

はじめに

改めて OAuth2 または OpenID Connect の処理フローについて

処理フローを箇条書きで文字起こし

AWS-CLIを実行したら `CERTIFICATE_VERIFY_FAILED` というエラーメッセージが表示されてハマってしまった

背景

どのようなエラーメッセージが表示された？

実行環境

どのように aws-cl を利用していたか？

試してみたこと

aws コマンドのバージョンアップ

aws コマンドのオプション追加

Amazon DynamoDBのプライマリーキーの２つのタイプについて理解できたことをまとめました

はじめに

プライマリーキーのタイプとデータの保存方法

「パーティションキー」タイプ

「パーティションキー+ソートキー」タイプ

「パーティションキー+ソートキー」タイプの注意点

Amazon DynamoDBの構成要素について理解できたことをまとめました

はじめに

参考資料

DynamoDBの構成要素

プライマリーキーの「属性」の特徴・制約

プライマリーキーは1つ以上の「属性」で構成しなければならない

プライマリーキーは一意な値でなければならない

プライマリーキーはスカラー値でなければならない

AWS-CLIを使ってDynamoDBを操作してみる

検証環境

DynamoDBの概念・コンセプトを整理してみる

Amazon DynamoDBの構成要素・コンセプト

コンセプト

検証用のテーブル定義

検証用のtable名

検証用の属性名

「Amazon Cognito」を使ってログイン機能を作成する（SNS認証あり）

はじめに

準備

Cognito アーキテクチャ

設定方法

ステップ 1.ユーザープールを使用してユーザーディレクトリを作成する

Amazon Cognito コンソール を開きます。

ページの右上にある [ユーザープールを作成する] を選択します。

ユーザープールの名前を入力し、[デフォルトを確認する] を選択して、名前を保存します。

[属性] ページで、[E メールアドレスおよび電話番号] および [E メールアドレスを許可] を選択します。

S3にファイルが作成されたことを検知してLambda関数でファイルを読み込む( `aws-cli` で構築)

はじめに

ゴールとする構成

必要なもの

検証環境

作業開始

「Amazon API Gateway」から「Lambda」を通さずに「S3」へアクセスできるようにしてみる（ `aws-cli` で構築）

はじめに

作成する「API」概要

MySQL の `MAX_EXECUTION_TIME` とはなにか？

どのように `aws-cl` を利用していたか？

`aws` コマンドのバージョンアップ

`aws` コマンドのオプション追加

Amazon Cognito コンソールを開きます。

`aws-cli` (AWSコマンドの利用可能な環境づくり)

`aws-cli` (AWSコマンドの利用可能な環境づくり)

`aws-cli` (AWSコマンドの利用可能な環境づくり)

S3バケットの作成 ( `aws s3api create-bucket` / `aws s3 mb` )

Dockerを使った `aws-cli` を早速試してみる