20210506のAWSに関する記事は23件です。

AWS環境をゼロから設計、構築してみた。

背景 今までゼロからインフラを構築する経験がなかった (別部署のインフラチームにオーダーして構築してもらうなどしていた)のですが、 自分で構築する機会があったので、他社事例などを参考にしながら構築してみた。 完成図 図は、draw.ioで書きました。デフォルトでAWSのアイコンセットがあり、必要なコンポーネントが揃っているためです。 手順 だいたい下記の手順に従って、構築したので忘備録とし残します。 1. VPC作成 Virtual Private Cloud (VPC) は、AWS アカウント専用の仮想ネットワークのこと。 VPCは、AWSクラウドの他の仮想ネットワークから論理的に切り離されている。 FYI : AWS Black Belt Online Seminar Amazon VPC Basic 2. subnet作成 VPCの中で、CIDRブロックを分割したネットワーク群をsubnetと呼びます。 外のネットワークと直接繋がっている「public subnet」と、直接は外のネットワークに繋ぐことのできない「private subnet」の2種類があります。 3. InternetGateWay作成 VPC内部とインターネットとの間の通信を可能にするためのものGatewayです。 ので、構築したVPCにアタッチすることで利用可能になります。 4. RouteTable作成とsubnet関連付け サブネット内の通信がどの宛先のネットワークに対して、どこに転送されるべきかを設定するのが、RouteTableの役割になります。 「public subnet」、「private subnet」毎にRouteTableを紐づけます。 これを紐づけることで、「public subnet」から出ていくときの通信経路、「private subnet」から出ていくときの通信経路を確保できます。 5. public-subnetと関連づけたRouteTableにInternetGateWayへのルート登録 例えば、「public subnet」であれば、外のインターネットと通信して欲しいので、 転送先に「InternetGateWay」を設定します。 「private subnet」からも外に通信してほしいケースがあるので、 「NatGateway」を「public subnet」に設置して「private subnet」からの転送先に「NatGateway」を指定します。 図でいう、「private subnet」 -> 「NatGateway」 -> 「InternetGateWay」への通信経路がこれで確保できます。 6. Route53設定 別AWSアカウントで取得しているドメインに対し、 さらに別AWSアカウントで構築した環境にサブドメインとして利用できるようにしたかったので、下記の作業を実施しました。 譲渡先アカウントでホストゾーン作成、NSレコードとSOAレコードが自動作成される。 譲渡元アカウントで上記のNSレコードを登録する。というステップが必要になります。 7. Certificate ManagerによるSSL証明書発行 画面の手順に従って、証明書を発行したドメインを入力していきます。 最後にroute53へのレコード登録ボタンが出てくるので、押下してあげることで利用可能になります。 8. FargateSpot構築 割愛。ここの構築は別の人に構築いただきました。 9. AuroraForPostgres構築とRoute53でCNAME登録 画面に従って、設定していきます。 構築後にエンドポイントが表示されるので、Route53のCNAMEレコードで、分かりやすい名称を設定します。 10. NatGateway作成 「public subnet」にNATGatewayを作成します。 ECS(Fargate)を設置する「private subnet」 のルーティング(0.0.0.0/0) を 「NATGateway」に設定します。 11. Application Load Balancer作成とRoute53でAレコード登録 後から設定するCloudFrontにて、 「インターネットアクセス」 -> 「CloudFront」 -> 「Application Load Balancer」となるのですが、 一旦 「ドメイン名」のAレコードに、「Application Load Balancer」を設定します。 12. ElatiCacheForRedis構築とRoute53でCNAME登録 画面に従って、設定していきます。 構築後にエンドポイントが表示されるので、Route53のCNAMEレコードで、分かりやすい名称を設定します。 13. セキュリティグループ設定 完成図でいう赤枠の箇所がセキュリティグループを設定した箇所になります。 必要な経路に必要なアクセスポートを設定します。 14. CloudWatch Alarm Alertは通知先にslackを設定したので、chatbotとSNSを組み合わせます。 Cloudwatchで監視する項目は、下記のシンプルなリソース監視を設定します。diskはS3を使用する想定です。 ALBのアラート作成(HTTPCode_Target_5XX_Count) redis memory / cpu Aurora memory / cpu fargate memory / cpu 15. Session Manager 今回、Session Managerを用意することで、踏み台サーバの構築をなくしました。 Session Manager経由でEC2にアクセスし、そこから必要に応じてコンポーネントを利用します。 Session Managerでのコマンド実行履歴は、「CloudWatchLogs」に転送するように設定したので、 誰がいつどのような操作をしたかを確認することができます。 踏み台サーバも構築していないのでよりセキュアな環境になります。 FYI : セッションマネージャーのハマりどころをパターンごとに整理してみる 16. VPCエンドポイント 下記4つのVPCエンドポイントが必要になります。 参考にしたクラスメソッドの記事がよくまとまっていて助かりました。 com.amazonaws.region.ssm com.amazonaws.region.ec2messages com.amazonaws.region.ssmmessages com.amazonaws.region.s3 FYI : セッションマネージャーのハマりどころをパターンごとに整理してみる 17. CloudFront CloudFront用証明書発行します。(仕様でバージニア北部リージョンで発行する必要があります) Behaviorで、ルーティング先を「Application Load Balancer」に設定します。 18-1. Route53 「ドメイン名」のAレコードに、「CloudFront」に設定します。 これでドメインにアクセス時、「CloudFront」を経由する形になります。 18-2. 「Application Load Balancer」のルール変更 「CloudFront」からのアクセスのみ処理するように、HTTPヘッダーに 「CloudFront」から渡される値を設定します。 18-3. CloudFront キャッシュ用S3 バケット作成 コンソールでS3バケットを作成します。外部からのアクセスは許可しない設定にしておきます。 18-4. CloudFront Origin Access Identity 設定 「CloudFront」からのアクセスのみ許可したいので、この設定を行います。 設定途中で指定したS3バケットにポリシーを反映するか確認する項目があるので、選択します。 19. WAF for CloudFront / WAF for Application Load Balancer 必要に応じて、ルールを設定します。 基本的にマネージドルールを採用し、できるだけセキュアな設定にします。 20. ClouFront for WAF ログ出力 cloudFront用のfirehoseは仕様で「バージニア北部リージョン」で構築する必要があります。 また、firehoseから出力するS3バケットもfirehoseと同じリージョンで構築する必要があるため、「バージニア北部リージョン」で構築します。 FYI : CloudFrontのログをAWS WAF + FirehoseでS3に送信しようとしてハマった話 21. ALB for WAF ログ出力 「Cloufront for WAF」で設定した手順とほぼ同等になります。今度は「東京リージョン」で構築すれば良いです。 最後に 実際に手を動かしてみてハマってみないと「だからこの設定が必要なのか」「確かにこの設定は分かりづらいし、気づけない」 「どこがおかしいかわからない」といったことが実感できないなと改めて感じました。 と同時に、AWSのリファレンスやBlackBeltを読むだけでは直感的にイメージが湧きにくく、 やはりクラスメソッドの記事は頼りになるなと感謝の気持ちでいっぱいです。 今回ゼロから構築できたので、だいたいこれくらいの時間あればできそうだなという勘所と、 ベストプラクティスの知見も得られたので、自身の成長につながったかなと実感できました。 やはり、今までできなかったことができるようになるのは楽しいですね!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS console ログイン 簡単(ルートユーザーではなくIAMユーザーで入る)

メールアドレスでログイン 毎回セキュリティチェックで文字を入力する AWS console ログイン 面倒 簡単にしたい。 結論:IAMユーザーを作る。 アカウントID、ユーザー名、パスワードだけでログインできる。 制限かかったアカウントなのでは? 全部使えるアカウントが欲しい ポリシーで「AdministratorAccess」をチェック ※公式の5.-d.より 詳しいことは
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSデプロイ時、Node.jsで困った話

環境 Ruby 3.0.1 Rails 6.1.3 Amazon Linux 2 AMI エラー AWSにアプリをデプロイしようとしていた時、 bundle exec rake assets:precompile RAILS_ENV=production でプリコンパイルを行った際、何やら長文のエラーが起きました。 よく読んでみると何やら原因らしきものを発見 error /var/www/rails/myapp/node_modules/node-sass: Command failed. 原因 どうやら最新のバージョンのNode.jsではnode-sassは非推奨のようです。 とりあえずでNode.jsをインストールしたため、最新バージョンがインストールされていました。 $ nvm install node Downloading and installing node v16.1.0... $ node -v v16.1.0 解決方法 Node.jsのバージョンを下げることで解決しました。 バージョンは、公式サイトでも推奨版とされている14.16.1 手順 $ nvm ls-remote で変更可能なバージョンを確認 $ nvm install 14.16.1 Downloading and installing node v14.16.1... Downloading https://nodejs.org/dist/v14.16.1/node-v14.16.1-linux-x64.tar.xz... ############################################################################################################################## 100.0% Computing checksum with sha256sum Checksums matched! Now using node v14.16.1 (npm v6.14.12) $ nvm use 14.16.1 Now using node v14.16.1 (npm v6.14.12) で変更完了! $ bundle exec rake assets:precompile RAILS_ENV=production Yarn executable was not detected in the system. Download Yarn at https://yarnpkg.com/en/docs/install Yarn executable was not detected in the system. Download Yarn at https://yarnpkg.com/en/docs/install Yarn not installed. Please download and install Yarn from https://yarnpkg.com/lang/en/docs/install/ Exiting! 無事、プリコンパイルが完了しました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Cost ExplorerのデータをRedshiftに統合してLookerで可視化する

概要 AWSを利用する上でコストを分析することは、コスト削減のために重要です。 AWS Cost ExplorerはAWSのコストに関する情報を取得することができるサービスであり、コスト分析に対する強力なツールとなります。 例えば、他のサービスの使用状況やコストについての情報と組み合わせて、グラフを作成することは分析に効果的です。 しかし、新しくデータが増える度にデータをダウンロードして最新の状態にし、グラフを作り直すのは手間がかかる作業です。 そこで今回は、troccoという分析基盤向けデータ統合サービスを使い、レポート取得の自動化+DWHへの統合+可視化までやってみようと思います。 今回、データの転送手段として採用したtroccoは、AWS Cost Explorerの他にも、様々な広告・CRM・DBなどのデータソースに対応しています。 troccoの使い方まとめ(CRM・広告・データベース他) ゴール ↓画像のようにグラフをまとめたものを30分くらいで作り上げます(作成後は自動で最新値に更新することも可能です) こんな人におすすめ AWS Cost Explorerを利用しており、分析基盤やデータウェアハウスへのデータ移行を考えている方 様々なサービス利用に関する情報をまとめてひとつのサービスで管理したい方 管理画面からデータ取得を行う作業に疲れている方 1. DWHと同期する手段の選定 1-1. DWHの選定 まずはデータを集約する場所である、DWH(データウェアハウス)を選定します。 Amazon Redshift Google BigQuery MySQLやPostgreSQL 今回はAmazon Redshiftを利用することにします。 1-2. AWS Cost ExplorerのデータをAmazon Redshiftに転送する4つの方法 Amazon Redshiftにデータを集約することが決まったので、続いては転送するための手段を検討します。 1. AWS Cost Explorerのデータを管理画面からダウンロードし、手動でAmazon Redshiftにアップロードする 2. AWS Cost ExplorerとAmazon Redshiftの各APIを用いて、プログラムを書いて連携する 3. Embulkを利用し、自分で環境を構築する 4. troccoを利用し、画面上で設定する 1は単発の実行であれば問題はありませんが、定期的な取り込みを行うことを考えると毎回同じ作業を繰り返すことになり、手間と時間が取られます。 2は連携を始める前にAPIのキャッチアップ+プログラムを書く+環境構築の時間がかかり、エラー対応などの運用工数も継続的に発生します。 3も2と同じくEmbulkはある程度の専門知識が必要になり、自分で環境構築・運用を行うため、手間が発生します。加えてエラーの内容が少し専門的なためエラーの解消に時間が取られる可能性があります。 そこで今回はEmbulkの課題も解決し、プログラムを書かずに画面上の設定のみで作業が完結する、4のtroccoというSaaSを利用します。 2. troccoでAWS Cost Explorer→Redshiftの転送自動化 2-0. 事前準備 データの転送のためにはtroccoのアカウント・AWSのアカウントが必要です。 無料トライアルを実施しているので、事前に申し込み・登録しておいてください! https://trocco.io/lp/index.html (申込の際に、この記事を見た旨を記載して頂ければご案内がスムーズに行えます) 2-1. 転送元・転送先を決定 troccoにアクセスして、ダッシュボードから「転送設定を作成」のボタンを押します。 転送元に「AWS Cost Explorer」を指定し、転送先に「Redshift」を選択して転送設定作成ボタンを押します。 すると、設定画面になるので、必要な情報を入力していきます。 2-2. AWS Cost Explorerとの連携設定 あとで見たときに自分で分かるように転送設定の名前とメモを入力します。 次に「転送元の設定」内の「接続情報を追加」ボタンを押します。 別タブで接続情報の新規作成画面が開きますので、必要事項を記入して保存ボタンを押します。 再度転送設定画面に戻り、接続情報の「再読込」ボタンを押すと、先ほど作成した接続情報が選択できるようになります。 これでAWS Cost Explorerとの連携は完了です。 2-3. AWS Cost Explorerからのデータ抽出設定 次に、どのようなデータを取得するかを設定していきます。 ここではUnblededCostのデータを取得してみます。 指標で「UnblededCost」を指定し、データ取得期間を指定します。 2-4. 転送先Redshiftの設定 転送元と同様に設定していきます。 転送先とするデータベース名、スキーマ、テーブルを設定します。 また、一時的にデータを保存するS3バケットとプレフィックスを指定してください。 最後に転送モードを選択します。insertとすることでテーブルにデータを追加することができます。 これで入力は完了です。「保存して自動データ設定・プレビューへ」をクリックし、確認作業に進みましょう。 2-5. データのプレビュー 少し待つと、転送元のデータがプレビューされます。ここではAWS Cost Explorerから取り込んだデータが表示されています。 転送したいデータが取れているので、このまま「確認画面へ」で次に進みます。 次の画面では転送設定の内容確認を行うので、設定の確認が終了したら右下の「適用」のボタンを押します。 2-6. スケジュール・通知設定 「スケジュール・トリガー設定」タブを開きます。 「スケジュールを追加」ボタンを押すと、以下の画像のような入力欄が出てきます。ここで実行スケジュールを設定することで、転送を定期的に実行し自動化することが出来ます。 2-7. データ転送ジョブの実行 設定は以上です。最後に、手動で転送ジョブを実行し、Redshiftにデータを送ります。 手動で実行する場合はジョブ詳細画面の「実行」ボタンを押します。 これで転送は完了です! 3. Redshiftの設定 特に設定することありません。データが転送されているので、今すぐに分析・可視化を行うことが出来ます。 データがきちんと送られているかをプレビューで確認してみます。 転送されていることが確認できました! 4. Lookerで可視化 それでは、これらのデータをLookerで可視化していきます。 まずはRedshiftとLookerを接続の設定を行います。 管理タブを開いて「Database」の「Connections」を開きます。 接続しているデータベース一覧が表示されています。ここで「Add Connection」→「Database Connection」から接続するデータベース情報を入力します。 Redshiftのデータベースに接続できたら、次はデータを可視化するために必要なLookMLプロジェクトを作成していきます。 開発タブを開いて「LookMLプロジェクトの管理」に移動します。 「New LookML Project」から新しいLookMLプロジェクトを作成します。 「Create Project」を押したら、エディタでmodelとviewを定義します。 後々必要になるので、modelの中ではexploreを設定しておきましょう。 (書き方が分からない場合はLookerの公式ドキュメントを参照してください) これでグラフを作る準備が整いました。 トップページに戻って「New」からDashboardを作成します。 白紙のダッシュボードができました。ここに各種グラフを追加していきます。まず「Dashboardの編集」を押します。 続いて、「タイルの追加」を押して、新しいグラフを作成していきます。 先ほどのmodel内で定義したExploreを選択します。 DIMENSIONSにグラフの横軸に表示したいデータ、MEASURESにグラフの縦軸に表示したいデータを設定し、Tileに表示したいデータをプロットします。ここでは日毎のコストをまとめてみます。 これで一つTileが完成しました。この調子で他のTileも作成すると、今回のゴールであるAWS Cost Explorerのデータダッシュボードが出来上がります。 まとめ いかがでしたでしょうか。troccoを使うとAWS Cost Explorerの管理画面を触ることなく、簡単にデータを取得し、DWH(Redshift)に貯めることが出来ます。 Redshiftにデータを貯めると、Lookerと連携することでデータを使ってグラフを作り、可視化できます。 実際に弊社サービスのtroccoにおいても、マーケティングKPI等をこのような流れで収集・分析しています。 ぜひ広告データ分析の際にはご活用ください。 https://trocco.io/lp/index.html 実際に試してみたい場合は、無料トライアルを実施しているので、この機会にぜひ一度お試しください。(申込時に、この記事を見た旨を記載して頂ければスムーズにご案内することができます) その他にも広告やデータベースなど、様々な分析データをETL・転送した事例をまとめました。 troccoの使い方まとめ(CRM・広告・データベース他)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

(備忘録)AWS認定試験テキストAWS認定クラウドプラクティショナーのデモ(ストレージサービス)

1. はじめに 2021年5月6日にヤマムギ様主催にて開催されたvol.20 AWS認定試験テキストAWS認定クラウドプラクティショナーのデモ(ストレージサービス)でのAWS学習内容について、自分への備忘録としてまとめてみました。ご参考になれば幸いです。 2. 学んだ内容 EBS EBSボリューム ボリュームタイプ(gp2、gp3、io1、io2、sc1、st1、standard) S3 パブリックアクセスブロック 3. 学習サイト YouTube:Amazon S3基本のデモ 4. 参考サイト One Page Website Template 404 5. ハンズオンで得た豆知識 EC2 Windowsサーバから2つのEBSボリュームにアタッチ アクションメニューからボリュームの変更(容量変更)が可能 ボリュームタイプはgp3を選ぶとよい ボリュームタイプ マグネティク(standard)は古いので選ぶ必要はない lopsは読み込み速度のこと EBSはアベイラビリティゾーンに保存されている スナップショットを定期的にとるとよく、内部的にリージョンのS3に保存されている スナップショットはポリシースケジュールにて、自動保存可能 暗号化はサーバサイトで暗号化される インスタンスストアという、EC2内部ストレージが扱えるインスタントタイプもある EBSには、サーバダウン時にも保存しておきたいデータを保存する インスタンスストアには、サーバダウン後にアクセスできないことを理解しておくこと S3は容量確保の必要はなく、使用容量に課金され無制限で利用できる S3はリージョン上の3つのアベイラビリティゾーンで保存されている S3 → アクション → 公開 インラインポリシー(S3:ListBacket) // EC2 Linux から S3 へファイルアップロード cd ~ ls python3 s3upload.py 6. おわりに AWS学習の参考になれば幸いです。 ハンズオン開催してくださいましたヤマムギ様、感謝いたします。 2021/05/06 NISHIZONO Takahiro
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSとWordPressを使ってWebサイトを構築しよう⑥

仮想サーバー(EC2インスタンス)を構築しよう 前回はネットワーク周りの設定をしましたが、この記事では前回作成したパブリックサブネット内に仮想サーバーを構築していきます。 目次 1.全体感をイメージする 2.インスタンスを作成する 3.インスタンスの起動と停止 1. 全体感をイメージする まずは全体感をイメージするために下記画像を見てください。 今回は赤枠で囲ったWEBサーバーという仮想サーバーを構築します。 パブリックサブネット内にあるWebサーバーを構築する際にまず最初に仮想サーバーを構築していきます。 仮想サーバーはEC2というサービスを用いて作成します。(EC2で作成された仮想サーバーのことをインスタンスと言います。) インスタンスを作成後、インスタンスにWebサーバーソフトをインストールしていきWebサーバーを完成させます。 さらにインスタンスには2つのIPアドレスを持たせます。 ・パブリックIPアドレス:インターネットとの通信用 ・プライベートIPアドレス:VPC内での通信用 では早速インスタンスを作成していきましょう! 2. インスタンスを作成する 画面上部の入力バーに「EC2」と入力してください。 すると「EC2」のサービスを選択できるようになるので、「EC2」をクリックしてください。 EC2の画面へ移行したら、まずは右上のリージョン選択バーより現在のリージョンが「東京」になっていることを確認してください。 (もし東京になっていない場合は「アジアパシフィック (東京)ap-northeast-1」を選択して、リージョンを東京に変更してください。) 次に左メニューから「インスタンス」を選択し、画面右上の「インスタンスを起動」をクリックしてください。 次にAMI(Amazon Machine Image)を選択していきましょう。 AMIとはソフトウェアの構成を記録したテンプレートのことで、簡単に言うとサーバーのセーブデータのようなものです。 これによりある時点でAMIを取得しておけば何か誤ってサーバーに設定をしてしまった場合でも、AMIからサーバーを起動し直すことでAMI取得時の状態に戻すことが可能となります。 今回は「Amazon Linux 2 AMI」を使用するので画像のように「選択」をクリックしてください。 次にインスタンスタイプを選択します。 インスタンスタイプとは仮想マシンのスペックのことで、今回は「t2.micro」を選択します。 t2.microはAWSのサインアップ日から12ヶ月間は無料利用枠の対象となっております。(無料利用枠の詳細は画面内緑色で「無料利用枠の対象」と記載のあるバーにカーソルを移すと詳細を見ることができます。) t2.microを選択したら画面右下の「次のステップ:インスタンスの詳細の設定」をクリックしてください。 「インスタンスの詳細の設定」画面へ移行するので下記画像を見ながら各項目それぞれ設定をします。 画像上部から順番に解説します。 ・ネットワーク:以前作成した「VPC」を選択 ・サブネット:以前作成した「Public_subnet」を選択 ・自動割り当てパブリックIP:「有効」を選択  →インターネットからインスタンスへ通信できるようにパブリックIPアドレスを作成します。なおここで割り当てられるパブリックIPアドレスは動的IPなので、インスタンス起動時にIPアドレスがランダムで変わります。 ・プライマリIP:「10.0.1.10」を入力  →ここではパブリックIPを設定します。Public_subnetは以前「10.0.1.0/24」の範囲でIPアドレスを設定したので、使用できるIPアドレスは「10.0.1.0〜10.0.1.255」までです。今回は10.0.1.10を設定します。 全て入力が終えたら画面右下の「次のステップ:ストレージの追加」をクリックしてください。 「ストレージの追加」画面へ移行したら、ここでは何も入力しないのでそのまま「次のステップ:タグの追加」ボタンをクリックしてください。 「タグの追加」画面へ移行するので、ここではインスタンスに名前を付けていきます。 まずは新しくタグを作成するので「タグの追加」をクリックしてください。 次に下記のように入力してください。 ・キー:「Name」と入力 ・値:「Webサーバー」と入力 入力後「次のステップ:セキュリティグループの設定」をクリックしてください。 「セキュリティグループの設定」へ移行したら、セキュリティグループを設定していきます。 インスタンスにアタッチするセキュリティを設定することができます。 下記のように入力してください ・セキュリティグループ名:「Web_security」と入力  →ここではセキュリティグループ名の入力のみで、他はデフォルト設定のままにしてください。 ※画像下に「警告」と表示されていますが、これはデフォルトのセキュリティ設定のままだとSSH接続(サーバーにリモートでログインして操作する時に使う接続方法)した際にどこからでも接続可能な状態になってしまい、悪意ある人からサーバーに接続されてしまう恐れがあります。 より安全に使用するためには「ソース」と記載ある箇所に「マイIP」という項目があり、「マイIP」を選択して自分のパソコンのパブリックIPからのみ接続可能にしたり、現在「0.0.0.0/0」と書かれてるIPアドレスを特定のIPアドレスに設定して、設定したIPアドレスからのみ接続可能にする方法があります。 セキュリティグループ名を入力したら「確認と作成」をクリックしてください。 「インスタンス作成の確認」へ移行すると、ここでは今まで設定してきたインスタンスの設定を確認できます。 「起動」ボタンをクリックしてください。 キーペアを作成する画面に移行しますので、ここでインスタンスにログインするために必要なキーペアを取得します。 まず「新しいキーペアの作成」を選択し、キーペア名に下記を入力してください。 キーペア名:「My_Keypair」と入力 キーペアを入力後「キーペアのダウンロード」をクリックしてください。 「キーペアのダウンロード」を選択すると「My_Keypair.pem」というファイルがダウンロードされます。 ダウンロードしたファイルは再びダウンロードし直すことはできないので必ず失くさないよう注意してください。失くしてしまうとインスタンスへログインできなくなります。 キーペアのダウンロードが完了したら「インスタンスの作成」ボタンをクリックしてください。 すると下記画像のようにインスタンスの作成が始まります。 次にインスタンスが作成されたか確認するため画面上部の検索バーに「EC2」と入力し、「EC2」をクリックしてください。 左メニューから「インスタンス」をクリックするとインスタンス一覧が表示されます。 そこに先ほど作成したインスタンス「Webサーバー」が作成されていればOKです。 さらに緑色の文字で「実行中」と書かれていればインスタンスが起動している状態で、「2/2のチェックに合格しました」と書かれていれば正常に起動している状態を表しています。 (インスタンス起動直後は画像のようなステータスにならないのでしばらく待ってから画面更新して確認してください。) ※インスタンスを起動している間は課金対象となるため必ず不要になったらインスタンスの停止や削除をしてください。 下記にイインスタンスの停止や削除方法を紹介していますので参考にしてください。 3. インスタンスの起動と停止 インスタンスを使っていない時はインスタンスを停止することで課金されなくなるので練習中はこまめにインスタンス停止してあげるといいでしょう。 しかしインスタンス作成時にストレージ(EBS)を追加しましたが、このストレージはインスタンス停止時も課金対象となります。 なので完全に課金を外したい場合はインスタンスを削除する必要があります。 インスタンスを削除することでストレージも開放されて課金されることがなくなります。 ■インスタンスの停止方法 停止したいインスタンスを選択すると、青色にバーが変わるのでそのバーの上で右クリックします。 するとインスタンスを操作できるメニューが開くので、その中から「インスタンスを停止」をクリックしてください。 ※「インスタンスを終了」を選択するとサーバーが削除されてしまうのでご注意ください。 するとインスタンスを停止するためのポップアップ画面が出るので「停止」をクリックしてください。 小さく赤枠で囲った「更新ボタン」をクリックすることでコンソール画面を更新することができます。 しばらくしてから更新ボタンをクリックするとインスタンスの状態が「停止済み」となります。 これでインスタンスを正常に停止することができました。 ■インスタンスの起動方法 インスタンス停止の時と同様に、起動したいインスタンスを選択し選択したインスタンス上で右クリックします。 「インスタンスを開始」をクリックしてください。(一見すると「インスタンスを起動」で起動するように見えますが「インスタンスを起動」を選択すると新しくインスタンスを作成する画面へ移行します。) 正常にインスタンスが起動されるとインスタンスの状態が「実行中」に、ステータスチェックの状態が「2/2のチェックに合格しました」と表示されます。 ■インスタンスの削除方法 まず削除したいインスタンスを選択して右クリックをし「インスタンスを終了」をクリックしてください。 ポップアップ画面が出てくるので「終了」をクリックしてください。 するとインスタンスの状態が「シャットダウン中」から「終了済み」となるので、これでインスタンスの削除は完了です。 今回はここまで。 次回は作成したEC2インスタンスへSSH接続してみましょう! 次の記事はこちらから AWSとWordPressを使ってWebサイトを構築しよう⑦
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】ElastiCacheのMemcachedとRedisの比較

プログラミング勉強日記 2021年5月6日 ElastiCacheの特徴  ElastiCacheはデータをノードのメモリに保存する。これによって高速でデータの出し入れを行うことができる。  ただ、メモリにデータを保存しているため再起動などでノードが落ちるとデータがなくなってしまうので、注意が必要。 Memcachedとは  Memcachedのクラスタは単純にノードを追加・削除して負荷を分散できる。しかし、これは自動検出の機能に依存している。  Memcachedはノードの状態をポーリングしてノードにアクセスをする。 ポーリングとは、「サーバーとクライアント」や「主システムと周辺機器」といった複数の機器を円滑に連携させる方法のひとつです。主に通信などの競合を回避するために、ホスト側が各機器に対して定期的に問い合わせを行い、条件を満たした場合に送受信や各種処理を行います。 引用:https://blogs.manageengine.jp/itom_what_is_polling/  Memcachedはマルチスレッドで動作するため、CPUのコア数を上げれば性能を上げられる。シンプルなデータしか扱うことができないので、複雑なデータを扱う場合はアプリ側で格納できる型に変更する必要がある。また、扱えるコマンドも少ない。 Redisとは  Redisにはいくつかの種類があるが、Memcachedクラスターとの違いはクラスターのエンドポイントを持っていること。Redisクラスターもノードの数を加減することで負荷の分散ができる。  Redisはクラスターがエンドポイントを持っているので、アプリ側でポーリングする必要がない。  Redisはシングルスレッドで動作するため、CPUのコア数を上げてもMemcachedほどパフォーマンスの向上を期待できない。Redisは豊富なデータ型を使うことができるだけでなく、正規表現を用いたキーの検索などget/setにも機能が豊富。 MemcachedとRedisの使い分け Memcachedを使うとき 単純なデータ型でいい場合 マルチスレッドを使用する場合 オブジェクトをキャッシュする必要がある場合 Redisを使うとき 複雑なデータ型が必要な場合 フェイルオーバーが必要な場合 永続化が必要な場合 参考文献 Memcached と Redis の比較 ElastiCacheはMemcachedとRedisのどっちを選ぶ?
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【1時間で実装】 Amazon SageMaker Studio の PySpark 実行環境

はじめに Sagemaker studio でとりあえず Pyspark 試したい。。 でも実装するには IAM とか VPC とか細かく設定しなきゃいけないっぽい。。しかも後ろで EMR が動いてるとかもう無理。。 そう思って断念しかけたのですが、とても便利なテンプレートがありました!!! こちらの記事で紹介されている CloudFormation スタックのテンプレートです。 以下のリンクからスタックの作成画面に飛びます。 https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=blog&templateURL=https://aws-ml-blog.s3.amazonaws.com/artifacts/ml-1954/template.yaml 実装手順 今回はとにかく最小限の労力で SageMaker Studio で PySpark が使える環境を作ることを目的としています。(なので、権限設定やネットワークについてはデフォルトの設定で行います) スタックの作成 以下のテンプレートリンクをクリックして AWS のコンソールにサインインし、スタックの作成画面を開く(サインインしたら自動で遷移します)。「次へ」をクリック。 https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=blog&templateURL=https://aws-ml-blog.s3.amazonaws.com/artifacts/ml-1954/template.yaml スタックの詳細を指定の画面。「次へ」をクリック。 スタックオプションの設定の画面。「次へ」をクリック。 レビューの画面まで来たら一番下までスクロール。 「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」にチェックを入れ、「スタックの作成」をクリック。 スタックの作成の進捗画面です。スタック名の下の「CREATE_IN_PROGRESS」が「CREATE_COMPLETE」になるまで待ちます。大体15分くらいかかります。 「CREATE_COMPLETE」になりました。 SageMaker Studio の起動 次に SageMaker を開きます。コンソールの検索窓に「sagemaker」と入力し、「Amazon SageMaker」をクリック。 「Open SageMaker Studio」をクリック。 「defaultuser」というユーザーが作成されています。このユーザーの「Studioを開く」をクリック。 ブラウザの別タブで Amazon SageMaker Studio が開いたら「File」→「New」→「Terminal」をクリック。 ターミナル画面が開きます。 ここに以下のコマンドを打ち込みます。(最後の"."忘れに注意) aws s3 cp s3://aws-ml-blog/artifacts/ml-1954/smstudio-pyspark-hive-sentiment-analysis.ipynb . 左のウインドウにノーブックファイルがコピーされていることが確認できます。これを開きます。 ノートブックを開くにはカーネルを選択する必要があります。「PySpark(SparkMagic)」を選択し、「Select」をクリック。 マネジメントコンソール画面に戻ってEMRの画面を開きます。検索窓に「emr」と入力し「EMR」をクリック。 クラスターが作成されています。クラスターの「ID」をコピーします。 次に SageMaker Studio の画面に戻り、以下のように記載されているセルの"x-XXXXXXXXXXXX"の部分を先ほどのクラスターの「ID」に書き換えて実行します。 %%local emr_cluster_id="x-XXXXXXXXXXXX" その次に以下のコマンドが書いてあるセルを実行します。 %%local !sm-sparkmagic connect --cluster-id {emr_cluster_id} --user-name "user1" ここまでできたら「Launch terminal icon」をクリック。 ターミナル画面が開くので"kinit user1"と打ち込んで実行。初期パスワードは"pwd1"に設定されています。 任意の新しいパスワードを入力し、そのパスワードを再度入力します。 ノートブックのタブに戻り、「Restart kernel icon」をクリック。 カーネルが再起動したら、 %%info を実行します。以下のような出力がでていればokです。 Current session configs:{'driverMemory': '1000M', 'executorCores': 2, 'kind': 'pyspark'} No active sessions. PySpark の実行 SparkSessionを生成します。 from pyspark.sql import SparkSession spark = SparkSession.builder.getOrCreate() "SparkSession available as 'spark'"と表示されればokです。 サンプルノートの後続のコードを PySpark でやってみます。 dbs = spark.sql("show databases") dbs.show() tables = spark.sql("show tables") tables.show() 実行可能であることが確認できます。 おわりに Amazon SageMaker Studio で PySpark を実行できる環境を作成しました。 テンプレート、ほんとに便利です。。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SSO のアカウント割り当てを特定ユーザーやグループに委任する

はじめに AWS SSO で管理する AWS アカウントが増えてくると、アクセス制御設定を行う管理者の作業負荷も高くなっていきます。以下の AWS Security Blog でアクセス権限セットの作成とアカウントの割り当ての制御を特定のユーザーやグループに委任する方法が紹介されていました。 上記の Post では権限セットに付与するカスタム権限ポリシーのタグと Condition 要素を使用して以下の 3 つのパターンで制御を行う方法が記載されています。 アカウント ID ベースの委任モデル 権限セットベースの委任モデル OU ベースの委任モデル 本記事では OU ベースの委任モデルについて検証した内容やその際の補足手順等を交えて記載しています。前提として AWS SSO の設定そのものについては詳しく記載しません。また参考として記載する権限セットのカスタムアクセス権限ポリシーは外部 IdP と連携した環境を想定しています。 OU ベースの委任モデルの注意点 前述のとおり、あくまで権限セットに付与するカスタム権限ポリシーのタグと Condition 要素を組み合わせた手法であるため、AWS Organizations の OU-ID (ou-xxxx-yyyyyyyy) を使用した制御ではないことに注意してください。詳細は後述しますが、カスタムアクセス権限ポリシーにアカウント ID をリストする必要があるため、OU に新規アカウントが追加される都度、ポリシーを更新する必要があります。 委任用権限セットの作成 最初に特定のユーザー、グループへ権限セットの作成やアカウント割り当てを委任するための権限セットを作成します。ここでは Sandbox という OU の配下にあるアカウントに対するアカウント割り当て権限を委任する例を考えます。今回は CloudFormation で権限セットを作成したため、最終的なテンプレートは以下のようになりました。アクセス権限ポリシーは AWS Security Blog に記載の内容から若干カスタマイズしています。 template.yaml Parameters: pAwsSsoInsanceArn: Type: String Default: arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx Description: No change required. Resources: rPermissionSetSandboxDelegatedAdmin: Type: AWS::SSO::PermissionSet Properties: InstanceArn: !Ref pAwsSsoInsanceArn Name: SandboxDelegatedAdmin Description: "Sandbox Delegated Administrator" ManagedPolicies: - arn:aws:iam::aws:policy/AWSSSOReadOnly RelayStateType: https://ap-northeast-1.console.aws.amazon.com/singlesignon/home?region=ap-northeast-1#/accounts/organization SessionDuration: "PT1H" Tags: - Key: "OU" Value: "None" InlinePolicy: { "Version": "2012-10-17", "Statement": [ { "Sid": "DelegatedOUAdmin", "Effect": "Allow", "Action": [ "sso:CreatePermissionSet", "sso:DeletePermissionSet", "sso:UpdatePermissionSet", "sso:ProvisionPermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:TagResource" ], "Resource": "arn:aws:sso:::permissionSet/*/*", "Condition": { "StringEquals": { "aws:ResourceTag/OU": [ "Sandbox" ] } } }, { "Sid": "Instance", "Effect": "Allow", "Action": [ "sso:CreatePermissionSet", "sso:DeletePermissionSet", "sso:UpdatePermissionSet", "sso:ProvisionPermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:TagResource" ], "Resource": [ "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx", "arn:aws:sso:::account/123456789012", "arn:aws:sso:::account/111111222222" ] }, { "Sid": "AllowRootPermissionSet", "Effect": "Allow", "Action": [ "sso:ProvisionPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment" ], "Resource": "arn:aws:sso:::permissionSet/*/*", "Condition": { "StringEquals": { "aws:ResourceTag/OU": [ "Root" ] } } }, { "Sid": "DenyRootPermissionSet", "Effect": "Deny", "Action": [ "sso:DeletePermissionSet", "sso:UpdatePermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:PutInlinePolicyToPermissionSet", ], "Resource": "arn:aws:sso:::permissionSet/*/*", "Condition": { "StringEquals": { "aws:ResourceTag/OU": [ "Root" ] } } }, { "Sid": "AllowSsoDirectory", "Effect": "Allow", "Action": [ "sso-directory:DescribeDirectory", "sso-directory:DescribeGroups", "sso-directory:DescribeUsers", "sso-directory:ListGroupsForUser", "sso-directory:ListMembersInGroup", "sso-directory:SearchGroups", "sso-directory:SearchUsers" ], "Resource": "*" } ] } 以降、部分毎に補足します。 InstanceArn InstanceArn には SSO インスタンスの ARN を指定します。 Parameters: pAwsSsoInsanceArn: Type: String Default: arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx Description: No change required. Resources: rPermissionSetSandboxDelegatedAdmin: Type: AWS::SSO::PermissionSet Properties: InstanceArn: !Ref pAwsSsoInsanceArn Name: SandboxDelegatedAdmin Description: "Sandbox Delegated Administrator" AWS SSO コンソールの設定画面から確認するか、sso-admin の list-instances から取得します。 $ aws sso-admin list-instances { "Instances": [ { "InstanceArn": "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx", "IdentityStoreId": "d-xxxxxxxxxx" } ] } ManagedPolicies 委任するユーザー、グループに AWS SSO コンソールへの読み取りアクセスを提供するため、AWS 管理ポリシーの AWSSSOReadOnly をアタッチしています。特定の設定レベルで参照を許可したい場合は権限が大きすぎる場合もあるかと思いますので、適宜カスタムポリシーをご使用ください。 ManagedPolicies: - arn:aws:iam::aws:policy/AWSSSOReadOnly RelayStateType RelayStateType では SSO による認証後にユーザーをリダイレクトする URL を指定できます。今回のようなケースでは AWS SSO の URL を指定することでユーザーはすぐにアカウント割り当て操作を始めることができます。 RelayStateType: https://ap-northeast-1.console.aws.amazon.com/singlesignon/home?region=ap-northeast-1#/accounts/organization Tags タグに指定された OU の値で、委任されたユーザー、グループが対象の権限セットをアカウントに割り当てできるかを制御します。この権限セットは自由に割り当ててほしくないため、OU 名ではない別の値 (ここでは None) を指定しています。 Tags: - Key: "OU" Value: "None" InlinePolicy カスタムアクセス権限ポリシーを記載しています。 長いので更に 4 項目に分けて補足します。 OU 固有の権限セットをフィルタリングするポリシー アカウントをフィルタリングするポリシー 組織で共有する権限セットをフィルタリングするポリシー AWS SSO Directory にアクセスを許可するポリシー 以下のステートメントは OU 固有の権限セットをフィルタリングするポリシーです。Resource および Condition 要素を使用して、OU タグに Sandbox とつけられた権限セットにのみ書き込み権限および、アカウントへのアクセス割り当てを許可します。 { "Sid": "DelegatedOUAdmin", "Effect": "Allow", "Action": [ "sso:CreatePermissionSet", "sso:DeletePermissionSet", "sso:UpdatePermissionSet", "sso:ProvisionPermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:TagResource" ], "Resource": "arn:aws:sso:::permissionSet/*/*", "Condition": { "StringEquals": { "aws:ResourceTag/OU": [ "Sandbox" ] } } } 以下のステートメントは AWS アカウントをフィルタリングするためのポリシーです。Resources 要素を使用して SSO Instance と Sandbox OU に所属するアカウントをリストします。明示的にアカウント ID をリストしているため、このポリシーは OU に属するアカウントに変更が発生する度に編集する必要があります。 { "Sid": "Instance", "Effect": "Allow", "Action": [ "sso:CreatePermissionSet", "sso:DeletePermissionSet", "sso:UpdatePermissionSet", "sso:ProvisionPermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:TagResource" ], "Resource": [ "arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx", "arn:aws:sso:::account/123456789012", "arn:aws:sso:::account/111111222222" ] }, 以下のステートメントは組織内で共有する権限セットをフィルタリングするポリシーです。AdministratorAccess や ViewOnlyAccess などの既存の職務機能ポリシーを使用する権限セットに関しては特定 OU ではなく、組織全体で使用するケースが考えられます。そのような共通の権限セットには OU タグに Root (任意の値でOK) を設定しておき、アカウント割り当てを許可します。ただし共有の権限セットに対する編集権限は Deny します。 { "Sid": "AllowRootPermissionSet", "Effect": "Allow", "Action": [ "sso:ProvisionPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment" ], "Resource": "arn:aws:sso:::permissionSet/*/*", "Condition": { "StringEquals": { "aws:ResourceTag/OU": [ "Root" ] } } }, { "Sid": "DenyRootPermissionSet", "Effect": "Deny", "Action": [ "sso:DeletePermissionSet", "sso:UpdatePermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:PutInlinePolicyToPermissionSet", ], "Resource": "arn:aws:sso:::permissionSet/*/*", "Condition": { "StringEquals": { "aws:ResourceTag/OU": [ "Root" ] } } } 以下のステートメントは AWS SSO Directory へのアクセスを許可するポリシーです。Managed Policy にアタッチした AWSSSOReadOnly は AWS SSO Directory に対する権限が sso-directory:DescribeDirectory のみしか含まれていないため、外部 IdP から SCIM で連携されたユーザー, グループ情報を検索するために必要な権限を追加で付与します。 { "Sid": "AllowSsoDirectory", "Effect": "Allow", "Action": [ "sso-directory:DescribeDirectory", "sso-directory:DescribeGroups", "sso-directory:DescribeUsers", "sso-directory:ListGroupsForUser", "sso-directory:ListMembersInGroup", "sso-directory:SearchGroups", "sso-directory:SearchUsers" ], "Resource": "*" } CloudFormation でテンプレートをデプロイし、委任用の権限セット (SandboxDelegatedAdmin) を作成します。 委任用権限セットを割り当てる AWS SSO の操作を委任するユーザーまたはグループに AWS SSO が動作する組織の管理アカウントへのアクセスを割り当てを行います。権限セットは先ほど作成した SandboxDelegatedAdmin を指定します。 動作確認 AWS SSO にサインインし、割り当てた権限セットが表示されることを確認します。 SandboxDelegatedAdmin でマネジメントコンソールを開くと、RelayStateType の指定に従い、AWS SSO の AWS アカウント画面に遷移します。 権限セットの作成、変更、削除 OU 固有の権限セットをフィルタリングするポリシーにより、OU タグに Sandbox とつけられた権限セットのみ作成、変更、削除が可能になります。例えば OU タグに Sandbox ではなく、Test を指定して権限セットを作成しようとすると以下のように権限エラーとなります。 OU タグに Sandbox を指定すると権限セットの作成に成功します。 アカウント割り当て アカウントをフィルタリングするポリシーにより、ポリシーにリストされていないアカウント (Sandbox OU 外のアカウント) に対して割り当てを行なうと以下のように権限エラーとなります。 アカウントをフィルタリングするポリシーにリストされているアカウント (Sandbox OU 内のアカウント) であっても、OU タグが Sandbox または Root 以外の権限セットを割り当てようとした場合は権限エラーになります。厳密にはアカウントに対するロールのプロビジョニングは行われますが、実際のユーザー/グループへの割り当てには失敗します。 アカウントをフィルタリングするポリシーにリストしたアカウントに対し、OU タグに Sandbox がセットされた権限セットを指定すると想定通り正常に割り当てることができました。 まとめ 委任用の権限セットに付与するカスタムアクセス権限ポリシーのタグと Condition 要素を組み合わせることで、特定の OU に絞った形で任意のユーザー/グループに権限セットの作成とアカウントの割り当ての制御を委任できることがわかりました。一方でこれを実現するためにはカスタムアクセス権限ポリシーに明示的にアカウント ID をリストする必要があるため、多くの OU が存在する環境や頻繁に新規アカウントが追加されるような環境では、委任用権限セットのメンテナンスにそれなりの運用コストがかかりそうです。 冒頭のブログで記載されてるポリシーには前提となる権限が一部省略されていたりもするので、検証した内容がどなたかの参考になれば幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

awsでデプロイする【初心者】

スクールのデプロイ手順 卒業してからも使うために忘備録。ところどころ違うかも知れませんので注意です。 目次 1.VPCを作成する 2.サブネットを作成する 3.インターネットゲートウェイを作成する 4.ルートテーブルを作成する (1~4まではdefaultで作成させることも出来る) 5.EC2を作成する 6.RDSを作成する 7.EC2にログインして設定を行う 8.デプロイの自動化をする 9.SSLの導入 1,VPCを作成する VPCとは「Virtual Private Cloud」の略で、物理的な環境(リージョン)上に構築する仮想ネットワークのこと。 今から作るEC2達が使える住所はここだよ~って定義してあげるもの(多分) サービスからVPCを選択 VPCをクリックしたら、オレンジ色のボタンのVPCを作成をクリックする 名前タグ-オプション 任意で決める。私は分からなくなっちゃうので、「VPC-for-アプリケーション名」で作成 IPv4 CIDR ブロック 住所を決める。この住所はプライベートなIPアドレスで、ルールが決められている IPアドレス範囲 CIDR表記 0.0.0.0 ~ 10.255.255.255 10.0.0.0/8 172.16.0.0 ~ 172.31.255.255 172.16.0.0/12 192.168.0.0 ~ 192.168.255.255 192.168.0.0/16 「172.31.0.0/16」とか、「192.168.0.0/16」とか入力 VPCを作成をクリック 2,サブネットを作成する サブネットはVPCで設定した中に、さらに小さな仮想ネットワークを作成するAWSのサービス。用途に合わせて、必要な仮想ネットワークを作成する。 VPCが東京都だとしたら、サブネットは新宿区とか渋谷区とかそんな感じのイメージ(多分。違うけどイメージはそんな感じ) 左からVPCの下にあるサブネットをクリックし、右のサブネットを作成をクリック VPC ID 先ほど作ったVPCを選択する。 このVPCを間違ってしまうと、うまく接続出来ない (さっきの例で行くと東京都新宿区なのに北海道新宿区みたいになって、住所が無いよ!ってなってしまう(多分)) VPCを選択するとサブネットの設定が出てくる サブネット名 任意の名前を入力。私は分からなくなってしまうので、「public-subnet-1a-for-アプリケーション名」で作成 アベイラビリティーゾーン アジアパシフィック(東京)のap-northeast-1aを選択。 (どのアベイラビリティーゾーンでもいいけど、私はサブネット名が-1aの時は1aで-1cの時は1cで命名している。) IPv4 CIDR ブロック サブネットのCIDRは被ってはいけない。(エラーが出る) (東京都に新宿区が2つあってはいけないみたいな(多分)) さっき、「172.31.0.0/16」で入力していたら、「172.31.0.0/20」と入力 「192.168.0.0/16」で入力していたら、「192.168.0.0/20」と入力。 サブネットを作成をクリック え?????被って無いの??????って私は最初なったので、後で解説を書いておこうかなと思う。 3,ゲートウェイを作成する 左のタブのルートテーブルを一つ飛ばして、ゲートウェイを作成する。 ゲートウェイは名の通りgate。インターネットと接続できるためのゲートを用意するもの。 左のタブのインターネットゲートウェイをクリックし、右上のインターネットゲートウェイの作成をクリックする 名前タグ 任意の名前を決める。私は分からなくなってしまうので「gateway-for-アプリケーション名」を入力 インターネットゲートウェイの作成をクリック 作成されましたみたいな画面になったら、VPCへアタッチをクリック 先ほど作成したVPCを選択して、インターネットゲートウェイのアタッチをクリック。 状態がAttachedだったらOK 4,ルートテーブルを作成する 「ルートテーブル」はAWS上の仮想的なネットワーク環境のことで、サブネット内のAWSリソース(EC2インスタンスなど)がどこに通信しにいくのかのルールを定めます。 ゲートウェイという門を作っても、道路が無いとインターネットを行き来できないので、ルートテーブルを作成するという感じ。 左のタブのルートテーブルをクリックし、今度は青いボタンのルートテーブルの作成をクリックする。 名前タグ 任意の名前を入力。私は分からなくなってしまうので、「public-route-table-for-アプリケーション名」と入力 VPC 先ほど作成したVPCを選択する 作成をクリック 次にルートテーブルとサブネットを紐づける。先ほど作成したルートテーブルのサブネットの関連付けのタブをクリック サブネットの関連付けの編集をクリック 先ほど作成したサブネットを選択し、保存 次にルートタブをクリックし、ルートの編集をクリック 今はローカルだけになっているので、ルートの追加をクリック。 送信先 0.0.0.0/0を入力 ターゲット 選択タブの Internet Gatewayを選択後、先ほど作成したゲートウェイが出てくるので、クリック 出てこなかったら、上の設定のどこかが違う可能性あり。 無事出てきたら、ルートの保存をクリック インターネットに接続するための住所と道路の確保が出来た状態になりました。 結構書くの時間かかった!EC2からは明日書きます
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2 Webサーバーを構築しよう①

はじめに EC2を学ぶ上での備忘録として EC2とは EC2とは「Amazon Elastic Compute Cloud」の略称で、AWSで利用できるシステムのひとつ。 伸縮性や弾力性を意味するElasticという言葉通り、ユーザーの必要に応じてスペックを変更できるのがEC2の魅力です。 継続利用時に起こりがちなスペック不足やディスク容量問題への対処も容易なコンピューティングキャパシティーであるため、長期的な運用も視野に入れることができます。 EC2では仮想サーバの事を「インスタンス」という単位で扱います。 インスタンスには様々な種類や性能のものがあるため、ユーザーの求める形で利用が可能です。 インスタンスを複数使って仮想サーバーを分割することで、可用性や信頼性を考慮した運用ができます。 インスタンスによって柔軟にWeb上のインフラ環境を構築することができるため、サーバーの増強が必要になった場合や、さらなる効率化を求めて改善が行われる際にも、対応がしやすく インスタンスはコピーも削除も簡単に行えるので、スピーディな業務レベルを維持可能です。 EC2のメリット EC2のメリットは大きく分けて4つあります。 簡単なスペック変更 従量課金によるコストメリット スピーディな構築による時間短縮 冗長化も簡単に行える 簡単なスペック変更 EC2最大の魅力は、サーバースペックの簡単な変更機能にあります。 内容によって大きく変動する要求スペックに対して柔軟な変更が可能な点は、サーバーの運用において大きなメリットになります。 サーバーの追加・削除、マシンスペック変更は数分で可能です。 OSより上のレイヤについては自由に設定できます。 従量課金によるコストメリット EC2は基本的に従量課金制であるため、実際に利用した分に対して請求が行われます。 サーバー運用にかかるコストをカットしたいときには、不要なサーバーを停止するといった対応をすることで利用時のコストメリットが大きくなります。 数分で起動し、1時間または秒単位の従量課金です。 スピーディな構築による時間短縮 ハードウェア設定が必要な物理サーバーなどを使う場合には、設定完了まで数日のタイムラグが発生することも珍しくありませんが、EC2によって構築されるシステムはわずか数分あれば立ち上げが完了します。 冗長化も簡単に行える 仮想サーバーのテンプレート化や複製が容易であるため、事前に複数台数を用意することで安定したサーバー運用を実現できます。 冗長化によって負荷の分散を行ったり、システム上に障害が発生しても全体の環境を維持することが可能であるため、万が一に備えながらのサーバー運用が可能です。 EC2の作成 EC2の作成手順 AMIの選択 インスタンスタイプの選択 ストレージの追加 セキュリティグループの設定 SSHキーペアの設定 AMIとは AMIとはAmazon Machine Imageの略です。インスタンス(サーバー)起動に必要な情報が入ったOSのイメージ。 サーバーのテンプレートのようなもの。 インスタンスタイプとは サーバーのスペックを定義したものです。 インスタンスタイプにより、CPU、メモリ、ストレージ、ネットワーク帯域が異なります。 インスタンスタイプのスペックの違いにより料金が異なります。当然、スペックが高いほど料金も高くなります。 アクセス数などに応じて必要なスペックのあるインスタンスタイプを選択する必要があります。 ストレージとは サーバーにくっつけるデータの保存場所。EC2のストレージには2種類あります。 EBS(Elastic Block Store)とインスタンスストアです。 EBS インスタンスストア             高い可用性と耐久性を持つストレージ インスタンス専用の一時的なストレージ 他のインスタンスに付け替え可能 他のインスタンスに付け替えができない   EC2インスタンスをStop/TerminateしてもEBSは保持可能 EC2インスタンスをStop/Terminateするとクリアされる Snapshotを取得しS3に保存可能 EBSの費用が別途発生     追加費用なし(無料)             OSやDBなどの永続性や耐久性が必要なデータを置く 一時的ファイル、キャッシュなど消えても問題ないデータを置く EC2を作ってみよう それでは実際にEC2インスタンスを作成していきます。 1.AMIの選択 EC2を検索し、クリックします。 EC2のページに移動しました。インスタンスをクリックします。 インスタンスを起動をクリックします。 まずはAMIを選択していきます。 クイックスタートや自分で作成したマイ AMIやサードパーティが作成したAWS Marcketplaceなどがありますが 今回はクイックスタートで作成していきます。 一番上にあるAmazon Linux 2 AMIを選択します。 選択するとインスタンスタイプの選択ページに遷移しました。 2.インスタンスタイプの選択 今回は無料枠での利用を考えているためt2.microを選択して次のステップに進みます。 インスタンスタイプの種類についてはこちら AWS EC2 インスタンスタイプ 次にインスタンスタイプの詳細を決めていきます。 インスタンス数は起動するインスタンスの数です。今回は1にします。 購入のオプションはスポットインスタンスを使うかということですが、今回は使用しません。 スポットインスタンスとは ネットワーク、サブネット任意のものを指定します。 自動割り当てパブリックIPはインターネット経由でアクセスするグローバルIPアドレスをつけるかどうかを選択します。インターネットからアクセスできるようにしたいので、今回は有効を選択します。 配置グループは複数のEC2インスタンス間の通信を高速化するグループです。今回はスルーします。 キャパシティーの予約はAWSではAZごとにリソースの上限が決まっていて、それを超えるとEC2インスタンスの起動ができなくなります。キャパシティの予約をしていると事前にリソースを確保してくれます。(別料金がかかります) 今回はチェックしません。 IAMロールはEC2インスタンスが他のAWSサービスと連携する際の権限を設定できます。 今回はなしにします。 シャットダウン動作はインスタンスをシャットダウンした時に停止状態で残すか、削除するかを設定します。 今回は停止で設定します。 終了保護の有効化はインスタンスを誤って終了しないように保護することができます。有効になると、終了保護を無効にしない限り、API や AWS Management Console を使用してこのインスタンスを終了できなくなります。 本番環境では設定することがあるようですが、今回は違うため設定しません。 モニタリングは通常5分間隔で設定されているところを1分間隔にすることができる設定です。 厳密にする必要は今回はないので設定しません。 テナンシーはハードウェアを共有のものを使用するか専有するかの設定です。 今回は専有する必要はないので共有を選択します。 Elastic Inferenceは機械学習でGPUを使用する際に設定します。今回は使用しないのでチェックしません。 クレジット仕様は通常CPUには制限がかかっていて、制限よりも多く処理が必要な場合はバーストモードになり、CPUの性能を最大限利用できるようになります。クレジットがある内は利用できるのですが、クレジットを超える処理になると性能が低下してしまいます。それを制限なしにするかしないかの設定です。 ネットワークインターフェイスはこのインスタンスにパブリックIPだけでなくプライベートIPをつけることができます。 ネットワークインターフェイスのプライマリIPにパブリックサブネットの範囲内のIPアドレスを指定します。 次のステップに進みます。 3.ストレージの追加 必要に応じてストレージを追加していきます。 Amazon EBS(Amazon Elastic Block Storage)は長期間データを保存できますが、料金がかかりますので、必要に応じて追加します。 無料利用枠では30GBまで使えます。30GBとして無料期間が終了した場合は、その分がそのまま課金されます。 ボリュームタイプがルートになっているものはOSが入っているストレージです。 デバイスはEBSかインスタンスストアだと名前を設定できます。ルートの場合は自動で決まっています。 スナップショットはスナップショットは、S3 に保存された EC2 ボリュームのバックアップです。ルートの場合は自動で決まっています。 サイズはボリュームのサイズです。ボリュームサイズは、0 または使用されるスナップショットのサイズ以上である必要があります。 ボリュームタイプはルートかEBSの場合選択可能で、汎用SSDはその中で価格と性能のバランスが良いため、よく使用されます。 プロピジョンドSSDはデータベースなどに使用されます。 マグネティックはデバイスへの入出力があまりないときに使用します。 スループットは一秒間でのデータ転送速度です。 **終了時に削除はインスタンスを削除したときに一緒に削除するかを選択できます。 消し忘れによる課金を防止できます。 次へ進みます。 次にインスタンスに付与するタグを設定します。 この項目では作成するインスタンスにタグ付けし、他のインスタンスと区別することができます。 EC2インスタンス起動後にマネジメントコンソールで探しやすいように、Nameタグのみ設定しておきます。「タグの追加」をクリックし、キーに「Name」、値に区別しやすいEC2インスタンス名を入力します。 次へ進みます。 4.セキュリティグループの設定 次はセキュリティグループの設定です。 セキュリティグループはEC2インスタンスの仮想ファイアウォールです。 必要に応じて設定します。 設定できたら確認と作成をクリックします。 設定内容を確認しましょう。 問題なければ起動ボタンをクリックします。 するとキーペアの設定画面が開きます。 5.SSHキーペアの設定 キーペアとはインスタンスにログインするための鍵のことです。 これがないとインスタンスにログインすることができません。 新しいキーペアを作成します。 任意のキーペアの名前を記入します。 キーペアのダウンロードをクリックします。 ダウンロードされました。この鍵はもう一度ダウンロードはできないのでなくさないよう管理しましょう。 次にインスタンスの作成をクリックします。 作成ステータスの画面に遷移しました。 インスタンスの表示をクリックします。 インスタンスの作成ができました。 お疲れ様でした。 次回はキーペアでインスタンスにアクセスするなどをまとめていきます。 参考サイト Rito Labo AWS EC2インスタンスを作成する(AMI:Amazon Linux / Amazon EBSの設定など) Qiita AWS EC2 インスタンスの作成 HACK NOTE AWSにEC2インスタンスを立ち上げよう Waf Charm 【EC2ってなに?】初心者でもわかる簡単 AWS 用語解説 AWS Column AWSのインスタンス作成手順7つ|使う際のメリットや注意点も紹介
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS EC2インスタンスにDocker環境を入れてDiscord Botを動かす(Python)

導入 Docker上でDiscordのBotを動かす のアイデアを元に誰かがボイスチャットに入ったときに入場曲を流すBotを、勉強を兼ねてPython/Docker/AWS EC2の環境で作成してみました。 ローカルで実行したいだけの場合や、ローカルのDocker環境で実行したい場合はDockerのくだりやEC2のくだりを適宜省略すれば動かせます。 下準備 discordのBotを作成し、アクセストークンを控えておく。 参考: 簡単なDiscord Botの作り方(初心者向け) EC2インスタンスを作成し、SSH接続できるようにしておく。今回は無料枠のAmazon Linux 2 t2.microを選びます。 参考:【初心者向け】Amazon EC2にSSH接続する【Windows、Macintosh】 EC2インスタンス上にdocker環境を構築しておく。こちらの2,3をご参考に。 参考: AWS EC2インスタンスにdockerとdocker-composeをインストールして簡単なWEBサービスを立ち上げる方法 これで進捗90%です。 Pythonコードの作成 discord.py の使用を前提で作成します。 discord.PCMVolumeTransformer(xxx, volume=0.04)の部分で音量を絞っています。結構小さめですが、これくらいがちょうどよいです。 if before.channel is None:で、接続なしの状態からそのチャンネルに入った場合のみの再生に限定しています。 sleep()で時間を決めて退出していますが、もっといいやり方があるかも。 今回は複数の音源をランダムに再生するように決めています。確率はお好みで。人によって再生する音源を変えても良いです。 entrancebot.py import discord import random from time import sleep # Botのアクセストークン discord_token = 'XXXX0XXX0000XX00.XXX00XX0.x000XXX0-XXXXX00000XXX0X000X' client = discord.Client() @client.event async def on_ready(): print('Botを起動しました') @client.event async def on_voice_state_update(member, before, after): if member.bot: return if before.channel is None and after.channel.id == 000000000000000000: # 接続するボイスチャンネルのID sleep(1) await member.voice.channel.connect() print('接続しました。') num = random.randint(0,5) if num == 0: member.guild.voice_client.play(discord.PCMVolumeTransformer(discord.FFmpegPCMAudio("makenai.mp3"), volume=0.04)) sleep(22) elif 1 <= num <= 2: member.guild.voice_client.play(discord.PCMVolumeTransformer(discord.FFmpegPCMAudio("tigau.mp3"), volume=0.04)) sleep(20) elif 3 <= num <= 4: member.guild.voice_client.play(discord.PCMVolumeTransformer(discord.FFmpegPCMAudio("arigatou.mp3"), volume=0.04)) sleep(20) elif num == 5: member.guild.voice_client.play(discord.PCMVolumeTransformer(discord.FFmpegPCMAudio("ambitious.mp3"), volume=0.04)) sleep(14) member.guild.voice_client.stop() await member.guild.voice_client.disconnect() print('接続解除しました。') client.run(discord_token) Dockerfileの作成 dockerイメージの元となるDockerfileを作成します。拡張子のないただのテキストです。 今回は音声を扱うのでffmpegをインストールし、音声を扱えるdiscord.py[voice]を入れます。 ローカルで実行する場合もこれらをインストールしておけば動きます。 Dockerfile FROM python:3.9.4-buster WORKDIR /app COPY . /app RUN apt-get update && apt-get install -y ffmpeg RUN python -m pip install \ --upgrade pip \ --upgrade setuptools \ discord.py[voice] CMD ["python3.9", "entrancebot.py"] docker-compose.ymlファイルの作成 直接Dockerfileで構築する場合は不要ですが、使っておきます。 ほぼbuild: .でDockerfileを指定しているだけです。 docker-compose.yml version: "3" services: python-service: restart: always build: . container_name: "pythonContainer" working_dir: "/app" tty: true ディレクトリの作成 作った3ファイル+音源ソースファイルを同じディレクトリにぶち込んでおきます。今回はentrancebotディレクトリとします。 ディレクトリのコピー 下準備のssh接続完了後、entrancebotディレクトリの上階層で下記を実行し、ローカルのディレクトリをEC2インスタンス上のディレクトリにコピーします。 指定するユーザー名はデフォルトではec2-user, IPアドレスはご確認を。 $ scp -r -i ~/.ssh/xxxx.pem entrancebot ec2-user@xx.xxx.xxx.xx:/home/ec2-user dockerイメージ・コンテナの作成 まずはEC2インスタンスの中に入ります。 $ ssh -i ~/.ssh/xxxx.pem ec2-user@xx.xxx.xxx.xx 入るとホームディレクトリ/home/ec2-userにいるはずです。 そこで $ cd entrancebot で、先程コピーしたディレクトリの中に移動します。 さらに、 $ docker-compose up -d --build で、dockerイメージとコンテナが作成され、起動されるはずです。 これでPythonコード上で指定したボイスチャンネルに入場すれば、Botが歌ってくれます! ちなみに $ docker-compose exec python-service /bin/sh でdockerコンテナの中に入ることもできます。 片付け $ docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES daad8f6d5c15 entrancebot_python-service "python3.9 entranceb…" 21 seconds ago Up 20 seconds pythonContainer で表示されたIDを使って、 $ docker container stop daad8f6d5c15 $ docker container rm daad8f6d5c15 コンテナを停止して、削除。さらに、 $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE entrancebot_python-service latest e235b4decbcd 4 minutes ago 1.15GB python 3.9.4-buster 8f3a05c42ee5 32 hours ago 886MB で表示されたIDを使って、 $ docker image rm e235b4decbcd $ docker image rm 8f3a05c42ee5 イメージを削除。 あるいはコンテナ・イメージ削除はdocker-composeコマンドでまとめてできます。 $ docker-compose down --rmi all また、cd ../でentrancebotディレクトリの上階層に移動して $ rm -r entrancebot でディレクトリを削除。最後に、 $ exit EC2を抜けて、ローカルに戻れます。お疲れさまでした。 実行内容を変えたい場合はリファレンスをご参考に。 不明点・うまく行かなかったところ ローカル(macOS)のdocker環境で実施したときは生成されるimageはentrancebot_python-service1つのみで、pythonが別に先に持ってこられることはなかったのだが、EC2上ではpythonイメージが別にある。この違いはなに...?どちらも空の状態から実行したけれど。。理解が足りていない。。 ローカルのdocker環境では問題はなかったが、EC2インスタンス上ではentrancebot.pyでconnect()前にsleep()等で間隔開けないとうまく再生されなかった。性能の問題...? Python/Docker/EC2 すべてが初めて触るものだったので、特定できず。。 詳しい方、コメントいただければと思いますm(_ _)m
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】IPアドレス・Elastic IPアドレスについて no.10

こんにちは。まゆみです。 AWSについての記事をシリーズで書いています。 今回は第10回目になります。 今回の記事では、ネットワークを学ぶ上で必要な『IPアドレス』と『Elastic IPアドレス』について、解説していこうと思います では、さっそく始めていきますね。 IPアドレスには2種類ある。 あなたがもし、友達のAちゃんに連絡を取りたい時、それが手紙であれEmailであれ電話であっても、Aちゃんに特別に割り当てられた住所・Emailアドレス・電話番号を知らなければいけませんよね。 IPアドレスとは、 >インターネットに接続されたマシーンが持つ独自の数字の羅列のことになります。 それぞれの機器に、独自の数字を割り当てることにより、その特定の機器とつながることができます。 IPアドレスにはIPv4とIPv6というものがあります。 元々古くから使われていたのがIPv4で、IPv6は新参者になります IPv4 より多くの場面で使われている IPv6 IoTなどで使われている またIPv4アドレスは [0-255].[0-255].[0-255].[0-255] と、0から255の数字4組がランダムに組み合わされて作られて割り当てられています 0から255のランダムな数字の組み合わせでできていると聞くと、無限にあるように思えますが、インターネットの急速な発展とともに、IPv4アドレスが枯渇してきています。 その問題を解決するために登場したのが、『IPv6』です。 AWSではIPv6にも対応していますが、この記事ではIPv4を使って解説していきますね。 引用元:AWSドキュメント パブリックIPとプライベートIP さらにIPアドレスは、どこに向けて発信したいかによって パブリックIP プライベートIP に分けることができます。 例えば会社などの組織内でのみ使うものは『プライベートIP』と呼ばれます。 上記のイラストで言えば、CompanyAやCompanyB内でのみ使うIPアドレスのことです。 CompanyA内で、同じプライベートIPアドレスを使うことはできませんが、CompanyAとCompanyBで同じプライベートIPが使われていても大丈夫です。 組織外との通信を可能にするのは『パブリックIP』と呼ばれます。 外のものと通信するときはインターネットゲートウェイを通して外部のものとつながることができます パブリックIPとプライベートIPの違い EC2インスタンスを起動させると、デフォルトでパブリックIPとプライベートIPが割り当てられます。 後述するElastic IPアドレスの説明をする前に知っておきたいことに、 パブリックIPはインスタンスを停止してスタートするたびに『変わるもの』 プライベートIPは変わらないもの ということを頭の隅に置いていおいてくださいね。 プライベートIPがその都度変わるのは、IPv4アドレスが枯渇しているため、再利用しているとの説を聞いたことがあります。 ともかくパブリックIPは変わるということは覚えておいてください。 Elastic IPアドレスとは? Elastic IPアドレスとは、パブリックIPの一種なのですが、先ほど言及したように、その都度変化するパブリックIPではなく、固定のパブリックIPになります 引用元:AWSドキュメント その性質上『静的なIPアドレス』とも呼ばれます。 パブリックIPとElastic IPとを比較して、どのような特徴があるのか下記に記します 静的パブリックIPアドレス もし使わないと課金される インスタンスのプライベートIPアドレスに関連付けられる インスタンスからElastic Network Adaptersに付け替えることができる 上記の2についてですが、IPv4の枯渇ゆえ、Elastic IPがどこかに関連付けて使われていない場合は課金されるようです。 実際のEC2インスタンスをのぞいてみる では、AWSのコンソールでどのように表示されているか下記に示していきますね。 調べたいEC2インスタンスにレ点を付けると下に詳細が表示されます。 スクショの上の方が最初に起動した時の様子、スクショの2枚目が停止した後、再び開始させた様子です。 パブリックIDは停止して再び開始させると、その都度変わっているのが分かると思います。 ただ、プライベートIPアドレスは変化していないということに注意です。 Elastic IP アドレスを使ってみる では次にElastic IPを試してみます 『割り当て』をクリックします 割り当てられたあと、このElastic IPをインスタンスに関連付けます インスタンスと書かれた検索バーをホバーすると、あなたの今までに作ったインスタンスが提示されます。 好きな物を選択し、『関連付ける』をクリックします EC2インスタンスを見てみると、ちゃんとElastic IPが特定のインスタンスに関連付けられています Elastic IPは付け替えることができる Elastic IPは、他のインスタンスに付け替えることができるので、その方法も示しておきますね。 Elastic IPアドレスの関連付けの解除をクリック 最初に関連付けをした時と同じ要領で、関連付けていきます EC2インスタンスを見てみると、別のインスタンスの方に、Elastic IPアドレスが移っています そもそもElastic IPアドレスってなんのため? どんな時にElastic IPが便利に使えるの?って疑問がわいてくると思います。 例えばあるトラフィックが特定のElastic IPに向かっていて、そのインスタンスが失敗した時に、そのトラフィックを簡単に別のインスタンスに向けさせることができます。 Elastic IP を削除するには? Elastic IPのアクションから Elastic IPアドレスの関連付けの解除 Elastic IPアドレスの解放 の順番で削除する事ができます まとめ 今回の記事はこれで終わりにします。 少し長めの記事になりました。<(_ _)> お疲れさまでした!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでS3にアップロードしたオブジェクトのメタデータを変更

概要 cli経由でメタデータを変更させなければいけなかったのでその時のメモ 結果 とりあえず結果だけ 以下のコマンドは content-encoding と content-type の変更 $ aws s3api copy-object --bucket バケット名 --copy-source バケット名/オブジェクト名 --key オブジェクト名 --content-encoding "エンコーディング名" --content-type "コンテンツタイプ" --metadata-directive REPLACE その他 copy-object の help は下のような感じ SYNOPSIS copy-object [--acl <value>] --bucket <value> [--cache-control <value>] [--content-disposition <value>] [--content-encoding <value>] [--content-language <value>] [--content-type <value>] --copy-source <value> [--copy-source-if-match <value>] [--copy-source-if-modified-since <value>] [--copy-source-if-none-match <value>] [--copy-source-if-unmodified-since <value>] [--expires <value>] [--grant-full-control <value>] [--grant-read <value>] [--grant-read-acp <value>] [--grant-write-acp <value>] --key <value> [--metadata <value>] [--metadata-directive <value>] [--tagging-directive <value>] [--server-side-encryption <value>] [--storage-class <value>] [--website-redirect-location <value>] [--sse-customer-algorithm <value>] [--sse-customer-key <value>] [--sse-customer-key-md5 <value>] [--ssekms-key-id <value>] [--ssekms-encryption-context <value>] [--bucket-key-enabled | --no-bucket-key-enabled] [--copy-source-sse-customer-algorithm <value>] [--copy-source-sse-customer-key <value>] [--copy-source-sse-customer-key-md5 <value>] [--request-payer <value>] [--tagging <value>] [--object-lock-mode <value>] [--object-lock-retain-until-date <value>] [--object-lock-legal-hold-status <value>] [--expected-bucket-owner <value>] [--expected-source-bucket-owner <value>] [--cli-input-json | --cli-input-yaml] [--generate-cli-skeleton <value>]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS学習の軌跡

AWS CloudFront コンテンツデリバリーネットワークの一つ。 デリ。動的、静的コンテンツを高い転送速度で配信するサービス。 静的コンテンツはS3にアクセス。 動的コンテンツはELBを経由してEC2とアクセス。 例:Webアプリとのやりとり(CRUD)をしている。 S3とGlacierの違い GlacierはS3に比べて遅いが、大容量のデータを安価に保管できる。 AWS WAF web application firewallのこと SQLインジェクションやクロスサイトスプリクティングのおような一般的な攻撃から保護する機能を提供している。 Webアプリケーションを保護するサービス。 許可されたIPアドレスのみを通過させたり、CloudFront経由のアクセスのみ許可するなど。 適用できるのはCloudFront、ALB、API Gateway。 送信元IPアドレスに基づいてアクセス制限ができる。 AWS Shield アベンジャーズではない。 DoSやDDoSに代表される一斉攻撃に対する防御にはこれが適している。 無償版と有償版が存在。有償版はサポート対応が得られる。 RDSのリードレプリカ マスターデータベースと同じデータベースを複製し、読み取り専用として構築したもの。 読み取り頻度の高いデータベースを増設できるため、読み取りスループットを増やし、パフォーマンスを向上させることができる。 マルチAZや異なるリージョン間で構築できる。 マスターとリードレプリカの構成にすることでパフォーマンスと耐久性が向上する。 読み取り処理の負荷軽減に役立つが、自動フェイルオーバーには使えない。可用性が低いってこと マルチAZとの違いを考えよう。 RDSのマルチAZ 単純にデータベースを異なるAZに複製しホットスタンバイ。常に同期させてるイメージ。 データの欠損はほぼ起こらず、データベースの切り替えもすぐに完了する。 自動フェイルオーバーにとても役立つ。 ただしコストが二倍以上(!)システム構成自体の冗長化なので。 AWS Snowmobile 超大容量データは物理で殴れ。トレーラーを使って運ぶすごいやつ 100PBまで運べる途方もないの。 AWS Snowball edge データ移行とエッジコンピューティングデバイス。 二つのオプションがあって、S3と互換性のあるオブジェクトストレージを提供し、40個のvCPUを提供する。ローカルストレージや大規模データ転送に最適。80TBの容量がある。 Direct Connect 専用線接続でVPCとオンプレミス環境を接続する。通常のデータ接続に使う。大量のデータ移行用サービスではない。 DynamoDB AWSリージョンの3つの施設にデータを複製し、サーバー障害AZの停止が発生した場合でも予備系統を提供する。 何ができるんだって構造化データ以外の一部の非構造化データを扱える。(音声や位置情報、システムのセンサー、ログなど) EFS NASとして利用できる共有ファイルストレージ。インターネットからアクセスができない、完全内部サーバ向けのストレージ。セキュリティ強化に役立つ。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2 Discovery Pluginを使ってElasticsearch7のクラスタを構築してみた話

はじめに ElasticsearchのクラスタをEC2で構築する場合、EC2 Discovery Pluginは便利です。 また、Elasticsearchの7系ではクラスタ構成時のノード検出(Discovery)方式が変わっています。 そこで、7系でEC2 Discovery Pluginを利用した場合に elasticsearch.ymlの設定がどのようになるのか改めて確認してみました。 本投稿は、その際の備忘録になります。 7系におけるノード検出について 6系までは、discovery.zen.minimum_master_nodesで クラスタを維持する上で最低限必要なマスター適合ノードの数を指定していました。 7系では、クラスタの起動チェックプロセスにおいて cluster.initial_master_nodesで指定したマスター適合ノードの ホスト名もしくはIPアドレスを見に行くため、明示的に指定する必要があります。 ※ローリングアップデートの場合のみ、設定がなくても動作します。 また、Zen Discoveryのパラメータ名が下記のように変わっています。 ※ 今回は、discovery.seed_providersを利用します。 6系まで 7系から discovery.zen.ping.unicast.hosts discovery.seed_hosts discovery.zen.hosts_provider discovery.seed_providers discovery.zen.no_master_block cluster.no_master_block 【参考】 ・ 新世代Elasticsearchクラスターコーディネーション ・ 7系におけるノード検出方法の変更点 ・ Bootstrapping a cluster EC2 Discovery Pluginとは 複数台のEC2でElasticsearchのクラスタを構成する際 discovery.seed_hostsを使わずにプラグインでマスター適合ノードを検出します。 ノード検出には、EC2に付与したタグやセキュリティグループを使うことができます。 (今回は、セキュリティグループを利用した設定を確認しています) 【参考】 ・ EC2 Discovery Plugin 利用環境 項目 内容 Elasticsearch 7.12.1 OpenJDK (同梱) AdoptOpenJDK (build 16+36) OS Amazon Linux 2 AMI ami-0cf6f5c8a62fa5da6 Instance Type t3.medium (2vCPU,4GB) EBS 20GB (gp2) Region us-west-2 【構成図】 ・3つのAZ(2a、2b、2c)にそれぞれ1台ずつ、全部で3台のEC2を用意します。 【補足】 ・ インストールに必要なパッケージダウンロードのため、Publicに配置しています。 ・ Elasticsearchは3台ともマスター兼データノードの役割としています。 ・ EC2のIPアドレスは事前にip addrコマンドで確認済みとしています。 実施手順 IAMロールの作成 セキュリティグループの作成 Elasticsearchのインストール discovery-ec2 pluginのインストール クラスタの設定 動作確認 【補足】 ・ 本投稿では、VPC、サブネット、EC2は事前に作成済みとします。 ・ EC2の操作を全てSystems Managerのセッションマネージャー経由としています。 1. IAMロールの作成 AWSマネージメントコンソールにログインします。 IAM > ポリシーでポリシーの作成を実施します。 JSONタブを開き、下記のポリシーを貼り付けます。 AmazonEC2RoleforES { "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstances" ], "Effect": "Allow", "Resource": [ "*" ] } ] } ※ Elasticsearchがノード検出時にEC2のメタ情報を参照するため 次に作成したIAMポリシーをIAMロールに割り当てます。 IAM > ロールでロールの作成を実施します。 下記内容で作成します。 項目 内容 信頼されたエンティティの種類 AWSサービス ユースケースの選択 EC2 Attachアクセス権限ポリシー AmazonEC2RoleforSSM、AmazonEC2RoleforES ロール名 AmazonEC2RoleforES 作成したIAMロールを3台のEC2に割り当てます。 2. セキュリティグループの作成 EC2 > セキュリティグループでセキュリティグループを作成を実施します。 下記内容で作成します。 項目 内容 セキュリティグループ名 sg_es 説明 SGforES VPC ES_VPC インバウンドルール1 ポート: TCP9200、ソース: 10.0.0.0/16 インバウンドルール2 ポート: TCP9300、ソース: 10.0.0.0/16 セキュリティグループIDは後で利用するため控えておきます。 作成したセキュリティグループを3台のEC2に割り当てます。 3. Elasticsearchのインストール Amazon Linux2は公式サイトのRPMでの手順でインストールします。 下記コマンドでPGP鍵をインポートします。 PGP鍵インポート $ sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch 下記コマンドでRPMリポジトリ定義ファイルを作成します。 RPMリポジトリ定義ファイル作成 $ sudo vi /etc/yum.repos.d/elastic.repo [elastic] name=Elasticsearch repository for 7.x packages baseurl=https://artifacts.elastic.co/packages/7.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=0 autorefresh=1 type=rpm-md 下記コマンドでElasticsearchパッケージをインストールします。 Elasticsearchインストール $ sudo sudo yum install --enablerepo=elastic elasticsearch 下記コマンドでElasticsearchと同梱されているOpneJDKのバージョンを確認します。 バージョン確認 $ yum list installed | grep elastic $ /usr/share/elasticsearch/jdk/bin/java --version 下記コマンドでElasticsearchデーモンの自動起動設定をします。 サービス自動起動設定 $ sudo systemctl daemon-reload $ sudo systemctl enable elasticsearch ※ ここではデーモン起動はしません。 ※ 本インストール手順を3台で同じ内容を実施します。 4. discovery-ec2 pluginのインストール 下記コマンドでプラグインをインストールします。 プラグインインストール $ sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install discovery-ec2 5. クラスタの設定 下記コマンドで設定ファイルにクラスタ設定を行います。(3台とも同じ設定を行います) Elasticsearchクラスタ設定 $ sudo vi /etc/elasticsearch/elasticsearch.yml # リッスンするIPアドレスを指定 - #network.host: 192.168.0.1 + network.host: _eth0_ # ノード検出方法でEC2 Discovery有効化 - discovery.seed_hosts: ["host1", "host2"] + discovery.seed_providers: ec2 + discovery.ec2.groups: "sg-01b2b630a5385f442" + discovery.ec2.endpoint: "ec2.us-west-2.amazonaws.com" + discovery.ec2.availability_zones: ["us-west-2a", "us-west-2b", "us-west-2c"] # 初期構築時のマスター選出設定 + cluster.initial_master_nodes: ["10.0.1.174", "10.0.2.92", "10.0.3.230"] 下記コマンドでElasticsearchを起動します。(3台とも) Elasticsearch起動 $ sudo systemctl start elasticsearch 6. 動作確認 下記コマンドでクラスタ状態を確認します。 クラスタ状態確認 $ curl http://<ElasticsearchのIPアドレス>:9200/_cluster/health?pretty # 下記は正常時のレスポンスになります。 { "cluster_name" : "elasticsearch", "status" : "green", "timed_out" : false, "number_of_nodes" : 3, "number_of_data_nodes" : 3, "active_primary_shards" : 0, "active_shards" : 0, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 } ※ statusがgreen、number_of_nodesが3であればOKです。 ※ cluster_nameはデフォルトでelasticsearchとなります。 下記コマンドはクラスタ内のノードの状態になります。(es02がマスターに選出されています) ノード一覧 $ sudo curl http://<ElasticsearchのIPアドレス>:9200/_cat/nodes?v # 下記は正常時のレスポンスになります。 ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name 10.0.2.92 33 64 4 0.02 0.15 0.11 cdfhilmrstw * ip-10-0-2-92.us-west-2.compute.internal 10.0.3.230 8 63 4 0.05 0.22 0.15 cdfhilmrstw - ip-10-0-3-230.us-west-2.compute.internal 10.0.1.174 45 63 4 0.01 0.08 0.05 cdfhilmrstw - ip-10-0-1-174.us-west-2.compute.internal 余談ですが、cluster.initial_master_nodesを設定しないと下記エラーログが出力されます。 エラーログ $ sudo tail -f /var/log/elastixsearch/elasticsearch.log 2021-05-05T23:53:31,994][WARN ][o.e.c.c.ClusterFormationFailureHelper] [ip-10-0-1-174.us-west-2.compute.internal] master not discovered yet, this node has not previously joined a bootstrapped (v7+) cluster, and [cluster.initial_master_nodes] is empty on this node: have discovered [{ip-10-0-1-174.us-west-2.compute.internal}{ctcTgFMWQGiCqi0dWIr9Ow}{7yMMGhinTViqK2eoeL_wzg}{10.0.1.174}{10.0.1.174:9300}{cdfhilmrstw}{ml.machine_memory=4073328640, xpack.installed=true, transform.node=true, ml.max_open_jobs=20, ml.max_jvm_size=1073741824}, {ip-10-0-3-230.us-west-2.compute.internal}{9Xpmo5b6SqKlloXUWRzeGg}{J9Ag6Ng3QXuwqCxMZGVj6g}{10.0.3.230}{10.0.3.230:9300}{cdfhilmrstw}{ml.machine_memory=4073328640, ml.max_open_jobs=20, xpack.installed=true, ml.max_jvm_size=1073741824, transform.node=true}, {ip-10-0-2-92.us-west-2.compute.internal}{2V-zcyrySuy13tlNBtRskQ}{xqPqlOH7Sp-pMEGFTGDOSA}{10.0.2.92}{10.0.2.92:9300}{cdfhilmrstw}{ml.machine_memory=4073328640, ml.max_open_jobs=20, xpack.installed=true, ml.max_jvm_size=1073741824, transform.node=true}]; discovery will continue using [127.0.0.1:9300, 127.0.0.1:9301, 127.0.0.1:9302, 127.0.0.1:9303, 127.0.0.1:9304, 127.0.0.1:9305, [::1]:9300, [::1]:9301, [::1]:9302, [::1]:9303, [::1]:9304, [::1]:9305, 10.0.2.92:9300, 10.0.1.174:9300, 10.0.3.230:9300] from hosts providers and [{ip-10-0-1-174.us-west-2.compute.internal}{ctcTgFMWQGiCqi0dWIr9Ow}{7yMMGhinTViqK2eoeL_wzg}{10.0.1.174}{10.0.1.174:9300}{cdfhilmrstw}{ml.machine_memory=4073328640, xpack.installed=true, transform.node=true, ml.max_open_jobs=20, ml.max_jvm_size=1073741824}] from last-known cluster state; node term 0, last-accepted version 0 in term 0 やはり、プラグインだけではダメで、cluster.initial_master_nodesの設定が必要なようです。 まとめ 以上がEC2でのクラスタ構成設定手順でしたが、いかがでしたでしょうか? プラグイン使うことでマスター適合ノードのIPアドレスを意識しなくて良くなると思ったんですが cluster.initial_master_nodesで指定する必要があるため、嬉しみ半減でした。 ですが、無事に7系でもEC2でクラスタを組めたので、良しとしましょう^^
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Circleci で Pulumi Service を利用せず pulumi preview を実行する (AWS - TypeScript/JavaScript編)

はじめに CircleCIで Pulumi Service を利用せずに pulumi preview するまでの手順と設定をまとめました。 pulumi 公式のドキュメントにも CircleCI で preview を実行する方法は用意されていますが、 Pulumi Service の利用が前提になっています。 CircleCI で pulumi preview を実行する際に Pulumi Service を利用できる場合は公式ドキュメントを参照することをおすすめします。 また、既に pulumi のプロジェクトを作成済みであることを前提に記述します。 ブロジェクト作成方法は以下等を参照してください。 依存パッケージ等バージョン 利用したバージョンは以下のとおりです。 pulumi v3.1 以上 node v14 CircleCIの設定ファイルを作成する タイトルの通り. CircleCIの設定ファイルを用意しましょう。 先に完成後のファイルを載せ、ポイントは後で記載します。 .circleci/config.yml version: 2.1 orbs: pulumi: pulumi/pulumi@2.0.0 jobs: pulumi_preview: docker: - image: 'circleci/node:14' steps: - checkout - run: name: Define PULUMI_CONFIG_PASSPHRASE as an environment variable command: echo "export PULUMI_CONFIG_PASSPHRASE=$TEST_PULUMI_CONFIG_PASSPHRASE" >> $BASH_ENV - pulumi/login: version: 3.1.0 cloud-url: file://~ - run: name: Yarn install command: yarn install - pulumi/stack_init: stack: 'mziyut-test-pr_${CIRCLE_BUILD_NUM}' - run: name: Set AWS region to ap-northeast-1 command: pulumi config set aws:region ap-northeast-1 - pulumi/preview: stack: 'mziyut-test-pr_${CIRCLE_BUILD_NUM}' - pulumi/stack_rm: stack: 'mziyut-test-pr_${CIRCLE_BUILD_NUM}' workflows: version: 2 test: jobs: - pulumi_preview: filters: branches: ignore: - main - master ポイント1: Orb の設定をしよう Orb に対する詳しい説明は以下を参照してください。 簡単に説明すると、後述する pulumi/loginを実行出来るよう、設定等を読み込むための設定です。 定義しない場合、 pulumi/login 等実行することができません。 orbs: pulumi: pulumi/pulumi@2.0.0 ポイント2: PULUMI_CONFIG_PASSPHRASE を定義しよう pulumi/stack_init を実行する際に、パスフレーズが定義されていない場合パスフレーズを要求され先に進みません。 また、よほどのことがない限り、本番とテスト環境でパスフレーズを同一にする必要はないためVariablesに別名で定義しておき、Job内で PULUMI_CONFIG_PASSPHRASE に定義し直しています。 - run: name: Define PULUMI_CONFIG_PASSPHRASE as an environment variable command: echo "export PULUMI_CONFIG_PASSPHRASE=$TEST_PULUMI_CONFIG_PASSPHRASE" >> $BASH_ENV ポイント3: pulumi/login 実行時の cloud-url の設定について 今回は Pulumi Serviceを利用しない(=Localにあるstate ファイルを参照する)ため、 cloud-url に file://~ と定義します。 ちなみに、 pulumi login --local と実行したときに設定される cloud-url と同値です。 - pulumi/login: version: 3.1.0 cloud-url: file://~ また、この時点で pulumi コマンドが存在しない(未インストールの場合)同時にインストールも実行されます。 ポイント4: リージョンを設定しよう pulumi preview を実行する場合、リージョンの設定が必要です。 今回は東京リージョンを定義しておきます。 - run: name: Set AWS region to ap-northeast-1 command: pulumi config set aws:region ap-northeast-1 最後に 今回はテスト用にstackを定義しましたが、production環境に適用しているstackを用いpreviewすることもできます。 CircleCIの設定ファイル内、stack定義部分を書き換えてみてください。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

(備忘録)AWSではじめるLinux入門ガイドのデモ(ファイル操作コマンドなど)

1. はじめに 2021年5月2日にヤマムギ様主催にて開催されたヤマムギ vol.19 AWSではじめるLinux入門ガイドのデモ(ファイル操作コマンドなど)でのAWS学習内容について、自分への備忘録としてまとめてみました。ご参考になれば幸いです。 2. 学んだ内容 EC2起動テンプレート AWS CloudShell コマンドを用いたS3操作 コマンドを用いたEFS操作 3. 学習サイト YouTube:LinuxサーバーでS3にファイルを保存するデモ YouTube:LinuxサーバーからAmazon EFSをマウントするデモ GitHub:yamamanx/yamamugi GitHub:CloudShell用.yaml定義 サンプル.png画像 4. 参考サイト 5. ハンズオンで得た豆知識 EC2の起動テンプレートを用いると、毎回同じEC2を作成&起動できる CloudShellを用いると、コマンドラインで起動テンプレートを実行できる // AWS CloudShell aws ec2 run-instances --cli-input-yaml file://linux.yaml awsコマンド操作 // S3操作コマンド // ホームディレクトリへ移動 $ cd ~ // S3バケットの作成 $ aws s3 mb s3://xxxxxxxx $ aws s3 mb s3://yamamugi20210505 // 新規ディレクトリの作成 $ mkdir ~/work // 画像のダウンロード $ wget https://xxxxxxxx $ wget https://yamashita-20210505.s3.amazonaws.com/yamamugi.png // S3バケットへのファイルアップロード $ aws s3 cp xxxxxxxx.png s3://xxxxxxxx // S3バケット内の一覧表示 $ aws s3 ls s3://xxxxxxxx // S3バケット内の一覧表示 $ aws s3 ls -recursive s3://xxxxxxxx // S3アクセス権限の確認 $ aws s3api get-object-acl --bucket xxxxxxxx -- key xxxxxxxx.png // S3アクセス権限の付与 $ aws s3api put-object-acl --acl public-read --bucket xxxxxxxx --key xxxxxxxx.png // テキストファイルの新規作成 $ echo HelloWorld > ~/work/hash.txt // ハッシュ値の確認 $ md5sum hash.txt // opensslにてハッシュ値の生成&base64化 $ openssl md5 -binary hash.txt | -base64 // ハッシュ値チェック付きでS3へアップロード $ aws s3api put-object / // EFS(Elastic File System) // マウントポイントの作成 $ sudo mkdir /mnt/efs // マウントヘルパー $ sudo yum install -y amazon-efs-utils // EFSをマウント $ sudo mount -t efs fs-xxxxxxxx:/ /mnt/efs // マウント先のEFSへファイルコピー $ sudo cp hash.txt /mnt/efs // マウント先のEFS内のファイル内容表示 $ sudo cat /mnt/efs/hash.txt 6. おわりに AWS学習の参考になれば幸いです。 ハンズオン開催してくださいましたヤマムギ様、感謝いたします。 2021/05/05 NISHIZONO Takahiro
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】 AWS Certificate Manager(ACM)証明書の有効期限が切れた場合の対処法

はじめに やってしまいました・・・。 証明書の有効期限切れという初歩的なミスです。 個人請負で運営しているサイトなのですが、Amazon Web Services, Inc.から以下のメールが来ていることに気づきました。 一部抜粋 Your certificate has expired Greetings from Amazon Web Services, You have an SSL/TLS certificate from AWS Certificate Manager (ACM) in your AWS account that expired on Apr 30, 2021 at 12:00:00 UTC. This certificate includes the primary domain xxxxxxxxx.org and a total of 2 domains. DeepLで訳すと 証明書の有効期限が切れている Amazon Web Servicesからのご挨拶です。 あなたのAWSアカウントには、AWS Certificate Manager(ACM)からのSSL/TLS証明書があり、その有効期限は2021年4月30日12:00:00 UTCに切れています。この証明書には、プライマリドメインであるxxxxxxxx.orgと、合計2つのドメインが含まれています。 となっています。証明書の期限切れです。 そもそもなぜ有効期限が切れたのか 不明です。 ACMは自動更新のはずなので何か設定にミスがあったのかもしれません。 今回は既に有効期限が切れており、時間もないので原因調査を行わずに暫定対処のみ行いました。 Amazonから来ていたメール メールボックスを見返すと、Amazonから「やばいよ、そろそろやばいよ」というメールがたくさん来ていました。 以下の件名のメールが来ていたら注意です。 Action Required - Your certificate renewal 翻訳すると アクションが必要です - あなたの証明書の更新 です。 URGENT Action Required - Your certificate renewal 翻訳すると 緊急のアクションが必要です - あなたの証明書の更新 です。 対処法 「新しい証明書を作る」だけです。 とりあえずそれでなんとかなりました。 マネージメントコンソールからACMにアクセスし、「証明書のリクエスト」で新規の証明書作成フローに入ります。 ここから先のフローは調べるとたくさん出てくると思うので一部割愛します。 証明書を作成したら、「Route53でのレコードの作成」を行います。 ※Route53を使用している場合 後は30分程度待ったら反映されました。 有効期限の切れた証明書もそのままにしていますが特に問題はないです。 この情報が誰かの役にたったのなら幸いです。 以上です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Angular×Spring Boot×AWS Rekognitionで笑顔認識アプリ作り

前回までのあらすじ 上から順番になっております。 https://qiita.com/NoOne/items/c7b5b2bd84fa9ca317d5 https://qiita.com/NoOne/items/9019baf366aaeb000e68 ソースコード https://github.com/yukihiro-maeda0731/AngularDetectFace/tree/master (Angular) https://github.com/yukihiro-maeda0731/SpringDetectFace/tree/master (Spring Boot) Angularで撮影した画像をSpringに送る HTMLのvideoで撮影しCanvasに描写した画像データをSpringにHttp通信で送るため.toDataURL()でBase64形式に変換しております。 app.component.ts import { Component } from '@angular/core'; import { ImgService } from './img.service'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.css'] }) export class AppComponent { constructor(private service: ImgService) { } private video: any; // Springから返ってくる笑顔の判定メッセージを格納 result: String = ""; //撮影フォーム設定 ngOnInit(): void { this.video = document.querySelector('video')!; const options = { video: true } navigator.mediaDevices.getUserMedia(options) .then(stream => { this.video.srcObject = stream; }) .catch((error) =>{ console.log(error); }) } //撮影ボタン押下時の処理 captureImg(){ let canvas = document.getElementById('canvas') as HTMLCanvasElement; const context = canvas.getContext('2d'); context?.drawImage(this.video, 0, 0, canvas.width, canvas.height); let base64CapturedImg : ConstrainDOMString = canvas.toDataURL("image/png"); this.service.transferImg(base64CapturedImg).subscribe( data => this.result = data, error => console.log(error) ); ; } } Http通信を行うためのserviceを作成します。現段階ではローカルのみでの動作となるのでurlはspringのlocalhostです。 img.service.ts import { HttpClient } from '@angular/common/http'; import { Injectable } from '@angular/core'; import { Observable } from 'rxjs'; @Injectable({ providedIn: 'root' }) export class ImgService { constructor(private http: HttpClient) { } private destinationUrl = 'http://localhost:8080'; transferImg(base64CapturedImg: String): Observable<any> { return this.http.post(this.destinationUrl, base64CapturedImg,{ headers: { "Content-Type": "text/plain; charset=UTF-8", //CORS対策 "Access-Control-Allow-Headers": "*", "Access-Control-Allow-Origin": "*" }, //jsonではなく文字列で結果が欲しいので追記(なくても落ちはしないが余分なエラーメッセージ出る) 'responseType': 'text' }) } } Springで画像情報を受け取り、AWS Rekognitionに提供する Angularからのhttpリクエストを受け取るSpringのコントローラーです。先ほどBase64形式になったdataの余分な部分「data:image/jpg;base64」を外し、デコードしデバイスのhomeディレクトリにpng形式で撮影画像を保存します。これで後はAWS Rekognitionにそのディレクトリを教えてあげれば基本的にはAWS docサンプルのAWS SDK固有の処理を流用で問題なく動きます。今回は笑顔ですが、face.smile().value()のsmileのところをBeardに変えるとあごひげ判定などもできたりと他にも色々できます。 ImgController.java package suita.tarumi.SpringDetectFace.Controller; import org.springframework.web.bind.annotation.*; import software.amazon.awssdk.core.SdkBytes; import software.amazon.awssdk.regions.Region; import software.amazon.awssdk.services.rekognition.RekognitionClient; import software.amazon.awssdk.services.rekognition.model.*; import java.io.*; import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.util.Base64; import java.util.List; @CrossOrigin(origins = "http://localhost:4200") @RestController public class ImgController { @RequestMapping(value = "/", method = RequestMethod.POST) public String transferImg(@RequestBody String base64CapturedImg) throws IOException { //Base64のデコードをする前にdataから「data:image/jpg;base64」を削除する必要があるためデータと分ける String[] base64CapturedImgForDecode = base64CapturedImg.split(","); //デコード・base64CapturedImgForDecode[1]はデータを指す、[0]は「data:image/jpg;base64」 byte[] decodedCapturedImg = Base64.getDecoder().decode(base64CapturedImgForDecode[1].getBytes(StandardCharsets.UTF_8)); //撮影画像の置き場をOSに依存しないように作成 System.out.println("User homeは" + System.getProperty("user.home")+File.separator); Path destinationFile = Paths.get(System.getProperty("user.home")+File.separator, "detectedFace.png"); //撮影画像をpngファイルとして作成 Files.write(destinationFile, decodedCapturedImg); //ここからAWS Rekognition String sourceImage = destinationFile.toString(); Region region = Region.AP_NORTHEAST_1; RekognitionClient rekClient = RekognitionClient.builder() .region(region) .build(); String result = detectFaceImage(rekClient, sourceImage ); rekClient.close(); return result; } public static String detectFaceImage(RekognitionClient rekClient,String sourceImage ) { String result = ""; try { InputStream sourceStream = new FileInputStream(new File(sourceImage)); SdkBytes sourceBytes = SdkBytes.fromInputStream(sourceStream); Image souImage = Image.builder() .bytes(sourceBytes) .build(); DetectFacesRequest facesRequest = DetectFacesRequest.builder() .attributes(Attribute.ALL) .image(souImage) .build(); DetectFacesResponse facesResponse = rekClient.detectFaces(facesRequest); List<FaceDetail> faceDetails = facesResponse.faceDetails(); for (FaceDetail face : faceDetails) { System.out.println("笑顔判定 : "+ face.smile().value().toString()); if(face.smile().value().toString() == "true"){ result = "いってらっしゃい!"; } else { result = "笑顔でもう一度!"; } } } catch (RekognitionException | FileNotFoundException e) { System.out.println(e.getMessage()); System.exit(1); } finally { return result; } } } こちらデモになります。撮影画像が笑顔なら「言ってらっしゃい!」、それ以外だと「笑顔でもう一度!」というメッセージを表示します。 感想など ひとまず大まかなコーディングはこれで完了です。 機械学習の知見が全くなくとも顔認識が実装でき、とても感動しました。 画像関連の処理の復習もでき、いい題材を見つけたなとしみじみ思います。 もし読者の方で実装してみて上手くいかない・もしくはこういうのできますか? などご意見いただければ非常にありがたいです。 今後の課題 ・WEB上で動くようにする(S3?EC2?Elastic Bean Stalk?) ・デザインをましにする ・携帯アプリちっくにする(PWA) ・テストコード 挙げてみれば課題が山ほどありますね(笑)。 参考 AWS SDK For Java2.0 Rekognitionのサンプルコード https://github.com/awsdocs/aws-doc-sdk-examples/tree/master/javav2/example_code/rekognition/src/main/java/com/example/rekognition Rekognitionのモデル群 https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/rekognition/model/package-summary.html
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSでのwebサイト構築での流れメモ

参考本↓ 触って学ぶクラウドインフラ AmazonWeb Services基礎からのネットワーク&サーバー構築改訂3版 内容通りにやる ↓ wordpressがインストールされていない ↓ sudoでインストールして、無事インスコ ついでにmyadminも入れよ ↓ でもwordpressは出てこない ↓ 以下のサイトを参考にして色々やる https://qiita.com/daichi_sugiyama/items/623218b6e9173d5e7ed7 https://qiita.com/moomindani/items/9968df0d4396564bf74c https://teratail.com/questions/173834 https://www.searchman.info/linux/1080.html ↓ 無理出てこん ↓ Apacheを再スタートしてみる sudo systemctl restart httpd ↓ なんかphp入って無くない? ↓ 管理者権限持っているコマンドじゃないとインストールできないやつだと気が付く vi /etc/httpd/conf.moduls.d/15-php7-php.conf ↓ 教科書のwordpressの初期画面は出てきた http://18.180.193.57/wp-admin/setup-config.php MyAdminは出てこない http://18.180.193.57/phpMyAdmin/ phpinfoは出てきた http://18.180.193.57/phpinfo.php ↓ MyAdminは、コンポーザーが無いらしいで Composer detected issues in your platform: Your Composer dependencies require the following PHP extensions to be installed: xml ↓ とりあえず今の各ディレクトリの中身 [ec2-user@ip-10-0-1-10 ~]$ dir end my-key.pem node-v14.16.1-linux-x64 :s wordpress [ec2-user@ip-10-0-1-10 /]$ dir bin dev home lib64 media opt root sbin sys usr boot etc lib local mnt proc run srv tmp var [ec2-user@ip-10-0-1-10 var]$ dir account cache empty gopher lib lock mail opt run tmp yp adm db games kerberos local log nis preserve spool www [ec2-user@ip-10-0-1-10 www]$ dir cgi-bin html [ec2-user@ip-10-0-1-10 html]$ dir index.php wp-admin wp-includes wp-signup.php license.txt wp-blog-header.php wp-links-opml.php wp-trackback.php phpinfo.php wp-comments-post.php wp-load.php xmlrpc.php phpMyAdmin wp-config-sample.php wp-login.php readme.html wp-content wp-mail.php wp-activate.php wp-cron.php wp-settings.php [ec2-user@ip-10-0-1-10 wordpress]$ dir index.php wp-blog-header.php wp-includes wp-settings.php license.txt wp-comments-post.php wp-links-opml.php wp-signup.php readme.html wp-config-sample.php wp-load.php wp-trackback.php wp-activate.php wp-content wp-login.php xmlrpc.php wp-admin wp-cron.php wp-mail.php [ec2-user@ip-10-0-1-10 html]$ dir index.php wp-admin wp-includes wp-signup.php license.txt wp-blog-header.php wp-links-opml.php wp-trackback.php phpinfo.php wp-comments-post.php wp-load.php xmlrpc.php phpMyAdmin wp-config-sample.php wp-login.php readme.html wp-content wp-mail.php wp-activate.php wp-cron.php wp-settings.php wordpressを何個もダウンロードしてたっぽい。 証明無しではあるが、wordpressの表示は成功。 現在、月額1400円かかる計算になる。 ↓ 実はTerraformでAPI経由すれば上記の設定は可能だったと気が付く。 ↓ 気を取り直す。 SSL/TSL化をするために、ゼロからわかるAmazonEWebServices超入門を参考に、ElasticIPを設定して関連付ける。 ↓ wordpressが見られない(今ココ)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS、EC2でインスタンスを作り直した際のEC2への接続エラーについて

こんにちは、今日は ポートフォリオをAWSにデプロイする際に起きたEC2への接続エラー について書き残します。 以前、デプロイしていた別のアプリのインスタンスを削除し、再度インスタンスを生成、下記を入力してEC2に接続しようとした際に以下のようなエラーが出ました。 ssh -i ###.pem ec2-user@hostname @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:###### Please contact your system administrator. Add correct host key in /Users/###/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /Users/###/.ssh/known_hosts:1 ECDSA host key for hostname has changed and you have requested strict checking. Host key verification failed. 原因は同一ホストに対し、認証鍵が違っていたためでした。 (今回はelastic IPは従来のまま、インスタンスのみ生成しなおした) 初めて接続した際に"known_hosts"ファイル内に認証鍵が書き加えられていたようです。 これを下記を入力し取り除きます。 ssh-keygen -R hostname (hostnameはこの場合、AWSのパブリックIPです。) これにより"known_hosts"ファイルがアップデートされ、過去のファイルとして"known_hosts.old"という名前で保管されます。 この後、再度 ssh -i ###.pem ec2-user@hostname を入力すると、無事EC2に接続することができました。  以上です! 余談ですが 当初hostnameが何を指しているのかわからなかったため、known_hostsファイルの内容を確認しようとしていました。 ファイルの内容は下記で確認することができます。 ssh-keygen -l -f known_hosts 以下、内容 256 SHA256:############################# hostname (ECDSA) SHA256というのは、NSA(米国家安全保障局)が考案した「任意の長さのデータから固定長の出力データを返す暗号化技術」のようです。 下記サイトから勉強させていただきました。 https://gaiax-blockchain.com/sha-256#SHA-256-3 また、今回のエラー解決については https://sayjoyblog.com/aws-ec2-identification-warning/ を参考にさせていただきました。 ありがとうございました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DynamoDB操作

Query import boto3 from boto3.dynamodb.conditions import Key, Attr dynamodb = boto3.resource('dynamodb') table = dynamodb.Table("LINEBot") def lambda_handler(event, context): queryData = table.query( KeyConditionExpression = Key("user_id").eq("1"), Limit = 1 ) return queryData["Items"][0]["name"]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む