- 投稿日：2021-01-01T22:51:07+09:00
【メモ】みんなのAWS 〜AWSの基本を最新アーキテクチャでまるごと理解！
メモです
みんなのAWS 〜AWSの基本を最新アーキテクチャでまるごと理解！：書籍案内｜技術評論社
第１章 AWSの基礎知識
- クラウドとは
- ITインフラの歴史
- メインフレームからクラウドの時代へ
- AWS のはじまり
- クラウドの定義
- クラウドの特徴
- オンデマンド・セルフサービス
- 幅広いネットワークアクセス
- リソースの共用
- スピーディな拡張
- サービスが計測可能であること
- クラウドのサービスモデル
- IaaS
- PaaS
- SaaS
- クラウドの物理的な世界へ
- 責任共有モデル
AWS のベストプラクティス
- AWS Well-Architected フレームワーク
- 一般的な設計の原則
- 運用上の優秀性
- コスト最適化
- 信頼性
- パフォーマンス効率
- コンピューティング
- ストレージ
- ネットワーク
- セキュリティ
- 認証情報の管理
- データ保護
- 監視とログ管理
- セキュリティのベストプラクティス
最低限押さえておくべきアカウント開設時のセキュリティ
- AWSセキュリティの概要
- AWS はセキュリティ的に安全なのか
- AWS クラウドセキュリティ
- データの保護
- コンプライアンスの要件に準拠
- コスト削減
- 迅速なスケーリング
- 責任共有モデル
- 日本国内の導入事例
- AWS セキュリティの考え方
- アカウント開設時のセキュリティ
- root ユーザーを利用せず、IAM ユーザーを利用する
- AWS CloudTrail を有効化する
- AWS Config を有効化する
- Amazon GuardDuty を有効化する
- その他アカウント開設時の参考情報
- IAM の概要と使い方
- ユーザー/グループ/ポリシー/ロール
- 権限設定の考え方
- AWS Well-Architected の「セキュリティの柱」
- 設計原則
- 強力なアイデンティティ基盤の実装
- トレーサビリティの実現
- 全レイヤーへのセキュリティの適用
- セキュリティのベストプラクティスの自動化
- 伝送中および保管中のデータの保護
- データに人の手を入れない
- セキュリティイベントへの備え
- ベストプラクティス
- アイデンティティ管理とアクセス管理
- 発見的統制
- インフラストラクチャ保護
- データ保護
- インシデント対応
- その他の参考情報
AWS における監視（モニタリング）
- 監視の基本用語にみる時代の変化
- メトリック、ログ、イベント
- モニタリング・4つの立ち位置
- ブラックボックス監視
- ホワイトボックス監視
- ヘルスチェック監視
- シンセティック監視、リアルユーザー監視
- 可観測性と「トレース」
- AI・機械学習による「AIOps」
- AWS上のシステムを「監視（モニタリング）」する
- Amazon CloudWatch
- AWS X-Ray
- その他の監視（モニタリング）機能
- AWS以外の選択肢
AWS を学習するコツ
- AWS 認定
- AWS Webinar
- よくある質問
- AWSの最新情報
第２章 AWS で作るWebサービス
- 本章で解説するアプリケーションの全体構成と利用する AWS サービス
- Amazon ECS
- PHP
- CodePipeline
- AWS のネットワーク基礎
- Amazon VPC
- Amazon VPN の構成要素
- サブネット
- ゲートウェイサービス
- ENI とIPアドレス
- ルートテーブル
- セキュリティグループとNACL
- Amzon Provided DNS
- VPC の設計
- CIDRの決定
- サブネットの分割
- ルートテーブルの設定
- パブリックドメインとSS:/TLS証明書
- Amazon Route53を用いたドメインの取得とレコードの管理
- AWS Certificate Manager とSSL/TLS 証明書
- アプリケーション構築・運用手段としてのコンテナ関連サービス
- コンテナとは何かを理解する
- コンテナを使う意味を考える
- 複数の環境で使うか？
- 頻繁に変更するか？
- 増えたり減ったりするか？
- AWS におけるコンテナ関連サービスについて理解する
- Amazon Elastic Container Registory
- コントロールプレーンとデータプレーン
- Amazon Elastic Container Service
- Amazon Elastic Kubernetes Service
- AWS Fargate
- 要件に合ったコンテナ環境の選択が非常に重要
- CI/CD を実現する Code シリーズ
- AWS フルマネージド Git リポジトリ「CodeCommit」
- CodeCommitの利用方法（HTTPS）
- CodeCommitの利用方法（SSH）
- アプリケーションのテストやビルドを実行する「CodeBuild」
- CodeBuildによるテストスクリプトの実行
- Codeシリーズを束ねる「CodePipeline」
- CodePipelineの作成
- CodeCommitへのプッシュによるPipeline自動起動の確認
- CodePipelineのその他の機能
- アプリケーションのデプロイを実現する「CodeDeploy」
- インプレイスデプロイ
- Blue/Greenデプロイ
- モニタリング：障害監視、リソース監視
- AWSコンポーネントでのデータ収集
- ログの収集
- メトリクスの収集
- CloudWatch Logsメトリクスフィルターを用いらログ内の特定イベント数の集計
- アプリケーションレイヤでのカスタムメトリクスの収集
- Container Insightsによるコンテナの詳細情報の収集
- ダッシュボードによる可視化
- 各サービスの標準ダッシュボード
- カスタムダッシュボード
- 作成可能なウィジェット
- メトリクスと統計値の取得
- CloudWatch Metric Math
- 各サービスの標準ダッシュボードからのウィジェットのインポート
- アラーム
- 設定の流れ
- メトリクスの選択
- 条件の設定
- アクションの設定
- 説明の追加、設定の完了
- 異常検知用学習モデルのカスタマイズ
- アプリケーションセキュリティ
- WAF と AWS WAF
- AWS WAF の設定
- Web ACLの作成
- ロギングの設定
- Amazon Athenaによるログの確認
- 分析データ準備
- コンテナセキュリティの概要
- イメージリスク
- レジストリリスク
- オーケストレーターリスク
- コンテナリスク
- ホストOSリスク
- Amazon ECR のイメージスキャン
- Aquaによるコンテナ環境の保護
- コードによるインフラの運用管理
- AWS CloudFormationとは
- CloudFormationのシステム概要
- CloudFormationのテンプレートの基礎を理解する
- CloudFormationを AWS マネジメントコンソールから実行する
- CloudFormationを CLI から実行する
- チェンジセットの活用
- CloudFormationで複数リソースを作成する
- 方法1 クロススタック参照
- 方法2 ダイナミック参照（動的な参照）
- 方法3 シェルスクリプトを利用する方法
- CloudFormation を利用したコンテナアプリケーション構築
- ハンズオンの目的
- ハンズオンで作成するAWS サービスの構成図
- 管理者用管理画面
- アプリケーション画面
- ハンズオンに必要な環境の用意
- Bashの動作環境
- ハンズオンで利用するソースコードの取得方法、および内容の解説
- ハンズオンの実行方法
- エラーが起こったときの対処方法
- なぜCloudFormationだけで全環境を構築する構成にしなかったか
- 手順1：VPCの作成
- 手順2：SecuriryGroupの作成
- 手順3：CodeCommitの作成
- 手順4：ECRの作成
- 手順5：RDSの作成
- コンソールからパラメータストアへのデータベース接続パスワード登録
- CloudFormationからのRDS作成
- 手順6：ECSクラスターの作成
- 手順7：管理者用コンソール画面の作成
- 管理画面（phpMyAdmin）ページの作成
- アプリケーションから利用するテーブルの作成
- phpMyAdminで利用しているコンテナの解説
- 手順8：アプリケーション画面の作成
- 1.PHPコンテナのビルドとECRへのプッシュ
- 2.アプリケーションの公開（ALB、ECSタスク、ECSサービスの作成）
- CloudWatch Logsの確認
- Container Insightsによるコンテナ環境のメトリクスの確認
- 手順9：CI/CDパイプラインの作成
- 1.CodeCommitリポジトリへのソースコード格納
- ハンズオン環境に対するブラッシュアップの方向性
- ハンズオン環境の削除方法
- スタック削除時の注意点
第３章 サーバーレスプラットフォームで作るモバイル向けアプリケーション
- サーバーレスアーキテクチャとは
- なぜサーバーレスを選択するか
- サーバーレスサービス登場以前
- 提供したい価値と、それを実現するための効率的な手段
- サーバーレスアーキテクチャの定義
- マネージドサービスのみで構築されている
- イベントドリブンなアーキテクチャ
- 実使用リソース量・時間に対する従量課金（最大値に対する課金ではない）
- スケーリングが自動で行われる
- サーバーレスを実現する AWS サービス
- AWS Lambda
- Lambda の特徴
- Lambda の基本操作
- Lambda のトリガーとなるイベントソース
- Lambda のユースケース
- Web サービスのバックエンド
- データの整形・変数処理
- 定期的な処理
- Lambda 開発におけるポイント
- Lambda からRDSへの接続
- Lambda コールドスタート対策
- Lambda Layers
- Amazon API Gateway
- API Gateway の基本操作
- HTTP のメソッドを定義
- API Gatewayのテスト
- API のデプロイ
- API Gateway 利用時のポイント
- メソッド設定
- メソッドリクエスト
- 統合リクエスト
- 統合レスポンス
- メソッドレスポンス
- API に対する認証機能の追加
- IAM アクセス権限を利用する
- Lambda オーソライザーを利用する
- Cognito オーソライザーを利用する
- WAF によるセキュリティ対策
- Amazon DynamoDB
- DynamoDBの特徴
- DynamoDBの基本操作
- DynamoDB利用によるおけるポイント
- キャパシティユニット
- 結果整合性のある読み込みと強力な整合性のある読み込み
- Amazon S3
- S3の基本操作
- S3のユースケース
- データのバックアップ
- ログの保存
- コンテンツの配信
- S3を利用するときのポイント
- バージョニング
- ライフサイクル、ストレージタイプ
- Amazon CloudFront
- CloudFrontの特徴
- CloudFrontの基本操作
- CloudFront利用におけるポイント
- ディストリビューションとビヘイビアー
- カスタムエラーページ
- カスタムヘッダー
- 構築するアプリケーションの全体構成
- クラウド開発キット（AWS CDK）の準備
- AWS CDK とは
- AWSCDK で利用する IAM ユーザーの作成
- credential ファイルの作成
- ランタイムのインストール
- AWS CDK のテンプレート生成
- Bootstrap処理
- バックエンドアプリケーション（API）の構築
- 必要なライブラリのインストール
- バックエンドの作成
- 全体構成
- API Gateway Endpoint の作成
- DynamoDB テーブルの作成
- Lambda Function の作成
- 処理の実装
- AWS CDK Appの定義
- ビルド＆デプロイの定義
- デプロイの実行
- 確認
- フロントエンドアプリケーションの作成
- Vue.jsとは
- Vue.js登場前との比較
- PWAとは
- Vue.jsアプリケーションの作成
- main.js
- App.vue
- Tab.vue
- Home.vue
- Persons.vue
- index.js
- フロントエンドアプリケーションの配信
- 必要なライブラリのインストール
- フロントエンドの作成
- 全体構成
- S3バケットの作成
- CloudFront Distributionの作成
- AWS CDK Appの定義
- ビルド＆デプロイの定義
- デプロイの実行
- 動作確認
- サーバーレスアプリケーションのモニタリング
- モニタリングの考え方
- 監視ポイント
- パフォーマンス（性能）モニタリング
- 異常検知
- キャパシティプランニング
- AWS X-Ray
第４章 AWS で作るデータの取集・可視化基盤
- AWS で作るデータ収集基盤
- 本節で構築するデータ収集基盤
- 想定するシナリオ
- 高速道路にあるETCゲート
- 構築するデータ収集基盤の概要
- 仮想IoTデバイス
- 構築するデータ収集基盤の詳細
- アーキテクチャと処理の流れ
- データの変換処理
- 使用しているAWSサービス
- IoT Core
- Kinesis Data Firehose
- Lambda
- DynamoDB
- S3
- プログラミング環境
- Python 3
- AWS SAM（Serverless Application Model）
- データ収集基盤の構築
- 仕様を決める
- ETCゲートとIoT Core の仕様
- データ収集結果の内容
- DynamoDB の設計と格納するデータ
- Python 仮想環境の構築
- 必要なライブラリをインストール
- AWS SAMプロジェクトの作成
- デプロイ先S3バケットの作成
- デプロイ先のS3バケットのCloudFormationテンプレートを作成
- デプロイ先のS3バケットをデプロイ
- AWS SAM テンプレートの作成
- ライブラリを未使用にする
- Lambda 関数のコードを作成
- ビルド
- デプロイ
- データ収集結果を格納するS3バケットの情報
- 動作確認（簡易）
- DynamoDBに格納するデータのJSONファイルを作成する
- ブラウザの IoT Core でテストする
- 仮想IoTデバイスの作成
- キーペアの作成
- IPアドレスの確認
- EC2インスタンスの作成
- EC2インスタンス内でAWS CLI を使うユーザーの作成
- EC2インスタンスに接続する
- Python 3 の環境を構築する
- AWSCLI の設定を行う
- IoT デバイスを IoT Core に接続するための準備
- IoT Core にモノを作成する
- IoT Core にポリシーを作成する
- 証明書の作成
- モノと証明書の紐付け
- 証明書とポリシーの紐付け
- サーバー認証用のルートCA証明書の取得
- IoT Core のエンドポイントを取得
- ETC ゲート用プログラムの作成
- AWSIoTPythonSDKのインストール
- データ送信用プログラムの作成
- 動作確認（仮想IoTデバイス）
- データの送信を終了する
- S3 バケットの様子
- より実用的に利用する場合
- データ分析の基本知識と AWS サービス
- データ分析の基本知識
- データレイク
- データウェアハウス
- ETL
- Extract（抽出）
- Transform（変換）
- Load（ロード）
- 可視化
- データ分析で使用するAWSサービス
- Amazon S3
- AWS Glue
- クローラ
- データカタログ
- ジョブ
- トリガー
- ジョブフロー
- Amazon Athena
- Amazon Redshift
- Amaozn Quicksight
- データレイクを構築する
- S3のデータをカタログ化する
- AWS Glue クローラの設定と実行
- データカタログ内のテーブル定義確認
- Athenaでログ検索
- データウェアハウスを構成し、グラフ表示する
- データウェアハウス構成
- Redshiftクラスター構築
- Redshiftテーブル作成
- AWS Glue からRedshiftへのコネクションの作成
- Redshiftテーブルのカタログ登録
- Glue ジョブの作成と実行
- Redshiftテーブル確認
- Amazon QuickSightからデータを参照する
- QuickSightアカウント作成
- Redshift-QuickSight間通信用VPCの作成
- データセットの作成
- グラフ作成
- 機械学習を導入する
- AWS における機械学習利用のアプローチ
- AI サービスを利用する
- Amazon Forecast
- Amazon Personalize
- Amazon Comprehend
- Amazon SageMakerを使用する
- 機械学習を導入する前にすべきこと
- 構築したシステム（AWSリソース）を削除する
- データ分析基盤の削除
- QuickSight環境の削除
- 分析の削除
- データセットの削除
- VPC 接続設定の削除
- QuickSightアカウントの削除
- Glueリソースの削除
- ジョブの削除
- クローラの削除
- カタログの削除
- Redshiftクラスターの削除
- VPCエンドポイントの削除
- 仮想IoTデバイスの削除
- モノと証明書とポリシーの紐付けを解除
- モノと証明書とポリシーの削除
- EC2インスタンス およびユーザーの削除
- データ収集基盤の削除
- S3バケット名の取得
- データ収集基盤の本体を削除
- S3バケットを削除
- 投稿日：2021-01-01T20:20:08+09:00
Serverless FrameworkでIAMロールを使ってデプロイする方法
Serverless FrameworkでIAMロールを使ってデプロイしようとしてハマったときのメモ。
結論としては、.aws/configだけではなく、.aws/credentialsにもrole_arnとsource_profileの設定をすればOK。環境
Serverless Framework
$ serverless --version Framework Core: 1.69.0 Plugin: 3.6.9 SDK: 2.3.0 Components: 2.30.5AWSのconfigとcredentials
assume roleしてadmin権限でcli実行するprofileを下記のように設定。
$ cat ~/.aws/config [default] region = ap-northeast-2 output = json [profile admin] region = ap-northeast-2 role_arn = arn:aws:iam::NNNNNNNNNNNN:role/xxxxxxxx-yyyyyyyy source_profile = defaultcredentialsファイルはdefaultのみ、下記のように設定。
$ cat ~/.aws/credentials [default] aws_access_key_id = XXXXXXXXXXXXXXXXXXXXX aws_secret_access_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYTerminalからaws cliコマンドを直接実行する分には、この設定で問題ない。
現象
serverless frameworkを使って、AWS Lambdaのデプロイを試みると、profileが見つからないエラーが表示されて、処理が中断する。参照して欲しいprofileは--aws-profileで設定しているはずなのに...。
serverless deploy --aws-profile admin Error -------------------------------------------------- Error: Profile admin does not exist at Object.addProfileCredentials (/Users/shizuku/.nodebrew/node/v12.16.2/lib/node_modules/serverless/lib/plugins/aws/provider/awsProvider.js:102:15) at AwsProvider.getCredentials (/Users/shizuku/.nodebrew/node/v12.16.2/lib/node_modules/serverless/lib/plugins/aws/provider/awsProvider.js:3 ...対策
awsのcredentialsファイルの方にも、configファイルと同様のプロファイル名のエントリを追記して、role_arnとsource_profileを記載する。
$ cat ~/.aws/credentials [default] aws_access_key_id = XXXXXXXXXXXXXXXXXXXXX aws_secret_access_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY [admin] region = ap-northeast-2 role_arn = arn:aws:iam::NNNNNNNNNNNN:role/xxxxxxxx-yyyyyyyy source_profile = default
- 投稿日：2021-01-01T16:36:18+09:00
AWS Lambda実践ガイドでハマった話。event['body']がbase64だった
はじめに
AWS Lambda実践ガイドの5章Sの3に配置したhtml のフォームを叩いてAPI経由でlambdaを呼出してpostした内容をdynamoDBに書き込む練習問題でハマったた備忘録として記載。結論として、event['body']がbase64にエンコードされていた。
経緯
実践ガイドのサンプルコードをそのまま実装しても動かないため、CWのlogを見てみると
htmlのフォームから入力されたデータを受け取るところに問題がありそう。案の定、print(param)してみるとnullになっていたので、
print(json.dumps(event,indent=4))でevent全体を見てみる。
すると
"body": "dXNlcm5hbWU9YWEmZW1haWw9aGg=",でどうやら値が入ってはいるが、なんだこれ。色々とネットを漁るとbase64というすべてのデータをアルファベットと一部の記号であらわすエンコード仕様らしい。
試しにhttps://www.en-pc.jp/tech/base64.phpでエンコードしてみるとちゃんと結果が返ってきていた！コードの修正
というわけでbase64にデコードしてparseするように修正した。
import base64 (中略) body = base64.b64decode( event['body'] ) param =urllib.parse.parse_qs(body.decode('utf-8'))おわりに
今回のような値を渡すところは、勝手にエンコード等されていないか確認することが大切と学んだ。
- 投稿日：2021-01-01T16:13:14+09:00
AWS IAM ユーザが, 自身で MFA 登録できるようにするメモ
背景
AWS で IAM でチームメンバー用にユーザを作りたい(権限は最低限 + CodeCommit 用に git repo アクセス).
ユーザは. MFA 認証を各自で設定できるようにしたい.デフォルトだと, 最低権限だとユーザは MFA 認証を使えません.
方法
IAMユーザにMFA設定を強制するにあたりiam:ListUsersが必須では無くなった話
https://blog.serverworks.co.jp/tech/2019/04/02/mysecuritycredentials/ありがとうございます.
AWS は MFA 認証したい場合いろいろと JSON でポリシー設定しないといけないのでめんどいですね.
(基本はコピペでいけますが, 一度理解しないといけないので結局めんどい)他のサービスのように, MFA 認証をぺろっとお手軽に設定できるようになってほしい.
CodeCommit との連携
上記だと, codecommit 関連も deny されてしまい. git clone とかするとエラーになってしまいます.
MFAを強制しながらCodeCommitをgitコマンドや各種ツールから利用する
https://qiita.com/Morihaya/items/0ab6d5599cca96de3543ありがとうございます.
- 投稿日：2021-01-01T16:03:13+09:00
文系新卒エンジニアがAWS認定ソリューションアーキテクト – アソシエイトに合格した話
概要
先日SAAに合格したので、合格体験記的なものを書いておこうと思います。
これからSAAを受験される方の参考になれば幸いです。自己紹介
高校時代、理系を志すもmolで挫折し文転。大学はそのまま文系学部へ。
その後、国内独立系SIerに就職。
営業職で内定をもらっていたが、SE職かっこええな～と思ってダメ元で転向願い出したらOK出てSEの道へ。
AWSを扱うチームに配属される。だいたいのスケジュール
いつごろ何をやってたか、徒然と書いていきます。
7月
配属される。AWSとは、、、そもそもクラウドとは、、、という状態。
何か勉強しなきゃ！と思って先輩に何から始めればいいか尋ねると、とりあえずSAA目指せば？と言われた。
（なぜクラウドプラクティショナーすっ飛ばしたのかは不明）とりあえず参考書を購入。先輩からオススメされた黒本をポチる。
割と有名な参考書っぽい。8~9月
基本的なサービスについて勉強する。
黒本の第1章だけ読んでた。
○○ってサービスは何ができるサービス？って聞かれたらなんとなく答えられるようになる。10月
各サービスがどんな感じで連携するんか勉強する。
黒本の第2章以降を読み進めて、代表的なアーキテクチャを知る。
あ～～このサービスってこんな使われ方するんや～～ってなる。会社の検証環境でEC2立てたり、S3バケット作ったり、IAMロール作って適当にアタッチしたりした。
実物を触るとどんなオプションがあるんかとか分かる。
SAAではオプション機能について聞いてくるもの（例↓）もあるから、役に立った。
・ EBS ボリュームの DeleteOnTermination 属性
・ S3オブジェクトのバージョニング
・ MFA Delete
⇒クラスメソッドさんの記事です。いつも本当にありがとうございます。
（公式よりクラスメソッドさんの記事の方が分かりやすいまである）11月
黒本付属の演習問題に手を付け始める。
分からないところがあれば、公式サイトやクラスメソッドさんのサイトで調べる。
EC2の購入オプション、IAMポリシーの種類、RDSとAuroraの違い、AutoScalingのスケーリングポリシー、Route53のルーティングポリシーなどなど、細かい知識を足していく。
（○○ポリシー系はアップデートが頻繁にあるため要チェック）YouTubeのAWS関連動画を漁る。通勤中とか食事中とかにラジオ感覚で流してた。
興味あるやつだけ見ればいいかと、、、
オススメはセキュリティ・可用性関連の動画。
最新アップデートの発表みたいなやつもあるけど、試験にはあまり出ない気がするので、試験対策としてはたぶん見なくていい。そろそろ受験すっかと思ってサイトから試験を予約。
ネタで受験日を12/25にした。12月
認定トレーニング「Architecting on AWS」に経費で参加（圧倒的感謝）
試験対策のつもりでいくとイメージと違うな～～ってなるかも。
どちらかといえば、実際にAWS上でリソース立ててみよう～～みたいな感じだった。
実務でAWS触ってるから、正直行かなくてもよかったかもと思う。
ただ黒本に載っていない（初見の）サービスをすごくざっくり紹介してくれたり、講師の方に自分の誤った理解を指摘してもらったりしたので、無駄ではなかった。
会社が行ってもいいよと言ってくれるなら行ってもいい。
個人で行くのは出費的に死ねる。あとは最後の追い込み。
少しでも理解があやふやな部分は公式サイトやクラスメソッドさんの（ryクリスマス（試験日）が迫り、街を歩くたびやる気（殺意の間違いでは）が湧いてくる。
試験当日。
試験終了後すぐに合否が表示される。いいような悪いような。
脳の疲労がピークで合格を実感できない。ほぼ放心状態だった気がする。所感
黒本だけじゃ無理
黒本で触れられていないサービスが普通に試験に出たりする。
黒本で触れられているけどめっちゃあっさりとしか書いてないサービスもある。
基本的にAWSの情報はネットにあふれているので、ネットの情報を活用しない手はない。AWS系資格は、参考書の内容が「最新」でなくなるスピードが恐ろしく速い。
もしかしたら黒本の内容が間違ってるかも、、みたいな意識は常に持っておいたほうが安全。初手からSAAでもいけるけど・・・
やっぱクラウドプラクティショナー取ってからSAAの方が安全かもしれない。
クラウドプラクティショナーでクラウド特有の考え方やお作法の部分を理解してからSAAの勉強したほうがいろいろ捗ると思う。
まあクラウドプラクティショナーってどんな試験なのか全然知らないんですけどねぇ（）試験の問題を解釈するのに読解力が必要（余談）
○○を実現したいんだけどどのサービス使えば実現できそう？？みたいな、あらかじめ解決すべき課題が明示されている問題は知識だけで回答できる。
が、どんな課題を解決しないといけないのか、というところから読み取る必要がある問題もある。
それには読解力が必要。
SE業務全般に言えることだが、文系の国語力って割と必要だったりする。
もっと文系SEが増えればいいのにと思う。
- 投稿日：2021-01-01T15:54:47+09:00
SpringBootで作成したWebアプリをEC2にデプロイするときに躓いた話
はじめに
自分用のメモです。
開発環境
・Windows10
・OpenJDK 1.8
・SpringBoot 2.2.4
・Gradle 6.3
・MySQL5.7
・AWS（EC2・RDS・VPC）作業の流れ
1.デプロイ用のSpringBootアプリを用意
2.EC2・RDS・VPCを準備する
3.Amazon Linux2で必要ツールをインストール
4.Buildしてデプロイ1.デプロイ用のSpringBootアプリを用意する
こちらは何でも構わないので自身で作成しているアプリで可
2.AWS（EC2・RDS・VPC）の用意
ここは後日投稿する予定です
3．Amazon Linux2で必要ツールをインストール
EC2にログインしyumを最新にします
# yum updateGitのバージョンを確認とインストール
# yum search git # yum install gitGitがインストール終わったら一応確認
# git --versionJava8をインストール
# yum install -y java-1.8.0-openjdk-develTomcatをインストールし配置しなおす
詳しくはこちらgitをクローンする
# git clone https://github.com/sample.gitクローンしたディレクトリに移動しgradlewの権限を広める
# chmod 755 gradlewこのままビルドしたいがapplication.propertiesに移動し設定変更
application.propertiesは環境に依存する関係# cd src/main/resources # vim application.propertiesMySQLのURLがlocalhostになっていると思うのでここを変更
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://「localhost」←ここ！:3306/sample?serverTimezone=JST spring.datasource.username=root spring.datasource.password=password spring.datasource.initialization-mode=alwayslocalhostの部分をRDSのエンドポイントに変更
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://~~~~~~~~~~:3306/sample?serverTimezone=JST spring.datasource.username=root spring.datasource.password=password spring.datasource.initialization-mode=alwaysこれでRDSに接続していけるように変更しました。
ここからbuildしていきます！！# ./gradlew buildビルド終了次第buildのlibs配下に移動
ビルドしたアプリケーションがあると思うので権限を緩めるのと
持ち主とグループをtomcatに変更# chmod 755 sample.war # chown tomcat:tomcat sample.warそしてwebapps配下に移動させTomcatを起動させる
# mv sample.war /opt/apache-tomcat/webapps # systemctl start tomcat.serviceEC2の設定したURLに接続してあげると・・・
以上です
- 投稿日：2021-01-01T14:13:25+09:00
boto3でのendpoint_url=Noneの指定
はじめに
新年明けましておめでとうございます。
本年（2021年）ですが、「技術の目利き」のスキルと技術戦略策定のスキルの向上、エンジニアの採用方法の確立、CTO（Chief Technical/Technology Officer）やTech Leadとの人的ネットワーク構築を目標に頑張っていきたいと考えています。
本年もよろしくお願いいたします。確認したかったこと
AWS SDKやAWS CLIで使用するAWSのサービスエンドポイントですが、AWSのリファレンスガイドには、以下のような記述があり、特に指定しない場合は自動でエンドポイントが決まる仕様のようです。
AWS SDK と AWS Command Line Interface (AWS CLI) では、AWS リージョンで各サービスのデフォルトのエンドポイントを自動的に使用します。
LocalStackという、ローカル（自分の手元の環境）で動かすAWSを模したテスト用モック環境を利用する場合は、LocalStackのエンドポイントを指定することになります。Boto3だと以下のようにendpoint_urlを指定します。
s3 = boto3.client('s3', endpoint_url='http://localhost:4566')このときに
endpoint_url=Noneを指定した場合の挙動がどうなるのかが確認したかったことです。私の予想
Boto3のドキュメントによると、
boto3.session.Sessionクラスのclientメソッドの引数にendpoint_url=Noneがあり、デフォルト値はNoneになっているようです。ここから考えると、endpoint_url=Noneを指定した場合は、自動的にAWSのエンドポイントが使用されるのではないかと考えましたが、念のため試してみました。試行のための準備（環境構築）
今回使用したソフトウェアのバージョン一覧
- Ubuntu 20.04.1 LTS
- AWS CLI 2.1.15
- LocalStack 0.12.4
- Docker 19.03.8
- python3-pip 20.0.2
- boto3 1.16.47
AWS CLI
まず、公式のユーザーガイドに従い、以下のコマンドでAWS CLIをインストールします。
wget "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" unzip awscli-exe-linux-x86_64.zip sudo ./aws/install
実行結果
stack@stack:~$ wget "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" --2021-01-01 01:29:18-- https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip Resolving awscli.amazonaws.com (awscli.amazonaws.com)... 54.239.169.102, 54.239.169.98, 54.239.169.20, ... Connecting to awscli.amazonaws.com (awscli.amazonaws.com)|54.239.169.102|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 35197257 (34M) [application/zip] Saving to: ‘awscli-exe-linux-x86_64.zip’ awscli-exe-linux-x86_64.zip 100%[=============================================================================================================>] 33.57M 2.57MB/s in 11s 2021-01-01 01:29:29 (2.97 MB/s) - ‘awscli-exe-linux-x86_64.zip’ saved [35197257/35197257] stack@stack:~$ unzip awscli-exe-linux-x86_64.zip Archive: awscli-exe-linux-x86_64.zip creating: aws/ creating: aws/dist/ inflating: aws/install inflating: aws/THIRD_PARTY_LICENSES inflating: aws/README.md creating: aws/dist/_struct/ creating: aws/dist/awscli/ creating: aws/dist/botocore/ creating: aws/dist/cryptography/ creating: aws/dist/cryptography-2.8-py3.7.egg-info/ creating: aws/dist/docutils/ creating: aws/dist/include/ creating: aws/dist/lib/ creating: aws/dist/zlib/ inflating: aws/dist/grp.cpython-37m-x86_64-linux-gnu.so （中略） inflating: aws/dist/cryptography-2.8-py3.7.egg-info/LICENSE.BSD creating: aws/dist/include/python3.7m/ inflating: aws/dist/include/python3.7m/pyconfig.h stack@stack:~$ sudo ./aws/install You can now run: /usr/local/bin/aws --version stack@stack:~$ aws --version aws-cli/2.1.15 Python/3.7.3 Linux/5.4.0-54-generic exe/x86_64.ubuntu.20 prompt/off次にAWS ウェブコンソールから生成されたCSV形式の認証情報を「aws configure import」コマンドでインポートします（ユーザーガイドを参照）。今回、私はCSVファイルを編集して、CSVの中のUser name列の値を「default」に変更して、defaultプロファイルになるようにしました。また、デフォルトのリージョン設定を行ないました（aws configure set region コマンド）。
stack@stack:~$ aws configure import --csv file://new_user_credentials.csv Successfully imported 1 profile(s) stack@stack:~$ aws configure set region ap-northeast-1 stack@stack:~$ aws configure list-profiles defaultLocalStack
LocalStackをインストールする前に、以下のコマンドでDockerをインストールして、Dockerのサービスを起動します。
sudo apt-get install docker docker.io sudo systemctl start docker.servicerootユーザでなくても、Dockerを操作できるように、現在のユーザ（私の場合はstack）をdockerグループに所属させます。（newgrpコマンドは、すぐにdockerグループへの所属を反映させるために行なっています。）
sudo usermod -a -G docker stack newgrp dockerそして、以下のコマンドでLocalStackをインストールします。pip3をインストールして、その後pip3を使ってLocalStackをインストールします。
sudo apt-get install python3-pip pip3 install localstack
実行結果
stack@stack:~$ sudo apt-get install python3-pip Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: build-essential dpkg-dev fakeroot g++ g++-9 libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libexpat1-dev libfakeroot libpython3-dev libpython3.8-dev libstdc++-9-dev python-pip-whl python3-dev python3-wheel python3.8-dev zlib1g zlib1g-dev Suggested packages: debian-keyring g++-multilib g++-9-multilib gcc-9-doc libstdc++-9-doc The following NEW packages will be installed: build-essential dpkg-dev fakeroot g++ g++-9 libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libexpat1-dev libfakeroot libpython3-dev libpython3.8-dev libstdc++-9-dev python-pip-whl python3-dev python3-pip python3-wheel python3.8-dev zlib1g-dev The following packages will be upgraded: zlib1g 1 upgraded, 19 newly installed, 0 to remove and 71 not upgraded. Need to get 17.8 MB of archives. After this operation, 75.0 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://jp.archive.ubuntu.com/ubuntu focal-updates/main amd64 zlib1g amd64 1:1.2.11.dfsg-2ubuntu1.2 [53.6 kB] Get:2 http://jp.archive.ubuntu.com/ubuntu focal-updates/main amd64 libstdc++-9-dev amd64 9.3.0-17ubuntu1~20.04 [1714 kB] （中略） Processing triggers for libc-bin (2.31-0ubuntu9) ... stack@stack:~$ pip3 install localstack Collecting localstack Downloading localstack-0.12.4.tar.gz (279 kB) |████████████████████████████████| 279 kB 76 kB/s Collecting boto3>=1.14.33 Downloading boto3-1.16.47.tar.gz (99 kB) |████████████████████████████████| 99 kB 131 kB/s Collecting dnspython==1.16.0 Downloading dnspython-1.16.0-py2.py3-none-any.whl (188 kB) |████████████████████████████████| 188 kB 132 kB/s Collecting docopt>=0.6.2 Downloading docopt-0.6.2.tar.gz (25 kB) Collecting localstack-client>=0.14 Downloading localstack-client-1.10.tar.gz (4.3 kB) Collecting localstack-ext>=0.11.0 Downloading localstack-ext-0.12.3.3.tar.gz (716 kB) |████████████████████████████████| 716 kB 196 kB/s Collecting requests>=2.20.0 Downloading requests-2.25.1-py2.py3-none-any.whl (61 kB) |████████████████████████████████| 61 kB 1.8 MB/s Requirement already satisfied: six>=1.12.0 in /usr/lib/python3/dist-packages (from localstack) (1.14.0) Collecting botocore<1.20.0,>=1.19.47 Downloading botocore-1.19.47-py2.py3-none-any.whl (7.2 MB) |████████████████████████████████| 7.2 MB 2.6 MB/s Collecting jmespath<1.0.0,>=0.7.1 Downloading jmespath-0.10.0-py2.py3-none-any.whl (24 kB) Collecting s3transfer<0.4.0,>=0.3.0 Downloading s3transfer-0.3.3-py2.py3-none-any.whl (69 kB) |████████████████████████████████| 69 kB 1.5 MB/s Collecting dnslib>=0.9.10 Downloading dnslib-0.9.14.tar.gz (72 kB) |████████████████████████████████| 72 kB 646 kB/s Collecting pyaes>=1.6.0 Downloading pyaes-1.6.1.tar.gz (28 kB) Requirement already satisfied: idna<3,>=2.5 in /usr/lib/python3/dist-packages (from requests>=2.20.0->localstack) (2.8) Collecting certifi>=2017.4.17 Downloading certifi-2020.12.5-py2.py3-none-any.whl (147 kB) |████████████████████████████████| 147 kB 2.1 MB/s Requirement already satisfied: urllib3<1.27,>=1.21.1 in /usr/lib/python3/dist-packages (from requests>=2.20.0->localstack) (1.25.8) Requirement already satisfied: chardet<5,>=3.0.2 in /usr/lib/python3/dist-packages (from requests>=2.20.0->localstack) (3.0.4) Requirement already satisfied: python-dateutil<3.0.0,>=2.1 in /usr/lib/python3/dist-packages (from botocore<1.20.0,>=1.19.47->boto3>=1.14.33->localstack) (2.7.3) Building wheels for collected packages: localstack, boto3, docopt, localstack-client, localstack-ext, dnslib, pyaes Building wheel for localstack (setup.py) ... done Created wheel for localstack: filename=localstack-0.12.4-py3-none-any.whl size=311544 sha256=79900437f8ab3902817e8a2a65fc9c418cc004a01652d6c77db4b4365a78138a Stored in directory: /home/stack/.cache/pip/wheels/6b/96/58/9a299ffed3f2630dddb6ad3cdc17b61f5fb508fe06b71122f3 Building wheel for boto3 (setup.py) ... done Created wheel for boto3: filename=boto3-1.16.47-py2.py3-none-any.whl size=128711 sha256=5f71da0686eed283d5e01894769a08bd0435ceb9583a493bc326697b64084d2b Stored in directory: /home/stack/.cache/pip/wheels/6a/90/d3/ebaaf8d74ce53fcdb09354cf37b93aa7e03e43bd8c6558e4cf Building wheel for docopt (setup.py) ... done Created wheel for docopt: filename=docopt-0.6.2-py2.py3-none-any.whl size=13704 sha256=592c6e4c0f8dc7fb2fb27139159ff6365abd4bba7a7cb90f7bfa24ecda0aa9a8 Stored in directory: /home/stack/.cache/pip/wheels/56/ea/58/ead137b087d9e326852a851351d1debf4ada529b6ac0ec4e8c Building wheel for localstack-client (setup.py) ... done Created wheel for localstack-client: filename=localstack_client-1.10-py3-none-any.whl size=3810 sha256=4b50d57e15684b2c672a7a6bcf909e098800dbb1d9e03ec55dfe68718ec42a41 Stored in directory: /home/stack/.cache/pip/wheels/70/fd/cf/27fa4e7b43bf50e49bd08ee4b92356e745059f28fb0b015a62 Building wheel for localstack-ext (setup.py) ... done Created wheel for localstack-ext: filename=localstack_ext-0.12.3.3-py3-none-any.whl size=738468 sha256=6ccfc9c4798f123f03f2e63bc27599a87840eb42d8e2a8bfa886e240dd812553 Stored in directory: /home/stack/.cache/pip/wheels/e9/cb/3e/efe9714198c2e65df0d1582764b166ebbc3fdf36a65630746c Building wheel for dnslib (setup.py) ... done Created wheel for dnslib: filename=dnslib-0.9.14-py3-none-any.whl size=54650 sha256=73718ca66fd25b49d34013e5c3b6ef3c4040b826ab365fb370a663d8978b39f1 Stored in directory: /home/stack/.cache/pip/wheels/8b/3d/dd/faac4d3774f42937334e7b65bfdae225a60204088f04f5b684 Building wheel for pyaes (setup.py) ... done Created wheel for pyaes: filename=pyaes-1.6.1-py3-none-any.whl size=26345 sha256=a92c10cd13668abb873fd630d0996f6de763d08715731af12fcf6b8cc378bad0 Stored in directory: /home/stack/.cache/pip/wheels/aa/ca/9c/8a3c00512585c703edc457db81c066b9609d76758c74f72ac6 Successfully built localstack boto3 docopt localstack-client localstack-ext dnslib pyaes Installing collected packages: jmespath, botocore, s3transfer, boto3, dnspython, docopt, localstack-client, dnslib, pyaes, certifi, requests, localstack-ext, localstack Successfully installed boto3-1.16.47 botocore-1.19.47 certifi-2020.12.5 dnslib-0.9.14 dnspython-1.16.0 docopt-0.6.2 jmespath-0.10.0 localstack-0.12.4 localstack-client-1.10 localstack-ext-0.12.3.3 pyaes-1.6.1 requests-2.25.1 s3transfer-0.3.3「$HOME/.local/bin」ディレクトリにに「localstack」コマンドがインストールされたので、そのlocalstackコマンドを使用してLocalStackを起動します（localstack start）。
stack@stack:~$ export PATH=$PATH:~/.local/bin stack@stack:~$ localstack start「localstack start」を実行して「Ready.」のメッセージが出力されれば準備完了です。ログ出力にもあるとおり、デフォルトでは4566番のポートを使用しています（ポート番号は環境変数EDGE_PORTに設定して変更できるようです）。そのため、「http://localhost:4566」のエンドポイントを使用してアクセスします。
localstack startの実行結果
stack@stack:~$ localstack start Starting local dev environment. CTRL-C to quit. docker run -it -e TEST_AWS_ACCOUNT_ID="000000000000" -e LOCALSTACK_HOSTNAME="localhost" -e DEFAULT_REGION="us-east-1" --rm --privileged --name localstack_main -p 4566:4566 -p 4571:4571 -p 8080-8081:8080-8081 -v "/tmp/localstack:/tmp/localstack" -v "/var/run/docker.sock:/var/run/docker.sock" -e DOCKER_HOST="unix:///var/run/docker.sock" -e HOST_TMP_FOLDER="/tmp/localstack" "localstack/localstack" Unable to find image 'localstack/localstack:latest' locally latest: Pulling from localstack/localstack 4880f1046b03: Pull complete Digest: sha256:e52abfdd82fbd1a6503a857f1aa6daa81aa46af424a26ad7c98417ea371d9759 Status: Downloaded newer image for localstack/localstack:latest Waiting for all LocalStack services to be ready 2021-01-01 02:25:30,806 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message. 2021-01-01 02:25:30,811 INFO supervisord started with pid 13 2021-01-01 02:25:31,822 INFO spawned: 'dashboard' with pid 19 2021-01-01 02:25:31,831 INFO spawned: 'infra' with pid 20 2021-01-01 02:25:31,855 INFO success: dashboard entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) (. .venv/bin/activate; exec bin/localstack start --host) 2021-01-01 02:25:32,865 INFO success: infra entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2021-01-01 02:25:32,865 INFO exited: dashboard (exit status 0; expected) Starting local dev environment. CTRL-C to quit. LocalStack version: 0.12.4 Waiting for all LocalStack services to be ready Starting edge router (https port 4566)... Starting mock ACM service on http port 4566 ... 2021-01-01T02:25:39:INFO:localstack.utils.analytics.profiler: Execution of "load_plugin_from_path" took 634.166955947876ms 2021-01-01T02:25:39:INFO:localstack.utils.analytics.profiler: Execution of "load_plugins" took 634.6888542175293ms 2021-01-01T02:25:40:INFO:localstack.multiserver: Starting multi API server process on port 56613 [2021-01-01 02:25:40 +0000] [21] [INFO] Running on https://0.0.0.0:4566 (CTRL + C to quit) 2021-01-01T02:25:40:INFO:hypercorn.error: Running on https://0.0.0.0:4566 (CTRL + C to quit) [2021-01-01 02:25:40 +0000] [21] [INFO] Running on http://0.0.0.0:56613 (CTRL + C to quit) 2021-01-01T02:25:40:INFO:hypercorn.error: Running on http://0.0.0.0:56613 (CTRL + C to quit) Starting mock API Gateway service on http port 4566 ... Starting mock CloudFormation service on http port 4566 ... Starting mock CloudWatch service on http port 4566 ... Starting mock DynamoDB service on http port 4566 ... Starting mock DynamoDB Streams service on http port 4566 ... Starting mock EC2 service on http port 4566 ... Starting mock ES service on http port 4566 ... Starting mock Firehose service on http port 4566 ... Starting mock IAM service on http port 4566 ... Starting mock STS service on http port 4566 ... Starting mock Kinesis service on http port 4566 ... Starting mock KMS service on http port 4566 ... Starting mock Lambda service on http port 4566 ... Starting mock CloudWatch Logs service on http port 4566 ... Starting mock Redshift service on http port 4566 ... Starting mock Route53 service on http port 4566 ... Starting mock S3 service on http port 4566 ... Starting mock Secrets Manager service on http port 4566 ... Starting mock SES service on http port 4566 ... Starting mock SNS service on http port 4566 ... Starting mock SQS service on http port 4566 ... Starting mock SSM service on http port 4566 ... Starting mock Cloudwatch Events service on http port 4566 ... Starting mock StepFunctions service on http port 4566 ... Waiting for all LocalStack services to be ready Waiting for all LocalStack services to be ready Ready. 2021-01-01T02:25:54:INFO:localstack.utils.analytics.profiler: Execution of "start_api_services" took 14802.880048751831ms以下はLocalStackにS3のBucketを作成して、一覧取得を行なった結果です。
stack@stack:~$ aws s3 mb s3://test-localstack --endpoint-url http://localhost:4566 make_bucket: test-localstack stack@stack:~$ aws s3 ls --endpoint-url http://localhost:4566 2021-01-01 02:43:44 test-localstack試行
以下のプログラムを作成して、エンドポイントが指定された時は、そのエンドポイントを使用してS3のBucketの一覧を取得し、エンドポイントが指定されない場合は、
endpoint_url=NoneとしてAWSのエンドポイントを使用してS3のBucketの一覧を取得することにしました。listbuckets.pyimport sys import boto3 if len(sys.argv) not in (1, 2): print("Usage: python3 listbuckets.py [endpoint_url]") sys.exit(1) endpoint_url = sys.argv[1] if len(sys.argv) == 2 else None s3 = boto3.client('s3', endpoint_url=endpoint_url) response = s3.list_buckets() if 'Buckets' in response: for bucket in response['Buckets']: print(bucket['Name'])実行してみると以下のとおり
endpoint_url=Noneの場合は、AWSのエンドポイントにアクセスできています。stack@stack:~$ aws s3 ls --endpoint-url http://localhost:4566 2021-01-01 02:43:44 test-localstack stack@stack:~$ aws s3 ls 2021-01-01 04:46:14 test-aws-20210101 stack@stack:~$ python3 listbuckets.py http://localhost:4566 test-localstack stack@stack:~$ python3 listbuckets.py test-aws-20210101
- 投稿日：2021-01-01T11:21:40+09:00
AWS構成単位
AWS構成単位
リージョン
世界中にある複数のデータセンターを物理的に設置している場所
日本でアプリを発信するなら、東京リージョンで構築するアベイラビリティーゾーン
リージョンの中に存在するデータセンターの集まり
東京リージョンにある3つのアベイラビリティーゾーン（1a,1c,1dはZoneIdと呼ばれる）
①ap-northease-1a
②ap-northease-1c
③ap-northease-1dVPC（バーチャル・プライベート・クラウド）
AWSでの仮想ネットワーク空間
インターネットゲートウェイ
個々人のVPCとインターネットゲートウェイを紐づけて、インターネットにアクセスできる
VPCとゲートウェイを紐付けるためにルートテーブルが必要になるルートテーブル
ゲートウェイとアプリ間を繋げるために必要
このままだと外部からEC2にダイレクトに影響してしまうので、ルートテーブルを2つに分ける
・パブリックサブネット（VPC←ルートテーブル{（パブリック）←（プライベート）}EC2等））
・プライベートサブネット（ここにWebアプリを配置）NATゲートウェイ
パブリックサブネットの中に設置して、プライベートと通信する
※IGW ← パブリックサブネット（NATGW）←プライベートサブネット（EC2） ← プライベートサブネット（DB）
- 投稿日：2021-01-01T03:38:37+09:00
AWS Single Sign-OnでIBM Cloudを認証する
目的
AWS Single Sign-On（以下、AWS SSO）はSAML IdPになることができます。一方、IBM Cloudのポータル、CLI等はIAMのIDプロバイダーとして、IBM IDだけでなくApp IDに対応し、App IDはSAMLのSPになることができます。というわけで、AWS SSOのIdPを使ってIBM Cloudの認証をしてみます。
利点
デフォルトではIBM CloudのポータルにアクセスするためにIBM IDを取得し、アカウントから招待してもらう必要があります。このマルチクラウド時代に、AWSとIBM Cloudでそれぞれユーザー管理をしなければいけないうのは、ユーザー数が増えてきたら管理者にとってはかなりの負担になります。
また、会社のメールアドレスを使ってIBM IDを取得するという行為が特にエンタープライズな環境では抵抗を受けるケースもあります。
AWS SSOのIdPと連携することで、次のようなメリットがあります。
- ユーザーはIBM IDの登録が不要
- AWS IdPのユーザーでIBM CloudにログインするとIBM Cloudにユーザーが自動登録される
- AWS SSOを使ったアプリケーションとIBM Cloud ConsoleやApp IDを使ったアプリケーションでSSOできる
手順
AWS SSOの初期設定
当然AWSのアカウントが必要です。アカウントに管理者でログインしたら
AWS Single Sign-Onサービスを選択します。
初めての場合は
AWS SSOを有効にするをクリックします。
初めての場合は
AWS 組織の作成をクリックします。
3 クラウドアプリケーションへの SSO アクセスの管理を選択します。
新規アプリケーションの追加をクリックします。
カスタム SAML 2.0 アプリケーションの追加を選択します。
表示名と説明に任意の値を入力します。
ここで、
AWS SSO SAML メタデータファイルをダウンロードしますAWS SSO サインイン URLを控えておきますAWS SSO 証明書をダウンロードします画面をそのままにしてApp IDの設定画面を開きます。
App IDの初期設定
App IDのインスタンスを用意しておきます。
わかりやすさのために
SAML 2.0連携以外のIDプロバイダーを無効化し、SAML 2.0連携の編集をクリックします。
プロバイダ名に任意の値を入力し、
SAML メタデータ・ファイルのダウンロードをクックします。これはいわゆるSPメタデータです。
画面右側の値を入力します。
項目 値 エンティティーID 先ほどダウンロードしたAWSのIdPメタデータをテキストエディタで開き、1行目のentityId値を入力 サインインURL 先ほど控えたAWS SSOのサインインURLを入力 1次証明書 先ほどダウンロードしたAWS SSO証明書の中身を入力
保存をクリックします。AWS SSOのSPメタデータ取り込みと属性マッピング
再びAWSに戻り、先ほどダウンロードしたSPメタデータをアップロードし
変更の保存をクリックします。
属性マッピングタブをクリックします。
AWS SSO IdPのアサーションとSP間で属性のマッピングをします。
参考）https://cloud.ibm.com/docs/account?topic=account-idp-integration
最低限下記のマッピングを追加します。
アプリケーションのユーザー属性 この文字列または AWS SSO のユーザー属性にマッピング 形式 意味 Subject ${user:email} emailAddress App IDのユーザープロファイルの識別に使用（必須） familyName ${user:familyName} basic IBM Cloudのユーザープロファイルで名前の表示に使用（姓部分） givenName ${user:givenName} basic IBM Cloudのユーザープロファイルで名前の表示に使用（名部分） name ${user:preferredUsername} basic App IDのユーザープロファイルで名前の表示に使用
入力後、
変更を保存をクリックします。AWS SSOのユーザー追加
AWS SSOを利用できるユーザーを追加します。
ユーザーメニューからユーザーを追加をクリックします。
必要な情報を入力し、
次: グループをクリックします。
グループはSSOには不要なので、
ユーザーを追加をクリックします。
ユーザーが追加されました。
メールアドレス宛にインビテーションメールが送信されますので、メールを開きリンクをクリックします。
パスワードを設定し
新しいパスワードの設定をクリックします。
これでAWS SSO側の作業は完了です。
App IDの接続テスト
SAML 2.0連携画面で
テストをクリックします。
設定がうまくいっていればAWSのサインイン画面が表示されるので、先ほど登録したAWS SSOのユーザー名を入力して
次のをクリックします。
先ほど設定したパスワードを入力し
サインインを選択します。
設定がうまくいっていれば
Good job, It worksと表示されます。
ユーザープロファイルを確認します。初回ログイン時にプロファイルが自動登録されます。
これでApp ID側の作業は完了です。
IBM Cloud ConsoleのIDプロバイダー設定
IAMのIDプロバイダーを設定します。過去記事「App IDのユーザーでIBM Cloudのポータルを利用する」を参照ください。
設定が終わったら、IdP URLをブラウザで開きます。ブラウザにAWS SSOの認証情報が残っていればIBM Cloud Consoleのダッシュボードが表示されます。残っていなければAWS SSOのサインイン画面が表示されます。
IAMを確認するとAWS SSOのユーザーが登録されていることがわかります。
うまくSAML連携することができました。
考慮点
ユーザーの権限設定
AWS SSOでサインインしたユーザーはIBM Cloudに対して何の権限も持っていませんので、管理者が別途必要な権限を付与するか、アクセスグループの動的ルール機能を使って自動付与することもできます。
しかしこの方法だと、IdPはAWS SSOなのに、App IDでユーザーにカスタム属性を付与することになり、少々面倒です。AWS SSOで属性を設定しそれをIBM Cloudに渡すことができないか、別途調査してみます。
CLIの利用
CLIを利用する場合はユーザー・パスワード方式ではなくSSO方式になります。
$ ibmcloud login -u teruq@lesmiz.jp --sso API エンドポイント: https://cloud.ibm.com リージョン: jp-tok Get a one-time code from https://identity-1.ap-north.iam.cloud.ibm.com/identity/passcode to proceed. デフォルトのブラウザーで URL を開きますか? [Y/n] > y One-time code >このとき表示されるURLは残念ながらIBM IDによるログイン画面になってしまい、AWS SSOユーザーの認証をすることができません。これは次の手順を踏むことで回避できました。
- ブラウザでAWS SSOを使って認証しておく
- CLIのログインコマンド（-sso）を打ち、表示されたURLを同じブラウザのURL欄にコピー＆ペーストして開く
- ワンタイムパスワードが発行される
AWS SSOのログアウト
AWS SSOを使ってログインするとおそらくはCookieが残り、ブラウザを閉じて開きなおしてもログイン状態が維持されます。IBM Cloud ConsoleでログアウトしてもAWS SSOには効果ありません。
AWS SSOをログアウトするためには、次の方法が考えられます。まず、IBM Cloud Consoleが開く直前に下記の画面が数秒間表示されますので、その隙に右上の
Sign outをクリックします。
もう1つの方法は、AWS SSOの
ユーザーポータルを利用します。AWSの設定画面からURLを知ることができます。
このURLにアクセスし、右上の
Sign outをクリックすることでログアウトすることができます。
以上です。
- 投稿日：2021-01-01T03:38:37+09:00
AWS Single Sign-OnでIBM Cloudポータルを認証する
目的
AWS Single Sign-On（以下、AWS SSO）はSAML IdPになることができます。一方、IBM Cloudのポータル、CLI等はIAMのIDプロバイダーとして、IBM IDだけでなくApp IDに対応し、App IDはSAMLのSPになることができます。というわけで、AWS SSOのIdPを使ってIBM Cloudの認証をしてみます。
利点
デフォルトではIBM CloudのポータルにアクセスするためにIBM IDを取得し、アカウントから招待してもらう必要があります。このマルチクラウド時代に、AWSとIBM Cloudでそれぞれユーザー管理をしなければいけないうのは、ユーザー数が増えてきたら管理者にとってはかなりの負担になります。
また、会社のメールアドレスを使ってIBM IDを取得するという行為が特にエンタープライズな環境では抵抗を受けるケースもあります。
AWS SSOのIdPと連携することで、次のようなメリットがあります。
- ユーザーはIBM IDの登録が不要
- AWS IdPのユーザーでIBM CloudにログインするとIBM Cloudにユーザーが自動登録される
- AWS SSOを使ったアプリケーションとIBM Cloud ConsoleやApp IDを使ったアプリケーションでSSOできる
手順
AWS SSOの初期設定
当然AWSのアカウントが必要です。アカウントに管理者でログインしたら
AWS Single Sign-Onサービスを選択します。
初めての場合は
AWS SSOを有効にするをクリックします。
初めての場合は
AWS 組織の作成をクリックします。
3 クラウドアプリケーションへの SSO アクセスの管理を選択します。
新規アプリケーションの追加をクリックします。
カスタム SAML 2.0 アプリケーションの追加を選択します。
表示名と説明に任意の値を入力します。
ここで、
AWS SSO SAML メタデータファイルをダウンロードしますAWS SSO サインイン URLを控えておきますAWS SSO 証明書をダウンロードします画面をそのままにしてApp IDの設定画面を開きます。
App IDの初期設定
App IDのインスタンスを用意しておきます。
わかりやすさのために
SAML 2.0連携以外のIDプロバイダーを無効化し、SAML 2.0連携の編集をクリックします。
プロバイダ名に任意の値を入力し、
SAML メタデータ・ファイルのダウンロードをクックします。これはいわゆるSPメタデータです。
画面右側の値を入力します。
項目 値 エンティティーID 先ほどダウンロードしたAWSのIdPメタデータをテキストエディタで開き、1行目のentityId値を入力 サインインURL 先ほど控えたAWS SSOのサインインURLを入力 1次証明書 先ほどダウンロードしたAWS SSO証明書の中身を入力
保存をクリックします。AWS SSOのSPメタデータ取り込みと属性マッピング
再びAWSに戻り、先ほどダウンロードしたSPメタデータをアップロードし
変更の保存をクリックします。
属性マッピングタブをクリックします。
AWS SSO IdPのアサーションとSP間で属性のマッピングをします。
参考）https://cloud.ibm.com/docs/account?topic=account-idp-integration
最低限下記のマッピングを追加します。
アプリケーションのユーザー属性 この文字列または AWS SSO のユーザー属性にマッピング 形式 意味 Subject ${user:email} emailAddress App IDのユーザープロファイルの識別に使用（必須） familyName ${user:familyName} basic IBM Cloudのユーザープロファイルで名前の表示に使用（姓部分） givenName ${user:givenName} basic IBM Cloudのユーザープロファイルで名前の表示に使用（名部分） name ${user:preferredUsername} basic App IDのユーザープロファイルで名前の表示に使用
入力後、
変更を保存をクリックします。AWS SSOのユーザー追加
AWS SSOを利用できるユーザーを追加します。
ユーザーメニューからユーザーを追加をクリックします。
必要な情報を入力し、
次: グループをクリックします。
グループはSSOには不要なので、
ユーザーを追加をクリックします。
ユーザーが追加されました。
メールアドレス宛にインビテーションメールが送信されますので、メールを開きリンクをクリックします。
パスワードを設定し
新しいパスワードの設定をクリックします。
これでAWS SSO側の作業は完了です。
App IDの接続テスト
SAML 2.0連携画面で
テストをクリックします。
設定がうまくいっていればAWSのサインイン画面が表示されるので、先ほど登録したAWS SSOのユーザー名を入力して
次のをクリックします。
先ほど設定したパスワードを入力し
サインインを選択します。
設定がうまくいっていれば
Good job, It worksと表示されます。
ユーザープロファイルを確認します。初回ログイン時にプロファイルが自動登録されます。
これでApp ID側の作業は完了です。
IBM Cloud ConsoleのIDプロバイダー設定
IAMのIDプロバイダーを設定します。過去記事「App IDのユーザーでIBM Cloudのポータルを利用する」を参照ください。
設定が終わったら、IdP URLをブラウザで開きます。ブラウザにAWS SSOの認証情報が残っていればIBM Cloud Consoleのダッシュボードが表示されます。残っていなければAWS SSOのサインイン画面が表示されます。
IAMを確認するとAWS SSOのユーザーが登録されていることがわかります。
うまくSAML連携することができました。
考慮点
ユーザーの権限設定
AWS SSOでサインインしたユーザーはIBM Cloudに対して何の権限も持っていませんので、管理者が別途必要な権限を付与するか、アクセスグループの動的ルール機能を使って自動付与することもできます。
しかしこの方法だと、IdPはAWS SSOなのに、App IDでユーザーにカスタム属性を付与することになり、少々面倒です。AWS SSOで属性を設定しそれをIBM Cloudに渡すことができないか、別途調査してみます。
CLIの利用
CLIを利用する場合はユーザー・パスワード方式ではなくSSO方式になります。
$ ibmcloud login -u teruq@lesmiz.jp --sso API エンドポイント: https://cloud.ibm.com リージョン: jp-tok Get a one-time code from https://identity-1.ap-north.iam.cloud.ibm.com/identity/passcode to proceed. デフォルトのブラウザーで URL を開きますか? [Y/n] > y One-time code >このとき表示されるURLは残念ながらIBM IDによるログイン画面になってしまい、AWS SSOユーザーの認証をすることができません。これは次の手順を踏むことで回避できました。
- ブラウザでAWS SSOを使って認証しておく
- CLIのログインコマンド（-sso）を打ち、表示されたURLを同じブラウザのURL欄にコピー＆ペーストして開く
- ワンタイムパスワードが発行される
AWS SSOのログアウト
AWS SSOを使ってログインするとおそらくはCookieが残り、ブラウザを閉じて開きなおしてもログイン状態が維持されます。IBM Cloud ConsoleでログアウトしてもAWS SSOには効果ありません。
AWS SSOをログアウトするためには、次の方法が考えられます。まず、IBM Cloud Consoleが開く直前に下記の画面が数秒間表示されますので、その隙に右上の
Sign outをクリックします。
もう1つの方法は、AWS SSOの
ユーザーポータルを利用します。AWSの設定画面からURLを知ることができます。
このURLにアクセスし、右上の
Sign outをクリックすることでログアウトすることができます。
以上です。
- 投稿日：2021-01-01T03:38:37+09:00
AWS Single Sign-OnでAWSマネジメントコンソールとIBM Cloudポータルをシングルサインオンする
目的
AWS Single Sign-On（以下、AWS SSO）はSAML IdPになることができます。一方、IBM Cloudのポータル、CLI等はIAMのIDプロバイダーとして、IBM IDだけでなくApp IDに対応し、App IDはSAMLのSPになることができます。というわけで、AWS SSOのIdPを使ってIBM CloudのポータルやCLIの認証をしてみます。
利点
デフォルトではIBM CloudのポータルにアクセスするためにIBM IDを取得し、アカウントから招待してもらう必要があります。このマルチクラウド時代に、AWSとIBM Cloudでそれぞれユーザー管理をしなければいけないうのは、ユーザー数が増えてきたら管理者にとってはかなりの負担になります。
また、会社のメールアドレスを使ってIBM IDを取得するという行為が特にエンタープライズな環境では抵抗を受けるケースもあります。
AWS SSOのIdPと連携することで、次のようなメリットがあります。
- ユーザーはIBM IDの登録が不要
- AWS IdPのユーザーでIBM CloudにログインするとIBM Cloudにユーザーが自動登録される
- AWS SSOを使ったアプリケーションとIBM Cloud ConsoleやApp IDを使ったアプリケーションでSSOできる
手順
AWS SSOの初期設定
当然AWSのアカウントが必要です。アカウントに管理者でログインしたら
AWS Single Sign-Onサービスを選択します。
初めての場合は
AWS SSOを有効にするをクリックします。
初めての場合は
AWS 組織の作成をクリックします。
3 クラウドアプリケーションへの SSO アクセスの管理を選択します。
新規アプリケーションの追加をクリックします。
カスタム SAML 2.0 アプリケーションの追加を選択します。
表示名と説明に任意の値を入力します。
ここで、
AWS SSO SAML メタデータファイルをダウンロードしますAWS SSO サインイン URLを控えておきますAWS SSO 証明書をダウンロードします画面をそのままにしてApp IDの設定画面を開きます。
App IDの初期設定
App IDのインスタンスを用意しておきます。
わかりやすさのために
SAML 2.0連携以外のIDプロバイダーを無効化し、SAML 2.0連携の編集をクリックします。
プロバイダ名に任意の値を入力し、
SAML メタデータ・ファイルのダウンロードをクリックします。これはいわゆるSPメタデータです。
画面右側の値を入力します。
項目 値 エンティティーID 先ほどダウンロードしたAWSのIdPメタデータをテキストエディタで開き、1行目のentityId値を入力 サインインURL 先ほど控えたAWS SSOのサインインURLを入力 1次証明書 先ほどダウンロードしたAWS SSO証明書の中身を入力
保存をクリックします。AWS SSOのSPメタデータ取り込みと属性マッピング
再びAWSに戻り、先ほどダウンロードしたSPメタデータをアップロードし
変更の保存をクリックします。
属性マッピングタブをクリックします。
AWS SSO IdPのアサーションとSP間で属性のマッピングをします。
参考）https://cloud.ibm.com/docs/account?topic=account-idp-integration
最低限下記のマッピングを追加します。
アプリケーションのユーザー属性 この文字列または AWS SSO のユーザー属性にマッピング 形式 意味 Subject ${user:email} emailAddress App IDのユーザープロファイルの識別に使用（必須） familyName ${user:familyName} basic IBM Cloudのユーザープロファイルで名前の表示に使用（姓部分） givenName ${user:givenName} basic IBM Cloudのユーザープロファイルで名前の表示に使用（名部分） name ${user:preferredUsername} basic App IDのユーザープロファイルで名前の表示に使用
入力後、
変更を保存をクリックします。AWS SSOのユーザー追加
AWS SSOを利用できるユーザーを追加します。
ユーザーメニューからユーザーを追加をクリックします。
必要な情報を入力し、
次: グループをクリックします。
グループはSSOには不要なので、
ユーザーを追加をクリックします。
ユーザーが追加されました。
メールアドレス宛にインビテーションメールが送信されますので、メールを開きリンクをクリックします。
パスワードを設定し
新しいパスワードの設定をクリックします。
AWSマネジメントコンソールのユーザー権限設定
AWS SSOのユーザーでAWSマネジメントコンソールを利用できるようにします。これで、IBM CloudとAWSでポータルのSSOが実現できるようになります。
ダッシュボードで
2 AWSアカウントへの SSO アクセスの管理をクリックします。
初めての場合はアクセス権限セットがないので
アクセス権限多分をクリックしアクセス権限セットを作成をクリックします。
必要に応じてどちらかを選択します。今回は
既存の職務機能ポリシーを使用を選択して次: 詳細をクリックします。
今回はとりあえず
PowerUserAccessを選択し次: タグをクリックします。
今回は何もせず
次: 確認をクリックします。
確認し
作成をクリックします。
アクセス権限セットが作成されました。
AWS組織タブをクリックし、アカウントを選択してユーザーの割り当てをクリックします。
ユーザーを選択して
次: アクセス権限セットをクリックします。
アクセス権限セットを選択し
完了をクリックします。
少し待つと完了します。
AWS SSO側の設定はこれで完了です。
App IDの接続テスト
SAML 2.0連携画面で
テストをクリックします。
設定がうまくいっていればAWSのサインイン画面が表示されるので、先ほど登録したAWS SSOのユーザー名を入力して
次のをクリックします。
先ほど設定したパスワードを入力し
サインインを選択します。
設定がうまくいっていれば
Good job, It worksと表示されます。
ユーザープロファイルを確認します。初回ログイン時にプロファイルが自動登録されます。
これでApp ID側の作業は完了です。
IBM CloudポータルのIDプロバイダー設定
IAMのIDプロバイダーを設定します。過去記事「App IDのユーザーでIBM Cloudのポータルを利用する」を参照ください。ここでApp IDとの連携とSSOログイン用のIdP URLを生成します。
IBM CloudポータルへのSSOログイン
設定が終わったら、IdP URLをブラウザで開きます。ブラウザにAWS SSOの認証情報が残っていればIBM Cloud Consoleのダッシュボードが表示されます。残っていなければAWS SSOのサインイン画面が表示されます。
IBM Cloudのダッシュボードが表示されました。
IAMを確認するとAWS SSOのユーザーが登録されていることがわかります。
うまくSAML連携することができました。
AWSマネジメントコンソールへのSSOログイン
AWS SSOユーザーは通常のマネジメントコンソールへのログイン画面は使いません。かわりにユーザーポータルを使用します。
ユーザーポータルで
AWS Accountを選択し、Management consoleをクリックします。ちなみにIBM Cloud App IDが見えていますがここをクリックしてもエラーになります。なぜなら、IBM Cloudとの連携はSP Initiatedのため、IdPであるAWS SSOからここをクリックしても行先がないからです。
無事、マネジメントコンソールが表示されました。
これで、AWSとIBM Cloud両方にSSOできるようになりました。
考慮点
ユーザーの権限設定
AWS SSOでサインインしたユーザーはIBM Cloudに対して何の権限も持っていませんので、管理者が別途必要な権限を付与するか、アクセスグループの動的ルール機能を使って自動付与することもできます。
しかしこの方法だと、IdPはAWS SSOなのに、App IDでユーザーにカスタム属性を付与することになり、少々面倒です。AWS SSOで属性を設定しそれをIBM Cloudに渡すことができないか、別途調査してみます。
CLIの利用
CLIを利用する場合はユーザー・パスワード方式ではなくSSO方式になります。
$ ibmcloud login -u teruq@******.jp --sso API エンドポイント: https://cloud.ibm.com リージョン: jp-tok Get a one-time code from https://identity-1.ap-north.iam.cloud.ibm.com/identity/passcode to proceed. デフォルトのブラウザーで URL を開きますか? [Y/n] > y One-time code >このとき表示されるURLは残念ながらIBM IDによるログイン画面になってしまい、AWS SSOユーザーの認証をすることができません。これは次の手順を踏むことで回避できました。
- ブラウザでIBM CloudのIdP URLからAWS SSOを使って認証しておく
- CLIのログインコマンド（--sso）を打ち、表示されたURLを同じブラウザのURL欄にコピー＆ペーストして開く
- ワンタイムパスワードが発行される
AWS SSOのログアウト
AWS SSOを使ってログインするとおそらくはCookieが残り、ブラウザを閉じて開きなおしてもログイン状態が維持されます。IBM Cloud ConsoleでログアウトしてもAWS SSOには効果ありません。
AWS SSOをログアウトするためには、次の方法が考えられます。まず、IBM Cloud Consoleが開く直前に下記の画面が数秒間表示されますので、その隙に右上の
Sign outをクリックします。
もう1つの方法は、AWS SSOの
ユーザーポータルを利用します。AWSの設定画面からURLを知ることができます。
このURLにアクセスし、右上の
Sign outをクリックすることでログアウトすることができます。
以上です。
- 投稿日：2021-01-01T01:52:10+09:00
【初心者向け】CircleCIからAWSにデプロイしてみる
はじめに
最近、会社の同期にcircleciを使ったCI/CDのやり方を教える機会があったので、初心者向けのはじめの一歩のための記事として残そうと思います。
やること
今回はcircleciを利用して、terraformでAWS上にLambdaとAPIGatewayをデプロイしたいと思います。
プロジェクトはこちらの記事のものを使いたいと思います。
やることは、以下の4つです。
- tfstateファイルをs3管理にするよう変更
- circleciとgithubの連携
- プロジェクトの設定
- config.ymlファイルでパイプラインの設定
tfstateファイルをs3で管理する
チームでの開発や、circleciなどでterraformで書いたインフラをデプロイする際には、tfstateファイルをどこかプロジェクトとは別の場所に保存しておく必要があります。今回はS3を利用します。AWSコンソールからtfstateファイルを管理するバケットを作成しておいてください。私は
manage-terraform-state-odaとして作成していますので適宜読み替えてください。こちらの記事で作成したプロジェクトに以下のtfファイルを追加します。
terraform.tfterraform { required_version = ">= 0.12.0" backend "s3" { bucket = "manage-terraform-state-oda" region = "ap-northeast-1" key = "serverless-express-app.tfstate" encrypt = true } required_providers { aws = "~> 3.0" } }
backend "s3"のブロック内がtfstateの管理設定の部分です。tfstateファイルを置くS3バケットとリージョン、暗号化の設定、tfstateのファイル名を記載します。keyで指定するファイル名は他のtfstateファイルと被らないようにしておくとよいと思います。
これで、S3でtfstateファイルを管理できるようになりました。circleciとgithubの連携
githubのリポジトリにpushされたら、
terraform applyやterraform planなどの処理が走るようにしたいので、githubとcircleciを連携させます。
1. circleci.comからSign Upを選択
2.Sign Up with GitHubを選択
3. githubのusernameとpasswordを入力してサインインこれでgithubとcircleciの連携が完了しました。
プロジェクトの設定
次にcircleciでプロジェクトのセットアップをします。
ログイン後の画面で左のメニューからprojectsを選択します。連携したgithubアカウントのリポジトリが表示されますので、設定したいリポジトリの行の青いSet Up Projectを押下します。
↓のような画面になります。何も変更せずに青い
Add Configボタンを押下します。セットアップが終わると自動で画面が遷移します。何かしら動き始めるかもしれませんが、今は成功/失敗は気にしなくてOKです。
gitリポジトリを確認してみると、
circleci-project-setupというブランチが自動で生成されています。このブランチでは.circleci/config.ymlというファイルが生成されています。ファイルの中身は↑の画面で設定したyml形式のファイルです。このファイルでテストやデプロイの設定を行いますが、編集は後ほど実施します。
次にcircleciがterraform planやapplyする時にawsのアクセスキーが必要となるので設定しておきます。
Project Settingsからプロジェクトの設定画面にいきます。
Environment VariablesのAdd Environment Variablesから環境変数を追加します。
以下の3つの環境変数を追加します。値は自身のAWSのキーを設定してください。
- AWS_SECRET_ACCESS_KEY
- AWS_ACCESS_KEY_ID
- AWS_DEFAULT_REGION
※環境変数にシークレットキーを設定することについて
ドキュメントに以下のようにあり、仮に第三者がログインできたとしてもキーを盗むことはできないので安心して利用できると思います。設定された後の変数の値は、アプリで読み取ることも編集することもできません。 環境変数の値を変更するには、現在の変数を削除し、新しい値を設定して再度追加します。
config.ymlでパイプラインの設定
続いてパイプラインの設定を実施していきます。先ほどの
.circleci/config.ymlファイルを編集します。config.ymlversion: 2.1 jobs: plan: working_directory: ~/work docker: - image: yushinoda/terraform_npm:latest steps: - checkout - run: name: npm install command: cd lambda && npm install && cd .. - run: name: Init terraform command: terraform init - run: name: Validate terraform command: terraform validate - run: name: Plan terraform command: terraform plan deploy: working_directory: ~/work docker: - image: yushinoda/terraform_npm:latest steps: - checkout - run: name: npm install command: cd lambda && npm install && cd .. - run: name: Init terraform command: terraform init - run: name: Apply terraform command: terraform apply -auto-approve workflows: version: 2.1 plan: jobs: - plan: filters: branches: ignore: release deploy: jobs: - deploy: filters: branches: only: release今回はconfig.ymlのルールについて詳細な説明は省きます。詳しくはリファレンスを参照してください。
今回のconfig.ymlでは、jobs以下でterraform planを確認するplanという名前のjobと、terraform applyするためのdeployという名前のjobを設定し、workflows以下で、releaseブランチにpushされた時にdeployを実行し、それ以外のブランチの時はplanを実行する設定にしています。
jobの実行環境はdockerを選択し、hashicorp/terraformイメージをベースにnpmを追加したイメージを利用してコマンドを実行しています。編集して適当なブランチでコミットしてpushしてください。circleciのDashboardを見ると、planが動き出していると思います。
緑のチェックマークがついていればそのステップは正常に完了しています。続いて、デプロイしてみます。先ほどのブランチをreleaseブランチにpushすると動き出します。プルリクでもOKです。
$ git push origin head:release今度はapplyが動いているのがわかると思います。
aws上にもしっかりapi gatewayとlambdaがデプロイされています。
以降は、
開発 -> commit&push -> plan確認 -> releaseブランチにpush -> deploy
の流れです。必要に応じて、jobsやworkflowsに追加していけば良いと思います。最後に
githubとcircleciを連携して、terraformで書いたプロジェクトをawsにデプロイしてみました。
こんなに簡単にセットアップできるのは嬉しいですね。
github actionsも興味あるので勉強したら書きたいと思います。
- 投稿日：2021-01-01T01:15:35+09:00
AWS Snowballについて
勉強前イメージ
AWSに大容量(数TBくらい)のデータ打ち上げるときに使われるものって感じ。
大きいパソコンみたいなの届いて、それにデータ入れてAWSに送ったらs3？にデータが打ち上がる調査
AWS Snowballとは
AWS Snow Family の中の選択肢の一つで、
物理ストレージデバイスを使用してS3に大量のデータを打ち上げるためのデバイスです。
郵送でSnowballデバイスが送られ、そこにデータを格納して送り返すことで大容量のデータを早く、セキュアに打ち上げることができます。Snowballの種類
Snowball
- 容量を50TB,80TBを選べる
Snowball Edge
- 100TB転送することができる
- 複数ディスクでクラスタリングを組むことができる
- Snowballよりエンドポイントの選択肢が多い
マネジメントコンソールから見てみた
Snowball Edgeしかないけど、Snowballは東京リージョンでは頼めないのかな・・・？
勉強後イメージ
実際には個人ではあまり見ることはないんじゃないかというSnowball。
1回だけ見たことはありましたが、そのときはよくわからず・・・
ただ数TBくらいだったら別のサービスで打ち上げたほうが効率がいいらしい。参考
- 投稿日：2021-01-01T00:18:39+09:00
M5Stack Core2 for AWS
はじめに
昨年M5Stackで FreeRTOSを動かしてみた記事 をQiitaに投稿した後、M5StackでFreeRTOSを動かしてみる人が増えた気がします。AWSのIoT/FreeRTOSワークショップでもM5Stackが使われることもありました。M5Stackは安価に上手にパッケージングされていて、誰でも気軽に使うことができる本当に便利なデバイスです。
そして先日、M5Stack Core2 for AWS - ESP32 IoT開発キット が発売されました。M5Stack BASICはIoTやFreeRTOSの勉強用には便利なものでしたが、メモリが512Kだったり、使いこなすにはちょっと不足を感じる点がありましたが、M5Stack Core2 for AWS - ESP32 IoT開発キット はいくつかの面でパワーアップされています。
初日、M5Stack Core2 for AWS - ESP32 IoT開発キット は30分くらいで売り切れてしまいましたが、幸い購入できましたので簡単にレポートさせて頂きます。
M5Stack Core2 for AWS - ESP32 IoT開発キット
シンプルなパッケージで送られてきました。本体、USB-Cケーブル、レンチが入っています。スイッチを入れるとロゴが表示されて起動音が鳴ります。その後AWS IoT EdukitページのQRコードが表示されて、本体の横に配置されたLEDが点灯します。
出荷時のファームウェアは こちら のようです。
接続には SiLabs CP210x drivers が必要ですが、以前M5Stackを使用していればすでにインストールされています。Tera Termでシリアル接続してみると、次のようなメッセージが表示されます。
ets Jul 29 2019 12:21:46 rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:4 load:0x3fff0034,len:7600 ho 0 tail 12 room 4 load:0x40078000,len:15348 load:0x40080400,len:4888 entry 0x400806a4 I (31) boot: ESP-IDF v4.2-beta1-227-gf0e87c933a 2nd stage bootloader I (31) boot: compile time 10:30:21 I (31) boot: chip revision: 3 I (36) boot_comm: chip revision: 3, min. bootloader chip revision: 0 I (43) qio_mode: Enabling default flash chip QIO I (48) boot.esp32: SPI Speed : 80MHz I (53) boot.esp32: SPI Mode : QIO I (57) boot.esp32: SPI Flash Size : 16MB I (62) boot: Enabling RNG early entropy source... I (67) boot: Partition Table: I (71) boot: ## Label Usage Type ST Offset Length I (78) boot: 0 nvs WiFi data 01 02 00011000 00006000 I (86) boot: 1 phy_init RF data 01 01 00017000 00001000 I (93) boot: 2 factory factory app 00 00 00020000 00100000 I (101) boot: End of partition table I (105) boot_comm: chip revision: 3, min. application chip revision: 0 I (112) esp_image: segment 0: paddr=0x00020020 vaddr=0x3f400020 size=0x5eb6c (387948) map I (255) esp_image: segment 1: paddr=0x0007eb94 vaddr=0x3ffb0000 size=0x01484 ( 5252) load I (258) esp_image: segment 2: paddr=0x00080020 vaddr=0x400d0020 size=0x41e70 (269936) map I (356) esp_image: segment 3: paddr=0x000c1e98 vaddr=0x3ffb1484 size=0x00ff4 ( 4084) load I (357) esp_image: segment 4: paddr=0x000c2e94 vaddr=0x40080000 size=0x00404 ( 1028) load I (363) esp_image: segment 5: paddr=0x000c32a0 vaddr=0x40080404 size=0x11b30 ( 72496) load I (410) boot: Loaded app from partition at offset 0x20000 I (410) boot: Disabling RNG early entropy source... I (411) psram: This chip is ESP32-D0WD I (416) spiram: Found 64MBit SPI RAM device I (420) spiram: SPI RAM mode: flash 80m sram 80m I (425) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (433) cpu_start: Pro cpu up. I (436) cpu_start: Application information: I (441) cpu_start: Project name: core2forAWS-default-firmware I (448) cpu_start: App version: 2b790e5-dirty I (453) cpu_start: Compile time: Nov 17 2020 10:30:15 I (459) cpu_start: ELF file SHA256: cb6c82cca7492871... I (465) cpu_start: ESP-IDF: v4.2-beta1-227-gf0e87c933a I (472) cpu_start: Starting app cpu, entry point is 0x40081dac I (0) cpu_start: App cpu up. I (975) spiram: SPI SRAM memory test OK I (975) heap_init: Initializing. RAM available for dynamic allocation: I (976) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (982) heap_init: At 3FFC7730 len 000188D0 (98 KiB): DRAM I (988) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (994) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1001) heap_init: At 40091F34 len 0000E0CC (56 KiB): IRAM I (1007) cpu_start: Pro cpu start user code I (1012) spiram: Adding pool of 4096K of external SPI memory to heap allocator I (1032) spi_flash: detected chip: generic I (1032) spi_flash: flash io: qio I (1032) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (1045) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations I (1063) atecc608a: Seeding the random number generator... I (1064) atecc608a: ok I (1086) atecc608a: Initializing ATECC608a secure element I (1086) atecc608a: ok I (1086) atecc608a: Checking data zone lock status... I (1108) atecc608a: ok: locked I (1108) atecc608a: Get the device info (type)... I (1126) atecc608a: ok: 60 02 I (1126) core2forAWS: Firmware Version: 1.0.0 I (2740) I2S: DMA Malloc info, datalen=blocksize=256, dma_buf_count=2 I (2740) I2S: PLL_D2: Req RATE: 44100, real rate: 44642.000, BITS: 16, CLKM: 14, BCK: 8, MCLK: 11289966.924, SCLK: 1428544.000000, diva: 64, divb: 11 I (2750) I2S: PLL_D2: Req RATE: 44100, real rate: 44642.000, BITS: 16, CLKM: 14, BCK: 8, MCLK: 11289966.924, SCLK: 1428544.000000, diva: 64, divb: 11 I (2769) main: ************************************** I (2770) main: Device Serial: 0123xxxxxxxxxxxxxx I (2776) main: **************************************ワークショップ
AWSから ワークショップのドキュメント が公開されています。内容は次のようなものです。IoTの自習ができるようになっています。
- Getting Started - 動作確認とWiFiのプロビジョニング
- Blinky Hello World - 開発環境(ESP-IDF)とAWS IoT Coreのセットアップ
- Smart Thermostat - AWS IoT Coreの基礎知識
- Smart Spaces - AWS IoTと機械学習の基礎知識
- Intro to Alexa for IoT - Alexa for IoTデモ
残念ながら、FreeRTOSは登場しません。
Getting Started
起動の確認ができたので、ワークショップのドキュメント を参考に開発環境を準備します。
- SiLabs CP210x drivers
M5StackをPCにシリアル接続するためにドライバーをインストールします。このドライバーはM5Stack BASICなどと同じなので、すでにM5Stackを使用している人は改めてインストールする必要はありません。
- Visual Studio Code + PlatformIO
Visual Studio Codeに加えてさまざまな開発ボートをサポートするPlatformIOを使用します
- ESP RainMaker
スマホからデバイスを設定するためのESP RainMakerをAndroid/iOSのアプリストアからインストールします
- ソースコードのクローン
M5Stack Core2 for AWS IoT EduKit 用に提供されている学習用のソースコードをGitHubからクローンします。
git clone https://github.com/m5stack/Core2-for-AWS-IoT-EduKit.gitWindows PCの場合、PlatformIOのデフォルトのプロジェクトのフォルダー C:\Users<ユーザー>\Documents\PlatformIO\Projects 下だとパス名が長すぎるというエラーでクローンできませんでした。その場合は C:\ の直下にフォルダーを作成するなどしてください。
USBケーブル接続、電源投入
PlatformIOでGetting-Startedプロジェクトを開く
- シリアルポートの調整
platformio.iniに記載されたシリアルポートをPCのOSに合わせて調整します。Windowsであればデフォルトで指定されたupload_portを消すか、; でコメントにします。
platformio.ini; PlatformIO Project Configuration File ; ; Build options: build flags, source filter, extra scripting ; Upload options: custom port, speed and extra flags ; Library options: dependencies, extra library storages ; ; Please visit documentation for the other options and examples ; http://docs.platformio.org/page/projectconf.html [env:core2foraws] platform = espressif32@2.1.0 framework = espidf board = esp32dev ;upload_port = /dev/cu.SLAB_USBtoUART monitor_speed = 115200 board_build.partitions = partitions_4MB_sec.csv board_build.embed_txtfiles = components/esp_rainmaker/server_certs/mqtt_server.crt components/esp_rainmaker/server_certs/claim_service_server.crt components/esp_rainmaker/server_certs/ota_server.crt
- ビルド
PlatformIOでビルドします。
- ファームウェアの書き込み
作成されたファームウェアをM5Stack Core2に書き込みます
MonitorにQRコードが表示されます。スマホにインストールしたRainMakerアプリから、Add Deviceをクリックして、QRコードを読み取ります。
接続できました！
参考
