アイコン探しって、結構大変じゃないですか？ 開発をしていると、アイコンが必要になります。 しかし、たまに 検索するための名前がわからない という問題が起きる... 例えば、メニューに使われる「⋯」のアイコン。 なんて検索すればいいかわからない... なので、 手書き検索 できるようにしました！ 作ったアプリ 手書きアイコン検索アプリ iconow アイコンの名前がわからなくて探せない...という問題を解決するため、手書きで検索できるようにしたアプリです。 みんな大好き FontAwesome と、Web や Flutter のアイコンに採用されている Material Icon を検索できます。 iOS Android 使用した技術 Flutter Firebase Authentication Firestore AWS Lambda ECR API Gateway DynamoDB S3 Serverless Docker TensorFlow フロントエンドについて フロントエンドは Flutter を使っています。 iOS、Android を同時に開発できる Flutter はやはり非常に強力です。 状態管理は Riverpod + freezed + StateNotifier を採用しました。 ユーザー管理周りは Firebase を使っています。 技術的な点では、今回のアプリの肝である手書き部分にこだわりました。 画面をなぞったところを検知し、そのポジションを Riverpod で管理することによって、高速かつ軽量に手書きが実現できます。 また、手書きの基本的な Undo、Redo 機能も実装しています。 詳しい実装方法は以下の記事に書いています。 バックエンドについて 画像を受け取り、それを学習モデルに解析させ結果を送る API を作成しています。 学習モデルが動くコンテナを構築しておき、それを ECR にあげて Lambda で展開し、API Gateway で接続する構成です。 CircleCI と Serverless を用いて GitHub にあげたときに自動展開できるようにしました。 詳しくは以下の記事に書いています。 また、DynamoDB や S3 は学習モデルのログを保存するために使っています。 機械学習について 特に苦労したところ。 基本的に、機械学習は大量のデータを学習させることで汎用性を高め、精度を上げます。 つまり、学習データが少ないと精度が上がらないのです。 しかし、このアプリは製作者が2人しかいないため、大量の手書きデータを用意するのは不可能でした。 というわけで、考え方を変えて精度ではなく汎化性能を重要視しました。 検索結果には推論結果の 1位 から 20位 までくらいを出して、その中からユーザーに判断してもらうという作戦です。 これなら1位をズバッと当てられなくとも、検索アプリとしては成り立ちます！ まずは似ているアイコンの画像をグループ分けし、グループをターゲットとします。 そしてこれらをもとに手書きして、教師データを作成しました。1グループにつき 5～20枚ほど手書きしています。 教師データの画像はぐにゃぐにゃにしたもので 100倍に水増ししておきました。これにより汎化性能が大幅に向上しました。 そして、学習時には「上下/左右移動」「カットアウト」「回転」「ズーム」「スキュー」などの DataAugmentation を使っています。（フリップは矢印などのアイコンに悪影響のため使っていません。また、グレースケールとして処理しているため色の DA は使っていません。） モデルは、ドロップアウトの確率を多めに設定し、畳み込みを広く取ることで、損失率を出来るだけ抑えるネットワークを構築しています。 開発者 バックエンド, 機械学習担当 @GleamingCake Twitter フロントエンド担当 @tigeeer Twitter さいごに 使ってみての感想やご意見、バグ報告などありましたら、ぜひコメント欄にお願いします！

背景 昨今のアドレス共有技術(DS-Lite/MAP-Eなど)に関わる問題として「IP アドレスだけではユーザが特定できなくなること」が指摘されており、通信先のサーバなどでアクセスしてきた送信元ポート番号、正確なタイムスタンプを取ることをRFC6302では推奨しています もちろん、記録されたログが保全（改ざんされていないなど）されることも重要ですね で、本題 どうやるか？ （アドレス共有技術の適用はIPv6とセットにされることが多いので、サーバのIPv6化すればいいのですが、ここではおいておいて） apache httpdの場合 こんなconfigを設定可能です %{remote}p　の部分ですね httpd.conf LogFormat "[%h]:%{remote}p %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "[%h]:%{remote}p %l %u %t \"%r\" %>s %b" common 出力 [xxx.xxx.xxx.xxx]:47716 - - [08/May/2013:10:26:10 +0900] "GET / HTTP/1.1" 200 4658 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727)" AWS ELBの場合 X-Forwarded-Portを使えればいいのですが、これはサーバ側（送信先ポート番号）です なので、ALB/ELBでアクセスログを取得するしかありません。 方法は、ALB/ELBの属性の編集から、アクセスログを有効化します。指定のS3バケットに保存されます。 このログのclient:portに保存されます AWSLogs/xxxxxxxxxxxx/elasticloadbalancing/ap-northeast-1/2021/MM/DD/xxxxxxxxxxxx_elasticloadbalancing_ap-northeast-1_app.ELB01.xxxxxxxxxxxxxxxx_2021MMDDT0000Z_xx.xxx.xx.xx_xxxxxxxx.log.gz http 2021-MM-DDTHH:MM:SS.nnnnnnZ app/ELB01/xxxxxxxxxxxx xx.xx.xx.xx:1614 172.xx.xx.xx:80 0.002 0.003 0.000 200 200 433 4288 "GET http://xxxxxxxxxxxxxxxx:80/hogehoge.txt HTTP/1.1" "Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible)" - - arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxxxx:targetgroup/TG01/xxxxxxxxxxxx "Root=1-xxxxxxxxxxxx "-" "-" 2 2021-MM-DDTHH:MM:SS.nnnnnnZ "forward" "-" "-" "172.xx.xx.xx:80" "200" "-" "-" 詳細は公式ドキュメント　AWS Application Load Balancer のアクセスログ 　をご確認ください

はじめに クラスメソッドさんの8/17(火)リモート開催の AKIBA.AWS ONLINE で「ABAC」という言葉を初めて知りました。是非試してみたい！と思い、色々調べたりして自分なりに扱うことはできました。ということで、この記事では ABAC をやってみる一例を紹介します。 この記事は AWS 初心者が書いており、AWS を不適切なやり方、間違ったやり方で使用している可能性があります。ご指摘等がございましたら、コメント頂けると幸いです。 ABAC とは ABAC は「Attribute Based Access Control」の略称です。 属性ベースのアクセスコントロール (ABAC) は、属性に基づいてアクセス許可を定義する認証戦略です。 引用元：AWS の ABAC とは - AWS Identity and Access Management AKIBA.AWS ONLINE の登壇資料を見るとわかりやすいです。 ゴール 赤チームの鈴木さんは、S3 バケット内の赤チームのオブジェクト（.txt ファイル）をダウンロードでき、青チームのオブジェクトをダウンロードできないようにします。 一方、青チームの田中さんは、青チームのオブジェクトをダウンロードでき、赤チームのオブジェクトをダウンロードできないようにします。 前提条件 AWS アカウントを持っている。 AWS アカウント作成の流れ 作業用の IAM ユーザーを持っている。 AWSの全権限を持つルートユーザーの使用は非推奨です。代わりに IAM ユーザーを作成して使用しましょう。 この記事は AWS 未経験者・初心者向けです。 手順 ABAC ポリシー（ IAM ポリシー）の作成 IAM ユーザーの作成（鈴木さんと田中さん） .txt ファイルの作成（赤チーム用と青チーム用） S3 バケットの作成、オブジェクトのアップロード ABAC できるかテスト 1. ABAC ポリシー（ IAM ポリシー）の作成 初めに、AWS マネジメントコンソールにサインインします。 この記事では [東京リージョン] を選択して、進めていきます。 上部の検索ボックスでIAMと検索して、サービス欄の [IAM] を選択し、IAM コンソールを開きます。 左側のナビゲーションペインで、[ポリシー] を選択します。 [ポリシーを作成] を選択します。 [JSON] タブを選択して、以下の JSON ポリシードキュメントを入力します。 エラー等がないことを確認して、[次のステップ: タグ] を選択します。 前半部分（4～8行目）は 自分（ AWS アカウント）が持つバケットの一覧を表示すること（s3:ListAllMyBuckets）をを許可する（Allow）。 真ん中部分（9～13行目）は 全ての S3 バケット（arn:aws:s3:::*）に対して、オブジェクト等のバケットの中身を表示すること（s3:ListBucket）を許可する（Allow）。 後半部分（14～23行目）は オブジェクトタグのteamキーの値（s3:ExistingObjectTag/team）とリクエストを行うプリンシパルタグのteamキーの値（aws:PrincipalTag/team）が完全一致（StringEquals）する条件で（Condition）、全ての S3 バケット（arn:aws:s3:::*）に対して、オブジェクトを取得すること（s3:GetObject）を許可する（Allow）。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/team": "${aws:PrincipalTag/team}" } } } ] } タグを追加せず、[次のステップ: 確認] を選択します。 [名前] にGetObjectSameTeamと入力します。 [概要] を確認して、 [ポリシーの作成] を選択します。 IAMポリシーGetObjectSameTeamが作成できました。 これで、1. ABAC ポリシー（ IAM ポリシー）の作成は終了です。 2. IAM ユーザーの作成（鈴木さんと田中さん） 前述のとおり、IAM コンソールを開きます。 左側のナビゲーションペインで、[ユーザー] を選択します。 [ユーザーを追加] を選択します。 [ユーザー名] にsuzukiと入力します。 [アクセスの種類] は [AWS マネジメントコンソールへのアクセス] を選択します。 [コンソールのパスワード] は [カスタムパスワード] を選択して、任意のパスワードを入力します。 [パスワードのリセットが必要] は選択しません。（チェックボックスをはずします） [既存のポリシーを直接アタッチ] を選択します。 真ん中の検索ボックスでGetObjectSameTeamと検索して、先ほど作成した IAM ポリシーGetObjectSameTeamを選択します。 [次のステップ: タグ] を選択します。 [キー] にteam、[値 (オプション)] にredと入力します。 [次のステップ: 確認] を選択します。 作成する IAM ユーザーの選択内容を確認して、[ユーザーの作成] を選択します。 IAMユーザーsuzukiの作成が成功したことを確認して、右下の [閉じる] を選択します。 同様に IAMユーザーtanakaを作成します。 [タグの追加(オプション)] では、[キー] にteam、[値 (オプション)] にblueと入力します。 IAMユーザーsuzukiとtanakaが作成できました。 これで、2. IAM ユーザーの作成（鈴木さんと田中さん）は終了です。 3. .txt ファイルの作成（赤チーム用と青チーム用） この記事では、Microsoft Windows に付属するテキストエディタ「メモ帳」を使用して、red-team.txtとblue-team.txtを作成します。 これで、3. .txt ファイルの作成（赤チーム用と青チーム用）は終了です。 4. S3 バケットの作成、オブジェクトのアップロード 前述のとおり、上部の検索ボックスでS3と検索して、S3 コンソールを開きます。 [バケットを作成する] を選択します。 この記事では [バケット名] にteam-bucket-2と入力します。 バケット名は一意である必要があり、世界で同じバケット名を複数作成することはできません。 team-bucket-2以外のバケット名で作成してください。 [AWS リージョン] は [アジアパシフィック (東京) ap-northeast-1] を選択します。 その他の設定はデフォルトのままです。 下にスクロールして、[バケットを作成する] を選択します。 S3 バケットteam-bucket-2が作成できました。 作成したバケットの名前team-bucket-2を選択します。 [アップロード] を選択します。 [ファイルを追加] を選択します。 先ほど作成したred-team.txtを選択します。 [プロパティ] を選択して、[タグの追加] を選択します。 [キー] にteam、[値 (オプション)] にredと入力します。 [アップロード] を選択します。 オブジェクトred-team.txtのアップロードが成功したことを確認して、[閉じる] を選択します。 同様にオブジェクトblue-team.txtをアップロードします。 [タグ - オプション)] では、[キー] にteam、[値 (オプション)] にblueと入力します。 オブジェクトred-team.txtとblue-team.txtがアップロードできました。 これで、4. S3 バケットの作成、オブジェクトのアップロードは終了です。 5. ABAC できるかテスト ナビゲーションバーでアカウント名を選択します。 [サインアウト] を選択します。 IAM ユーザーsuzukiで AWS マネジメントコンソールにサインインします。 前述のとおり、S3 コンソールを開きます。 S3バケットteam-bucket-2を選択します。 オブジェクトred-team.txtを選択します。 [ダウンロード] を選択します。 オブジェクトred-team.txtがダウンロードできました！ 同様にオブジェクトblue-team.txtをダウンロードしてみます。 「AccessDenied」と表示され、アクセス（ダウンロード）できないです。 IAM ユーザーtanakaの場合も、ぜひお試しください。 これで、5. ABAC できるかテストは終了です。 おわりに この記事では ABAC をやってみましたが、これからも色んな AWS サービスや機能に触れて紹介していきたいと思います。

はじめに クラウドの機能って、どのベンダーでも同じような機能があるけど、どれが対応してるんだっけ？って思いました。探してみるとGCPの公式に比較表がありました。 各サービスの比較表 まとめ どれ使えばいいんだっけ、ってなったときに見返そうと思います。公式で出してくれるととても便利です。

はじめに 各クラウドが提供しているAIサービスはたくさんあるな〜と思い調べていたのでまとめました。本記事で扱っているクラウドベンダーは主要クラウドということでシェア率の過半数を占める、AWS、Azure、GCPの３つとなります。 クラウドインフラサービス市場の成長と各社のシェア（出典：Synergy Research Group） 以下の表中の機能概要は参考文献からの引用になります。 AWS サービス名 機能概要 Amazon SageMaker 機械学習モデルを大規模に構築、トレーニング、デプロイする。 Amazon Augmented AI 　ML予測のヒューマンレビューを簡単に導入する。 Amazon CodeGru 最もコストがかかるコード行を見つける。 Amazon Comprehend 　テキストのインサイトや関係性を検出する。 Amazon DevOps Guru ML駆動のクラウドオペレーションサービス。 Amazon Elastic inference 深層学習推論の高速化。 Amazon Forecast 機械学習を使用して予測の制度を向上させる。 Amazon Fraud Detector オンライン詐欺をより素早く検知。 Amazon Healthlake ヘルスデータの解明。 Amazon Kendra MLを利用してエンタープライズ検索を刷新する。 Amazon Lex 　音声やテキストに対応するチャットボットの構築。 Amazon Lookout for Equipment センサーデータの分析による異常動作の検知。 Amazon Lookout for Metrics メトリクスの異常を検知する。 Amazon Lookout for Vision コンピュータビジョンを使用した製品血管の検出。 Amazon Monitron 機器モニタリングのためのエンドツーエンドシステム。 Amazon Personalize アプリケーションへのリアルタイムレコメンデーションの構築。 Amazon Polly テキストを生きた話し声に変換 Amazon Rekognition イメージとビデオを分析。 Amazon SageMaker Data Wrangler MLようにデータを準備するための最も速い方法。 Amazon SageMaker Ground Truth 制度の高い機械学習トレーニングデータセットの構築。 Amazon Textract ドキュメントからテキストやデータを抽出する。 Amazon Translate 自然で流暢な言語翻訳。 Amazon DeepLearning AMI EC２で今すぐ深層学習を始める。 Amazon DeepLearning Containers 深層学習向けDockerイメージ。 Amazon DeepComposer 機械学習が有効化されたミュージカルキーボード。 Amazon DeepLens 深層学習に対応したビデオカメラ。 Amazon DeepRacer 機械学習による１８分の１のスケールでの自律走行型レースカー。 Amazon Inferentia 機械学習インファレンスチップ。 Amazon Panorama エッジに設置したコンピュータビジョンによる運営改善。 AmazonでのPyTorch 柔軟なオープンソースの機械学習フレームワーク。 AmazonでのApache MXNet スケーラブルでパフォーマンスに優れた深層学習。 AmazonでのTensorFlow オープンソースのMachine Intelligence Library。 Azure サービス名 機能概要 Anomaly Detector 異常検出機能をアプリに簡単に追加する。 Azure Bot Service 顧客向けの会話型 AI エクスペリエンスを構築する。 Azure Cognitive Serach モバイルおよび Web アプリ開発のための AI を活用したクラウド検索サービス。 Azure Databricks 迅速、簡単で協調型の Apache Spark ベースの分析プラットフォーム。 Azure Machine Learning 実験とモデル管理ができる、エンド ツー エンドのスケーラブルで信頼性の高いプラットフォームで、すべてのユーザーが AI を使えるようにする。 Azure Open Datasets 機械学習モデルの開発を加速させる選別されたオープン データセットをホストして共有するためのクラウド プラットフォーム。 Azure Cognitive Services 高品質の AI モデルを API としてデプロイする。 Azure Video Analyzer ビデオ分析ソリューションを迅速に構築するための AI サービス。 Computer Vision 画像から意思決定に役立つ情報を抽出する。 Content Moderator 画像、テキスト、ビデオを自動モデレート する。 Custom Vision 貴社の最先端のコンピューター ビジョン モデルを、独自の用途向けに簡単にカスタマイズできる。 Data Science Virtual Machines AI 開発のためにあらかじめ構成されたリッチな環境。 Face API 写真に含まれる顔の検出、識別、分析、グループ化、タグ付けする。 Azure Form Recognizer フォームを解釈し、ドキュメントを抽出できる AI サービス。 Azure Immersive Reader あらゆる年齢や能力のユーザーがテキストを読み理解できるようにサポートする。 Kinect DK 高度な AI センサーと開発者キットを使用して、コンピューターによる視覚と音声のモデルを作成する。 Language Understanding ユーザーが入力したコマンドをアプリが理解できるようにする。 Microsoft Genomics ゲノム シーケンシングと研究の分析情報を強化する。 Personalizer パーソナライズされたユーザー エクスペリエンスを提供する AI サービス。 Project Bonsai シミュレーションを使用したインテリジェントな産業用制御システムを作成するための機械教示サービス。 QnA Maker 情報から会話形式のナビゲーションしやすい回答を抽出する。 Speaker Recognition 話者を認証して識別する Speech サービス機能。 Speech to Text 読み上げられたオーディオをテキストに正確に変換する音声サービス機能。 Speech Translation リアルタイムの音声翻訳をアプリに簡単に統合する。 Text Analytics センチメントとトピックを簡単に評価して、ユーザーが求めるものを理解する。 Text to Speech テキストをリアルな音声に変換する音声サービス機能。 Translator シンプルな REST API 呼び出しで機械翻訳を簡単に実行する。 Azure Metrics Advisor メトリクスを監視して問題を診断する AI サービス。 Health Bot 仮想医療アシスタントの開発向けに構築されたマネージド サービス。 Azure Percept シリコンからサービスまでのエッジ インテリジェンスを加速する。 Azure Applied AI Services よくあるシナリオを解決するために AI を適用する際、組織が価値を生み出すまでの時間を短縮することを可能にする専門サービス。 GCP サービス名 機能概要 Vertex AI MLモデルをトレーニング、ホスト、管理するための統合プラットフォーム。 Deep Learning VM Image ディープラーニングアプリケーション向けに事前構成されたVM。 NoteBooks プロジェクトをたった数分で立ち上げて稼働できるエンタープライズノートブックサービス。 Deep Learning Containers ディープラーニング環境向けに最適化された構成済みコンテナ。 Vertex Data Labeling 高品質なモデルトレーニングデータのマネージドアノテーション。 TensorFlow Enterprise エンタープライズグレードのサポートとマネージド・サービスによりAIアプリの信頼性とパフォーマンスを向上。 AI Building Block カスタムモデルや事前トレーニング済みのモデルを使用して、アプリケーションにAIを簡単に搭載する。 AutoML カスタム機械学習モデルのトレーニングと開発。 Vision AI 感情やテキストなどを検出するためのカスタムモデルと事前トレーニング済みモデル。 Video AI 機械学習を使用した動画分類と認識。 Cloud Natural Language 非構造化テキストの感情分析と分類。 Cloud Translation 言語の検出、翻訳、用語集のサポート。 Media Translation 動的な音声翻訳をコンテンツとアプリケーションに直接追加。 Text-to-Speech 220以上の音声と40以上の言語で音声を合成。 Speech-to-Text 125言語に対応した音声認識と音声文字変換。 Dialogflow 仮想エージェント向けの会話アプリケーションとシステム開発スイート。 AutoML Tables 構造化データでMLモデルをトレーニングするサービス。 Cloud Inference API 型付き時系列データセットの大規模な相関分析を迅速に実行する。 Recommendations AI 極めて個人に特化したおすすめ商品情報を幅広く提供する。 AI Infrastructure 費用対効果の高い方法でディープラーニングモデルと機械学習モデルをトレーニングするための、あらゆるビジネス向けのオプション。 Cloud GPU 機械学習、科学技術計算、3D描画処理に特化したGPU。 Cloud TPU 機械学習アプリケーション用のTensor Processing Unit。 Dataprep 分析と機械学習に使用するデータを準備するためのサービス。 Healthcare Natural Language AI 非構造化医療テキストからのリアルタイム分析情報。 Edge TPU ML推論とAIをエッジで実行するたえのASIC。 Google Workspace Google AIが組み込まれたセキュアでクラウドネイティブのコラボレーションアプリや生産性向上アプリを１つにまとめた統合スイート。 まとめ GCPはAIに強みがあるとよく言われていますが、どのベンダーでも同じような機能のサービスがあるので、同じようなことができそうですね。AWSしか使ったことがないのですが、実際にそれぞれを使用して比較すると違いがわかるのでしょうか。またAIの知識がなくてもすぐに使い始められるサービスが思った以上に多く、「AIの民主化」が進んでいる印象を受けました。 Qiita内の参考記事 クラウドベンダーごとの対応表やAI以外の機能のサービスについてはこちらが詳しいです。 出典

はじめに EKS AnywhereをvSphere上で実行してみました。ついでにGitOpsして、EKS ConnectorでAWSマネジメントコンソールに登録してみました。 Amazon EKS Anywhereとは AWS環境以外でEKSを実行するためのKubernetesディストリビューション。詳しくはこの辺を。 Amazon EKS Anywhere Amazon EKS Anywhere – Now Generally Available to Create and Manage Kubernetes Clusters on Premises EKS Anywhere Documentation 準備 最新のeks cliのダウンロード curl "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" \ --silent --location \ | tar xz -C /tmp sudo mv /tmp/eksctl /usr/local/bin/ バージョン確認 $ eksctl version 0.66.0 anywhereサブコマンドは使えるのか？プラグインが必要 $ eksctl anywhere "eksctl-anywhere" plugin was not found on your path eks anywhereを利用するためのプラグインのインストール export EKSA_RELEASE="0.5.0" OS="$(uname -s | tr A-Z a-z)" curl "https://anywhere-assets.eks.amazonaws.com/releases/eks-a/1/artifacts/eks-a/v${EKSA_RELEASE}/${OS}/eksctl-anywhere-v${EKSA_RELEASE}-${OS}-amd64.tar.gz" \ --silent --location \ | tar xz ./eksctl-anywhere sudo mv ./eksctl-anywhere /usr/local/bin/ anywhereサブコマンドが利用できるようになったことを確認 $ eksctl anywhere Use eksctl anywhere to build your own self-managing cluster on your hardware with the best of Amazon EKS Usage: anywhere [command] Available Commands: create Create resources delete Delete resources generate Generate resources help Help about any command upgrade Upgrade resources version Get the eksctl anywhere version Flags: -h, --help help for anywhere -v, --verbosity int Set the log level verbosity Use "anywhere [command] --help" for more information about a command. eksを作成するためのマニフェストテンプレートの作成 クラスター名を指定してeksctl anywhere generate clusterconfigを実行するとクラスターの構成情報を記述するためのコンフィグファイル(マニフェスト)が生成される。 CLUSTER_NAME=prod eksctl anywhere generate clusterconfig $CLUSTER_NAME \ --provider vsphere > eksa-cluster.yaml コンフィグファイル(eksa-cluster.yaml)は以下のリソースを定義する。kind: VSphereMachineConfigが3つあるが、それぞれコントロールプレーン(Master)、ノード、etcdを構成するためのものになっている。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: Cluster -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereDatacenterConfig -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod-cp -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod-etcd コンフィグファイルの編集 Cluster .spec.controlPlaneConfiguration.endpoint.hostとしてKubernetes APIのIPアドレスを指定する。このIPアドレスはノードがDHCPで取得するIPアドレスと同じCIDRで、DHCPのレンジ外のものを固定IPアドレスとして指定する。 spec: controlPlaneConfiguration: endpoint: host: "192.168.201.100" GitOpsを利用する場合は、specに以下を追加する。(※GitOpsConfigを別途定義する必要がある) spec: gitOpsRef: kind: GitOpsConfig name: eksacl VSphereDatacenterConfig EKS Anywhereクラスターを作成するvSphereクラスターの情報を定義する。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereDatacenterConfig metadata: name: prod spec: datacenter: "Tanzu-DC" insecure: true network: "/Tanzu-DC/Network/eks" server: "tanzu-vc.example.com" thumbprint: "" VSphereMachineConfig cp, worker, etcdそれぞれに対してdatastore、resourcePool、sshAuthorizedKeysを指定する。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod spec: datastore: "vsanDatastore" diskGiB: 25 folder: "" memoryMiB: 8192 numCPUs: 2 osFamily: bottlerocket resourcePool: "/Tanzu-DC/host/Tanzu-Cluster/Resources/eks" users: - name: ec2-user sshAuthorizedKeys: - ssh-rsa AAAA... 現在EKS Anywhereで利用可能なOSイメージはbottlerocketとubuntuを利用可能であるため、osFamiliyとしてどちらかを指定する。ubuntuのOVAが8.54GBであるのに対し、bottolerocketは1.27GBと非常に小さいため、クラスター構築時間を大きく短縮できる。 GitOps GitOpsを有効化する場合は、GitOpsConfigを追加する。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: GitOpsConfig metadata: name: eksacl spec: flux: github: branch: main clusterConfigPath: clusters/eksacl fluxSystemNamespace: flux-system owner: masanara personal: true repository: eksagitops クラスター作成時にGitHubにリポジトリを作成するため、repoに対してアクセスを許可するPersonal Access Tokenを生成してEKSA_GITHUB_TOKEN環境変数として構成する。 export EKSA_GITHUB_TOKEN=ghp_MyValidPersonalAccessTokenWithRepoPermissions GitOpsを有効化したクラスターを削除する際も、EKSA_GITHUB_TOKEN環境変数が求められる。 $ eksctl anywhere delete cluster eksacl Error: failed to delete cluster: failed to set up git ooptions: error Git provider: github access token environment variable EKSA_GITHUB_TOKEN is invalid; could not get var from environment vSphere環境の準備 EKSAクラスターを構成する仮想マシンはAWSが配布するOVAテンプレートを利用する。OVAテンプレートはコンテンツライブラリに登録された後、仮想マシンインベントリのTemplatesフォルダに仮想マシンテンプレートとして配置されるが、Templatesフォルダは自動的に生成されないため、あらかじめ用意しておく必要がある。 $ wget https://github.com/vmware/govmomi/releases/download/v0.26.1/govc_Linux_x86_64.tar.gz $ tar zxvf govc_Linux_x86_64.tar.gz govc $ mv govc /usr/local/bin $ export GOVC_URL='tanzu-vc.example.com' $ export GOVC_USERNAME='administrator@vsphere.local' $ export GOVC_PASSWORD='VMware1!' $ govc folder.create /Tanzu-DC/vm/Templates $ govc folder.info /Tanzu-DC/vm/Templates Name: Templates Path: /Tanzu-DC/vm/Templates Types: Folder,VirtualMachine,VirtualApp Children: 0 クラスターの作成 vSphereクレデンシャルを環境変数として設定する export EKSA_VSPHERE_USERNAME='administrator@vsphere.local' export EKSA_VSPHERE_PASSWORD='VMware1!' 作成したマニフェストを利用して、クラスターの作成を実行する。GitOpsを有効にした場合、クラスター作成時にEKSA_GITHUB_TOKEN環境変数が設定されていない場合、エラーとなる。 $ eksctl anywhere create cluster -f eksa-cluster.yaml Checking Github Access Token permissions ✅ Github personal access token has the required repo permissions Performing setup and validations Warning: VSphereDatacenterConfig configured in insecure mode VSphereMachineConfig folder for control plane is not set or is empty. Will default to root vSphere folder. VSphereMachineConfig folder for worker nodes is not set or is empty. Will default to root vSphere folder. VSphereMachineConfig folder for etcd machines is not set or is empty. Will default to root vSphere folder. ✅ Connected to server ✅ Authenticated to vSphere ✅ Datacenter validated ✅ Network validated ✅ Datastore validated ✅ Resource pool validated ✅ Datastore validated ✅ Resource pool validated ✅ Datastore validated ✅ Resource pool validated Creating template. This might take a while. ✅ Control plane and Workload templates validated ✅ Vsphere Provider setup is valid ✅ Flux path Creating new bootstrap cluster Installing cluster-api providers on bootstrap cluster Provider specific setup Creating new workload cluster Installing networking on workload cluster Installing storage class on workload cluster Installing cluster-api providers on workload cluster Moving cluster management from bootstrap to workload cluster Installing EKS-A custom components (CRD and controller) on workload cluster Creating EKS-A CRDs instances on workload cluster Installing AddonManager and GitOps Toolkit on workload cluster Adding cluster configuration files to Git Enumerating objects: 76, done. Counting objects: 100% (76/76), done. Compressing objects: 100% (39/39), done. Total 76 (delta 11), reused 71 (delta 6), pack-reused 0 Finalized commit and committed to local repository {"hash": "8094dc2f18b850bfc6954dbfc5c5d20edf7c67c8"} Writing cluster config file Deleting bootstrap cluster ? Cluster created! クラスター作成中に指定したリポジトリに、クラスターの構成が記述されたマニフェストファイルがclusters/クラスター名/eksa-system配下に作成される。 vSphere上には以下の仮想マシンが作成される。 GitOpsの利用 GitOpsを有効化してクラスターを構成すると、flux-systemネームスペースが作成され、Fluxが利用可能な状態でクラスターが作成される。 $ kubectl get pod -n flux-system NAME READY STATUS RESTARTS AGE helm-controller-6d875c9745-rkz9g 1/1 Running 0 5h48m kustomize-controller-74c85f9944-lhvlk 1/1 Running 0 112m notification-controller-7c59756d9d-wlz2v 1/1 Running 0 5h48m source-controller-65dcfdf7f7-c8dpr 1/1 Running 0 5h48m github上のマニフェストファイルを編集してGitOpsの動きを確認してみる。 クラスターの構成変更 デフォルトEKS Anywhereのマニフェストファイルの構成では2台のワーカーで構成されている。 $ kubectl get node NAME STATUS ROLES AGE VERSION 192.168.201.150 Ready control-plane,master 5h37m v1.21.3 192.168.201.152 Ready control-plane,master 5h33m v1.21.3 192.168.201.38 Ready <none> 5h35m v1.21.3 192.168.201.76 Ready <none> 5h35m v1.21.3 eksa-systems配下のeksa-cluster.yamlファイルのワーカーノード数(.spec.workerNodeGroupConfigurations.count)を修正・コミットし、暫く待つ仮想マシンが追加され、EKSクラスターのワーカーノードが増える。 $ kubectl get node NAME STATUS ROLES AGE VERSION 192.168.201.150 Ready control-plane,master 5h57m v1.21.3 192.168.201.152 Ready control-plane,master 5h53m v1.21.3 192.168.201.157 Ready <none> 36s v1.21.3 192.168.201.38 Ready <none> 5h55m v1.21.3 192.168.201.76 Ready <none> 5h55m v1.21.3 192.168.201.79 Ready <none> 33s v1.21.3 リソースの作成 github上に作成されたクラスターディレクトリ内にマニフェストを作成して、githubにpushするとクラスター上のfluxが変更を検出してマニフェストの内容をクラスターに反映させる。 クラスターディレクトリ内にtestディレクトリを作成してマニフェスト(nginx.yaml)を置く。 . └── clusters └── eksacl ├── eksa-system │   ├── eksa-cluster.yaml │   └── kustomization.yaml ├── flux-system │   ├── gotk-components.yaml │   ├── gotk-patches.yaml │   ├── gotk-sync.yaml │   └── kustomization.yaml └── test └── nginx.yaml nginx.yamlは以下の通り apiVersion: v1 kind: Namespace metadata: name: test --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx namespace: test spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:alpine name: nginx --- apiVersion: v1 kind: Service metadata: name: nginx namespace: test spec: selector: app: nginx ports: - port: 80 targetPort: 80 しばらくするとクラスターにはネームスペースが作成されて、マニフェストの内容が反映される。 $ kubectl get ns test NAME STATUS AGE test Active 113s $ kubectl get deploy,pod,svc -n test NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx 3/3 3 3 115s NAME READY STATUS RESTARTS AGE pod/nginx-cf4d5b4c8-2tghp 1/1 Running 0 115s pod/nginx-cf4d5b4c8-8cx2n 1/1 Running 0 115s pod/nginx-cf4d5b4c8-f2csm 1/1 Running 0 115s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nginx ClusterIP 10.99.191.46 <none> 80/TCP 115s helmによるリソースの作成 fluxはhelmチャートを利用したリソースの作成も可能。helmを利用する場合は、HelmRepositoryとHelmReleaseを定義する。 apiVersion: v1 kind: Namespace metadata: name: podinfo --- apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: HelmRepository metadata: name: podinfo namespace: podinfo spec: interval: 1m url: https://stefanprodan.github.io/podinfo --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: podinfo namespace: podinfo spec: interval: 5m chart: spec: chart: podinfo version: ">=5.0.0" sourceRef: kind: HelmRepository name: podinfo namespace: podinfo interval: 1m values: replicaCount: 3 作成したネームスペースにHelmRepositoryとHelmReleaseが作成されており、helm listで追加されたパッケージを確認することが可能。 $ kubectl get ns podinfo NAME STATUS AGE podinfo Active 85s $ kubectl get helmrepository -n podinfo NAME URL READY STATUS AGE podinfo https://stefanprodan.github.io/podinfo True Fetched revision: 8411f23d07d3701f0e96e7d9e503b7936d7e1d56 95s $ kubectl get helmrelease -n podinfo NAME READY STATUS AGE podinfo True Release reconciliation succeeded 104s $ kubens podinfo ✔ Active namespace is "podinfo" $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION podinfo podinfo 1 2021-09-13 09:51:04.350035442 +0000 UTC deployed podinfo-6.0.0 6.0.0 $ kubectl get deploy,pod,svc NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/podinfo 5/5 5 5 2m5s NAME READY STATUS RESTARTS AGE pod/podinfo-5c6c96c87b-5rfnq 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-m648v 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-ngxx4 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-pbwz4 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-ssgsr 1/1 Running 0 2m5s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/podinfo ClusterIP 10.96.150.177 <none> 9898/TCP,9999/TCP 2m5s EKS Connectorの利用 プレビューリリースとして提供されているEKS Connectorを利用するとAWSマネジメントコンソールにクラスターを登録することが可能。(ドキュメント:Amazon EKS Connector) Amzon EKS Connector Roleの作成 aws cliを利用してEKS Connectorに必要になるRole/Polciyを作成する。 aws iam create-service-linked-role --aws-service-name eks-connector.amazonaws.com Amazon EKS Connector Agent IAM Roleの作成 以下の内容でポリシーファイルを作成 eks-connector-agent-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Sid": "SSMAccess", "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } eks-connector-agent-policy.json { "Version": "2012-10-17", "Statement": [ { "Sid": "SsmControlChannel", "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel" ], "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "ssmDataplaneOperations", "Effect": "Allow", "Action": [ "ssmmessages:CreateDataChannel", "ssmmessages:OpenDataChannel", "ssmmessages:OpenControlChannel" ], "Resource": "*" } ] } 作成したjsonファイルを利用してEKSConnectorAgentRole/AmazonEKSConnectorAgentPolicyを作成する。 eks-anywhere aws iam create-role \ --role-name AmazonEKSConnectorAgentRole \ --assume-role-policy-document file://eks-connector-agent-trust-policy.json eks-anywhere aws iam put-role-policy \ --role-name AmazonEKSConnectorAgentRole \ --policy-name AmazonEKSConnectorAgentPolicy \ --policy-document file://eks-connector-agent-policy.json クラスターの登録 EKS Connectorを利用してオンプレミスのEKSクラスターをマネジメントコンソールに登録するためには、コンソール側でクラスターを登録し、生成されたマニフェストをクラスターに適用し、EKS Connectorコンポーネントをクラスター上で実行する必要がある。 AWSにマネジメントコンソールの「Elastic Kubernetres Service」を開き、「クラスター」を選択し、「クラスターを追加」メニューから「登録」を選択する。 登録するクラスターの名前、プロバイダーを指定し、接続設定として作成したEKSコネクタロール(AmazonEKSConnectorAgentRole)を選択し、「クラスターを登録」を実行する。 登録したクラスターに対して適用するマニフェストをダウンロードする。 ダウンロードしたyamlファイルにより、クラスターにeks-connectorを作成する。作成に成功すると、eks-connectorネームスペースにeks-connector-0/eks-connector-1 Podが作成される。 $ kubectl apply -f eks-connector.yaml namespace/eks-connector created secret/eks-connector-activation-config created role.rbac.authorization.k8s.io/eks-connector-secret-access created serviceaccount/eks-connector created secret/eks-connector-token created rolebinding.rbac.authorization.k8s.io/eks-connector-secret-access created configmap/eks-connector-agent created statefulset.apps/eks-connector created $ kubectl get pod -n eks-connector NAME READY STATUS RESTARTS AGE eks-connector-0 2/2 Running 0 46s eks-connector-1 2/2 Running 0 24s ここまでの手順でEKSクラスター自体は「アクティブ」な状態となる。 AWSマネジメントコンソールにアクセスするユーザーが、EKS Connectorを介してKubernetesクラスターにアクセスできるようClusterRole/ClusterRoleBindingを設定する。eks-connector-clusterrole.yaml と、eks-connector-console-dashboard-full-access-group.yamlを利用してClusterRole/ClusterRoleBinding/RBAC Authorizationを設定する。各マニフェスト内の%IAM_ARN%をIAMユーザーのARNに置き換えて適用する。 $ kubectl apply -f eks-connector-clusterrole.yaml clusterrolebinding.rbac.authorization.k8s.io/eks-connector-service created clusterrole.rbac.authorization.k8s.io/eks-connector-service created $ kubectl apply -f eks-connector-console-dashboard-full-access-group.yaml clusterrole.rbac.authorization.k8s.io/eks-connector-console-dashboard-full-access-clusterrole created clusterrolebinding.rbac.authorization.k8s.io/eks-connector-console-dashboard-full-access-clusterrole-binding created 上記のClusterRole/ClusterRoleBinding/RBAC Authorizationの設定が正しく完了していない場合、クラスター内部のリソースを表示することができない。 ClusterRole/ClusterRoleBinding/RBAC Authorizationを構成することで、クラスターを構成するノードはPod等の情報をマネジメントコンソールから確認することが可能になる。

はじめに EKS AnywhereをvSphere上で実行してみました。ついでにGitOpsして、EKS ConnectorでAWSマネジメントコンソールに登録してみました。 Amazon EKS Anywhereとは AWS環境以外でEKSを実行するためのKubernetesディストリビューション。詳しくはこの辺を。 Amazon EKS Anywhere Amazon EKS Anywhere – Now Generally Available to Create and Manage Kubernetes Clusters on Premises EKS Anywhere Documentation 準備 最新のeks cliのダウンロード curl "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" \ --silent --location \ | tar xz -C /tmp sudo mv /tmp/eksctl /usr/local/bin/ バージョン確認 $ eksctl version 0.66.0 anywehreサブコマンドは使えるのか？プラグインが必要 $ eksctl anywhere "eksctl-anywhere" plugin was not found on your path eks anywhereを利用するためのプラグインのインストール export EKSA_RELEASE="0.5.0" OS="$(uname -s | tr A-Z a-z)" curl "https://anywhere-assets.eks.amazonaws.com/releases/eks-a/1/artifacts/eks-a/v${EKSA_RELEASE}/${OS}/eksctl-anywhere-v${EKSA_RELEASE}-${OS}-amd64.tar.gz" \ --silent --location \ | tar xz ./eksctl-anywhere sudo mv ./eksctl-anywhere /usr/local/bin/ anywhereサブコマンドが利用できるようになったことを確認 $ eksctl anywhere Use eksctl anywhere to build your own self-managing cluster on your hardware with the best of Amazon EKS Usage: anywhere [command] Available Commands: create Create resources delete Delete resources generate Generate resources help Help about any command upgrade Upgrade resources version Get the eksctl anywhere version Flags: -h, --help help for anywhere -v, --verbosity int Set the log level verbosity Use "anywhere [command] --help" for more information about a command. eksを作成するためのマニフェストテンプレートの作成 クラスター名を指定してeksctl anywhere generate clusterconfigを実行するとクラスターの構成情報を記述するためのコンフィグファイル(マニフェスト)が生成される。 CLUSTER_NAME=prod eksctl anywhere generate clusterconfig $CLUSTER_NAME \ --provider vsphere > eksa-cluster.yaml コンフィグファイル(eksa-cluster.yaml)は以下のリソースを定義する。kind: VSphereMachineConfigが3つあるが、それぞれコントロールプレーン(Master)、ノード、etcdを構成するためのものになっている。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: Cluster -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereDatacenterConfig -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod-cp -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod -- apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod-etcd コンフィグファイルの編集 Cluster .spec.controlPlaneConfiguration.endpoint.hostとしてKubernetes APIのIPアドレスを指定する。このIPアドレスはノードがDHCPで取得するIPアドレスと同じCIDRで、DHCPのレンジ外のものを固定IPアドレスとして指定する。 spec: controlPlaneConfiguration: endpoint: host: "192.168.201.100" GitOpsを利用する場合は、specに以下を追加する。(※GitOpsConfigを別途定義する必要がある) spec: gitOpsRef: kind: GitOpsConfig name: eksacl VSphereDatacenterConfig EKS Anywhereクラスターを作成するvSphereクラスターの情報を定義する。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereDatacenterConfig metadata: name: prod spec: datacenter: "Tanzu-DC" insecure: true network: "/Tanzu-DC/Network/eks" server: "tanzu-vc.example.com" thumbprint: "" VSphereMachineConfig cp, worker, etcdそれぞれに対してdatastore、resourcePool、sshAuthorizedKeysを指定する。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: VSphereMachineConfig metadata: name: prod spec: datastore: "vsanDatastore" diskGiB: 25 folder: "" memoryMiB: 8192 numCPUs: 2 osFamily: bottlerocket resourcePool: "/Tanzu-DC/host/Tanzu-Cluster/Resources/eks" users: - name: ec2-user sshAuthorizedKeys: - ssh-rsa AAAA... 現在EKS Anywhereで利用可能なOSイメージはbottlerocketとubuntuを利用可能であるため、osFamiliyとしてどちらかを指定する。ubuntuのOVAが8.54GBであるのに対し、bottolerocketは1.27GBと非常に小さいため、クラスター構築時間を大きく短縮できる。 GitOps GitOpsを有効化する場合は、GitOpsConfigを追加する。 apiVersion: anywhere.eks.amazonaws.com/v1alpha1 kind: GitOpsConfig metadata: name: eksacl spec: flux: github: branch: main clusterConfigPath: clusters/eksacl fluxSystemNamespace: flux-system owner: masanara personal: true repository: eksagitops クラスター作成時にGitHubにリポジトリを作成するため、repoに対してアクセスを許可するPersonal Access Tokenを生成してEKSA_GITHUB_TOKEN環境変数として構成する。 export EKSA_GITHUB_TOKEN=ghp_MyValidPersonalAccessTokenWithRepoPermissions GitOpsを有効化したクラスターを削除する際も、EKSA_GITHUB_TOKEN環境変数が求められる。 $ eksctl anywhere delete cluster eksacl Error: failed to delete cluster: failed to set up git ooptions: error Git provider: github access token environment variable EKSA_GITHUB_TOKEN is invalid; could not get var from environment vSphere環境の準備 EKSAクラスターを構成する仮想マシンはAWSが配布するOVAテンプレートを利用する。OVAテンプレートはコンテンツライブラリに登録された後、仮想マシンインベントリのTemplatesフォルダに仮想マシンテンプレートとして配置されるが、Templatesフォルダは自動的に生成されないため、あらかじめ用意しておく必要がある。 $ wget https://github.com/vmware/govmomi/releases/download/v0.26.1/govc_Linux_x86_64.tar.gz $ tar zxvf govc_Linux_x86_64.tar.gz govc $ mv govc /usr/local/bin $ export GOVC_URL='tanzu-vc.example.com' $ export GOVC_USERNAME='administrator@vsphere.local' $ export GOVC_PASSWORD='VMware1!' $ govc folder.create /Tanzu-DC/vm/Templates $ govc folder.info /Tanzu-DC/vm/Templates Name: Templates Path: /Tanzu-DC/vm/Templates Types: Folder,VirtualMachine,VirtualApp Children: 0 クラスターの作成 vSphereクレデンシャルを環境変数として設定する export EKSA_VSPHERE_USERNAME='administrator@vsphere.local' export EKSA_VSPHERE_PASSWORD='VMware1!' 作成したマニフェストを利用して、クラスターの作成を実行する。GitOpsを有効にした場合、クラスター作成時にEKSA_GITHUB_TOKEN環境変数が設定されていない場合、エラーとなる。 $ eksctl anywhere create cluster -f eksa-cluster.yaml Checking Github Access Token permissions ✅ Github personal access token has the required repo permissions Performing setup and validations Warning: VSphereDatacenterConfig configured in insecure mode VSphereMachineConfig folder for control plane is not set or is empty. Will default to root vSphere folder. VSphereMachineConfig folder for worker nodes is not set or is empty. Will default to root vSphere folder. VSphereMachineConfig folder for etcd machines is not set or is empty. Will default to root vSphere folder. ✅ Connected to server ✅ Authenticated to vSphere ✅ Datacenter validated ✅ Network validated ✅ Datastore validated ✅ Resource pool validated ✅ Datastore validated ✅ Resource pool validated ✅ Datastore validated ✅ Resource pool validated Creating template. This might take a while. ✅ Control plane and Workload templates validated ✅ Vsphere Provider setup is valid ✅ Flux path Creating new bootstrap cluster Installing cluster-api providers on bootstrap cluster Provider specific setup Creating new workload cluster Installing networking on workload cluster Installing storage class on workload cluster Installing cluster-api providers on workload cluster Moving cluster management from bootstrap to workload cluster Installing EKS-A custom components (CRD and controller) on workload cluster Creating EKS-A CRDs instances on workload cluster Installing AddonManager and GitOps Toolkit on workload cluster Adding cluster configuration files to Git Enumerating objects: 76, done. Counting objects: 100% (76/76), done. Compressing objects: 100% (39/39), done. Total 76 (delta 11), reused 71 (delta 6), pack-reused 0 Finalized commit and committed to local repository {"hash": "8094dc2f18b850bfc6954dbfc5c5d20edf7c67c8"} Writing cluster config file Deleting bootstrap cluster ? Cluster created! クラスター作成中に指定したリポジトリに、クラスターの構成が記述されたマニフェストファイルがclusters/クラスター名/eksa-system配下に作成される。 vSphere上には以下の仮想マシンが作成される。 GitOpsの利用 GitOpsを有効化してクラスターを構成すると、flux-systemネームスペースが作成され、Fluxが利用可能な状態でクラスターが作成される。 $ kubectl get pod -n flux-system NAME READY STATUS RESTARTS AGE helm-controller-6d875c9745-rkz9g 1/1 Running 0 5h48m kustomize-controller-74c85f9944-lhvlk 1/1 Running 0 112m notification-controller-7c59756d9d-wlz2v 1/1 Running 0 5h48m source-controller-65dcfdf7f7-c8dpr 1/1 Running 0 5h48m github上のマニフェストファイルを編集してGitOpsの動きを確認してみる。 クラスターの構成変更 デフォルトEKS Anywhereのマニフェストファイルの構成では2台のワーカーで構成されている。 $ kubectl get node NAME STATUS ROLES AGE VERSION 192.168.201.150 Ready control-plane,master 5h37m v1.21.3 192.168.201.152 Ready control-plane,master 5h33m v1.21.3 192.168.201.38 Ready <none> 5h35m v1.21.3 192.168.201.76 Ready <none> 5h35m v1.21.3 eksa-systems配下のeksa-cluster.yamlファイルのワーカーノード数(.spec.workerNodeGroupConfigurations.count)を修正・コミットし、暫く待つ仮想マシンが追加され、EKSクラスターのワーカーノードが増える。 $ kubectl get node NAME STATUS ROLES AGE VERSION 192.168.201.150 Ready control-plane,master 5h57m v1.21.3 192.168.201.152 Ready control-plane,master 5h53m v1.21.3 192.168.201.157 Ready <none> 36s v1.21.3 192.168.201.38 Ready <none> 5h55m v1.21.3 192.168.201.76 Ready <none> 5h55m v1.21.3 192.168.201.79 Ready <none> 33s v1.21.3 リソースの作成 github上に作成されたクラスターディレクトリ内にマニフェストを作成して、githubにpushするとクラスター上のfluxが変更を検出してマニフェストの内容をクラスターに反映させる。 クラスターディレクトリ内にtestディレクトリを作成してマニフェスト(nginx.yaml)を置く。 . └── clusters └── eksacl ├── eksa-system │   ├── eksa-cluster.yaml │   └── kustomization.yaml ├── flux-system │   ├── gotk-components.yaml │   ├── gotk-patches.yaml │   ├── gotk-sync.yaml │   └── kustomization.yaml └── test └── nginx.yaml nginx.yamlは以下の通り apiVersion: v1 kind: Namespace metadata: name: test --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx namespace: test spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:alpine name: nginx --- apiVersion: v1 kind: Service metadata: name: nginx namespace: test spec: selector: app: nginx ports: - port: 80 targetPort: 80 しばらくするとクラスターにはネームスペースが作成されて、マニフェストの内容が反映される。 $ kubectl get ns test NAME STATUS AGE test Active 113s $ kubectl get deploy,pod,svc -n test NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx 3/3 3 3 115s NAME READY STATUS RESTARTS AGE pod/nginx-cf4d5b4c8-2tghp 1/1 Running 0 115s pod/nginx-cf4d5b4c8-8cx2n 1/1 Running 0 115s pod/nginx-cf4d5b4c8-f2csm 1/1 Running 0 115s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nginx ClusterIP 10.99.191.46 <none> 80/TCP 115s helmによるリソースの作成 fluxはhelmチャートを利用したリソースの作成も可能。helmを利用する場合は、HelmRepositoryとHelmReleaseを定義する。 apiVersion: v1 kind: Namespace metadata: name: podinfo --- apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: HelmRepository metadata: name: podinfo namespace: podinfo spec: interval: 1m url: https://stefanprodan.github.io/podinfo --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: podinfo namespace: podinfo spec: interval: 5m chart: spec: chart: podinfo version: ">=5.0.0" sourceRef: kind: HelmRepository name: podinfo namespace: podinfo interval: 1m values: replicaCount: 3 作成したネームスペースにHelmRepositoryとHelmReleaseが作成されており、helm listで追加されたパッケージを確認することが可能。 $ kubectl get ns podinfo NAME STATUS AGE podinfo Active 85s $ kubectl get helmrepository -n podinfo NAME URL READY STATUS AGE podinfo https://stefanprodan.github.io/podinfo True Fetched revision: 8411f23d07d3701f0e96e7d9e503b7936d7e1d56 95s $ kubectl get helmrelease -n podinfo NAME READY STATUS AGE podinfo True Release reconciliation succeeded 104s $ kubens podinfo ✔ Active namespace is "podinfo" $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION podinfo podinfo 1 2021-09-13 09:51:04.350035442 +0000 UTC deployed podinfo-6.0.0 6.0.0 $ kubectl get deploy,pod,svc NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/podinfo 5/5 5 5 2m5s NAME READY STATUS RESTARTS AGE pod/podinfo-5c6c96c87b-5rfnq 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-m648v 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-ngxx4 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-pbwz4 1/1 Running 0 2m5s pod/podinfo-5c6c96c87b-ssgsr 1/1 Running 0 2m5s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/podinfo ClusterIP 10.96.150.177 <none> 9898/TCP,9999/TCP 2m5s EKS Connectorの利用 プレビューリリースとして提供されているEKS Connectorを利用するとAWSマネジメントコンソールにクラスターを登録することが可能。(ドキュメント:Amazon EKS Connector) Amzon EKS Connector Roleの作成 aws cliを利用してEKS Connectorに必要になるRole/Polciyを作成する。 aws iam create-service-linked-role --aws-service-name eks-connector.amazonaws.com Amazon EKS Connector Agent IAM Roleの作成 以下の内容でポリシーファイルを作成 eks-connector-agent-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Sid": "SSMAccess", "Effect": "Allow", "Principal": { "Service": [ "ssm.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } eks-connector-agent-policy.json { "Version": "2012-10-17", "Statement": [ { "Sid": "SsmControlChannel", "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel" ], "Resource": "arn:aws:eks:*:*:cluster/*" }, { "Sid": "ssmDataplaneOperations", "Effect": "Allow", "Action": [ "ssmmessages:CreateDataChannel", "ssmmessages:OpenDataChannel", "ssmmessages:OpenControlChannel" ], "Resource": "*" } ] } 作成したjsonファイルを利用してEKSConnectorAgentRole/AmazonEKSConnectorAgentPolicyを作成する。 eks-anywhere aws iam create-role \ --role-name AmazonEKSConnectorAgentRole \ --assume-role-policy-document file://eks-connector-agent-trust-policy.json eks-anywhere aws iam put-role-policy \ --role-name AmazonEKSConnectorAgentRole \ --policy-name AmazonEKSConnectorAgentPolicy \ --policy-document file://eks-connector-agent-policy.json クラスターの登録 EKS Connectorを利用してオンプレミスのEKSクラスターをマネジメントコンソールに登録するためには、コンソール側でクラスターを登録し、生成されたマニフェストをクラスターに適用し、EKS Connectorコンポーネントをクラスター上で実行する必要がある。 AWSにマネジメントコンソールの「Elastic Kubernetres Service」を開き、「クラスター」を選択し、「クラスターを追加」メニューから「登録」を選択する。 登録するクラスターの名前、プロバイダーを指定し、接続設定として作成したEKSコネクタロール(AmazonEKSConnectorAgentRole)を選択し、「クラスターを登録」を実行する。 登録したクラスターに対して適用するマニフェストをダウンロードする。 ダウンロードしたyamlファイルにより、クラスターにeks-connectorを作成する。作成に成功すると、eks-connectorネームスペースにeks-connector-0/eks-connector-1 Podが作成される。 $ kubectl apply -f eks-connector.yaml namespace/eks-connector created secret/eks-connector-activation-config created role.rbac.authorization.k8s.io/eks-connector-secret-access created serviceaccount/eks-connector created secret/eks-connector-token created rolebinding.rbac.authorization.k8s.io/eks-connector-secret-access created configmap/eks-connector-agent created statefulset.apps/eks-connector created $ kubectl get pod -n eks-connector NAME READY STATUS RESTARTS AGE eks-connector-0 2/2 Running 0 46s eks-connector-1 2/2 Running 0 24s ここまでの手順でEKSクラスター自体は「アクティブ」な状態となる。 AWSマネジメントコンソールにアクセスするユーザーが、EKS Connectorを介してKubernetesクラスターにアクセスできるようClusterRole/ClusterRoleBindingを設定する。eks-connector-clusterrole.yaml と、eks-connector-console-dashboard-full-access-group.yamlを利用してClusterRole/ClusterRoleBinding/RBAC Authorizationを設定する。各マニフェスト内の%IAM_ARN%をIAMユーザーのARNに置き換えて適用する。 $ kubectl apply -f eks-connector-clusterrole.yaml clusterrolebinding.rbac.authorization.k8s.io/eks-connector-service created clusterrole.rbac.authorization.k8s.io/eks-connector-service created $ kubectl apply -f eks-connector-console-dashboard-full-access-group.yaml clusterrole.rbac.authorization.k8s.io/eks-connector-console-dashboard-full-access-clusterrole created clusterrolebinding.rbac.authorization.k8s.io/eks-connector-console-dashboard-full-access-clusterrole-binding created 上記のClusterRole/ClusterRoleBinding/RBAC Authorizationの設定が正しく完了していない場合、クラスター内部のリソースを表示することができない。 ClusterRole/ClusterRoleBinding/RBAC Authorizationを構成することで、クラスターを構成するノードはPod等の情報をマネジメントコンソールから確認することが可能になる。

AWS IAMでポリシーを指定する際の、ActionやResourceといった指定について。 たとえば、以下はEC2のドキュメントの例。 { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeTags", "ec2:DescribeSnapshots" ], "Resource": "*" } ] } こういったところに、なにが書けるかがよくわからなくなるので。 一覧は、こちらを見ると良いようです。 ポリシーの概念は、こちら。 よく探し方を忘れるので、メモ。

SystemsManagerChangeCalendarとは SystemsManagerの機能の一つで、カレンダー内の特定の日付・時間に「イベント」を挿入することで、そのイベント間のアクションの実行を制御を行える機能です。 例えば、「毎日定時にSystems Manager Automation ランブックからEC2インスタンスを停止させているが、この日だけは停止させたくない」といった場合に、対象日にイベントを設定しておくことでインスタンスを停止させないということができます。 更にEventBridgeとも連携できるため、柔軟にイベントの管理が行えます。 以下公式ドキュメントです。 AWS Systems Manager の一機能である Change Calendar では、指定したアクション (Systems Manager Automation ランブックなど) が AWS アカウント で実行できるまたはできない日付と時刻の範囲を設定できます。Change Calendar では、このような範囲はイベントと呼ばれます。Change Calendar エントリを作成すると、ChangeCalendar タイプの Systems Manager のドキュメントが作成されます。 使ってみる 実際に使ってみます。 以下の構成のようなイメージで作成します。 Systems Manager Automation ランブックの設定 まず、ChangeCalendarで実行管理するサンプルのメンテナンスウィンドウを作成します。 実行するタスクは「AWS-RestartEC2Instance」、実行時間は15分毎としています。 しばらく放置して正しく実行されていることを確認します。 カレンダーの作成 次にカレンダーを作成します。 最近の発表でカレンダーをインポートして作成することができるというアップデートがありましたので、こちらを利用します。 適当なイベントをGoogleカレンダーに入れ、エクスポートします。 ※後にインポートしてわかったのですが、Googleカレンダーの設定が日本標準時だとうまくインポートできません。なので、Googleカレンダーの設定を協定世界時に直してからエクスポートしてください。 ↓日本標準時で15:30~16:30のイベントを入れたカレンダーをインポートすると以下のように表示されます。 その後、マネージドコンソールのインポートから先ほどエクスポートした.ics形式のカレンダーをインポートします。 カレンダータイプはそれぞれ デフォルトで開く：イベントがある場合、タスクを実行しない。 デフォルトで閉じる：イベントがある場合のみタスクを実行する。 となります。 作成すると以下のようにカレンダーが表示されます。 タスクにカレンダーの状態確認ステップを追加 タスクのステップにカレンダーの状態を確認するステップを挟みます。 「ドキュメント」から「AWS-RestartEC2Instance」を選択し、クローンの作成を押下します。 次にドキュメントエディタから以下のように編集し「オートメーションを作成する」を押します。 ※AccountID,CalendarNameは置換して下さい。 Copy-AWS-RestartEC2Instance Copy-AWS-RestartEC2Instance { "description": "Restart EC2 instances(s)", "schemaVersion": "0.3", "assumeRole": "{{ AutomationAssumeRole }}", "parameters": { "InstanceId": { "type": "StringList", "description": "(Required) EC2 Instance(s) to restart" }, "AutomationAssumeRole": { "type": "String", "description": "(Optional) The ARN of the role that allows Automation to perform the actions on your behalf.", "default": "" } }, "mainSteps": [ { "name": "checkChangeCalendarOpen", "action": "aws:assertAwsResourceProperty", "inputs": { "Service": "ssm", "Api": "GetCalendarState", "CalendarNames": [ "arn:aws:ssm:ap-northeast-1:<AccountID:document/<CalendarName>" ], "PropertySelector": "$.State", "DesiredValues": [ "OPEN" ] }, "nextStep": "stopInstances" }, { "name": "stopInstances", "action": "aws:changeInstanceState", "inputs": { "InstanceIds": "{{ InstanceId }}", "DesiredState": "stopped" } }, { "name": "startInstances", "action": "aws:changeInstanceState", "inputs": { "InstanceIds": "{{ InstanceId }}", "DesiredState": "running" } } ] } 参考： 作成が完了したら「メンテナンスウィンドウ」からドキュメント「AWS-RestartEC2Instance」を「Copy-AWS-RestartEC2Instance」に変更します。 実行確認 イベントが予定されている時間のみ、実行が行われていないか確認します。 対象時間の実行履歴を見てみると... ChangeCalendarから「OPEN」が返ってきていない為、失敗となっています！ イベントの時間が過ぎると、成功に戻りました。 まとめ ChangeCalendarでssmAutomationランブックの実行制御を行えることを確認しました。これにより、Cronなどで表現しきれない急なイベントが発生しても、カレンダーにイベントを入れるだけで実行の調整が行えます。 今回はCalendarからOPENが返ってこない場合はエラーという単純な制御でしたが、作りこみ次第でよりいい感じにできると思います。 機会があれば試してみたいです。

全体の流れ VPC内でインスタンスを作成しインターネットからアクセスできるようにする(手順は割愛。インターネットゲートウェイとかで調べたら出てくると思います) springbootプロジェクトをインスタンスに入れる(ない場合はInitialierなどで適当に作る。参考1、参考2) DockerFileを作ってimageをbuildする 作ったimageを元にコンテナを起動 publicipアドレスからアクセス可能に DockerFileを作る FROM openjdk:11-jre-slim WORKDIR /app COPY ./build/libs/${jarname}.jar . ENTRYPOINT ["java", "-jar", "${jarname}.jar"] imageビルド $ docker build --build-arg JAR_FILE=build/libs/\*.jar -t ${username}/${repos} . コンテナ実行 $ docker run -p 8080:8080 ${username}/${repos} springbootアプリケーションが起動する $ docker run -p 8080:8080 name/repos . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v2.5.4)

発生していた現象 AWS Elastic Beanstalk からアプリケーションを作成しようとすると「The instance profile aws-elasticbeanstalk-ec2-role associated with the environment does not exist.」のというエラーメッセージが表示されてしまい環境構築に必ず失敗してしまう 強い権限があるはずのルートユーザで実行しても上記と同様のエラーで起動できなくなってしまっている aws-elasticbeanstalk-ec2-role ロールはIAMロールに定義されている 原因 AWS ElasticBeanstalkの初回のアプリケーション作成時にIAMロール（aws-elasticbeanstalk-ec2-role および aws-elasticbeanstalk-service-role）の自動作成を行うが、作成時のユーザの権限によって中途半端な状態でIAMロールが作成されてしまう場合がある。 一度IAMロールが作成されてしまうと、以降のElastic Beanstalkのアプリケーション作成時にそのIAMロールが使用されてしまうため、ルートユーザなど強い権限のユーザでもアプリケーション作成を行うことができない状態になってしまうと考えられる。 回避方法 1. IAMロールを操作できる権限のユーザで以下を実施 aws-elasticbeanstalk-ec2-role ロールの削除 aws-elasticbeanstalk-service-role ロールの削除 2. ElasticBeanstalkでアプリケーション作成を行うユーザにIAMロールの作成権限を付与 https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-iam-roles-create-permissions.html に記載されている権限を付与する 3. ElasticBeanstalkでアプリケーション作成を行う 2.のユーザでElasticBeanstalkのアプリケーション作成を実施する 初回起動時に 1.で記載した2つのIAMロールが自動生成される

ec2インスタンスを作成 ec2インスタンスを作り、SpringBootアプリケーションをbuildしておく。 ここでは略。 nginxファイルを作成する /etc/nginx/conf.dの下に.confファイルを作成。なかったらnginxをインストールする springboot.conf server { listen 80; server_name _; location / { proxy_pass http://localhost:8080; } } リバースプロキシの設定完了 nginxを再起動する sudo systemctl restart nginx.service SpringbootApplicationをビルドしたjarファイルを実行する java -jar ${repos}/build/libs/${project}.jar アプリケーション起動 . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v2.5.4) パブリックIPアドレスでインターネットからアクセスが可能になる。

はじめに ローカル環境を汚さずに手軽にTerraformとAWS CLIを利用したい... 本記事では、TerraformとAWS CLIの公式Dockerイメージを用いて、Dockerコンテナ上でAWS環境用のTerraformとAWS CLIを実行する方法をご紹介します。 Terraformとは、AWSなどの様々なクラウドサービスの環境を、Terraform用の設定ファイルを元に自動的に構築するツールです。AWSのWeb上のコンソール画面から環境を作成するのではなく、Terraform用の設定ファイルから環境を作成、変更、削除することができ大変便利です。 AWS CLIとは、AWSの操作をコマンドライン上から行えるツールです。 前提条件 AWSアカウントを持っている Dockerがインストールされている Windowsの場合: Docker Desktop for Windows Macの場合: Docker Desktop for Mac TerraformとAWS CLIの環境構築 ファイル構成 下記の構成でファイルを作成します。 /docker-compose.yml version: '3' services: terraform: image: hashicorp/terraform:1.0.6 env_file: - ./.aws/aws.env volumes: - ./terraform:/terraform working_dir: /terraform entrypoint: sh tty: true aws-cli: image: amazon/aws-cli:2.2.36 env_file: - ./.aws/aws.env volumes: - ./aws-cli:/aws-cli working_dir: /aws-cli entrypoint: sh tty: true /.gitignore .terraform *.tfstate *.tfstate.* aws.env /.aws/aws.env.default AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_REGION=ap-northeast-1 AWS_DEFAULT_REGION=ap-northeast-1 /terraform/test/main.tf # プロバイダ provider "aws" { region = "ap-northeast-1" } # VPC resource "aws_vpc" "test-vpc" { cidr_block = "10.1.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "test-vpc" } } IAMのアクセスキーとシークレットアクセスキーを設定 自分のAWSアカウントにログインし、下記のページからIAMのアクセスキーとシークレットアクセスキーを作成します。 AWSのIAMアクセスキーの作成画面 下記の環境変数ファイルをコピーして、IAMのアクセスキーとシークレットアクセスキーを設定します。 コピー元: /.aws/aws.env.default コピー先: /.aws/aws.env /.aws/aws.env の追記例: AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXX 不正アクセスの原因になるため、/.aws/aws.env はGit等にプッシュしないようご注意ください。 /.gitignore で/.aws/aws.envをGit対象外にしています。 Terraformを実行 下記のコマンドを実行してTerraformを実行します。 今回はサンプルとしてtest-vpcの名前でVPCを作成します。 実行対象ファイル: /terraform/test/main.tf > docker-compose up -d > docker-compose exec terraform sh # cd /terraform/test/ # terraform init (Terraformの初期化を行う。初回に1回だけ実行) # terraform plan (AWSの変更内容を確認します。まだAWSには反映されません) # terraform apply (実際にAWS上にtest-vpcのVPCを作成します。 「Enter a value:」と表示されるので「yes」を入力します) # terraform destroy (AWS上のtest-vpcのVPCを削除します。 「Enter a value:」と表示されるので「yes」を入力します) # exit > docker-compose down (もうDockerコンテナを利用しない場合) AWS CLIを実行 下記のコマンドを実行してAWS CLIを実行します。 今回はサンプルとしてEC2のリージョン一覧を表示します。 > docker-compose up -d > docker-compose exec aws-cli sh # aws ec2 describe-regions (EC2のリージョン一覧を表示。エラーになる場合は /.aws/aws.env の内容が間違っている。q を入力すると終了) # exit > docker-compose down (もうDockerコンテナを利用しない場合) まとめ Dockerコンテナ上でTerraformとAWS CLIを使うことにより、ローカル環境を汚さずに手軽にTerraformとAWS CLIを利用することができました。 このファイル構成でgit等でソース管理することにより、新しいプロジェクトメンバーが増えた際に、Gitのクローンとdocker-compose up -dの実行だけで、プロジェクト全体で同じバージョンのTerraformとAWS CLIのローカル環境を素早く作成することができます。

AWS S3のCSVにWatson Studioからアクセスします。 あらかじめS3にはバケットs3testwsとユーザーs3testwsuserを作っておきます。 参考：AWS S3の特定bucketにCLIやAPIでアクセスする設定 - Qiita Watson Studioからは「接続」オブジェクトでバケットへの接続情報を定義し、「接続データ」オブジェクトでバケット内のCSVを定義するとアクセスできるようになります。 1. 接続オブジェクトの作成 「プロジェクトに追加」で「接続」を選びます。 接続タイプにAmazon S3を選びます。 接続の作成で詳細を入力します。 名前: 任意ですが、ここではバケット名を指定しています。 バケット: s3testws エンドポイントURL：以下からリージョンにあったURLを探します。 https://docs.aws.amazon.com/ja_jp/general/latest/gr/s3.html リージョンがap-northeast-1の場合は、https://s3.ap-northeast-1.amazonaws.comです。 リージョン:ap-northeast-1 アクセスキー：s3testwsuserのアクセスキーIDを指定します。 秘密鍵：s3testwsuserのシークレットアクセスキー指定します。 2.接続データの設定 「プロジェクトに追加」で「接続データ」を選びます。 「ソースの選択」をクリックします。 「接続」からs3testwsを選び、test.csvを選び、「選択」ボタンをクリックします。 名前test.csvを付けて、作成をクリックします。 データ資産にtest.csvが登録されたのでクリックして中身を確認します。 中身を確認できました。

AWSの環境構築をTerraformで行う際に、環境依存やバージョン管理を考慮する必要があります。 その管理を簡略化するため、Dockerを用いて環境をコンテナ化します。 また、コンテナ内のTerraformでECRの操作を行うため、DooD(Docker outsude of Docker)という仕組みでコンテナ内からDockerの機能が利用できるようにします。 ターゲット TerraforomまたはAWS CLI環境をコンテナ化したい Dockerコンテナ内でDockerを使いたい Terraformを使う方法 TerraformをDockerコンテナで使用する方法として公式イメージを使用します。 バージョンを固定したい方は、latestを置き換えてください。 Dockerfile FROM hashicorp/terraform:latest HashiCorp公式のDocker Hubを参照することで、golang:alpineイメージにセットアップする方法も分かります。 AWS CLIを使う方法 AWS CLIを使用するには、glibcのインストールも必要です。 バージョンはENV GLIBC_VER=で指定してください。(例として2021/9/9時点で最新の2.34-r0を指定します。) 今回はAlpine Linuxにインストールする想定で作成しています。また、AWS CLIはv2をインストールします。 Dockerfile FROM golang:alpine # install glibc ENV GLIBC_VER=2.34-r0 RUN apk --no-cache add binutils curl && \ curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk && \ apk add --no-cache glibc-${GLIBC_VER}.apk glibc-bin-${GLIBC_VER}.apk # install awscliv2 RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && \ unzip -q awscliv2.zip && \ aws/install DooDをするための方法 DooDはDocker outside of Dockerの略です。 ホストのDockerソケット/var/run/docker.sockをマウントすることで、Dockerコンテナ内からもDockerの機能を使用できるようにすることです。 注意としては、ホストと同じDockerデーモンを使用するためイメージなども共有されます。 Alpine Linuxなど、Dockerコマンドがない場合はインストールが必要です。 Dockerfile FROM golang:alpine # install Docker CLI RUN apk update && \ apk add --no-cache docker-cli && \ apk add --no-cache docker-compose Dockerfileを使用してコンテナを起動する際は、以下のように-vオプションでソケットをマウントします。 docker run -it -v /var/run/docker.sock:/var/run/docker.sock <IMAGE_ID> /bin/ash おすすめの方法は、docker-compose.ymlを作成してvolumesで予め記述することです。 docker-compose.yml version: '3' services: dood: container_name: dood-container build: . volumes: - /var/run/docker.sock:/var/run/docker.sock entrypoint: ash tty: true docker-compose build --no-cache docker-compose up -d docker-compose exec dood /bin/ash Terraform+AWS CLI+DooDをする これまで説明した内容をふまえて、Terraform,AWS CLI,Dockerコマンドが使用できるDockerfileを作成します。 Dockerfile FROM hashicorp/terraform:latest # install Docker CLI RUN apk update && \ apk add --no-cache docker-cli && \ apk add --no-cache docker-compose # install glibc ENV GLIBC_VER=2.34-r0 RUN apk --no-cache add binutils curl && \ curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk && \ apk add --no-cache glibc-${GLIBC_VER}.apk glibc-bin-${GLIBC_VER}.apk # install awscliv2 RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && \ unzip -q awscliv2.zip && \ aws/install docker-compose.ymlで作成したDcokerfileのフォルダパスを指定します。(例では同じ階層にある想定です。) また、DooDのためにvolumesで/var/run/docker.sockをマウントします。 docker-compose.yml version: '3' services: terraform: container_name: terraform-container build: . volumes: - /var/run/docker.sock:/var/run/docker.sock entrypoint: ash tty: true コンテナを立ち上げてみましょう。 docker-compose build --no-cache docker-compose up -d docker-compose exec terraform /bin/ash execで中に入れたら、各ツールが使えるか確かめましょう。 例としてバージョンを確認してみます。 Terraformバージョン確認 terraform -v Terraform v1.0.6 Dockerバージョン確認 docker -v Docker version 20.10.7, build f0df35096d5f5e6b559b42c7fde6c65a2909f7c5 AWSCLIバージョン確認 aws --version aws-cli/2.2.36 Python/3.8.8 Linux/5.10.16.3-microsoft-standard-WSL2 exe/x86_64.alpine.3 prompt/off さいごに Alpine Linuxコンテナをベースに、TerraformやAWS CLIを使用する方法を説明しました。 DooDを組み合わせることで、TerraformでAWSのコンテナ関連サービスを利用する際に役立つのではないかと思いますので、ぜひ利用して頂ければ幸いです。 参考 DooD(Docker outside of Docker)でボリュームマウント DockerでTerraformを使う Alpine ベースのコンテナイメージで AWS CLI v2 を使う

やったこと - ip制限(sam) - api keyの設定(sam) - route53でドメインの設定 - api gatewayでlambdaとドメインを紐づける 今回紹介する項目 - api keyの設定(sam) 前提 AWS::Serverless::Functionでlambdaを作成済みであること。 参考：https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-resource-function.html 作成したlambdaにapi key設定を行なっていきます。 api keyの設定(sam) samで以下のコードでlambdaを作成しているものとします。 template.yml ApiGatewayRestApi: Type: AWS::Serverless::Api Properties: StageName: Prod ApiLambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: ApiLambdaFunction VpcConfig: 略 CodeUri: ./ Handler: lambda.handler Runtime: nodejs12.x Events: AnyPath: Type: Api Properties: Path: /{proxy+} Method: ANY 必要なことは以下の4点です。 - AWS::Serverless::FunctionにRestApiIdを入れる - AWS::ApiGateway::ApiKeyの追加 - AWS::ApiGateway::UsagePlanの追加 - AWS::ApiGateway::UsagePlanKeyの追加 AWS::Serverless::FunctionにRestApiIdを入れる RestApiId: !Ref ApiGatewayRestApi 結果こうなります。 template.yml ApiGatewayRestApi: Type: AWS::Serverless::Api Properties: StageName: Prod ApiLambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: ApiLambdaFunction VpcConfig: 略 CodeUri: ./ Handler: lambda.handler Runtime: nodejs12.x Events: AnyPath: Type: Api Properties: Path: /{proxy+} Method: ANY RestApiId: !Ref ApiGatewayRestApi AWS::ApiGateway::ApiKeyの追加 以下を追加します。 ApiKey: Type: AWS::ApiGateway::ApiKey Properties: Enabled: true Name: !Sub 'api-key' StageKeys: - RestApiId: !Ref ApiGatewayRestApi StageName: Prod 参考：https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-apikey.html AWS::ApiGateway::UsagePlanの追加 以下を追加します。 ApiUsagePlan: Type: AWS::ApiGateway::UsagePlan DependsOn: - ApiKey Properties: ApiStages: - ApiId: !Ref ApiGatewayRestApi Stage: Prod Throttle: BurstLimit: 200 RateLimit: 100 UsagePlanName: !Sub 'api-plan' これはapiのリクエスト制限をつけることができます。 設定した閾値を超えると、429 Too Many Requests エラーレスポンスを返します。 参考:https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-usageplan.html https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-request-throttling.html AWS::ApiGateway::UsagePlanKeyの追加 以下を追加します。 ApiUsagePlanKey: Type: AWS::ApiGateway::UsagePlanKey DependsOn: - ApiUsagePlan - ApiLambdaFunction Properties : KeyId: !Ref ApiKey KeyType: API_KEY UsagePlanId: !Ref ApiUsagePlan これでapi key と usage planを紐づけます。 参考：https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-usageplankey.html 結果 template.yml ApiGatewayRestApi: Type: AWS::Serverless::Api Properties: StageName: Prod ApiLambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: ApiLambdaFunction VpcConfig: 略 CodeUri: ./ Handler: lambda.handler Runtime: nodejs12.x Events: AnyPath: Type: Api Properties: Path: /{proxy+} Method: ANY ApiKey: Type: AWS::ApiGateway::ApiKey DependsOn: - ApiLambdaLogGroupSubscription Properties: Enabled: true Name: !Sub 'api-key' StageKeys: - RestApiId: !Ref ApiGatewayRestApi StageName: Prod ApiUsagePlan: Type: AWS::ApiGateway::UsagePlan DependsOn: - ApiKey Properties: ApiStages: - ApiId: !Ref ApiGatewayRestApi Stage: Prod Throttle: BurstLimit: 200 RateLimit: 100 UsagePlanName: !Sub 'api-plan' ApiUsagePlanKey: Type: AWS::ApiGateway::UsagePlanKey DependsOn: - ApiUsagePlan - ApiLambdaFunction Properties : KeyId: !Ref ApiKey KeyType: API_KEY UsagePlanId: !Ref ApiUsagePlan これでapi keyの設定は以上です。 sam deployするとコンソール上で確認できます。 注意 apiを叩くときのヘッダーは X-API-Keyになります。 これは変更できない仕様のようです。

やったこと - ip制限(sam) - api keyの設定(sam) - route53でドメインの設定 - api gatewayでlambdaとドメインを紐づける 今回紹介する項目 - ip制限(sam) 前提 AWS::Serverless::Functionでlambdaを作成済みであること。 参考：https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-resource-function.html 作成したlambdaにip制限の設定を行なっていきます。 ip制限(sam) samで以下のコードでlambdaを作成しているものとします。 template.yml ApiLambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: ApiLambdaFunction VpcConfig: 略 CodeUri: ./ Handler: lambda.handler Runtime: nodejs12.x Events: AnyPath: Type: Api Properties: Path: /{proxy+} Method: ANY 次に以下のドキュメントを参考にip制限の設定をしていきます。 https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-property-function-apifunctionauth.html AWS::Serverless::Apiをsamで書いていないので、これは自動で作成されています。 このままだとRestApiIdを指定することができないので、samにかいてidを指定できるようにします。 以下のsamを追記します。 ApiGatewayRestApi: Type: AWS::Serverless::Api Properties: StageName: Prod 次にIpRangeWhitelistの設定をしていきます。 template.yml ApiLambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: ApiLambdaFunction VpcConfig: 略 CodeUri: ./ Handler: lambda.handler Runtime: nodejs12.x Events: AnyPath: Type: Api Properties: Path: /{proxy+} Method: ANY RestApiId: !Ref ApiGatewayRestApi Auth: ResourcePolicy: IpRangeWhitelist: - ip1 - ip2 IpRangeWhitelist を追加しました。 これでipのホワイトリストができました。 ただし、注意点があります。 ipを設定するときに環境ごとに変えたい場合があると思います。 以下のようにParameters、Mappingsに環境ごとのipの設定を入れたとします。 Parameters: Env: Type: String AllowedValues: - develop - prod Mappings: Config: develop: allowIps: - ip1 - ip2 prod: allowIps: - ip3 - ip4 その場合、IpRangeWhitelistは以下のようになります。 IpRangeWhitelist: !FindInMap [ Config, !Ref Env, allowIps ] しかし、これは機能しませんでした。 なぜか、Mappingでの指定ができなかったので、CustomStatementsで直接指定しました。 template.yml Parameters: Env: Type: String AllowedValues: - develop - prod Mappings: Config: develop: allowIps: - ip1 - ip2 prod: allowIps: - ip3 - ip4 ApiLambdaFunction: Type: AWS::Serverless::Function Properties: FunctionName: ApiLambdaFunction VpcConfig: 略 CodeUri: ./ Handler: lambda.handler Runtime: nodejs12.x Events: AnyPath: Type: Api Properties: Path: /{proxy+} Method: ANY RestApiId: !Ref ApiGatewayRestApi Auth: ResourcePolicy: IpRangeWhitelist: !FindInMap [ Config, !Ref Env, allowIps ] CustomStatements: [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "execute-api:/Prod/*/*" }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "execute-api:/Prod/*/*", "Condition": { "NotIpAddress": { "aws:SourceIp": !FindInMap [ Config, !Ref Env, allowIps ] } } } ] これでip制限の設定の完了です。 sam deploy後に api gatewayで確認することができます。 ipの変更 既にdeployした場合、ipを変更するときに注意点があります。 ipリストを変更してsam deployすると変更は反映されますが、実際の挙動には反映されません。 api gatewayのコンソールにてdeployし直す必要があります。 これはResourcePolicyを変更する際の仕様のようです。 https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-resource-policies-create-attach.html

AWS S3の特定のbucketに、CLIやAPIからアクセスキーIDとシークレットアクセスキーでアクセスする設定を行います。 全体像は以下のようなイメージです。まず、s3testwsというバケットをつくります。そしてs3testwsuserというユーザーをつくり、アクセスキーIDとシークレットアクセスキーを生成します。 そして、バケットポリシーでこのバケットs3testwsに対してユーザーs3testwsuserのアクセス権限を付与します。 1 バケットの作成 以下のようにバケットを作成します。リージョンはap-northeast-1を選び、パブリックアクセスをすべてブロックしています。 テスト用にtest.csvというファイルをアップロードしておきました。 2 ユーザーの作成 以下のようにユーザーを作成します。「プログラムによるアクセス」にチェックをいれて、アクセスキーIDとシークレットアクセスキーを生成します。 グループやアクセス権限、タグは設定なしで構いません。 アクセスキーIDとシークレットアクセスキーをメモしておきます。 AWS CLIからアクセスしてみます。この時点では権限がないのでアクセスできないはずです。 aws configure --profile s3testwsuser 先ほどのアクセスキーIDとシークレットアクセスキーを設定し、リージョンはap-northeast-1に設定します。 C:\temp>aws configure --profile s3testwsuser AWS Access Key ID [None]: AXXXXXXXXXXXXXXXXXXXX AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Default region name [None]: ap-northeast-1 Default output format [None]: json まだアクセス権限を与えていないので、s3://s3testwsをlsすると失敗します。 C:\temp>aws s3 ls --profile s3testwsuser s3://s3testws An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied 次にバケットポリシーを設定していきますが、その前にこのユーザーのARNをメモしておきます。 arn:aws:iam::0xxxxxxxxxxxxx:user/s3testwsuserというような文字列です。 3.バケットポリシーの設定 バケットポリシーでs3testwsuserにアクセス権限を与えます。 バケットの「アクセス許可」タブの「バケットポリシー」を編集します。 以下のjsonで設定をします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:0xxxxxxxxxxx:user/s3testwsuser" }, "Action": [ "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::s3testws" ] }, { "Sid": "statement2", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::0xxxxxxxxxxx:user/s3testwsuser" }, "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::s3testws/*" ] } ] } statement1でユーザーs3testwsuserにバケットs3testwsに対するGetBucketLocationとListBucketを付与しています。これでバケット内をls可能になります。 statement2でユーザーs3testwsuserにバケットs3testws内のすべてのオブジェクトに対するGetObjectとPutObjectを付与しています。これでバケット内のファイルのアップロード、ダウンロードが可能になります。 この設定ができるとaws cliでバケット内のls、get、putが可能になります。 ls C:\temp\s3test>aws s3 ls --profile s3testwsuser s3://s3testws 2021-09-13 10:39:38 32 test.csv get C:\temp\s3test>aws s3 cp --profile s3testwsuser s3://s3testws/test.csv ./ download: s3://s3testws/test.csv to .\test.csv C:\temp\s3test>dir ドライブ C のボリューム ラベルは Windows です ボリューム シリアル番号は A0A9-D574 です C:\temp\s3test のディレクトリ 2021/09/13 11:15 <DIR> . 2021/09/13 11:15 <DIR> .. 2021/09/13 10:39 32 test.csv 1 個のファイル 32 バイト 2 個のディレクトリ 38,611,513,344 バイトの空き領域 put C:\temp\s3test>aws s3 cp --profile s3testwsuser test.csv s3://s3testws/test2.csv upload: .\test.csv to s3://s3testws/test2.csv C:\temp\s3test>aws s3 ls --profile s3testwsuser s3://s3testws 2021-09-13 10:39:38 32 test.csv 2021-09-13 11:16:18 32 test2.csv 4 参考 Amazon IAM編　S3バケット内特定フォルダだけ操作するIAMポリシー – ナレコムAWSレシピ | AIに強い情報サイト Bucket policy examples - Amazon Simple Storage Service AWS CLIでS3を操作するコマンド一覧 - Qiita

これは何 AWSでEC2にEIPを付与→関連解除すると、パブリックIPがEC2に残ってしまった(!)の記録です。 記録 自動割り当てパブリックIPを無効にします。 EIPを付与します。 EIPの関連を解除します。 残ってしまっている(!) (インスタンス削除済みなのでIP載せてます) 総括 EIPをアタッチしたら、パブリックIPは取り除けないんですね。 ネットワーク周りは構築初期から本当に気をつけて見ないとですね。 仮に外したいとなったら、AMIコピーからやらないといけなそう。（https://cloudpack.media/29286） 参考 https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-recover-ip-address/ https://josys-memo.com/ec2-public-kaijo/ https://cloudpack.media/29286 参考にさせていただきました。ありがとうございます。

概要 AWSにはIoT機器と接続、管理するためのAWS IoT Coreというサービスがある 公式にもハンズオンがあるが、最小限の手順、構成で動作を確かめてみる https://aws-iot-core-for-beginners.workshop.aws/phase2/step2.html 前回に引き続き温湿度センサーDHT22のデータを送信することを試みる 前回の記事 https://qiita.com/cami_oshimo/items/8e9c45230fccfac4ff4c Raspberry Piの操作 ライブラリseeed-python-dhtをインストールする # pip3 install seeed-python-dht まずセンサー、ライブラリの動作を確認するコードを書いてみる dht22.py import RPi.GPIO as GPIO import seeed_dht GPIO.setup(4, GPIO.IN) sensor = seeed_dht.DHT("22", 4) humi, temp = sensor.read() humidity = '{:.1f}'.format(humi) temperature = '{:.1f}'.format(temp) print(humidity) print(temp) 動作を確認してみる（温度、湿度が順番に表示される） # python3 dht22.py 26.3 78.1 前回使用したサンプルプログラムに組み込んでみる basicPubSub.py from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient import logging import time import argparse import json import RPi.GPIO as GPIO // 追加 import seeed_dht // 追加 GPIO.setup(4, GPIO.IN) // 追加 sensor = seeed_dht.DHT("22", 4) // 追加 AllowedActions = ['both', 'publish', 'subscribe'] basicPubSub.py while True: if args.mode == 'both' or args.mode == 'publish': humi, temp = sensor.read() // 追加 humidity = '{:.1f}'.format(humi) // 追加 temperature = '{:.1f}'.format(temp) // 追加 message = {} message['message'] = args.message message['sequence'] = loopCount message['temp'] = temp // 追加 message['humi'] = humi // 追加 messageJson = json.dumps(message) myAWSIoTMQTTClient.publish(topic, messageJson, 1) if args.mode == 'publish': print('Published topic %s: %s\n' % (topic, messageJson)) loopCount += 1 time.sleep(1) 修正したサンプルプログラムのbasicPubSub.pyを実行する pi@raspberrypi:~/aws-iot-device-sdk-python/samples/basicPubSub $ python3 basicPubSub.py --endpoint abc123abc123abc123-ats.iot.ap-northeast-1.amazonaws.com --rootCA ../certs/AmazonRootCA1.pem --cert ../certs/abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123-certificate.pem.crt --key ../certs/abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123-private.pem.key トピック sdk/test/Python にPublishされていることを確認する AWS IoT Coreの操作 テスト→MQTTクライアントでJSON形式のデータが到着していることを確認する 課題 seeed-python-dht から読みだした値を小数点以下1桁で送信したかったが、 Pythonで '{:.1f}'.format(temp) としても反映されない。 テスト用のコードでは再現しない。原因不明。時間のある際に調査する。

はじめに 以前バッチアプリをLambdaへアップロードしたのですが、今回はAmazon EventBridgeと組み合わせて定期的に実行させてみました。 EventBridge設定手順 定期実行させたいLambda関数を開き、"設定" > "トリガー"を開きます。 赤枠で囲っている"トリガーを追加"をクリックします。 "トリガーを追加"画面が表示されるので「EventBridge」を選択します。 詳細設定画面が表示されるのでルール名などを入力します。 スケジュール式で用いるcron式はUTCなので9時間前の日時を入れる必要があります。 入力が完了したら画面下の「追加」ボタンをクリックします。 完了後、Lambda関数概要画面にEventBridgeが表示されています。 おわりに これで定期的にバッチが実行されるようになりました～。 最初はローカルPCのタスクスケジューラにセットしていたのでローカルPCをスリープにすることも出来なかったのですが、これで安心してスリープさせられます（笑）