目的 開発マシン上のdockerで動作するrailsアプリケーションのdb接続を 踏み台サーバー経由でrdsに接続したい。 方法 前提 ◦踏み台サーバー ・エンドポイント ip: 12.12.12.12 ・pemファイル /Users/hoge/.ssh/hoge.pem ・接続ユーザー root ◦dbサーバー ・エンドポイント　private domain: hogehoge.internal (踏み台から見て) ・postgreSQL(portは、5432) ① macターミナルから以下コマンドを実行、SSHポートフォーワーディングを行う。 ssh -N -L 5434:hogehoge.internal:5432 -i /Users/hoge/.ssh/hoge.pem -p 22 root@12.12.12.12 ② database.ymlの行き先をmacの5434に設定。 database.yml host: host.docker.internal port: 5434 注) docker上で動くrailsアプリの場合なので、 localhost　でなく　host.docker.internal で指定 ③ rails サーバーを立ち上げる 正しくdbに接続されてることを確認。　 sshポートフォーワーディングとは sshポートフォーワーディングとは、sshコマンドのポート転送機能のこと。 sshコマンドは通常以下のように使用されるが、 ssh 10.10.10.10 ここに-L オプションをつけるとポートの転送先を設定できる。 例えば、 ssh -L ポート番号1:10.10.10.11:ポート番号2　10.10.10.10 これを実行すると、　 localhost:ポート番号1への接続が、10.10.10.10を経由して 10.10.10.11:ポート番号2に転送されるようになる。

初めに AWSの基礎について学習しています。 今回、AWSのサービスの１つであるIAMとCloudTrailについて学習したのでまとめていきます。 読みとして、「アイアム」と「クラウドトレイル」です。 どちらもAWSのセキュリティ対策の一種です。 通常の作業はIAMユーザーで行った方が良い AWSアカウントを作成するとルートユーザーが作成されますが、 ルートユーザーは色々なことができてしまう（完全なアクセス権を持つ）ため、 通常の作業はIAMユーザーで行うのがベストだそうです。 AWSユーザーと、グループを作成管理でき、 グループごとに操作権限の付与が可能なので、 複数人で作業をする場合にはIAMは必須なんだと思います。 IAM設定①グループ作成 注意：詳しい手順は説明してません。 IAMではグループを作成することができ、グループにはポリシーが設定できます。 今回はS３の権限のみ付与してみます！試しに！ IAM設定②ユーザー追加 グループ作ったらユーザー追加してみます。 そうするとIAMユーザーとしてサインインできます！ 権限ないところにアクセスしてみる！ このIAMユーザーには権限がないCloudWatchのページに行ってみます。 ページ自体は開けますが、、以下のように、 「権限がない」と表示されます！ このようにしてAWSを荒らされない、破壊されないようにできるんですね！！ CloudTrailで操作ログを記録する いつ誰が何をしたのかを記録してくれるのがCloudTrailです。 こちらはデフォルトで有効になっていますが、保存期間は90日間のみです。 S３（ファイルの置き場）に操作ログを保存することで、 ずっと保存できますが、S3は有料です AWSアカウントのアクティビティ（活動）を可視化することで、 AWSサービスの不正利用などを監査できます。 終わり 今回AWSのセキュリティ対策の一種であるIAMとCloudTrailをまとめてみました。

はじめに はじめまして、@cks7_です。 サーバーサイドエンジニア(SE)として都内の某WEB系企業で働いています。 先日、念願のSAA合格を果たしたので、SAA受験を考えている方などに少しでも参考になったらいいなという想いと、個人的な記録として、体験記を残そうと思います。 経験値・スキル 持っているIT系資格はITパスポートくらい 元々はインフラ分野に苦手意識 個人開発でEC2, S3の使用経験あり 業務でECS, ECR, Code系, API Gateway等の使用経験あり SESとして働いていた頃に、常駐した先でAWSを使用した業務を任されたものの、当時はAWSの知見はほぼ無し。 業務のキャッチアップのために学び始めたのがAWSに興味を持ったきっかけです。 当時所属していた会社の社内AWS勉強会で『Fargateを用いたコンテナ管理とCodePipelineを用いたデプロイの自動化について』という題目でスピーカーとして登壇してみたりもしました。 勉強期間 2021年6月上旬　試験対策の参考書を購入 2021年7月上旬　試験申し込み 2021年8月29日　試験当日 と、本腰を入れて勉強を始めてから試験当日までの期間は約2ヶ月。 勉強時間に換算すると、 平日　1日約1〜2時間（週3程度） 休日　1日約5〜6時間（土日のどちらか） それが2ヶ月間なので、ざっくり計90〜100時間くらいです。 ただ、それ以前からAWS関連の書籍を読んだり（1年くらい前に少し勉強していた形跡がQiitaの記事として残っている…完全に自分用メモ…）、業務で実際にAWSの機能に触れたりして広く浅い知識は得ていたので、0スタートから2ヶ月で合格というわけではなく、体感的には10時間程度勉強したくらいの状態からスタートした感じです。 使用した教材 私が使用したのは主に以下の3つです。 （必要に応じて、公式ドキュメントやホワイトペーパーやAWS Black Beltオンラインセミナーなども使用） ① 参考書 AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 ネットワーク、ストレージ、データベース、セキュリティ、などといった大きな分類ごとに、SAAで押さえておくべきAWSのメインサービスの概要を理解することが出来る1冊。 ◎ ここが良かった インプットだけでなくアウトプットにも対応 → 練習問題が充実しているのでセクションごとに理解度が確認出来るのと、巻末にちょうど良いレベルの模擬試験（全45問）がついているので、1冊の内容の到達度を測れる。 解説がとにかく分かりやすい！！ → 問題の選択肢1つ1つに対してなぜそれが正解/不正解なのかが丁寧に解説されており、「解説読んでもよく分からないけど、そういうものなのかー」というモヤっと感が生まれない。 試験対策としてのポイントも載っている → 「学習教材」「何に重きをおいて勉強すべきか」「問題を解く際の思考法」など、「合格を徹底サポート！」を謳っているだけある内容充実度。 ② Udenyのオンライン講座 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） 業務でAWSの使用経験が無いSAA合格者はみんな購入したんじゃないかというレベルで有名＆質の高い講座。 ◎ ここが良かった ハンズオン形式のレクチャー → 実際にAWSのサービスに触れることで、参考書では把握しづらいサービスの操作イメージや、サービス間の関係性を理解することが出来る。 難易度高めの模擬試験 → 130分65問の模擬試験が3回分ついているため、本番レベルの問題でどの程度点数が取れるか、理解が足りていない分野はどこかを把握することが出来る。実際の試験と同様の時間設定、問題数、形式なので、実際の試験イメージを持てる。 △ ここが残念 解説が少ないor無い → プラスに言えば「とことん自力で調べさせてくれる」マイナスに言えば「わからないことがモヤっと残ることがある」講座。 思わぬ課金が発生することも → 基本的には無料枠を使用してハンズオンを進めるものの、サービスによっては少なからず課金が発生してしまうものもあり、そういったものは課金が最小限になるよう講座内で課金対象の作成物を削除するよう促してくれますが、ハンズオンを途中でやり直してみたり、ちょっと別のことをしてみたりすると知らぬ間に課金対象のものが残ってしまったりするので注意。 ③ AWS公式模擬試験 AWS認定試験に備える 2,000円で購入するかたちになりますが、絶対に受けた方が良いです。 ◎ ここが良かった 本番の練習が出来る → 本番の画面と同じ画面での試験なので、表示や操作を事前に確認することが出来る。 実力試しになる → 本番同等レベルの問題でどの程度点数が取れるのかを確認する手段になる。 勉強方法 ① 参考書を3周読み込む 1周目：全体のイメージを掴みながらざっくり読む。 2周目：覚えるべき語句、重要なポイントにマーカーを引きながら読む。 3周目：2周目にマーカーを引いたところのみピックアップして声に出しながら読む。 ② 参考書の模擬試験を受ける 参考書を読み終えた時点での基礎レベルの理解度測定。 私の場合、それなりに正答率が高かったので「あれ、案外イケるじゃん」と感じてしまいました。（この後心が折れそうになることも知らずに…） ③ Udemyの動画を見ながらハンズオン 動画が32時間あるので1.5倍速で見ていましたが、ハンズオンをしながらだと結構な時間がかかりました。 ただ、実際にサービスを操作するということの価値は非常に感じました。 ④ Udemyの模擬試験×3回分を受ける 1回目は各回50〜60%程度しか正解出来ず、その難しさに心が折れかけました… 問題のレベルは本番に近く、むしろ個人的には本番よりも難しかった気がします。 ⑤ 模擬試験から得た知識を参考書にひたすら書き込んでいく 参考書を読み込んで、ハンズオンで理解を深めた状態で受けても、「こんな単語聞いたことない…」とか「こんなの載ってなかった…」という問題が多々出題されます。 不正解だった問題、正解したけど自信がなかった問題などに関して、参考書にどんどんメモを書き込みました。 この参考書さえ開けば自分の知りたいことは書いてある、という状態の1冊を作り上げるイメージ。 これは塾講師として働いていた頃に中3の受験生達に実践させていたことでもあります。 ⑥ Udemyの模擬試験×3回分をもう3周する 何度も解いていると答えが頭に入ってしまっているので、ただ正解するのではなく、各問題とその答えについて説明出来る状態になるレベルまで理解を深めることを意識して取り組みました。 最終的には正答率90%程度まで取れるようになり、だんだん自信も取り戻せてきました。 ⑦ AWS公式模擬試験を受ける 本来であれば本番前に余裕を持って模擬試験を受け、時間をかけて復習をするべきだと思いますが、せっかく湧いてきた自信や心の余裕が失われたら嫌だなと思い、私は試験前日の夜に受けました。（前日なら模擬試験の結果がダメでももう焦りようがないので） なんと本番12時間前に公式模擬試験で正答率50％という絶望的な結果を叩き出しましたが、そこから悪あがきはせずに「本番の練習が出来た！これで大丈夫だ！」くらいの潔さで即就寝。 2ヶ月の勉強の流れはこんな感じでした。 そして、無事一発合格できました！！！！！ まとめ 自分自身のやり方で勉強する 他の人の合格体験記を読んだりすると、「勉強期間1週間で合格！」とか「30時間で合格！」とか書いていたりしますが、あくまで人は人なので勉強時間や勉強方法は参考程度にし、自分のペース、自分に合う方法で進めることが大事かな、と。 「暗記」では無理、「理解」が必要 個人的な感覚ですが、暗記で合格できるような試験ではないな、と思いました。（覚えてさえいれば解けるような問題も多少出題はされますが。） 私は、合格するためだけの勉強にはしたくなく、本当の意味での理解や知識の習得を目的に勉強をすることを意識しました。 最後に 1つの目標だったSAA合格を果たしたので、また別の勉強を始めました。 SAAの勉強期間の反省点として、スケジューリングの面が挙げられるので、今回の経験を次に生かしたいなと思います。 最近Twitterを始めたのでフォローしてくれると喜びます！ @cks7_

はじめに PrimeHubをすぐ使ってみたい方へ、新たに発表されたAWS CloudFormationを使ったPrimeHubインストール方法が非常に簡単です。 本文記載時点はPrimeHub Enterprise v3.8を参考にしています。 Youtubeデモビデオこちらへ PrimeHub Enterprise 簡単な紹介〜 (v3.8) PrimeHub Enterpriseのフリープランは フル機能と 一つのグループを作成ができると 一つのモデルデプロイを使える 必要なもの AWSアカウント 約３０分の待ち時間があるので、? お茶や☕ コーヒーのご準備を ➡️ ワンクリックサイトでクリックすると サインイン スタックのクイック作成 最初にCloudFormationでPrimeHub Starter Stack(<スタックの名前>)を作成すると、このStarterは次のeks-<スタックの名前>-cdk-stackを築きます。eks-<スタックの名前>-cdk-stackはPrimeHubプラットフォームを運営します スタックの名前を入力する CPUInstanceType (auto scaling)を選ぶ GPUInstanceType (auto scaling)を選ぶ PrimeHubInstallMode ee: PrimeHub Enterprise チェックAWS CloudFormation によって IAM リソースが作成される場合があることを承認します。 スタックの作成ボタンをクリックすると Starter Stack(<スタックの名前>)を作成する eks-<スタックの名前>-cdk-stackを築く eks-<スタックの名前>-cdk-stackはCREATE_COMPLETE状態になったら完成。出力のタブで色々な情報を見れる 重要な値は PrimeHubAccount：ユーザー名はphadminに固定されており PrimeHubPassword：パスワード PrimeHubURL：ポータル入り口 PrimeHubURLへ ?　PrimeHub Enterpriseのインストール完成　? PrimeHub Enterprise初心者の方へ 最初にグループにおけるModel Deploymentを有効する Open TensorFlow Notebookからはじめチュートリアルをしましょう このチュートリアルでモデルトレーニングからモデルデプロイまでPrimeHubの使い方を学べる Prerequisitesの部分は用意されているので一つ目のセルから進む 詳しい使い方はPrimeHub Documentationへ 参考 Amazon EC2 T3 インスタンスの詳細 Amazon EC2 G4 インスタンスの詳細 AWS 見積り PrimeHub Documentation InfuseAI (インフューザーアイ)公式サイト | Discord | ツイッター | Newsletter

はじめに PrimeHubをすぐ使ってみたい方へ、新たに発表されたAWS CloudFormationを使ったPrimeHubインストール方法が非常に簡単です。 本文記載時点はPrimeHub Enterprise v3.8を参考にしています。 Youtubeデモビデオこちらへ PrimeHub Enterprise 簡単な紹介〜 (v3.8) PrimeHub Enterpriseのフリープランは フル機能と 一つのグループを作成ができると 一つのモデルデプロイを使える 必要なもの AWSアカウント 約３０分の待ち時間があるので、? お茶や☕ コーヒーのご準備を ➡️ ワンクリックサイトでクリックすると サインイン スタックのクイック作成 最初にCloudFormationでPrimeHub Starter Stack(<スタックの名前>)を作成すると、このStarterは次のeks-<スタックの名前>-cdk-stackを築きます。eks-<スタックの名前>-cdk-stackはPrimeHubプラットフォームを運営します スタックの名前を入力する EmailNotification メールの通知 CPUInstanceType (auto scaling)を選ぶ GPUInstanceType (auto scaling)を選ぶ PrimeHubInstallMode ee: PrimeHub Enterprise チェックAWS CloudFormation によって IAM リソースが作成される場合があることを承認します。 スタックの作成ボタンをクリックすると Starter Stack(<スタックの名前>)を作成する eks-<スタックの名前>-cdk-stackを築く eks-<スタックの名前>-cdk-stackはCREATE_COMPLETE状態になったら完成。出力のタブで色々な情報を見れる 重要な値は PrimeHubAccount：ユーザー名はphadminに固定されており PrimeHubPassword：パスワード PrimeHubURL：ポータル入り口 PrimeHubURLへログインする ?　PrimeHub Enterpriseのインストール完成　? PrimeHub Enterprise初心者の方へ 最初にグループにおけるModel Deploymentを有効する Open TensorFlow Notebookからはじめチュートリアルをしましょう このチュートリアルでモデルトレーニングからモデルデプロイまでPrimeHubの使い方を学べる Prerequisitesの部分は用意されているので一つ目のセルから進む 詳しい使い方はPrimeHub Documentationへ 参考 Amazon EC2 T3 インスタンスの詳細 Amazon EC2 G4 インスタンスの詳細 AWS 見積り PrimeHub Documentation InfuseAI (インフューザーアイ)公式サイト | Discord | ツイッター | Newsletter

はじめに DynamoDBでテーブルをまるっと取得するってなかなか難しくないですか？ 作成された順にitem(RDBでいうレコードみたいなもの)を全件並べて解析したい！みたいなことも難しい? 一回のScanで取得できるデータが最大1MBという制約がなかなか厄介で、 DynamoDB コンソール上からは簡単に全件データのエクスポートができないようになっています。 ページごとの表示数をMAXの300件にしても、全件を取得するために「次のページを取得」を連打して、CSVをエクスポートする必要がありました。 どうにか簡単にできる方法はないか色々調べてたところ、 以下の方法でコマンド一発でテーブルの内容をまるっとにCSVにエクスポートできるようになりました。 一括でCSVへ出力する方法 前提条件 AWS Config にAccessKeyやらのprofileを設定しておく AWS CLI を使用できるようにしておく 手順 jqコマンドを使用するのでインストールする (Mac環境なのでbrewでインストールしてます? ) AWS CLI と jqコマンドを組み合わせたコマンドを発行する terminal # jqコマンドをインストール $ brew install jq # インストールされたことを確認 $ jq --version jq-1.6 # 全件取得とCSV出力のコマンド発行 $ aws dynamodb scan --table-name HogeTable --profile hoge-profile | jq -r '["ID","ユーザー名","作成日"], (.Items[] | [.ID.S, .Name.S, .createdAt.S]) | @csv' > sample.csv コマンド詳細 AWS CLIでDynamoDBから値をJSONで取得 terminal aws dynamodb scan --table-name HogeTable --profile hoge-profile このコマンドで、DynamoDBの指定したテーブル内容をJSON形式で取得しています。 HogeTableを対象のテーブル名、hoge-profileを~/.aws/configに設定しているprofileにしてください。 なんか上手くいかない！という場合はまずこのコマンドでJSONを取得できているか確認してみてください。 jqコマンドでJSONをCSVに整形 terminal jq -r '["ID","ユーザー名","作成日"], (.Items[] | [.ID.N, .Name.S, .createdAt.S]) | @csv' ここの箇所でJSONをCSV形式に整形しています。 jq -r 'ヘッダー, (項目) | @csv'というイメージです。 aws dynamodb scan ~コマンドで取得されるJSONは以下のような形式かと思うので、それにあわせて項目の部分を設定します。 terminal # aws dynamodb scan ~で取得できるJSON例 { "Items": [ { "ID": { "N": "1" }, "Name": { "S": "清水真太郎" }, "createdAt": { "S": "2021-09-13T02:33:07.443Z" } }, { "ID": { "N": "2" }, "Name": { "S": "柴田大知" }, "createdAt": { "S": "2021-09-13T02:3７:２7.542Z" } } ] } 整形されたCSVデータをCSVファイルに出力 terminal > sample.csv 最後にCSVデータをCSVファイルとして出力させています。 まとめ DynamoDBのテーブルに合わせてコマンドを作成するのに最初やや時間がかかりますが、 一度作成してしまえばいつでもすぐ全件をCSVにエクスポートできるようになりました！? DynamoDBのTipsあればぜひ教えてください！

はじめに クロスアカウントの S3 バケット間でデータを移行する場合いくつか選択肢がありますが、 最近 AWS DataSync がクロスアカウントの移行に対応したようなので試しました。 比較的に容易に、かつ柔軟性のある設定でデータの移行ができました。 公式ブログの内容に沿って行っていますが、曖昧な箇所があり分かりづらいため日本語のドキュメントを残します。 送信先 S3 バケットの作成 移行対象の送信元 S3 バケットはすでにあるとして、送信先アカウントでバケットを作成します。 以下、 AWS CloudFormation のコードを示しながら進めます。 送信先バケット S3BucketDataSyncDist: Type: 'AWS::S3::Bucket' DeletionPolicy: 'Retain' Properties: AccessControl: 'Private' BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: 'AES256' BucketName: 'datasync-dist' VersioningConfiguration: Status: 'Enabled' PublicAccessBlockConfiguration: BlockPublicAcls: True BlockPublicPolicy: True IgnorePublicAcls: True RestrictPublicBuckets: True IAM ロールの作成 送信先アカウントで DataSync が送信元、送信先それぞれの Location にアクセスするための IAM ロールを作成します。 実際の移行を行う DataSync の Task も送信先アカウントで実行することになります。 ${S3BucketDataSyncSource} には送信元バケット名を渡してください。 送信元LocationのIAMロール IAMRoleDataSyncSourceLocation: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Principal: Service: 'datasync.amazonaws.com' Action: 'sts:AssumeRole' RoleName: 'datasync-source-location-role' Policies: - PolicyDocument: Statement: - Action: - 's3:GetBucketLocation' - 's3:ListBucket' - 's3:ListBucketMultipartUploads' Effect: 'Allow' Resource: !Sub 'arn:aws:s3:::${S3BucketDataSyncSource}' - Action: - 's3:AbortMultipartUpload' - 's3:DeleteObject' - 's3:GetObject' - 's3:ListMultipartUploadParts' - 's3:PutObjectTagging' - 's3:GetObjectTagging' - 's3:PutObject' Effect: 'Allow' Resource: !Sub 'arn:aws:s3:::${S3BucketDataSyncSource}/*' PolicyName: 'datasync-source-location-policy' 送信先LocationのIAMロール IAMRoleDataSyncDistLocation: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: 'Allow' Principal: Service: 'datasync.amazonaws.com' Action: 'sts:AssumeRole' RoleName: 'datasync-dist-location-role' Policies: - PolicyDocument: Statement: - Action: - 's3:GetBucketLocation' - 's3:ListBucket' - 's3:ListBucketMultipartUploads' Effect: 'Allow' Resource: !GetAtt S3BucketDataSyncDist.Arn - Action: - 's3:AbortMultipartUpload' - 's3:DeleteObject' - 's3:GetObject' - 's3:ListMultipartUploadParts' - 's3:PutObjectTagging' - 's3:GetObjectTagging' - 's3:PutObject' Effect: 'Allow' Resource: !Sub ${S3BucketDataSyncDist.Arn}/* PolicyName: 'datasync-dist-location-policy' 送信元バケットのバケットポリシーの追加 送信元アカウントで送信元バケットのバケットポリシーに、作成した送信元 Location の IAM ロール(datasync-source-location-role)と、 このあと aws datasync create-location-s3 を実行する送信先アカウントのユーザ(DataSyncDistAccountUserArn)に対して権限を与えます。 YAML 内の S3BucketDataSyncSource は送信元バケットのリソースです。 AWS CLI を実行する際のユーザの ARN は aws sts get-caller-identity で確認することができます。 送信元バケットのバケットポリシー S3BucketPolicyDataSyncSource: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3BucketDataSyncSource PolicyDocument: Statement: - Effect: Allow Principal: AWS: - !Sub 'arn:aws:iam::${DataSyncDistAccountId}:role/datasync-source-location-role' - !Ref DataSyncDistAccountUserArn Action: - 's3:GetBucketLocation' - 's3:ListBucket' - 's3:ListBucketMultipartUploads' - 's3:AbortMultipartUpload' - 's3:DeleteObject' - 's3:GetObject' - 's3:ListMultipartUploadParts' - 's3:PutObject' - 's3:GetObjectTagging' - 's3:PutObjectTagging' Resource: - !GetAtt S3BucketDataSyncSource.Arn - !Sub ${S3BucketDataSyncSource.Arn}/* DataSync Location の作成 送信先アカウントで Location を作成します。 CloudFormation に AWS::DataSync::LocationS3 リソースがありますが、 クロスアカウントの作成に対応していないようで、 Invalid request provided: Please provide a bucket in the us-east-1 region where DataSync is currently used. といったエラーとなるため、 送信元 Location のみ AWS CLI から作成します。 AWS CLI で送信先アカウントに対して以下のコマンドで送信元 Location を作成します。 送信元Locationの作成　 aws datasync create-location-s3 --s3-bucket-arn arn:aws:s3:::[送信元バケット名] --s3-config '{"BucketAccessRoleArn":"arn:aws:iam::[送信先アカウントID]:role/datasync-source-location-role"}' この時、コマンドを実行するユーザはバケットポリシで許可したユーザである必要があります。 送信先 Location は問題なく CloudFormation で作成することができます。 送信先Location DataSyncLocationS3DistLocation: Type: AWS::DataSync::LocationS3 Properties: S3BucketArn: !GetAtt S3BucketDataSyncDist.Arn S3Config: BucketAccessRoleArn: !GetAtt IAMRoleDataSyncDistLocation.Arn S3 のレプリケーションを使うと Prefix によって送信元、送信先で同じフォルダ間でしか移行ができないのに対し、 DataSync は Location で Subdirectory を指定することができるため、 送信元、送信先でそれぞれ別々のフォルダを指定することができるところが良いです。 ロググループの作成(オプション) 送信先アカウントで DataSync の Task 実行時にログを吐くためのロググループとリソースポリシーを作成します。ログが必要ないなら不要です。 LogsLogGroupDataSync: Type: AWS::Logs::LogGroup Properties: LogGroupName: datasync RetentionInDays: 14 LogsResourcePolicy: Type: AWS::Logs::ResourcePolicy Properties: PolicyName: datasync-log-resource-policy PolicyDocument: "{\"Statement\": [{\"Sid\": \"DataSyncLogsToCloudWatchLogs\", \"Effect\": \"Allow\", \"Action\": [\"logs:PutLogEvents\", \"logs:CreateLogStream\"], \"Principal\": {\"Service\": \"datasync.amazonaws.com\"}, \"Resource\": \"*\"}], \"Version\": \"2012-10-17\"}" PolicyDocument が String しか受け付けてくれませんが、 AWS::IAM::ManagedPolicy のように JSON で受け付けてくれると良いですね。 DataSync Task の作成 送信先アカウントで DataSync の Task を作成します。 YAML の DataSyncSourceLocationArn は aws datasync create-location-s3 の結果で返される LocationArn です。 aws datasync list-locations でも確認することができます。 AWS::DataSync::Task の細かな仕様は公式ドキュメントを参照してください。　 DataSyncTask: Type: AWS::DataSync::Task Properties: SourceLocationArn: !Ref DataSyncSourceLocationArn DestinationLocationArn: !GetAtt DataSyncLocationS3DistLocation.LocationArn Excludes: - FilterType: SIMPLE_PATTERN Value: /logs Schedule: ScheduleExpression: 'rate(1 hour)' Options: OverwriteMode: NEVER TransferMode: CHANGED VerifyMode: ONLY_FILES_TRANSFERRED LogLevel: BASIC CloudWatchLogGroupArn: !Select [0, !Split [':*', !GetAtt LogsLogGroupDataSync.Arn]] おわりに S3 のレプリケーションだと同じフォルダ間でしか移行できなかったり、 バッチオペレーションだと定期実行ができなかったりと、不都合があった部分が DataSync によってうまく解決できました。 ただし、もちろん料金は発生するためきちんと見積もりをしてから実行するのが良いでしょう。 https://aws.amazon.com/jp/datasync/pricing/

サクッとAmazon Aurora PostgreSQLを試そうと、サンプルデータを投入する際に 地味にハマったのでメモ 利用サンプルデータ PostgreSQL Tutorialのサンプルデータ 15個のテーブル、7つのViewなどいろいろ https://www.postgresqltutorial.com/postgresql-sample-database/ 手順 amazon linux2 EC2を作業環境で、Amazon Auroraに投入する 各リソース準備は省略 [1] psqlセットアップ sudo yum install -y postgresql これだけだと、あとでリストア実行pg_restoreの際に以下のエラーが出た pg_restore: [archiver] unsupported version (1.13) in file header バージョン違いのエラーとのことで、以下で解消。 sudo amazon-linux-extras install postgresql10 [2] サンプルデータ取得 上記のTutorialサイトからダウンロードしてunzipする（tarファイルができる） wget https://www.postgresqltutorial.com/wp-content/uploads/2019/05/dvdrental.zip unzip dvdrental.zip [3] データリストア 一旦psqlでDBに接続してデータベースを作成 CREATE DATABASE dvdrental 一旦DB接続を抜けて、pg_restoreでリストアする pg_restore -h [Auroraエンドポイント] -U test -d dvdrental ./dvdrental.tar すると以下のエラーが。。。 role "postgres" does not exist Aurora作成時のスーパーユーザー名をtestにしていて、roleが違うから。 スーパーユーザー名は変更できないので、rds_superuser権限のpostgresユーザーを別途作成 create role postgres with password 'XXX' login; grant rds_superuser to postgres; 参考） あらためてリストア実行 pg_restore -h [Auroraエンドポイント] -U postgres -d dvdrental ./dvdrental.tar 以上

■前提 Amazon CognitoのUser Poolを使用 ユーザーにはEmail + Passwordでサインアップ/サインインさせるように設定。 ■AmdinGetUser APIについて AdminGetUser APIは、管理者権限でCognito UserPoolから指定したユーザーの情報を取得するAPIです。 詳しくは公式ドキュメントを御覧ください。 Request Syntax { "Username": "string", "UserPoolId": "string" } ↑の通り公式ドキュメントには、「リクエストにはUsernameを指定してクレメンス」となっています。 ■AmdinGetUser APIで困ったこと 私は「UsernameじゃなくてEmailでユーザー情報を取得したいんよな」と困っていました。 ■結果 試しにUsernameにEmailを指定して実行してみた結果、、 { ["data":"Aws\Result":private]=> array(7) { ["Username"]=> string(36) 以下略 なんと期待したレスポンスが返ってきてくれました。やったぜ。 なので、AdminGetUser APIのUsernameにEmailを指定しても実行できます。 公式ドキュメントにそれっぽいことが書かれていなくても、とりあえず試してみることが大事だなと学びました。

■前提 Amazon CognitoのUser Poolを使用 ユーザーにはEmail + Passwordでサインアップ/サインインさせるように設定。 ■AdminGetUser APIについて AdminGetUser APIは、管理者権限でCognito UserPoolから指定したユーザーの情報を取得するAPIです。 詳しくは公式ドキュメントを御覧ください。 Request Syntax { "Username": "string", "UserPoolId": "string" } ↑の通り公式ドキュメントには、「リクエストにはUsernameを指定してクレメンス」となっています。 ■AdminGetUser APIで困ったこと 私は「UsernameじゃなくてEmailでユーザー情報を取得したいんよな」と困っていました。 ■結果 試しにUsernameにEmailを指定して実行してみた結果、、 { ["data":"Aws\Result":private]=> array(7) { ["Username"]=> string(36) 以下略 なんと期待したレスポンスが返ってきてくれました。やったぜ。 なので、AdminGetUser APIのUsernameにEmailを指定しても実行できます。 公式ドキュメントにそれっぽいことが書かれていなくても、とりあえず試してみることが大事だなと学びました。

はじめに AWSでポートフォリオをデプロイする事ができました。 デプロイするのに様々なエラーがあったので復習のために投稿します。 今回はunicorn起動時に起きたエラーです。 bundler: failed to load command: unicorn_rails EC2内 [ec2-user@ip-10-0-0-53 <リポジトリ名>]$ bundle exec unicorn_rails -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production このようにEC2内で起動コマンドをしました。 EC2内 bundler: failed to load command: unicorn_rails (/home/ec2-user/.rbenv/versions/2.6.5/bin/unicorn_rails) rubygems_integration.rb:364:in `block in replace_bin_path': can't find executable unicorn_rails for gem unicorn. unicorn is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception) 1つづつエラーを見ていきます。 bundler: failed to load command: unicorn_rails (/home/ec2-user/.rbenv/versions/2.6.5/bin/unicorn_rails) コマンドの読み込みに失敗しました：unicorn_rails これは単純に何かのエラーで読み込めませんでしたよと言われています。 もう1つのエラーが原因が記述されています。 rubygems_integration.rb:364:in `block in replace_bin_path': can't find executable unicorn_rails for gem unicorn. unicorn is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception) 和訳サイトで確認すると強気な和訳が返されました（笑） 単純にgemをインストールしてないだけでした。 確認作業 gemのディレクトリーを確認します。 EC2内 [ec2-user@ip-10-0-0-53 <リポジトリ名>]$ vi Gemfile テキストエディター開くコマンドで確認することができます。 Gemfile #省略 gem 'pry-rails' gem 'kaminari' gem 'ransack' gem 'gretel' 1番下には記述されていませんでした。 ここで記述していきます。 iコマンドを押すと記述できるようになります。 Gemfile group :production, :staging do gem 'unicorn' end 記述した後:wqで編集完了。 EC2内 [ec2-user@ip-10-0-0-53 <リポジトリ名>]$ gem install bundler [ec2-user@ip-10-0-0-53 <リポジトリ名>]$ bundle install すでにunicornの設定はできているので、最初の起動コマンドを押して起動します。 最後に 慎重にやっていたらミスらないと思うので確実にこなしていきたいと思います。

Amazon Managed Blockchain のネットワークを削除する方法 Amazon Managed Blockchainを利用してブロックチェーンの勉強をしていたけどネットワークが必要なくなった人向けの情報です。 Amazon Managed Blockchainはそもそもネットワークを所有(メンバーとして参加)しているだけで一時間$0.3かかるので、一か月で大体三万円ほどかかります(つらい)。書籍を使って勉強している場合は基本的に操作解説部分の終わりに削除方法が書いてあると思いますが、インターネットには単体の日本語解説がなくてめちゃくちゃ焦りました。 結論 ネットワークのメンバーを全員削除する 以上です。 『ネットワークの最後のメンバーが削除されると、ネットワークなどのすべての関連するBlockchainの情報が自動で削除されます』と公式英語ページにありました。 簡単なことなのによぉ、なんで英語の本家ドキュメントしかねぇんだ？？？ 「 Amazon Managed Blockchain 終了」とかでググっても始め方のサイトしかヒットしないので新手の詐欺かと思った。 Amazon Managed Blockchain自体は素晴らしいサービスなのでこの記事を読んで安心してバチバチに使い倒しましょう。 注意 個人練習用で開発している分には問題は起きないはずですが、メンバーが複数いる場合、ネットワークの所有者(Owner)をメンバーから削除してもネットワークは消えません。ネットワークの所有者以外のすべてのユーザーを削除してから最後に所有者ユーザーを削除するのが安全です。 参考 AWS 公式ドキュメント(英語) 「Delete a Hyperledger Fabric Network on Amazon Managed Blockchain」

はじめに 昨日の記事からの続きとなります。 ◆事前準備編◆ 　1.macOSのデスクトップにtempフォルダを作る 　2.tempフォルダにccxtをpip3でインストールする 　3.既に作ったpythonプログラムを lambda_function.py へリネームしてtempフォルダに入れる 　4.lambda_function.py の先頭に指定プログラムを追記する 　5.ターミナルでzipでまとめる ◆Lambda編◆ 　6.AWSへログインし、5をアップロードする ◆EventBridge編◆ 　7.EventBridge (CloudWatch Events)に定期実行ルールを登録する 今回は6の説明をします。(次回7を説明します) 手順 6.AWSへログインし、5をアップロードする 6-1.AWSのマネジメントコンソールヘログインします。 https://aws.amazon.com/jp/console/ 6-2.上部の検索バーに　Lambda　と入力します。Lambda　をクリックします。 6-3.右上の関数の作成をクリックします。 （何も関数を作成していない場合は若干画面が異なるかもしれません。） 6-4.[一から作成]が選択されていることを確認します。 　　[関数名] は任意の名前をつけます。(例:import_ccxt) 　　[ランタイム] はお使いのPythonのバージョンを指定してください。(例：Python3.9) 　　下にスクロールし[関数の作成]をクリックします。 6-5.[コードソース]＞[アップロード元]を選択し、中から[.zipファイル]を選択します。 6-6.[アップロード]ボタンを押し、手順１−５で作成した.zipファイルを選択し、[開く]をクリックします。 　　元の画面に戻ったら[保存]をクリックします。 6-7.[テスト]タブをクリックし、名前に任意の名前を記入します。(例：import_ccxt) 　　[テスト]をクリックします。 6-8.[実行結果：成功]　と出ていれば成功です！ ハマり注意 ここで　[実行結果：失敗]　となる場合は特に以下をご確認ください。 ・作成したPythonファイル名が　lambda_function.py　になっていない ・lambda_function.pyの先頭に以下が入っていない ・zipしたファイルにlambda_function.pyが入っていない lambda_function.py def lambda_handler(event, context): return { } 最後に いかがでしたでしょうか。 無事AWSへPythonを移行できましたでしょうか。 今回はライブラリも同時にuploadしましたので、より実践的かと思います。 次回は定期実行をするためにEventBridgeの使い方を記載しようと思います。 ご参考になれば幸いです。

AWS EKS on Fargete では主にPodをホスティングしているFargateのvCPU memory に課金がされます。 各podが使用しているvCPU memory は kubectl describe pods で取得できる、Annotations: CapacityProvisioned にて確認することができます $ kubectl describe pods Name: hogehoge Namespace: default Priority: 2000001000 Priority Class Name: system-node-critical Node: fargate-ip-xxxx.ap-northeast-1.compute.internal/xxxx Start Time: Tue, 14 Sep 2021 13:00:51 +0900 Labels: app=hogehoge eks.amazonaws.com/fargate-profile=fp-default Annotations: CapacityProvisioned: 0.25vCPU 0.5GB Logging: LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND kubernetes.io/psp: eks.privileged またdescribe pods以外にもkubectl get pods -o json でJSON形式でpodごとの情報を出力することができるので、jq と組み合わせて以下のように取得することができます $ kubectl get pods --all-namespaces -o json \ | jq -r '.items | .[] | [.metadata.name, .metadata.annotations.CapacityProvisioned] | @tsv' \ | grep vCPU hogehoge 0.25vCPU 0.5GB aws-load-balancer-controller-75887bfdc9-tbl27 0.25vCPU 0.5GB coredns-859bbbb85d-vdw97 0.25vCPU 0.5GB coredns-859bbbb85d-wbw9p 0.25vCPU 0.5GB kube-system で動くようなpodにも課金されるので注意が必要です

はじめに プログラミング初学者の@kat_logと申します。 Cloud9のインデントのデフォルト値の変更方法の共有です。 設定 設定の歯車マーク Code Editer (Ace) Soft tabsに任意の数値を設定 以上です！ おわりに お読みいただきありがとうございました！ （Qiita10周年おめでとうございます?）

terraform.tfstateの整合性 下記の記事では新規にvpcを展開する時の作成方法です。 今回は既に展開されている個別のterraformで作成されたマルチリージョンのvpcをworkspaceで一括管理しましょうといった流れです。 簡潔に言うとtfstateを一つにまとめたいって事です。 まずは現状確認。 ./ ├── tokyo │   ├── main.tf │   ├── terraform.tfstate │   ├── terraform.tfstate.backup │   └── variable.tf ├── oregon │   ├── main.tf │   ├── terraform.tfstate │   ├── terraform.tfstate.backup │   └── variable.tf └── virginia ├── main.tf ├── terraform.tfstate ├── terraform.tfstate.backup └── variable.tf これだと各リージョン毎に管理している状態です。 これらの管理変更を一括で適用したい場合、煩雑になるので一回のapplyで全リージョンに適用したい。 目標は大体こんな感じの構成。 ├── client.tf ├── internet_gateway.tf ├── main.tf ├── nat_gateway.tf ├── route_table.tf ├── routing.tf ├── subnet.tf ├── terraform.tfstate.d │   ├── ap-northeast-1 │   ├── us-east-1 │   └── us-west-2 │   ├── terraform.tfstate │   └── terraform.tfstate.backup └── variables.tf 現状、各tfファイルmv等でを移行してplanを叩くと新規にリソースが作成されてしまう。 原因はtfstateの中身と今の構成との整合性が取れていない事で、現状の構成に合わせてtfstateファイルを上書きしようとしている為です。 planを叩くとリソースが入れ替わってしまう状況が確認できたので、terraform.tfstateファイルを編集して辻褄合わせをしたい。 余談だが、リソースを一つづつ書いたものをリスト化して纏めようとした時も同様に、 planを叩くと既存のリソースが入れ替わる挙動になる。 planの結果（一例） # aws_subnet.public[2] will be created + resource “aws_subnet” “public” { + arn = (known after apply) + assign_ipv6_address_on_creation = false + availability_zone = “us-west-2c” + availability_zone_id = (known after apply) + cidr_block = “10.189.64.0/19" + id = (known after apply) + ipv6_cidr_block_association_id = (known after apply) + map_public_ip_on_launch = true + owner_id = (known after apply) + tags = { + “Name” = “public3" } + vpc_id = “vpc-hogehoge” } # aws_subnet.public_1d will be destroyed - resource “aws_subnet” “public_1d” { - arn = “arn:aws:ec2:us-west-2:332777730118:subnet/subnet-01a89dcb3070d5616" -> null - assign_ipv6_address_on_creation = false -> null - availability_zone = “us-west-2d” -> null - availability_zone_id = “usw2-az4" -> null - cidr_block = “10.189.64.0/19” -> null - id = “subnet-01a89dcb3070d5616" -> null - map_customer_owned_ip_on_launch = false -> null - map_public_ip_on_launch = true -> null - owner_id = “332777730118” -> null - tags = { - “Name” = “public3” } -> null - vpc_id = “vpc-hogehoge" -> null } Plan: 19 to add, 1 to change, 19 to destroy. ------------------------------------------------------------------------ Note: You didn’t specify an “-out” parameter to save this plan, so Terraform can’t guarantee that exactly these actions will be performed if “terraform apply” is subsequently run. じゃあ statefile自体を書き換えてしまえば良いのでは？となるのですが、このjsonを直接書き換えるのは公式では推奨されて無く、terraform state mvを使用することが推奨されている。 書き方としては、AのstateをBに合わせたい時は $ terraform state mv A B この様に実行すればstateの書き換えが可能になる。 使用例 既存のリソースを削除せずにstateをあわせる時は下記を実行すればリソースはそのままにリファクタリング可能。 $ terraform state mv aws_subnet.public_1d aws_subnet.public[2] stateファイルをmvするコマンドを各リソースに対してポチポチ実行してstateファイルの整合性を取るようにしていけば、各リソースの統合が可能になり、workspaceへの移行ができるようになる。 以下おまけ。 stateファイルをs3にアップロードする リソースをgitに上げるなどした時にstateファイルのみをs3に上げて、gitに上げたくない時等に使用。 main.tf provider “aws” { region = “us-west-2" } terraform { required_version = “>= 0.13.0” backend “s3" { bucket = “terraform-state” region = “us-west-2" key = “test/state” profile = “terraform” } } resource “aws_s3_bucket” “terraform_state” { bucket = “terraform-state” } tertraform{}でstateファイルをs3に置くように設定している terraform { # terraformのバージョン required_version = “>= 0.13.0" # backendをs3にすることでstateファイルをs3においている backend “s3” { # s3バケットを指定。 # 既存のs3バケットを指定する必要がある。 # backend記述をs3作成のリソースを書いてまとめてapplyは出来ない bucket = “terraform-state” region = “us-west-2” key = “test/state” # ~/.aws/にある、apply先のprofileを指定する。 # ここの項目は必須。たとえここのmain.tfにアカウントキーを入力していても読んではくれない模様 profile = “terraform” } } また、backendの設定に変数を使用する事は出来ない。 以下はkeyに変数を指定した場合のエラー $ terraform init Initializing the backend... Backend configuration changed! provider “aws” { Terraform has detected that the configuration specified for the backend has changed. Terraform will now check for existing state in the backends. Error: Variables not allowed on main.tf line 12, in terraform: 12: key = var.keys Error: Variables not allowed となる。 さらに、backendを書き換えた場合は、都度initしなくてはならない。 以下はbackendのs3バケットを変更した後のエラー $ terraform apply Backend reinitialization required. Please run “terraform init”. Reason: Backend configuration changed for “s3" The “backend” is the interface that Terraform uses to store state, perform operations, etc. If this message is showing up, it means that the Terraform configuration you’re using is using a custom configuration for the Terraform backend. Changes to backend configurations require reinitialization. This allows Terraform to setup the new configuration, copy existing state, etc. This is only done during “terraform init”. Please run that command now then try again. If the change reason above is incorrect, please verify your configuration hasn’t changed and try again. At this point, no changes to your existing configuration or state have been made. Error: Initialization required. Please see the error message above. backendは一度指定したら気軽に変更が出来ないので注意が必要。

Introduction In my previous blog, I gave you a brief Introduction of OCI Cloud Shell. AWS released their own service, "AWS CloudShell" a little later, which provides similar function as OCI Cloud Shell. Now let's take a look at the difference between OCI Cloud shell and AWS CloudShell. (There is no space in "CloudShell".) OCI Cloud Shell AWS CloudShell General Difference OCI Cloud Shell AWS CloudShell Release Time Feb 2020 Dec 2020 Storage Under Home 5GB 1GB Change Terminal Language Yes No (Only English) User Name Your IAM or federated user name(Dot is replaced by underline) "cloudshell-user" File Download/Upload Yes Yes Upload FileUsing Drag & Drop Yes No(Only from Menu) Upload Multiple Files Yes No(One file a time) Max Upload File Size 4GB 1GB sudo command No Yes New Tab,Split into rows/columns No Yes Long-running Session Max 24 hours Max 12 hours Inactive Session Timeout 20 minutes 20–30 minutes OCI provide much more storage under home directory than AWS. And you can upload multiple files to Cloud Shell using drag and drop, that is a very handy function. Pre-installed Software OCI Cloud Shell has a long list of per-installed software, which is friendly to developers. OCI Cloud Shell AWS CloudShell Shell bash bashPowerShell, Z Shell CLI OCI CLI AWS CLIEB CLI, ECS CLI, SAM CLI git Yes Yes python (2 and 3) Yes Yes Node.js Yes Yes Java Yes No SQL Plus Yes No kubectl Yes No helm Yes No maven Yes No gradle Yes No Terraform Yes No ansible Yes No Go Yes No TypeScript Yes No Ruby Yes No End Official Document OCI Cloud Shell AWS CloudShell User Guide

AWS SAM を用いて API Gateway リソースを作成した際、 設定していない　Stage という名称のステージが作成される現象が発生しました。 これはSAM CLIの不具合で以下のGitHub Issueに問題が上がっています。 SAM Creates stage named "Stage" by default? · Issue #191 · aws/serverless-application-model https://github.com/aws/serverless-application-model/issues/191 ■回避策 API Gateway REST API リソースの OpenApiVersion を '2.0' と指定する。 Globals: Api: OpenApiVersion: '2.0'

この記事を見る前に質問です。 次のコマンドを入力したときこのような結果は出ましたか？ コマンド ping www.google.com 結果 ping: www.google.com: Name or service not known →この結果が出た場合、名前解決ができていないのでこの記事は有用かもしれません →このような結果が出てない場合、別の記事を探しましょう 環境 Amazon Linux 2 AMI 本記事で解決したい内容 以下のコマンドを入力したときに コマンド yum install httpd 以下のエラー画面が出ないようにする 結果 Loaded plugins: extras_suggestions, langpacks, priorities, update-motd Could not retrieve mirrorlist https://amazonlinux-2-repos-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/2/core/latest/x86_64/mirror.list error was 14: curl#6 - "Could not resolve host: amazonlinux-2-repos-ap-northeast-1.s3.ap-northeast-1.amazonaws.com" One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=<repoid> ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable <repoid> or subscription-manager repos --disable=<repoid> 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: 試してほしいこと １．VPCのDNS名前解決・ホスト名有効化の確認 ２．サーバーの/etc/resolv.confにDNSサーバーのIPアドレスが記載されているか確認 １．VPCのDNS名前解決・ホスト名有効化の確認 ①VPCのダッシュボードから自分のVPCを選択 ②「アクション」>「DNS ホスト名を編集」をクリック DNS ホスト名の有効化のチェックボックスにチェック 「変更を保存」をクリック ③「アクション」>「DNS 解決を編集」をクリック DNS 解決の有効化のチェックボックスにチェック ④「変更を保存」をクリック ２．サーバーの/etc/resolv.confにDNSサーバーのIPアドレスが記載されているか確認 ①EC2にログインする ②コマンドを入力 コマンド cat /etc/resolv.conf 結果 # Generated by NetworkManager search local nameserver 8.8.8.8 nameserver 8.8.4.4 ③上記のような結果が表示がされていない場合、以下コマンドを入力して/etc/resolv.confを編集する （※されていた場合これ以上この記事を見る必要はないでしょう） コマンド vi /etc/resolv.conf /etc/resolv.conf # Generated by NetworkManager search local nameserver 8.8.8.8 nameserver 8.8.4.4 テスト 以下コマンドを入力 ping 8.8.8.8 結果 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=104 time=1.60 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=104 time=1.70 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=104 time=1.69 ms 以下コマンドを入力 コマンド ping www.google.com 結果 PING www.google.com (172.217.175.100) 56(84) bytes of data. 64 bytes from nrt20s21-in-f4.1e100.net (172.217.175.100): icmp_seq=1 ttl=105 time=3.67 ms 64 bytes from nrt20s21-in-f4.1e100.net (172.217.175.100): icmp_seq=2 ttl=105 time=1.59 ms 64 bytes from nrt20s21-in-f4.1e100.net (172.217.175.100): icmp_seq=3 ttl=105 time=1.59 ms 64 bytes from nrt20s21-in-f4.1e100.net (172.217.175.100): icmp_seq=4 ttl=105 time=4.83 ms 64 bytes from nrt20s21-in-f4.1e100.net (172.217.175.100): icmp_seq=5 ttl=105 time=1.58 ms 以下のコマンドを入力して画像のように最後にcomplete!と出るはず。。。 コマンド yum install httpd 画像↓ 補足 ・ルートユーザーではないとデフォルトで一部操作権限が与えられていないコマンドがあります。 →適宜sudoコマンドを使って実行して下さい （今回はviコマンド・yumコマンド） ・一度解決してもEC2を再度立ち上げた際に同様のエラーが発生してしまう場合があります。 →こちらの記事を参考にしてください。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-static-dns-ubuntu-debian/

前回ファイルの実行と今回 前回のlex_create_bot.pyファイルを実行していませんでした。 今回を前回ファイルを実行しbotを作成。botと文字で会話するプログラムを解説し、botを動かして行きます。 前回ファイル lex_create_bot.py import boto3 import time iam = boto3.client('iam') iam.create_service_linked_role(AWSServiceName='lex.amazonaws.com') lex = boto3.client('lex-models', 'us-east-1') #フレーバーのスロットタイプの作成 flavor_slot_type = lex.put_slot_type( name='FlavorSlotType', enumerationValues=[ {'value': 'vanilla'}, {'value': 'chocolate', 'synonyms': ['choc']}, {'value': 'strawberry', 'synonyms': ['berry']} ], valueSelectionStrategy='TOP_RESOLUTION', createVersion=True) print('slot type:', flavor_slot_type['name']) #容器のスロットタイプを作成 container_slot_type = lex.put_slot_type( name='ContainerSlotType', enumerationValues=[ {'value': 'corn'}, {'value': 'cup'} ], valueSelectionStrategy='TOP_RESOLUTION', createVersion=True) print('slot type:', container_slot_type['name']) #インテントの作成 intent = lex.put_intent( name='OrderIntent', #インテント内のスロット slots=[ { 'name': 'Flavor', 'slotConstraint':'Required', 'slotType':'FlavorSlotType', 'slotTypeVersion': '1', 'valueElicitationPrompt': { 'messages': [{ 'contentType': 'PlainText', 'content': 'Vanilla, chocolate or strawberry?' }], 'maxAttempts': 3 } }, { 'name': 'Container', 'slotConstraint': 'Required', 'slotType': 'ContainerSlotType', 'slotTypeVersion': '1', 'valueElicitationPrompt': { 'messages': [{ 'contentType': 'PlainText', 'content': 'Corn or cup?' }], 'maxAttempts': 3 } } ], #発話例 sampleUtterances=[ 'I want {Flavor} ice cream in {Container}', '{Flavor} ice cream {Container}', 'ice create' ], #完了時のセリフ conclusionStatement={ 'messages': [{ 'contentType': 'PlainText', 'content': 'OK, {Flavor} ice cream in {Container}' }], }, #完了の動作 fulfillmentActivity={'type': 'ReturnIntent'}, createVersion=True) print('intent:',intent['name']) #ボットの作成 bot = lex.put_bot( name ='MyBot', locale='en-US', childDirected=False, #インテント intents=[ { 'intentName': 'OrderIntent', 'intentVersion': '1' } ], #中止時のセリフ abortStatement={ 'messages':[ { 'contentType': 'PlainText', 'content': 'Please try again.' } ] }, voiceId='Joanna', createVersion=True) print('bot:', bot['name']) #ボット作成の進捗表示 start = time.time() status = '' while status not in ['READY', 'FAILED']: #ボットを取得 status = lex.get_bot(name='MyBot', versionOrAlias='1')['status'] time.sleep(10) print('{:7.2f} {}'.format(time.time()-start, status)) #作成に失敗した場合は理由を表示 if status == 'FAILED': print(lex.get_bot( name='Mybot', versionOrAlias='1')['failureReason']) #ボットエイリアスを作成 bot_alias = lex.put_bot_alias( name='MyBotAlias', botName='MyBot', botVersion='1') print('bot alias:', bot_alias['name']) 実行しbotを作成します python lex_create_bot.py 実行結果 botが作成されました。筆者は先にロールやスロットを作成し、同じロールやスロットを何度も作成し怒られて時間がかかりました。(ちなみに先にロールやスロットを作してしまった際には作成した部分をコメントアウトしてスキップして下さい) botが作成されたのでbotと文字で会話するプログラムを作成します。 文字でbotと会話する 以下コードになります。 lex_chat_text.py import boto3 import uuid #①lex-runtimeサービスクライアント作成 lex_runtime = boto3.client('lex-runtime', 'us-east-1') #②ユーザーIDの作成 user = str(uuid.uuid1()) #③インテントが完了するまで続ける state = '' while state != 'Fulfilled': result = lex_runtime.post_text( botName='MyBot', botAlias='MyBotAlias', userId=user, inputText=input('You: ')) #ボットの応答の表示 print('Bot:', result['message']) #会話の状態を取得 state = result['dialogState'] #④取得したスロットの値の表示 print() print('Flavor :', result['slots']['Flavor']) print('Container :', result['slots']['Container']) ①lex_runtimeのサービスクライアントを作成します。bot作成ではlexのサービスクライアントを作成しますが、botの会話にはlexRuntimeサービスクライアントを使います。 ②ユーザーIDの作成 uuidを用いてランダムなユーザーIDを作成する。 ③会話の状態がFulfilledになるまで会話を続ける。 post_textメソッドを用いてbotに文字列を送信する。post_textメソッドの戻り値はresultに代入されます。result['message']でbotの応答を指定したりresult['dialogState']で会話の状態を取得します。 ④スロットの値を表示 post_textメソッドの戻り値であるresult内の['Flavor']や['Container']を取得して画面に表示します。 botとの文字での会話の実行 会話ファイルを実行しチョコレートアイスを注文、するとbotがcornかcupか聞いてcornと答えるとbotから最終の注文を答えてくれました。 補足ですがFlavorのみ答えても無視されます(笑) iceというワードが入ると認識してくれましたね、どうやらちゃんとワードを与えないとシカトされる可能性もあるのでお忘れなく。 まとめ 今回はlexを用いて簡単なbot作成とbotとの会話をご紹介しました。 参考文献 この記事は以下の情報を参考にして執筆しました AWSでつくるAIプログラミング入門

前回ファイルの実行と今回 前回のlex_create_bot.pyファイルを実行していませんでした。 今回を前回ファイルを実行しbotを作成。botと文字で会話するプログラムを解説し、botを動かして行きます。 前回ファイル lex_create_bot.py import boto3 import time iam = boto3.client('iam') iam.create_service_linked_role(AWSServiceName='lex.amazonaws.com') lex = boto3.client('lex-models', 'us-east-1') #フレーバーのスロットタイプの作成 flavor_slot_type = lex.put_slot_type( name='FlavorSlotType', enumerationValues=[ {'value': 'vanilla'}, {'value': 'chocolate', 'synonyms': ['choc']}, {'value': 'strawberry', 'synonyms': ['berry']} ], valueSelectionStrategy='TOP_RESOLUTION', createVersion=True) print('slot type:', flavor_slot_type['name']) #容器のスロットタイプを作成 container_slot_type = lex.put_slot_type( name='ContainerSlotType', enumerationValues=[ {'value': 'corn'}, {'value': 'cup'} ], valueSelectionStrategy='TOP_RESOLUTION', createVersion=True) print('slot type:', container_slot_type['name']) #インテントの作成 intent = lex.put_intent( name='OrderIntent', #インテント内のスロット slots=[ { 'name': 'Flavor', 'slotConstraint':'Required', 'slotType':'FlavorSlotType', 'slotTypeVersion': '1', 'valueElicitationPrompt': { 'messages': [{ 'contentType': 'PlainText', 'content': 'Vanilla, chocolate or strawberry?' }], 'maxAttempts': 3 } }, { 'name': 'Container', 'slotConstraint': 'Required', 'slotType': 'ContainerSlotType', 'slotTypeVersion': '1', 'valueElicitationPrompt': { 'messages': [{ 'contentType': 'PlainText', 'content': 'Corn or cup?' }], 'maxAttempts': 3 } } ], #発話例 sampleUtterances=[ 'I want {Flavor} ice cream in {Container}', '{Flavor} ice cream {Container}', 'ice create' ], #完了時のセリフ conclusionStatement={ 'messages': [{ 'contentType': 'PlainText', 'content': 'OK, {Flavor} ice cream in {Container}' }], }, #完了の動作 fulfillmentActivity={'type': 'ReturnIntent'}, createVersion=True) print('intent:',intent['name']) #ボットの作成 bot = lex.put_bot( name ='MyBot', locale='en-US', childDirected=False, #インテント intents=[ { 'intentName': 'OrderIntent', 'intentVersion': '1' } ], #中止時のセリフ abortStatement={ 'messages':[ { 'contentType': 'PlainText', 'content': 'Please try again.' } ] }, voiceId='Joanna', createVersion=True) print('bot:', bot['name']) #ボット作成の進捗表示 start = time.time() status = '' while status not in ['READY', 'FAILED']: #ボットを取得 status = lex.get_bot(name='MyBot', versionOrAlias='1')['status'] time.sleep(10) print('{:7.2f} {}'.format(time.time()-start, status)) #作成に失敗した場合は理由を表示 if status == 'FAILED': print(lex.get_bot( name='Mybot', versionOrAlias='1')['failureReason']) #ボットエイリアスを作成 bot_alias = lex.put_bot_alias( name='MyBotAlias', botName='MyBot', botVersion='1') print('bot alias:', bot_alias['name']) 実行しbotを作成します python lex_create_bot.py 実行結果 botが作成されました。筆者は先にロールやスロットを作成し、同じロールやスロットを何度も作成し怒られて時間がかかりました。(ちなみに先にロールやスロットを作してしまった際には作成した部分をコメントアウトしてスキップして下さい) botが作成されたのでbotと文字で会話するプログラムを作成します。 文字でbotと会話する 以下コードになります。 lex_chat_text.py import boto3 import uuid #①lex-runtimeサービスクライアント作成 lex_runtime = boto3.client('lex-runtime', 'us-east-1') #②ユーザーIDの作成 user = str(uuid.uuid1()) #③インテントが完了するまで続ける state = '' while state != 'Fulfilled': result = lex_runtime.post_text( botName='MyBot', botAlias='MyBotAlias', userId=user, inputText=input('You: ')) #ボットの応答の表示 print('Bot:', result['message']) #会話の状態を取得 state = result['dialogState'] #④取得したスロットの値の表示 print() print('Flavor :', result['slots']['Flavor']) print('Container :', result['slots']['Container']) ①lex_runtimeのサービスクライアントを作成します。bot作成ではlexのサービスクライアントを作成しますが、botの会話にはlexRuntimeサービスクライアントを使います。 ②ユーザーIDの作成 uuidを用いてランダムなユーザーIDを作成する。 ③会話の状態がFulfilledになるまで会話を続ける。 post_textメソッドを用いてbotに文字列を送信する。post_textメソッドの戻り値はresultに代入されます。result['message']でbotの応答を指定したりresult['dialogState']で会話の状態を取得します。 ④スロットの値を表示 post_textメソッドの戻り値であるresult内の['Flavor']や['Container']を取得して画面に表示します。 botとの文字での会話の実行 会話ファイルを実行しチョコレートアイスを注文、するとbotがcornかcupか聞いてcornと答えるとbotから最終の注文を答えてくれました。 補足ですがFlavorのみ答えても無視されます(笑) iceというワードが入ると認識してくれましたね、どうやらちゃんとワードを与えないとシカトされる可能性もあるのでお忘れなく。 まとめ 今回はlexを用いて簡単なbot作成とbotとの会話をご紹介しました。 参考文献 この記事は以下の情報を参考にして執筆しました AWSでつくるAIプログラミング入門