Amazon Cognitoハンズオン
Amazon Cognitoハンズオンのリンク
最初は別の方の手順を参考にしていたのですが、途中でつまったので
最終的に以下を参考にさせて頂きました。
ハンズオンの補足
ハンズオンの管理画面は古いので現在の管理画面向けに補足します。
・ユーザプールの作成
下記以外はすべてデフォルト設定
多要素認証・・・MFAなし
ユーザーアカウントの復旧メッセージの配信方法・・・Eメールのみ
送信元Eメールアドレス・・・SESで認証済みのEメールアドレス
※下記「SES設定手順」参照
ユーザープール名・・・test-user-pool
アプリケーションクライアント名・・test-client
アプリケーションクライアント→属性の読み取りおよび書き込み許可→
roleに対しての読み込みと書き込みを許可する
・ユーザプール→メッセージング→メッセージテンプレート→検証メッセージ
→Eメール→検証タイプ→Linkに変更
・ユーザプール→アプリケーションの統合→ドメイン→Cognitoドメインの作成→
ドメインを何でもいいので入力
・IDプールの作成
手順通り
・クライアントアプリの実行環境としてcloud9を作成
・cloud9にサンプルの～.htmlを作成
・signup.htmlと同じ階層にjsフォルダを作成
・jsフォルダの中にjavascriptライブラリを格納
・各jsファイルのユーザプールID、クライアントIDを作成したIDに修正
SES設定手順
SES→IDの作成
設定したメールアドレス宛にAWSからメールが届くので、URLリンクをクリックする
IDステータスが「検証済み」になる
動作確認
まずサインアップの画面が表示されます
ユーザ登録するとメールが届くので、verifyします。
Verifyされます
次は登録したユーザでログインします
ログインできることを確認
感想
手順書に無い作業が多々あったので結構時間がかかりました。
AWS AmplifyでCognitoを使ったときは正直Cognitoが謎でしたが
今回のハンズオンでCognitoの機能がよく理解できました。
AWS Amplifyで爆速Webサイト構築
AWS Amplifyのハンズオンをやってみました。
AWS Amplifyとは？
パラメータを指定するだけでDBと連携したWebサイトが爆速で作成できる
サービスと理解しました。
認証機能など、追加したい機能を選ぶことでWebサイトに機能追加されます。
裏でAWS AppSync、DnynamoDBやら自動的に作成されます。
ハンズオンリンク
ハマりどころ
amplify initでerror
作成したamplifyユーザにIAMとS3のフルアクセス権限を追加した。
動作確認（API）
webブラウザからTodoアプリが表示されることを確認
動作確認（認証）
動作確認（ホスティング）
感想
３～４時間ぐらいで構築できました。
確かにパラメータを指定するだけでDynamoDBと接続して
リクエストを処理するWebアプリができました。
ReactでWebアプリを構築したことがないので爆速なのかは分かりませんが
イメージとしてはRuby on RailsのScaffold（１５分で作るブログ）みたいなものだと思います。
CloudFormationの自動デプロイ
Iacを導入するステップ
最終ステップとして、CloudFormationのスタック定義を
パイプラインで自動デプロイして自動化するというのがあります。
今日はこの最終ステップをAWSのハンズオンを参考に実践してみました。
内容はWordpressのEC2をCloudformationとCodepipelineで
自動リリースするというものです。
資料参考
ハンズオン参考
ハマり所
TestStageのCreateStackでtest-stack-configuration.jsonが無いと言われる。
ファイル圧縮時にフォルダを自動作成していたのが原因だった。
自動作成を無効にし、圧縮してS3にアップロード。
テスト用wordpressがcloudformationで作成されると承認待ちになります。
ここで、テスト用wordpressの構築内容に問題がないかを確認する
問題なければcodepipelineの画面から承認する
次に本番用の設定でCloudformationの変更セットが作成され
承認待ちで一時停止する。
Cloudformationの変更セットの画面から、更新内容が問題ないかを確認。
問題なければ承認。
本番用のwordpressが作成される
感想
今まではリリース手順書に「設定を確認する」みたいな項目があって
確認していたのが、これを導入することで自動で対応できるのは良い。
しかし、承認者が承認するとリリースしてしまうので
リリース担当者が初動確認をするためには
いつ承認者に承認されてもいいように待機する必要がある。
これは体制的になかなか厳しいかと。
自動リリースという仕組みは利用したいけど
あくまで承認は別フローやな
と思いました。
AWS ECSコンテナのBlue/Greenデプロイ
ハンズオンのリンク
https://pages.awscloud.com/rs/112-TZM-766/images/AWS_CICD_ECS_Handson.pdf
↑の詳しい動作解説
https://blog.serverworks.co.jp/cicd-ecs-build-deploy-flow
Blue/Greenデプロイメントの図解
https://www.sunnycloud.jp/column/20210620-01/
今回はテストリスナー無しパターンで実施しました。
ハンズオンからの変更点
- NAT Gatewayで課金されたくなかったのでCloudformationテンプレートから
NAT Gateway、プライベートサブネットのルート定義を削除
- NAT Gatewayを削除したのでECSはプライベートではなくパブリックに配置
- ハンズオンではGitクライアント、Dockerを利用するためにcloud9を 構築しているが自分のＰＣに変更
ハマった点
ECSが画面から入力する設定が多く、設定間違いでタスクやらALBを
何度も作り直す。。。
あとはaws CLIのバージョンアップの影響らしく、Codeシリーズでハマった。
１．コマンドの使い方が違いますエラー
[Container] 2023/01/22 10:16:26 Running command $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters] To see help text, you can run:
→ハンズオンではなく公式ドキュメントを確認すると、なんかコマンドが違う。
コマンドをget-login-passwordに変更
２．Login: not foundエラー
/codebuild/output/tmp/script.sh: 4: Login: not found
→1行目コマンドの先頭の$(と末尾の)を削除
３．またエラー
Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker push $REPOSITORY_URI:latest. Reason: exit status 1
サンプルのリージョンがusになってたので東京リージョンに変更
１０度目のデプロイにしてようやく成功。３時間ぐらいかかりました。
あれ？CodePipeline使って何しようとしてたんだっけ？となる。
動作確認
リリース前
リリース前ALBのターゲットグループ Blue側(～fargate-1)にリンクしている
タスクは１つだけ稼働している
リリース後
ターゲットグループは１系から２系へ変わる(～fargate-2)
新コンテナがリリースされ、旧コンテナは設定した猶予期間だけ残る
猶予期間経過後
旧コンテナは自動削除
感想
始めてcodeシリーズを使いましたがデプロイ時間が意外と長い。
１０分は待たされているイメージ。
待たされた挙句エラーで止まるので構築に時間がかかる。
※成功すると２分ぐらいで終了するようです。
gitからリポジトリにpushしてしまえば、あとは全自動でリリースなのは素晴らしい。
結構色々準備は必要ですが、ここまで一貫したリリースの仕組みをベンダーから
提供しているのはすごいことだと思います。
AWS ChatbotでアラートをSlackに通知
アラートはメールではなくSlackに飛ばしてほしい
という需要も増えてくるのでは思い、ハンズオンやってみました。
構成）
Cloudformationのスタック作成をトリガーにSlack通知する
Cloudformation → SNS → Chatbot → Slack
参考）
https://qiita.com/hayao_k/items/529539bbb07736ea0f41
１５分ぐらいで簡単に作成できました。
こんな感じで通知が来ました。
文面は変更不可。
Lambdaを使えば文言も変更できるらしい。
