AWSにデプロイしたRailsとVueで作成したポートフォリオにおいて画像が表示されないエラーが発生し、解決したのでその方法です。 修正前のディレクトリツリー original_app | |--app | | | |--assets | | | |--images | | | |--img1.svg | |--src | |--pages | |--Home.vue #このコンポーネントでimg1.svgを読み込みたい Home.vue <template> <img src="/assets/img1.svg"> </template> 開発環境だとing1.svgを読み込めたが本番環境だとうまくいかなかった。 原因 通常のrailsアプリであればviewファイルに/assets/画像ファイルと書けばassets以下のimagesフォルダからファイルを探してきてくれるがVueのファイルはjavascriptなのでそのような動作をしてくれなくなる。 修正後のディレクトリツリー original_app | |--app | |--src | |--assets #追加 | | | |--img1.svg | | |--pages | |--Home.vue #このコンポーネントでimg1.svgを読み込みたい Home.vue <template> <img src="../assets/img1.svg"> </template> 画像ファイルをvueファイルをまとめているフォルダ内に収納してし、直接参照できるようにしてしまう。

概要 AWSの試験の試験官の言語を英語にして受けたら良かったので、その内容を書いていく。 Solution Architect AssociateとDeveloper Associateの2回受けた経験に基づいた記述。 なぜ英語は良いのか？ AWSの資格試験はPearson Vueからオンライン試験で受けられるのだが、試験官の言語を日本語にすると結構予約枠がない。だいたい一週間後以降くらいに1枠ある感じだったと思う。英語だと、前日でも潤沢に枠があって、朝から深夜まで40枠くらいから選びたい放題なので、学習を進めてもう受けてもいいかなと思えた段階で次の日の試験を予約をして、忘れないうちに臨むことができる。 英語にして困りそうなポイント 本人確認書類にローマ字記載がない 試験の30分前にチェックインをすると、PCのシステムテストをした後に、本人確認書類のアップロードをする必要がある。ここで運転免許証などの写真をアップロードするのだが、当然、免許証に記載の氏名は日本語表記。 試験登録の際の言語はローマ字で登録していたので、名前の照合できるのかと不安になったが、本人確認書類についての以下の記載の通り、特に問題は発生しなかった。 ※ 登録氏名がローマ字で確認書類が日本語、または逆の場合は、読み合わせで一致を確認します。 試験開始前の試験官の確認内容 試験官は基本的にインド人らしく、インドなまりがひどい。2回とも分かりにくい英語だった。 だが、聞かれた内容はほぼ同じで、以下の内容。 PCを動かして机の全景を映すこと(おそらく、カンニングペーパーとかないことの確認) 長袖の服の袖をまくって、手首を見せること(おそらく、手首に文字書いてないか、電子機器を装着していないかの確認) わからない場合は、 I'm sorry? とか、 Say it again? とか言えば良い。本当に通じなくて困ったらチャットボックスに書いてくれるだろうから、焦らないこと。あちらは毎日やってて指示が通じない場面にも慣れているはずだから気にしなくて良い。 以下のページに記載の内容が聞かれると思っておけば良いだろう。 https://home.pearsonvue.com/aws/onvue?ot=collapse541 You may be subject to additional potential inspections, including the following: A proctor may ask you to show your ears if you have hair that covers your ears, for the purpose of verifying that no Bluetooth devices are present. A proctor may ask you to roll up your sleeves to verify that you have no writing on your arms. A proctor may ask you to empty your pockets for the purpose of ensuring nothing is in them. A proctor may ask you to complete a full 360-degree room scan either during check-in or during your exam. 試験中のコミュニケーション 問題行動をしていなければ特に生じない。1度だけ、悩んでいるときに口元に手がいってしまって、その際には口元から手をどけるように指示を受けた。 以下のページに記載の内容に違反しないようにすれば良いだろう。 https://home.pearsonvue.com/aws/onvue?ot=collapse541 Proctors will monitor you for suspicious movement during the duration of your exam. Please do not read the questions aloud and do not cover your mouth or attempt to hide your face or move it out of view of the webcam. まとめ Pearson Vueのオンライン試験で、試験官の言語を英語にすると、前日でも試験予約ができるのでとても良い。 英語にあまり抵抗がないなら是非そちらで。

はじめに VPCの不正トラフィックにアラームを設定する方法を、コンソールとCloudFormationの2手法で記事にしましたが、今回はS3のログに同様のことを行う方法を記事にしました。 目的 S3に置いた機密情報が、想定外の取得をされていないか、がわかる環境の構築を目的としました。 悪意あるサービス等からの取得があったら、すぐにメール通知が飛ぶ、という環境がゴールのイメージです。 S3を監視するサービス 調べたところ、以下がありました。 S3アクセスログ AWS CloudTrail を使用した Amazon S3 API コールのログ記録 サーバーアクセスログを使用したリクエストのログ記録 CloudWatchメトリクス 2つある、S3アクセスログ 参考にしたページなどからの情報によると、以下のような違いがありそうです。 CloudTrail使用 サーバアクセスログ 料金 少し掛かる 安価 改ざん防止 可能 不可 出力先 CloudWatch S3 S3 監視対象バケット 全て 任意（複数） 任意（１つ） アクセス元がわかるか sourceIPAddress Remote IP （プロキシやFW経由だと実際のアドレスが不明確になる）とあり アラームを送信することまでを目的としているため、CloudWatchに出力できる方が良いです。 S3だと、Athenaを作って、Lambda等で周期的に不正トラフィックの有無を取得するSelect文を流して、SNSで通知、という作りこみが必要になりそうです。 また改ざん防止やアクセス元の特定の用途から、CloudTrailの方法を用いました。 標準のメトリクスではダメ？ 標準機能として、CloudWatchメトリクスがありますが、使ってみたところ出来合いのメトリクスであり、”特定のアクセス元（以外）からのアクセス数”のような細かい内容での検出は出来なそうでした。 これだけでは不十分 ここで行うことは”検出”だけで、不正アクセスを未然に防ぐことはできません。 IAMポリシーやバケットポリシーを適切に設定する必要があります。 やったこと コンソールから、以下のことを行いました。 監視するバケットの作成 CloudTrailで、証跡の作成 保存先S3バケットは、操作の中で作成できます。 CloudWathLogsのロググループも、操作の中で作成できます。 IAMロールも、操作の中で作成できます。 CloudWatchLogsから、メトリクスの作成 アラームの作成 作成時に、SNSトピックも作成できます。 構成 実際の手順 監視するバケットの作成 普通にバケットを作成します。 CloudTrailで、証跡の作成 [CloudTrail]-[証跡]から、[証跡の作成]をクリック。 証跡名 任意の名前で。 ストレージの場所 今回は新しく作ります 証跡ログバケット及びフォルダ 自動でバケット名が入ります フォルダまで指定できますが、末尾のスラッシュ(/)はつけないでください。 作成されるバケットポリシーで、リソースに指定する出力先バケットのパスのスラッシュが重複してしまいます。 下部の「ログはxxxxに保存されます」を見て問題ないか確認ください。 ログファイルの SSE-KMS 暗号化 今回は無効で。 ログファイルの検証 有効にしました。 SNS 通知の配信 無効にしました。 CloudWatch Logs 有効 ロググループ 今回は新規としました。 ロググループ名 任意で。 IAMロール 新規に作ります。 ロール名 任意で。 イベントタイプ データイベントのみ選択。 [基本的なイベントセレクターに切り替えます]をクリックします。 データイベントソース S3を選択。 S3バケット 現在および将来のすべての S3 バケットの”読み取り”と”書き込み”のチェックを外す。 今回は、作成したバケットのみを監視します。 こちらを使うと、「他の証跡の出力先バケットのログ」や「自身の出力先バケットのログ」も対象になるようです。 個々のバケットの選択 監視するバケットを指定して、”読み取り”と”書き込み”のチェックを入れる。 [次へ]-[証跡の作成]で完了です。 CloudWatchLogsから、メトリクスの作成 VPCフローログの際の作業と同じですので省略します。 フィルターパターンは前回と異なりJSON形式のログなので、公式を参考に作成します。 # GetObject、かつ送信データが1KBを超えるアクセス { ($.eventName = "GetObject") && ($.additionalEventData.bytesTransferredOut > 1000 )} # VPCエンドポイントを経由していないアクセス { ($.vpcEndpointId NOT EXISTS) } # { ($.vpcEndpointId = "" ) } や { ($.vpcEndpointId IS NULL ) }はダメでした。 # 特定のIP以外からのアクセス { ($.sourceIPAddress!="123.123.123.123") } # GetObject、かつ送信データが1KBを超え、特定のIP以外またはVPCエンドポイント以外のアクセス { ($.eventName = "GetObject") && ($.additionalEventData.bytesTransferredOut > 1000 ) && ( ($.sourceIPAddress!="123.123.123.123") && ( ($.vpcEndpointId != "vpce-xxxxxxxx" ) || ($.vpcEndpointId NOT EXISTS) ) ) } # 多分あっている、はず アラームの作成 こちらもVPCフローログの際と同じになりますので省略します。 作成したアラームが動くかチェック 作った構成が機能するか確かめます。 1KBのファイルをアップし、CloudShell（決められたIP以外）から、GetObjectしました。 結構待ちます。 公式によると、15分以内といっています。 CloudTrail は、通常、API コールから平均 15 分以内にログを配信します。この時間は保証されません。 アラームが飛ぶと、以下のようになりました。 片づけ アラームの削除 [CloudWatch]-[すべてのアラーム]から、作成したアラームをチェックし、[アクション]-[削除]。 SNSの削除 [Amazon SNS]-[トピック]-[（作成したトピック）]をクリックして、"サブスクリプション"から対象のアドレスを選択し、削除。 その後、対象のトピックを削除。 メトリクスフィルターの削除 対象のメトリクスフィルターの右上にチェックをして、削除。 証跡の削除 [CloudTrail]-[証跡]から、作成した証跡をチェックし、削除。 S3の削除 監視対象バケット、および保存先バケットを両方とも空にして削除します。 IAMロールの削除 作成されたロールを選択し、削除。 ロググループの削除 [CloudWatch]-[ロググループ]から、作成したロググループを選択し、[アクション]-[ロググループの削除]。 メトリクスの削除は・・・ 手動では削除できず、新しくデータが発行されなければ自動で削除されるようです。 課題 VPCエンドポイント経由以外のアクセスをフィルタから除外する方法 パブリック経由のアクセス パブリックサービスからのアクセス Athena、Lambda、Glue等 コンソールからのアクセス 見たところ、以下のようなことが確認できました。 見落とし、見間違いあると思われますので、ご自身で確認ください。 サービス vpcEndpointId sourceIPAddress その他 パブリック経由のEC2 なし パブリックIP コンソールからのアクセス 存在するが、知らないID 接続元のIP CloudShellからのアクセス なし AWSのIP範囲のうち、region=="ap-northeast-1" service=="AMAZON"のIPか？ Athenaからのアクセス なし "athena.amazonaws.com"` がセット テーブル名は見当たらない（見落としたかも？） Lambdaからのアクセス なし AWSのIP範囲のうち、region=="ap-northeast-1" service=="EC2"のIPか？ ・userAgentにAWS_Lambda_python3.9の文字列あり ・$.userIdentity.sessionContext.sessionIssuer.userNameに、関数名あり これらを除外するフィルターを作るのは難しそうです。VPC内部からのアクセスに出来るのであれば、そちらが楽かもしれません。 まとめ 「S3ログから不正アクセスを検出」というテーマで環境を構築する方法をまとめました。 次はCloudFormationを用いて作る方法を記事にしたいと思います。

はじめに メンテナンス性も考慮した、API Gatewayの一部のリソースのみIP制限する方法についてまとめました。 前提条件 例として、hoge1,hoge2,fuga1,fuga2の4つのリソースを作成するとします。 作成する際、IP制限ありのhoge1,hoge2の手前にrestrictionをつけます。 対して、IP制限なしのfuga1,fuga2の手前にはfreeをつけます。 実際にIP制限する際に楽になりますので、説明した通りに作成しましょう。 4つのURL IP制限あり https://~/prod/restriction/hoge1 https://~/prod/restriction/hoge2 IP制限なし https://~/prod/restriction/fuga1 https://~/prod/restriction/fuga2 リソースポリシーで、一部のみIP制限する 左のリソースポリシーをクリックしましょう。 以下をコピペします。 ステージは、prodとします。 <account-id>は、文字通りAWSアカウントIDです。 <api-id>は、apigatewayのIDになります。（下記画像の赤線箇所です。） { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:ap-northeast-1:<account-id>:<api-id>/prod/*/*/*" }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:ap-northeast-1:<account-id>:<api-id>/prod/*/restriction/*", "Condition": { "NotIpAddress": { "aws:SourceIp": ["111.111.11.11/32", "222.222.22.22/32"] } } } ] } リソースポリシーの解説 上のAllowでは、全てのapiを許可しています。 下のDenyでは、/prod/*/restriction/*としており、restriction配下のリソースであるhoge1とhoge2のみIP制限できます。 手前にrestrictionをつけることで、 今後、IP制限したいリソースやIP制限しなくないリソースが出た際に、 リソースポリシーを修正する必要はなく、メンテが楽なため、 最初に、restrictionとfreeをつけるとよいと思います。 ちなみに、restriction配下のGETメソッドのみIP制限したい場合、以下のようにGETをつけるとよいです。 ↓ /prod/GET/restriction/ その他、リソースポリシーの一般的なユースケースはこちらが参考になります。 すべてのリソースをIP制限する場合 ちなみにすべてのリソースをIP制限する場合は、以下のとおりです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:ap-northeast-1:<account-id>:<api-id>/prod/*/*/*" }, { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:ap-northeast-1:<account-id>:<api-id>/prod/*/*/*", "Condition": { "NotIpAddress": { "aws:SourceIp": ["111.111.11.11/32", "222.222.22.22/32"] } } } ] }

はじめに AWSのサービスについて色々学習してく中で、EC2からDBに接続するような構成は多々見ると思います。今回はEC2からRDS（MySQL）に接続する方法について記述していきます。 前提 EC2インスタンスは構築済みという前提で記述していきます。EC2はLinuxでインスタンスタイプはt2.microです。 また、様々な手順を一部省略して記載していきます。最低限コンソールを操作できる知識とスキルは持ち合わせているものとして記述していきます。 セキュリティグループ作成 EC2⇒セキュリティグループ⇒セキュリティグループのを作成の順でクリックします。 ・セキュリティグループ名 セキュリティグループの名前を設定します。任意の名前を入れていください。入力は必須です。 ・説明 セキュリティグループの説明を入力します。 ・VPC どのVPCにセキュリティグループを作成するかを指定します。 今回は、EC2とRDSを同じVPC内に構築するので、その二つと同じVPCにしてください。 ・インバウンドルール RDSに対してどの通信を許可するかを指定します。今回はEC2からの接続のみ許可すれば良いので画像のように入力します。 ただ、IPアドレスの部分は各自のEC2のプライベートIPアドレスを入力してください。 サブネットグループ作成 次にサブネットグループの作成を行います。 RDS⇒サブネットグループ⇒サブネットグループを作成の順でクリックしていきます。 ・名前 サブネットグループの名前を設定します。入力は必須です。 ・説明 サブネットグループの説明を入力します。 ・VPC どのVPCにセキュリティグループを作成するかを指定します。 今回は、EC2とRDSを同じVPC内に構築するので、その二つと同じVPCにしてください。 ・アベイラビリティゾーン マルチAZ構成にする場合は二つのAZに属したRDSを構築するため、AZ-aのとAZ-cのAZを選択します。 今回はマルチAZ構成にしないため一つでも構いません。EC2インスタンスと同じAZを選択しましょう。（画像は二つ選択していますが気にしないでください。） ・サブネット 選択したAZに属するサブネットを選択しています。本来ですと、EC2をパブリックサブネットでRDSをプライベートサブネットに配置したりする構成が多いと思いますが、今回は特に気にせず同じサブネットに置いてみます。 AZを一つしか選択していない人はサブネットも一つで十分です。 DB作成 次にDBを作成していきます。 RDS⇒データベース⇒データベースを作成の順でクリックしていきます。 データベース作成方法は標準作成を選択肢、エンジンはMySQLを選択します。 バージョンはお好きなものを選択。特に指定等なければ最新のバージョンで構いません。 テンプレートは無料利用枠を選択します。 DBインスタンス識別子は先頭にtest等をつけてわかりやすくしましょう。 パスワードは自身のパスワードを利用します。 DBインスタンスサイズはdb.t2.micro、ストレージは20GBとします。 VPCはEC2と同じ環境を選択しましょう。 ※後でVPCの変更はできませんのでご留意ください。 サブネットグループは先ほど作成したサブネットグループを指定。 セキュリティグループも先ほど作成したセキュリティグループを指定します。 パブリックアクセスは今回は行わないため、なしにチェックを入れてください。 データベースの作成をクリックします。データベース起動までに数分かかりますので、少し待ちましょう。 データベースが作成できたら、作成したDBをクリックするとエンドポイントが表示されているので、それをメモしておきます。 DB接続 事前に構築してあるEC2にSSHで接続します。 以下コマンドを実行してmysqlをインストールします。 最後の完了しましたと表示されたらOKです。 $ sudo yum -y install mysql 次に以下のコマンドを実行します。 RDSのエンドポイントは各自のエンドポイントを入力します。 $ mysql -u admin -p -h <RDSのエンドポイント> パスワードを聞かれるのでDBインスタンスを作成する際に指定したパスワードを入力します。 以下のようにMySQL [(none)]>と表示されれば接続完了です。 [ec2-user@ip-172-31-33-168 ~]$ mysql -u admin -p -h <エンドポイント> Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 15 Server version: 8.0.23 Source distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> さいごに 以上がEC2とRDS(MySQL)の接続手順になります。 今度はマルチAZや複数のEC2から接続する方法などの記事を作成しようと思っていますので、ぜひそちらもごらんください。 最後までご覧いただきありがとうございました！

はじめに AWSでなにか起きたら、できるだけ早く気づきたいですよね。 ということで今回はタイトルの通り、AWSのイベントをSlackに通知する方法をご紹介していきます。 Amazon SNSとAWS Chatbotというサービスを利用すると、いとも簡単にSlack通知を実装することができるんです。 本記事では、Slack通知の概要をざっと説明した後に、「CloudWatchのアラームが発生したらSlackに通知がいく」というような実装をしていきます。 ※ 今回はCloudWatchのアラーム通知ですが、他のサービスの通知にも参考になるかと思います。 目次 Slack通知の概要 通知サービスの設定 CloudWatchのアラーム通知設定 Slack通知の概要 冒頭でも記載しましたが、通知にはAmazon SNS（Simple Notification Service、以下SNSと記載）とAWS Chatbot（以下Chatbotと記載）というサービスを利用します。 それぞれざっくり以下のようなサービスです。 サービス名 説明 SNS メッセージを受信&送信してくれる橋渡し的存在。具体的にはAWSサービスからメッセージを受け取り、他のAWSサービスやメール, SMS等にメッセージやイベントを受け渡すサービス。 Chatbot AWSのイベント情報をSlackに通知するサービス。具体的には、まずSNSから通知イベントを受け取り、各種AWSサービスからアラームの内容を取得する。そしてアラームの内容をSlackまたはAmazon Chimeに対してメッセージを送信するサービス。 今回は以下のような流れで通知が行われます（以下の図参照）。 CloudWatchでアラームが発生すると、まずはSNSに通知がいきます。その通知がきたということをSNSはChatbotに送ります。そして最後にChatbotはCloudWatchから情報を取得し、その情報をSlackに送ります。 ※ AWSのサービスとしてCloudWatchを例として挙げていますが、他のサービスもほぼ同じ流れです。 通知サービスの設定 ここでは以下の3つのことをしていきます。 Slackチャンネルの作成 SNSの設定 Chatbotの設定 Slackのチャンネル作成 まずは通知を受信するためのチャンネルを作りましょう。 本記事ではtestというチャンネルを作成しました。 【補足】 Slackチャンネルについて 異なるイベントを同じチャンネルに通知することも可能です。 例えば、CloudWatchのアラームとCodePipelineの通知を一緒のチャンネルに通知させることができます。どの範囲の通知を受け取るかでチャンネル名を決めるのが良いかもしれません。 SNSの設定 Slack通知の概要でも説明しましたが、SNSはメッセージを受け取り、それを各受信者に送信するサービスです。 SNSではメッセージを受信または、送信するポイントをトピックと呼びます。 まずはSNSトピックを作成していきます。 今回は以下のような設定で進めます。画像外の部分はデフォルトの設定で進めていきます。 【補足】 トピックの種類について サービス名 説明 FIFO 受信したメッセージの順序付けが厳密に行われる。Amazon SQS（Simple Queue Service）と組み合わせて使用する スタンダード FIFOほど厳密なメッセージに順序付けはされない。様々な送信先を選択することができる 次に作成したトピックが受け取ったメッセージを、どこに配信するのかという設定をしていきます。 この設定をサブスクリプションと呼びます。 今回の配信先はChatbotになります。配信先がChatbotの場合はChatbot側でサブスクリプションを設定するため、SNSの画面上では設定しません。 そのため、一旦Chatbotの設定をしていきます。 Chatbotの設定 Chatbotのトップ画面からメッセージを送る先を設定していきます。 チャットクライアントをSlackに設定して、送信先のSlackを設定していきます（今回はtestという名前のワークスペースを用いています）。 連携が完了すると、Chatbotの画面に連携したSlackのワークスペースが表示されます。 ワークスペースの部分をクリックすると、チャンネルの設定をすることができます。 それではワークスペース内のチャンネルについて設定していきます。 ここでは、設定するのは以下の3つです。 どのSlackチャンネルに通知するか Slackのユーザーにどのようなアクセス制限を設けるか どのSNSトピックからメッセージを受け取るか 順番に画面を見ていきます。 どのSlackチャンネルに通知するか 今回は先ほど作成したtestというパブリックなチャンネルを指定しました。 Slackのユーザーにどのようなアクセス制限を設けるか 今回は画像のような設定を組んでいます。 Channelガードレール（Slackのチャンネルメンバーに与えられる権限）はあまり権限を与えたくなかったので、とりあえずAmazonSNSReadOnlyAccessを設定しました（とりあえず感がすごいですが。。。） 今回は、チャンネルIAMロールを設定します。ロール名はtest-alarm-roleとしました。 これでChatbotの設定は以上になります。 CloudWatchのアラーム通知設定 ※ここでは、アラームの詳細な設定方法の説明はしません。あくまで通知の設定のみ説明します。 それではCloudWatchの通知を設定していきます すでにアラームを作成している場合は編集ボタンから、そうでない場合はアラームの作成ボタンを押します。 通知の設定をする箇所で、先ほど作成したSNSトピックを選択します（今回はtest-topic）。 選択し終わったら通知の設定は完了です。 アラームの設定自体を完了させてください。 最後に動作確認をしてみましょう 今回はEC2インスタンスのメモリ使用率が80%以上だとアラームが出るように設定したので、メモリに負荷をかけてアラームを出していきます。 しばらくすると、Slackに通知がきました。 これで問題なく設定できたことがわかりました。 これで以上となります。 最後まで読んでいただきありがとうございました。 参考文献 Amazon SNS(公式) AWS Chatbot（公式）

はじめに EC2をCloudWatchで監視するというテーマで記事を書いてたのですが、記事の量が多くなってしまったので2つに記事を分割しました。 記事 内容 ログファイルを確認する CloudWatch内でサーバー内のログファイルを確認する メモリ使用率を確認＆アラームを設定する（本記事） メモリ使用率をCloudWatchにて確認して、異常値になったらアラームを出す 今回はメモリ使用率をCloudWatchで確認&アラームを出す方法を見ていきます。また実際にメモリに負荷をかけてアラームが出るか確認もしていきます。（メモリ使用率以外にも、同様に方法でディスク使用率等も設定可能です）。 目次 メモリ使用率を監視するためのメトリクスの作成 CloudWatchにてメモリ使用率を確認する アラームの設定をする メモリ使用率を監視するためのメトリクスの作成 メトリクスの作成自体はamazon-cloudwatch-agentというソフトを用いて設定していくのですが、こちらの前編の記事にて、やり方を記載しています。 そのため、本記事ではやり方を割愛します。 【補足】 メトリクスとは、CloudWatchが各リソース（EC2インスタンス等）について監視するパラメーターのことをいいます。 これには大きく2種類あります。 種類 説明 パラメーターの例 標準メトリクス EC2を立ち上げた時に標準的に設定してくれるメトリクス CPU使用率, インスタンスのステータスチェック等 カスタムメトリクス ユーザーが自分で作成する必要のあるメトリクス メモリ使用率, ディスク使用率等 今回はメモリ使用率をCloudWatchにて確認したいので、カスタムメトリクスを作成する必要があります。 ということで、次からメモリ使用率の確認やアラームの設定を見ていきます。 CloudWatchにてメモリ使用率を確認する カスタムメトリクスを設定すると、CloudWatchの画面にてCWagentという名前空間のメトリクスがあることがわかります。 CWAgent => ImageId,InstanceId,InstanceTypeと進み、メトリクス名がmem_used_percentのチェックボックスに✓をつけます。 そうするとこのように値が出ることがメモリ使用率のグラフが確認できます。 メモリ使用率を確認することができたので、次にアラームを設定していきましょう。 アラームの設定をする CloudWatchのアラーム画面に行きます。 アラームの作成 => メトリクスの選択から該当するメトリクス(mem_used_percent)にチェックをつけます。 その後、メトリクスの選択というボタンを押しましょう。 次にアラームを出す条件を設定していきます。 設定したら次へボタンを押します。 今回は以下のような設定で進めてきます。 設定 設定値 統計 平均値 期間 1分 しきい値の種類 静的 条件 80よりも大きい 通知の設定は今回はしません。特に設定せずに次へボタンを押します。 名前と説明をつけて設定は完了です。 今回は名前も説明も両方test-alarmとつけました。 これで設定完了です。 完了するとCloudWatchの画面に設定したアラームが表示されます。 設定値やアラームの状態を確認することができます。今は特にメモリに負荷はかけていないので状態がokになっていますね。 試しにメモリに負荷をかけてアラームが出るか確認してみましょう。 今回はStressという負荷テストツールを用います。 まずはStressをインストールしていきます。 $ sudo amazon-linux-extras install -y epel $ sudo yum -y install stress どのくらいのメモリを確保すればエラーが出るかtopコマンドにより確認します。 $ top # 中略 KiB Mem : 454044 total, 275236 free, 108184 used, 70624 buff/cache 使用していないメモリが270,000 KiBくらいありそうなので、このメモリの分を確保してしまいます。 $ stress -m 1 --vm-bytes 270000000 --vm-hang 0 -q & しばらくするとCloudWatchにてエラーが出てきました。 グラフを見ると、80%以上行っていることがわかります。 確認できたので、processをkillしておきます。 $ jobs [1]+ 実行中 stress -m 1 --vm-bytes 270000000 --vm-hang 0 -q & $ kill %1 これで以上になります。 ここまで読んでくださりありがとうございました。 少しでもみなさんのお力になれたら幸いです！ p.s. このアラームをSlackに通知したいという場合はAWSのイベントをslackに通知するも参考にしてみてください！！ 参考文献 デフォルトでCloudWatchで監視できるEC2のパラメーター ストレスコマンドでメモリに負荷をかける

はじめに ログファイルやサーバーのメモリ使用率等を、サーバーに入って確認するのって少し面倒ですよね（僕だけだったらすみません笑）。 そんな人のために、今回はCloudwatchにてサーバーのログやメモリ使用率を確認するための方法をご紹介します。 内容が多くなってしまったので、記事を2つに分けていきます。 これからEC2の設定をCloudWatchで監視しようとしている方は是非参考にしてみてください。 記事 内容 ログファイルを確認する（本記事） CloudWatch内でサーバー内のログファイルを確認する メモリ使用率を確認＆アラームを設定する メモリ使用率をCloudWatchにて確認して、異常値になったらアラームを出す 目次 EC2の準備 amazon-cloudwatch-agentの設定 amazon-cloudwatch-agentの起動 CloudWatchにてログを確認 （おまけ）監視するログファイルを追加する 補足 後編の記事にてメモリ使用率を確認する実装をする際も『EC2の準備』 〜 『amazon-cloudwatch-agentの起動』まで同じ操作になります。 EC2の準備 まずはEC2を立ち上げていきます。 今回は特別な設定はしていないので、AWSの画面はここでは割愛します。 対象のインスタンスにロールをアタッチしていきます。 今回はCloudWatchAgentServerPolicyというポリシーをアタッチしたロールを使用しました。 サーバーに入って必要なソフトを入れていきます。 今回インストールするのはamazon-cloudwatch-agentです。 $ sudo yum install -y amazon-cloudwatch-agent 以上でEC2の事前準備完了です。 次にamazon-cloudwatch-agentの設定をしていきます。 amazon-cloudwatch-agentの設定 amazon-cloudwatch-agentを設定する方法は大きく2つあります。 方法 説明 ウィザードを用いる方法 サーバー内で設定する。質問に答えると設定ファイルを作成してくれる AWS Service Managerを用いる方法 AWSのコンソール画面にて設定する 今回はウィザードを用いる方法を記載していきます。 以下のコマンドを打つと、自動的に質問が出てきます。 $ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard ============================================================= = Welcome to the AWS CloudWatch Agent Configuration Manager = ============================================================= ここから質問に回答する部分になります。 各質問に対して数字を選択してEnterを押すと、次の質問を表示してくれます ※ 本記事では明示的にすべての数字を打ち込んでいますが、default値を用いるときは数字の入力は不要です。 # どのOSでエージェントを使うか？ => 1. linux On which OS are you planning to use the agent? 1. linux 2. windows 3. darwin default choice: [1]: 1 # EC2かオンプレか？ => 1. EC2 Trying to fetch the default region based on ec2 metadata... Are you using EC2 or On-Premises hosts? 1. EC2 2. On-Premises default choice: [1]: 1 # どのユーザーでagentを実行するか => 1. root Which user are you planning to run the agent? 1. root 2. cwagent 3. others default choice: [1]: 1 # StatsD（OSSの数値レポーティングツール）デーモンを起動するか => 2. no Do you want to turn on StatsD daemon? 1. yes 2. no default choice: [1]: 2 # CollectD（OSSの数値レポーティングツール）からのメトリクスは必要か => 2. no Do you want to monitor metrics from CollectD? 1. yes 2. no default choice: [1]: 2 # 諸々のメトリクス（CPUやmemoryに関するもの）は監視したいか => 1. yes # これでメモリ使用率等のカスタムメトリクスを取得することができます。 Do you want to monitor any host metrics? e.g. CPU, memory, etc. 1. yes 2. no default choice: [1]: 1 # コアあたりのCPUを監視したいか？ => 1. yes # Cloudwatchで追加料金が発生する可能性あり。 Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply. 1. yes 2. no default choice: [1]: 1 # イメージID, インスタンスID等も監視項目に入れたいか？ => 1. yes Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available? 1. yes 2. no default choice: [1]: 1 # メトリクスをどれくらいの間隔で収集するか？ => 4. 60秒 Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file. 1. 1s 2. 10s 3. 30s 4. 60s default choice: [4]: 4 # どのメトリクスの設定が良いか？ => 2. Standard Which default metrics config do you want? 1. Basic 2. Standard 3. Advanced 4. None default choice: [1]: 2 ここまで回答すると設定ファイルがJSON形式で表示されます。 設定値を確認して問題ないか聞かれるので、問題なかったらyesをしていきます。 ※ 2. noを選択すると再度Which default metrics config do you want?（どのメトリクスの設定が良いか）が聞かれます。他の質問は再度聞かれることはありません。謎です。 Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items. 1. yes 2. no default choice: [1]: 1 ここからも引き続き質問がいくつかされるので、回答していきます。 Cloudwathc Log Agentはすでにあるかという質問がされます。今回はまだないので2. noを選択しました。 Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration? 1. yes 2. no default choice: [2]: 2 この後、監視したいファイルについて、聞かれます。 今回は/var/log/messagesをCloudWatchで監視してみます（もし監視したいファイルがない場合は2. noを選択してください）。 # 監視したいファイルはあるか？ => 1. yes Do you want to monitor any log files? 1. yes 2. no default choice: [1]: 1 # ログファイルのpathは？ => /var/log/messages Log file path: /var/log/messages # ロググループ名は？ => [messages] Log group name: default choice: [messages] messages # ログストリーム名は => messages Log stream name: default choice: [{instance_id}] messages # 追加で監視したいファイルはある？ => 2.no Do you want to specify any additional log files to monitor? 1. yes 2. no default choice: [1]: 2 これで監視したいファイルの設定をすることができました。 【補足】 /var/log/messagesについて /var/log/messagesはシステムに関するログを残すファイルになっています。 内容は/etc/rsyslog.confにて設定をしています。 【補足】 ロググループ、ログストリームについて CloudWatchでは監視する大枠をロググループとして、実際の監視内容をログストリームとして設定することができます。 ロググループの中に、ストリームがあるという階層構造になっているイメージです。 ここまで設定すると、設定ファイルの内容が再度表示されます。 また設定値が/opt/aws/amazon-cloudwatch-agent/bin/config.jsonに記録されます。 最後にSSM（Systems Manager）に設定を保存するか聞かれます。 今回は2. noを選択しました。 ※ 設定をSSMに保存をする場合は別途ssm-agent等の設定が必要になります。 Please check the above content of the config. The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json. Edit it manually if needed. Do you want to store the config in the SSM parameter store? 1. yes 2. no default choice: [1]: 2 Program exits now. これでamazon-cloudwatch-agentの設定が完了です。 少し長くなってしまったので、一旦今回のウィザードでの僕の回答をまとめておきます。 ※ 必要に応じてご自身で設定は変更してください。 質問内容 回答 どのOSでエージェントを使うか？ 1. linux EC2かオンプレか？ 1. EC2 どのユーザーでagentを実行するか？ 1. root StatsD（OSSの数値レポーティングツール）デーモンを起動するか？ 2. no CollectD（OSSの数値レポーティングツール）からのメトリクスは必要か？ 2. no 諸々のメトリクス（CPUやmemoryに関するもの）は監視したいか？ 1. yes コアあたりのCPUを監視したいか？ 1. yes イメージID, インスタンスID等も監視項目に入れたいか？ 1. yes メトリクスをどれくらいの感覚で収集するか？ 4. 60秒 どのメトリクスの設定が良いか？ 2. Standard ここまでの設定で問題ないか？ 1. yes Cloudwatch Log Agentはすでにあるか？ 2. no 監視したいファイルはあるか？ 1. yes ログファイルのpathは？ /var/log/messages ロググループ名は？ messages ログストリーム名は？ messages 追加で監視したいファイルはあるか？ 2. no SSM（Systems Manager）に設定を保存するか 2. no この状態でamazon-cloudwatch-agentの設定は完了したのですが、まだCloudWatchの画面に行っても特にログは記録されていません。 ログを確認するには、amazon-cloudwatch-agentを起動する必要があります。 次項でamazon-cloudwatch-agentを起動させていきます。 amazon-cloudwatch-agentの起動 以下のコマンドによりamazon-cloudwatch-agentを起動していきます。 これで先程設定したログファイル（今回は/var/log/messages）をCloudWatchにて確認できるようになりました。 $ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s # 以下各オプションの説明 # -a fetch-config: エージェントは最新バージョンのCloudWatchエージェント設定ファイルをロードする # -m ec2: サーバーの種類を選択、オンプレの場合はonPremiseとなる # -c file:[ファイルパス] 設定ファイルを指定、ssmにて保存しているファイルを指定する場合は-c ssm:[ssmのファイル名]となる # -s :エージェントを開始 【補足】 amazon-cloudwatch-agentの起動について systemctlを使って以下のようなコマンドをうっても、初回はうまくいきません。 $ sudo systemctl start amazon-cloudwatch-agent これは先程ウィザードにて設定したconfigファイルに関して、amazon-cloudwatch-agentがうまく読み込めていないためです。 amazon-cloudwatch-agentはCloudWatchのconfigファイル（本記事の場合はウィザードで作成したファイル）から/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.tomlを作成します。そしてこのtomlファイルを元にログをCloudWatchに作成していきます。 デフォルトではtomlと同ディレクトリにあるconfigのjsonファイルを読み込もうとします。 試しに以下のように/etc/.jsonを作成すると、起動することができます。 $ sudo ln -s /opt/aws/amazon-cloudwatch-agent/bin/config.json /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json $ sudo systemctl start amazon-cloudwatch-agent CloudWatchにてログを確認 それではCloudWatchの画面に行ってログを確認していきましょう。 ロググループのページに行くと、messagesというロググループがあることが確認できます。 messagesに入ってログストリーム（こちらもmessages）を見るとログが確認できます。 ここまでで、ログを確認する方法を見てきました。 最後におまけで監視するログファイルを追加する方法を見ていこうと思います。 （おまけ）監視するログファイルを追加する 監視するログファイルを追加するには、amazon-cloudwatch-agentの設定ファイルに情報を追記して再起動する必要があります。 それでは手順を見ていきましょう！ まずはCloudWatchの設定ファイルに情報を追記していきます。 今回はamazon-cloudwatch-agent自体のログである/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.logを監視してみましょう。 /opt/aws/amazon-cloudwatch-agent/bin/config.jsonのfilesのcollect_listの部分に設定を追記していきます。 /opt/aws/amazon-cloudwatch-agent/bin/config.json { "agent": { "metrics_collection_interval": 60, "run_as_user": "root" }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "messages", "log_stream_name": "messages" }, # ここから追記　 # ロググループとログストリームは"amazon-cloudwatch-agent"という名前で設定してきます。 { "file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log", "log_group_name": "amazon-cloudwatch-agent", "log_stream_name": "amazon-cloudwatch-agent" } # ここまで追記 ] } } }, "metrics": { # （以下省略） 設定が完了したら、amazon-cloudwatch-agentを再起動していきます。 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s CloudWatchを確認すると、新しいロググループが生成されていることが確認できました。 以上となります！ ここまで読んでくださりありがとうございました。 参考文献 Cloudwatch、ウィザードを用いる方法（公式） amazon-cloudwatch-agentのコマンドオプション参照（公式） AWSServiceManagerを用いた設定方法

AmplifyのアプリをAWSのAmplifyコンソール　上から消そうとしたら、消せなくなりました。 当初の失敗理由は、多分、Amplifyでアップした設定をAWSコンソールで手動で変えてしまい、権限が壊れた系のアラートだったと思います。 手元に記録がないのでアップできないですが、とりあえずCloudFormationを使って、地道に削除。 CloudFormation上でもう何もないはずなので、消せるかなと思ったら以下のエラー どうも対応するスタックが無いとかいうエラーっぽい。すでに消しましたから当然です どうしたらいいかGoogle先生に相談 何個か同じような回答がありましたが、一番上の人のリンクを貼ります aws amplify delete-backend-environment --app-id <アプリID> --environment-name dev --profile=私のプロファイル これで削除成功！

AmplifyのアプリをAWSのAmplifyコンソール上から消そうとしたら、消せなくなりました。 当初の失敗理由は、多分、Amplifyでアップした設定をAWSコンソールで手動で変えてしまい、権限が壊れた系のアラートだったと思います。 手元に記録がないのでアップできないですが、とりあえずCloudFormationを使って、地道に削除。 CloudFormation上でもう何もないはずなので、消せるかなと思ったら以下のエラー どうも対応するスタックが無いとかいうエラーっぽい。すでに消しましたから当然です どうしたらいいかGoogle先生に相談 何個か同じような回答がありましたが、一番上の人のリンクを貼ります aws amplify delete-backend-environment --app-id <アプリID> --environment-name dev --profile=私のプロファイル これで削除成功！

はじめに Auto ScalingグループのAuto Healingの設定を解除する方法について色々と調査した為に備忘録も兼ねて記事にしております。先日、ALB配下にEC2インスタンスを紐付けて更にAuto Scalingを設定して色々と試しておりましたが、料金を見ると中々のお値段だったので、なるべく起動設定などは変更せずに、せめてEC2インスタンスだけは全て停止させておきたいな、と感じて調べてみました。 目的としては、起動しているEC2インスタンスはそのままの起動状態となりますが、停止した、もしくは停止させた場合に新しくインスタンスを起動させないようにしたい、というようなものになります。 一部のインスタンスをAuto Scalingから外す場合 もし特定のEC2インスタンスをAuto Scalingグループの管理下から外す場合、EC2インスタンスのデタッチを行い、再度Auto Scalingグループの管理下に戻す場合は、対象のEC2インスタンスをアタッチすることになると思います。その場合は以下説明が参考になると思います。 Auto Scaling グループからの EC2 インスタンスのデタッチする Auto Scaling グループに EC2 インスタンスをアタッチする 全てのインスタンスをAuto Scalingの管理下から外したい ところが全EC2インスタンスを管理下から除外するとなると少し面倒です。簡単に設定を変更して、Auto Scalingの管理下から外したい場合はヘルスチェックプロセスを停止することで実現出来るようです。 仕組みとしてはAuto Scalingグループにはプロセスの一時停止機能が提供されており、一時停止するプロセスで"Health Check"を指定します。その結果、EC2インスタンスおよびALBのヘルスチェックの結果として、インスタンスがUnhealthyとマークされなくなるようです。詳しくは以下ユーザーガイドをご参照ください。 中断の選択 ~ Auto Scaling グループのプロセスを一時停止および再開する 実際の設定画面 実際に設定すると以下の様になります。 ①Auto Scalingグループの選択 コンソール画面の「EC2」から「Auto Scaling グループ」を選択し、対象のグループのチェックボックスにチェックを入れます。 ②Auto Scaling設定の編集画面を開く 「Auto Scaling グループ」ページの下部に分割ペインが開かれるので「詳細」タブの下部にある、「高度な設定」欄の「編集」をボタンを押します。 ③中断プロセスの設定 高度な設定の中で「中断されたプロセス」欄のプルダウンリストから、「Health Check」を選択します。 ④確認と後進 「Health Check」が指定されていることを確認したら「更新」ボタンを押下します。これで設定は完了です。 実行中のEC2インスタンスを停止させても新たなインスタンスは起動されないはずです。 まとめ AWSで自宅学習を行っている方、また規模の小さい事務所で手探りで構築を勧めている方などはEC2インスタンスの費用が気になる為にこまめに落としておきたいものの数日後には元に戻したい、ということもあるかと思います。そんな時は結構お世話になるかもしれません。

1. はじめに 先日「AWS Backup」がVMware仮想環境に対応したと発表されました。 私もVMware Cloud on AWS環境のバックアップ/リストアでAWS Backupを試してみたので、手順を備忘録としてまとめます。オンプレミスVMware仮想環境でも同様な手順でAWS Backup利用可能なので、ご参考ください。 AWS re:Invent 2021でのVMware Cloud on AWS関連のアップデートは過去記事もご参考ください。 2. まずは手順の概要から 実際に私が辿ったおおまかな手順です。(3)(4)のステップではVMware Cloud on AWS側でNetworkとFirewall設定を実施します。(6)でリストアした仮想マシンをパワーオンするところまでの手順とTipsをまとめます。 (1) AWS Backup用のOVFテンプレートをダウンロード (2) OVFテンプレートから仮想アプライアンスをデプロイ (3) AWS Backup用ゲートウェイの作成 (4) AWS Backup用ゲートウェイに対象ハイパーバイザーを登録 (5) 仮想マシンをAWS Backupでバックアップ (6) バックアップした仮想マシンをリストア 3. 手順の詳細について (1) AWS Backup用のOVFテンプレートをダウンロード (1)-1 AWSコンソールからAWS Backupに遷移します (1)-2 「設定」から”VirtualMachine”のオプトインが”有効”となっていることを確認 デフォルトでは"無効"になっているので、初回は"有効"に設定変更します。 (1)-3 OVFテンプレートをダウンロード 約2GBあるのでゆっくり待ちましょう。 (2) OVFテンプレートから仮想アプライアンスをデプロイ (2)-1 vCenterにアクセスし、OVFテンプレートからデプロイ VMware Cloud on AWSで実施していますが、オンプレミスVMware仮想環境とフローは変わりません。 (2)-2 vCenterにアクセスし、OVFテンプレートからデプロイ バックアップ対象の仮想マシンと同じNWセグメントにデプロイします。今回はデフォルトのワークロード用ネットワークをそのまま利用しています。 (3) AWS Backup用ゲートウェイの作成 (3)-1 仮想アプライアンスにNATおよびFirewall Ruleを設定 作業端末(作業用PCで開いているAWSコンソール)から仮想アプライアンスにアクセス可能にします ※ 作業端末からAWSコンソール経由で仮想アプライアンスを操作するために必要なネットワーク設定です。ただし、仮想アプライアンスとAWSコンソールが同ネットワーク上に作業用端末が同じNW上に存在する場合はこのステップは不要です。 (3)-2 ゲートウェイの設定 ゲートウェイのIPアドレスは、作業端末のAWSコンソールからアクセス可能な仮想アプライアンスのIPを指定します。 ※ (3)-1をスキップした場合、指定するIPアドレスは仮想アプライアンスのプライベートIPとなります。 (4) AWS Backup用ゲートウェイに対象ハイパーバイザーを登録 (4)-1 仮想アプライアンスにFirewall設定 仮想アプライアンスからvCenterおよびESXiへのアクセスを可能にします。 (4)-2 ハイパーバイザーを登録 下図を参考にVMware Cloud on AWS情報を入力し、ハイパーバイザーを追加します。 ※ 「ゲートウェイ接続をテスト」で失敗する場合、VMware Cloud on AWSのFirewall設定およびFQDN形式を再確認します。 (4)-3 接続ステータスの確認 接続ステータス”がオンラインとなり、仮想マシンが確認できれば成功です！ ※ “接続ステータス”がオンラインとならない場合はハイパーバイザーの登録情報を削除し、(4)-2から再設定します。
接続された仮想マシンに仮想アプライアンス以外の仮想マシンが表示されない場合、仮想アプラインスが他の仮想マシンと同じNWに存在するか再確認します。 (5) 仮想マシンをAWS Backupでバックアップ (5)-1 対象の仮想マシンを選択し、バックアップを作成 本手順ではオンデマンドバックアップを実施しています。必要に応じてスケジューリングなども設定可能です。 ※ AWS Backupの利用が初めての場合は、このタイミングでバックアップボールトを作成しておきます。 (5)-2 バックアップジョブの進捗を確認 vSphere Clientの方からも進捗を確認できます。バックアップ対象の仮想マシンにスナップショットが作成・削除されます。 (5)-3 バックアップジョブの完了を確認 AWS Backupのコンソール画面から、バックアップジョブが完了したことを確認します。 (6) バックアップした仮想マシンをリストア (6)-1 対象のリカバリーポイントを選択 バックアップホールドから対象の復旧ポイントIDを選択し、「復元」に遷移します。 (6)-2 対象の仮想マシンをリストア 下図を参考に「バックアップを復元」します。 (6)-3 リストアの完了を確認 リストアした仮想マシンをパワーオンし、利用開始します。 4. さいごに (所感、利用料金について) いままではVMware Cloud on AWS上の仮想マシンのバックアップ・リストアは3rd Party製品を利用するのが唯一の選択肢でした。今回AWSサービスが対応したということで、より選択肢や組み合わせの幅が広がりそうです。今後もますますサービスや機能がアップデートされていくのが楽しみです！ AWS Backupの利用料金についてはAWS公式サイトをご参照ください。初期費用なし、バックアップ・リストアのデータ量による従量課金です。 5. 参考記事

ローカルからElastic Beanstalk環境で立ち上がっている複数インスタンス上Dockerコンテナ内に、同時にコマンド実行するコマンド ▼超参考 Elastic Beanstalk 特定環境の全インスタンス上でコマンドを実行する方法 - Qiita 複数インスタンス上Dockerコンテナ内に同時にコマンド実行するパイプライン CLIで以下パイプラインを実行 aws elasticbeanstalk describe-instances-health --environment-name my-env | jq -r ".InstanceHealthList[].InstanceId" | xargs -L1 -P2 -t -I {} eb ssh my-env --instance {} --command "sudo docker ps -a | grep 'entrypoint.sh' | awk '{print \$NF}' | xargs -t -I {} sudo docker exec {} bundle exec rails routes" my-envというEB環境に立ち上がっている2台のインスタンス内Railsアプリケーション（Docker）にrailsコマンドが実行できます。 ※もっとスマートに書ける方法をご存知の方がいましたらアドバイスいただけると嬉しいです！！ 必要なもの AWS CLI EB CLI jq (簡単な)解説 1. インスタンス情報取得 aws elasticbeanstalk describe-instances-health --environment-name my-env EB環境my-envのインスタンス情報を取得 jq -r ".InstanceHealthList[].InstanceId" 取得したインスタンス情報をjqに渡してインスタンスIDのみを抽出 2. インスタンスSSH接続 xargs -L1 -P2 -t -I {} 渡ってきたインスタンスIDを使用して以下eb sshコマンド作成 インスタンスが2台のため2プロセスを使って並列処理、それぞれ渡す引数は1つずつ eb ssh my-env --instance {} --command "" インスタンスIDを指定してeb ssh インスタンス内で実行するコマンドを引数に記載(中身は後述) 3. docker情報取得(インスタンス内) sudo docker ps -a インスタンス内のDockerコンテナ情報を表示 grep 'entrypoint.sh' | awk '{print \$NF}' Dockerコンテナ情報から対象のコンテナをgrepし、awkでNAMESを抽出 4. dockerコンテナ内コマンド実行 xargs -t -I {} sudo docker exec {} bundle exec rails routes" 渡ってきたDockerコンテナ名を使用してdocker execコマンドを作成 docker execコマンドにコンテナ内で実行したいコマンドを記載する(bundle exec ~) 参考

はじめに この記事は、2021年ROSAdvent Calendarの24日目の記事です。 投稿が遅くなりすみません。 ROS2、遠隔操縦、Unityでのシミュレーションが流行ってきているように感じたので、勉強のためにタイトルのようなものを作って見ました。 下記のような内容に興味がある方の参考になれば幸いです。 UnityのHDRPでROS2のシミュレータ環境構築(Ros2-For-Unity) GCP/DockerでのHeadlessなHDRP Unityアプリケーションの実行 AWS Kinesis Video Streamsを使ったWebRTC C/JSのクライアントの作成 実行の様子 実際に遠隔操縦している様子が下記になります。 UnityのHDRP環境はサンプルで用意されたものをそのまま利用していますが、非常に綺麗で動かしていて楽しいです。サンパウロは東京から18000km離れていますが、相手がクラウド上なので、比較的安定的に遠隔操縦できました(解像度は640x480)。ただシミュレータなので、サンパウロで実行されていようが、あまり分からないのが残念です。 ROS2で構築しており、カメラトピックが出力できて、cmd_vel を受け付けるロボットだとロボットの種類を問わず操作できます。 動かすために必要なコードはこちらです。 https://github.com/otamachan/ros2-unity-kvm-webrtc 構築方法は、最後に記載したので興味のある方は見てみてください(すみません、徐々に追記します)。 構成 以下のような構成になっています。 通信の流れはおおよそ以下のようになっています。 まずは、カメラ画像です。 Unityシミュレータではロボットに配置されたカメラ画像を、定期的にキャプチャし、 Ros2 For Unityを使用して、sensor_msgs/Image として非圧縮でROS2のトピックとして出力します。 別のノードで、その画像を受信し、NVENCを利用しh264にエンコードした後、Amazon Kinesis Video Streams C WebRTC SDK を使い作成されたWebRTCのPeerConnectionに流し込みます。 ブラウザ側では、同様にAmazon Kinesis Video Streams WebRTC SDK for JavaScriptを使って作成したPeerConnection経由で画像を受信し、Videoとして表示しています。必要に応じて、TURNが利用されるため、P2Pで接続できない場合でも、転送できます。 操縦側です。 Unityシミュレータは、Ros2 For Unityを利用して、geometry_msgs/Twist をSubscribeして、速度に応じて移動できるようしておきます。 ブラウザ側では、仮想のJoystickで操作量を作成し、カメラ画像で使ったPeerConnectionにはったDataChannelにJSON形式で送信します。画像を配信するノードが同様に、DataChannel経由でJSONを受け取りそれをROS2のgeometry_msgs/Twistとして発行しなおすことで、ブラウザ側から操作できるようにしています。 UnityシミュレータをGCPで実行するには、Nvidiaドライバが有効になったxserverを起動する必要があります。今回は、xserverをDocker内に起動することで、ホストOSにxserverを起動する必要なく、UnityシミュレータをDockerで実行させています。この方法は、ホストOSにxserverを上げられないk8s等の環境でも、Unityのアプリケーション等xserverが必要なアプリケーションが利用できるようになるので、色々と便利です。 一方、コンテナ内にホストのNvidiaドライバとまったく同じバージョンのNvidiaドライバ(のユーザランドライブラリ)をインストールする必要があり、そこは注意が必要です。 終わりに 組み合わせるだけかと思いきや色々大変でした。特にUnityは慣れていない世界だったので、C#の書き方から始まって苦労しました。 それでは2022年もLet's enjoy robot programming! ついでに。 PreferredRobotics社では、ROS/ROS2/AWS/GCPに興味があり、ロボットの製品化を一緒に推進していただける仲間を積極的に募集しております。 興味のある方は是非話を聞きに来てください！ 構築手順 構築環境 実行環境は、下記を想定しています。 Ubuntu 20.04 CUDA 10.2 ROS2 Foxy Unity 2020.03(LTS) 必要なコードの取得 GitHubから必要なコードをクローンしておきます。 git clone https://github.com/otamachan/ros2-unity-kvm-webrt.git UnityでHDRPサンプルプロジェクトの作成とビルド HDRPをするために、Vulkan環境も構築しておきます。2020では、Vulkan環境がなくてもHDRPが実行できる気がしますが、2019では必要だったので念の為にいれておきます。 sudo apt install vulkan-utils UnityHubの右上「新しいプロジェクト」をクリックし、HDRPのサンプルである、3D Sample Scene(HDRP) を選び、保存場所、プロジェクト名を適当につけて作成します。 メニューの「File」→「Build and Run」からビルドして実行できることを確認してください。実行すると以下のような画面がでて、キーボードやマウスで視点の移動ができるようになります。 ビルドにはかなり時間を要するので、気長にまちます。 Ros2ForUnityのビルド環境準備 今回、ROS2とUnityの通信として、Ros2 For Unity を使用しました。Unityの公式は、ROS TCP Connectorを使う方法ですが、今回画像トピックを扱うため、容量やレイテンシを考慮し、直接ROS2のトピックが発行できるRos2 For Unityを使いました。 DotNetのインストール https://docs.microsoft.com/ja-jp/dotnet/core/install/linux-ubuntu#2004- に従ってdotnetのSDKをインストールします。 各種ROS2のビルドツールのインストール また、Ros2ForUnityのビルドに必要なビルドツールをインストールしておきます。 sudo apt install python3-vcstool python3-colcon-common-extensions Ros2 For Unityのビルド https://github.com/RobotecAI/ros2-for-unity をクローンしビルドします。 以下の手順でビルドします。基本的には、README-UBUNTU.mdの通りです。 create_unity_package.shはUnityEditorがインストールされているパスを指定する必要があるので、注意してください。 source /opt/ros/foxy/setup.bash ./pull_repositories.sh ./build.sh source install/setup.bash # 重要 ./create_unity_package.sh -u ~/<path to unity editors>/2020.3.25f1/Editor/Unity ビルド後、先程のサンプルUnityプロジェクトで メニュー「Assets」→「Import Package」→「Custom Package...」から、ros2-for-unity/install/unity_package/Ros2ForUnity.unitypackage を選択し、ビルドしたパッケージを取り込みます。 これもhttps://github.com/RobotecAI/ros2-for-unity#usage に書かれた手順通りです。 Unityの再起動 Ros2 For Unity は、ROS2の実行環境に依存するため、ROS2の環境変数が設定された状態で、Unityを実行する必要があります。ターミナルから、以下のように、/opt/ros/foxy/setup.bash を読み込みUnityを再起動しておきます。UnityHubが常駐していた場合は、再起動前に一度終了させておいてください。 source /opt/ros/foxy/setup.bash ~/<path to unity editors>/2020.3.25f1/Editor/Unity 必要なスクリプトの配置 一番最初にクローンしておいた https://github.com/otamachan/ros2-unity-kvm-webrtc にある、UnitySampleRobot を、UnityプロジェクトのAssets以下にコピーします。 カメラを配置し、ROS2のgeometry_msgs/Twist型のトピックから動かせるようにする シーンにカメラを配置します 実行時に警告がでるので、「Audio Listener」のチェックをはずしておきます 「Add Component」で「ROS2 Unity Component」を追加します さらに「Add Component」で「RobotController」を追加します。これでcmd_velでカメラを移動できるようになります。 cmd_vel トピックでカメラが移動できるか、確認します。 Unityでアプリケーションを実行したあと、ターミナルで以下を実行しカメラがその場回転することを確認してください。 source /opt/ros/foxy/setup.bash ros2 topic pub /cmd_vel geometry_msgs/Twist '{linear: {x: 0.0}, angular: {z: 0.3}}' RobotControllerのコードはこちらです。 https://github.com/otamachan/ros2-unity-kvm-webrtc/blob/main/UnitySampleRobot/Assets/Scripts/UnitySampleRobot/RobotController.cs カメラの画像をROS2のsensor_msgs/Image型のトピックとして発行できるようにする HDRPで、レンダリング結果を取得したり、加工する場合は、CustomPassを利用し独自処理を書きます。今回は、Blit メソッドを使用しレンダリングテクスチャをY軸方向に反転して別のテクスチャにコピーします。別テクスチャにコピーしたあとは、RequestAsyncReadbackを利用し、GPUからCPUメモリに非同期でコピーします。 CameraPublisherのコードはこちらです。 https://github.com/otamachan/ros2-unity-kvm-webrtc/blob/main/UnitySampleRobot/Assets/Scripts/UnitySampleRobot/CameraPublisher.cs カメラのアンチエイリアスを有効にしておきます。 CustomPassVolumeを追加し、InjectionPointをAfterPostProcessにし、CameraPublisherをCustomPassとして追加します。これで、Cameraの画像がPublishされるようになります。 Unityでアプリケーションを実行したあと、Rvizでカメラ画像がPublishされていることを確認してください。 ros2 run rviz2 rviz2 シミュレータのビルド 最後に、シミュレータをビルドします。 メニューから「File」→「Build Settings...」でビルドメニューを開き、「Build」でビルドします。 ここまでで、Unityシミュレータの作成は完了です。 ↓にビルド結果をおいておきます。 https://drive.google.com/drive/u/0/folders/1QrvWHnIiJ9i2hPu0spXhjiOHHhJ8Lhsy ROS2/WebRTCプロキシノードのビルド 次は、ROS2の画像をSubscribeし、AWS Kinesis Video Streams WebRTCを使いWebRTCとして、転送するノードをビルドします。 処理の概要を説明します。 AWS Kinesis Video Streams WebRTC自体は、画像のエンコード処理が入っていないため、NVIDIA Video Codec SDKを使い、h264にエンコーディングを行いました。エンコードAPIの呼び出しに関しては、Nvidiaが提供しているサンプル実装(https://github.com/NVIDIA/video-sdk-samples )をそのまま呼び出しています。 AWS Kinesis Video Streams WebRTCに関しても、提供されているAmazon Kinesis Video Streams C WebRTC SDKのサンプルである、kvsWebRTCClientMasterをほぼ再利用して、実装しています。 ポイントとしては、 NVENCは、RGB系の入力として NV_ENC_BUFFER_FORMAT_ARGB の4byteフォーマットが必要であるため、Subscribeした画像はそのままエンコードできず、一度コピーを実施しています NVENCは、デフォルトでIDRフレームを生成しない設定になっていたので、適当なフレームで生成するような設定にしています(gopLength, idrPeriod, repeatSPSPPS)。これを設定しないと、途中から再接続した場合に、動画がデコードできなくなります。Amazon Kinesis Video Streams C WebRTC SDKは、FIR/PLIのコールバックが記述できるようになっているので、本来はこのコールバックでIDRフレーム等を生成させればよいのですが、今回はシンプルにするために、定期的に生成するだけにしています。 ros2_kvm_webrtc_sample のコードはこちらです。複数のサンプルを無理やりくっつけて実装しているので、きれいではないですが、500行程度で実装できました。 https://github.com/otamachan/ros2-unity-kvm-webrtc/blob/main/ros2_kvm_webrtc_sample/src/main.cpp ビルド方法は、適当な場所にROS2のビルドワークスペースを作り、colconを使ってビルドします。 依存ライブラリでのビルド警告がでますが、無視します。 mkdir -p ws/src cd ws/src ln -s ../../ros2_kvm_webrtc_sample source /opt/ros/foxy/setup.bash colcon build 実行には、AWSのAWS Kinesis Video Streams WebRTC周りの権限が必要なので、必要な権限をもったIAMユーザを作成し、適当にキーを用意して実行してください。 export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX export AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY export AWS_DEFAULT_REGION=ap-northeast-1 source install/setup.bash ros2 run ros2_kvm_webrtc_sample ros2_kvm_webrtc_sample_node 権限に問題がなければ、AWS Kinesis Video Streams WebRTCに「ScaryTestChannel」(SDKのサンプル通り)というチャネルが作られて、接続されます。 [KVS Master] Using trickleICE by default [KVS Master] Created signaling channel ScaryTestChannel [KVS Master] Finished setting audio and video handlers [KVS Master] KVS WebRTC initialization completed successfully [2021/12/31 12:08:10:9870] N: LWS: 4.2.1-v4.2.2, loglevel 7 [2021/12/31 12:08:10:9870] N: NET CLI H1 H2 WS ConMon IPv6-absent [2021/12/31 12:08:10:9871] N: ++ [wsi|0|pipe] (1) [2021/12/31 12:08:10:9871] N: ++ [vh|0|netlink] (1) [2021/12/31 12:08:10:9871] N: ++ [vh|1|default||-1] (2) [KVS Master] Signaling client created successfully [2021/12/31 12:08:10:9876] N: ++ [wsicli|0|POST/h1/kinesisvideo.ap-northeast-1.amazonaws.com] (1) [2021/12/31 12:08:11:0732] N: -- [wsicli|0|POST/h1/kinesisvideo.ap-northeast-1.amazonaws.com] (0) 85.593ms [2021/12/31 12:08:11:0735] N: ++ [wsicli|1|POST/h1/kinesisvideo.ap-northeast-1.amazonaws.com] (1) [2021/12/31 12:08:11:1478] N: -- [wsicli|1|POST/h1/kinesisvideo.ap-northeast-1.amazonaws.com] (0) 74.288ms [2021/12/31 12:08:11:1484] N: ++ [wsicli|2|POST/h1/r-2c136a55.kinesisvideo.ap-northeast-1.amazo] (1) [2021/12/31 12:08:11:3729] N: -- [wsicli|2|POST/h1/r-2c136a55.kinesisvideo.ap-northeast-1.amazo] (0) 224.424ms [2021/12/31 12:08:11:3735] N: ++ [wsicli|3|WS/h1/m-26d02974.kinesisvideo.ap-northeast-1.amazona] (1) [KVS Master] Signaling client connection to socket established [KVS Master] Channel ScaryTestChannel set up done GPU in use: NVIDIA GeForce GTX 1080 AWS Kinesis Video Streams WebRTCと接続確認 ROS2のトピックが、正しくPublishできているか確認します。 まず適当なUSBカメラから、image_rawトピックを発行します。 sudo apt install ros-foxy-v4l2-camera source /opt/ros/foxy.setup.bash ros2 run ros2 run v4l2_camera v4l2_camera_node 次に上述の通り、ROS2/WebRTCプロキシノードを起動します。 export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX export AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY export AWS_DEFAULT_REGION=ap-northeast-1 source install/setup.bash ros2 run ros2_kvm_webrtc_sample ros2_kvm_webrtc_sample_node AWSコンソールを開き、 該当チャネル(ScaryTestChannel)を選択後、メディア再生ビューワーで再生してみてください。 カメラ動画が再生できるのが、確認できると思います。 力付きてきたので、以下徐々に追記します。 GCP上にインスタンスを起動する gcloud compute ssh ros2-unity-xserver -- -L8081:localhost:8081 sudo docker run --gpus all -d -it --rm -v $(pwd):/ws -p 8081:8081 otamachan/gcp-ros2-xserver GCP上でDockerを使ってxserverを起動し、Unityシミュレータを立ち上げる GCP上にROS2/WebRTCプロキシノードを起動する Webクライアントをブラウザから読み込み遠隔操作してみる

パスパラメータから値を取得する Lambda関数に、以下のコードを追加します。 let name = event.pathParameters.name; console.info(`name: ${name}`); WebStormを使って、ローカル環境で実行する 「Edit Configurations...」をクリックします。 「API Gateway AWS Proxy」をクリックします。 「pathParamters」に、nameを追加します。 Lambda関数を実行します。 パスパラメーターから取得した値が出力されました。

ELB (Elastic Load Balancer) tutorial 今回の構成 ELBを2代のEC2に振り分ける用に設定 EC2にはindex.htmlを配置して、アクセスしたらそのHTMLが見れるようにする VPCはデフォルトVPCを使用 SecurityGroupを作成する VPCを作成 CIDR: 192.168.0.0/16で作成 インターネットゲートウェイを作成 IGをVPCにアタッチしないとVPCが外部からのアクセスを許可しないので、EC2インスタンスに接続できない。 VPCに設定されているルートテーブルでEC2を配置しているサブネットを関連付けする。 ルートにigw(インターネットゲートウェイがアタッチされていないとネットと接続できないので、なければ設定する。) subnet作成 以下の設定で作成 elb-tutorial-subnet1 AZ: ap-northeast-1a cidr: 192.168.0.0/24 elb-tutorial-subnet2 AZ: ap-northeast-1c cidr: 192.168.1.0/24 作成後： EC2 instanceの作成 セキュリティグループは新しく作成する。 Name: elb-tutorail-sg 説明: security group for elb tutorial キーペアの作成： EC2 instanceの設定 Server1: AMI: Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type インスタンスタイプ： t2.micro サブネット： ap-northeast-1a ストレージの追加： デフォルト タグ： key: Name value: elb-tutorial-server1 パブリックIPの自動割り当て 有効 Server2: AMI: Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type インスタンスタイプ： t2.micro サブネット： ap-northeast-1c ストレージの追加： デフォルト タグ： key: Name value: elb-tutorial-server2 パブリックIPの自動割り当て 有効 下記のスクリプトを高度な詳細のユーザーデータ欄に記入。Server1とServer2で内容を少しかえる。 なぜか、下記スクリプトが実行されていなかったので後々ssh接続して直接EC2内でコマンドを叩いた。 以前はできたので、設定の書き方がおかしかったのかもしれない。 ユーザーデータ Server1： #!/bin/bash sudo su yum update -y yum install httpd -y echo "<html><h1 color="red"> Hello World! This is Server 1 </h1><html>" > /var/www/html/index.html systemctl start httpd systemctl enable httpd ユーザーデータ Server2： #!/bin/bash sudo su yum update -y yum install httpd -y echo "<html><h1 color="blue"> Hello World! This is Server 2 </h1><html>" > /var/www/html/index.html systemctl start httpd systemctl enable httpd 作成後 ステータスチェックのところが「2/2 のチェックに合格しました」になればOK インターネットゲートウェイの作成 name: elb-tutorail-ig と言う名前に設定して,VPCにアタッチする。 ※ インターネットゲートウェイがアタッチされたVPCじゃないと、ロードバランサーに設定できない。 ターゲットグループの作成 Basic configuration instances Target group name elb-tutorail-tg vpc 作成したvpc その他はデフォルト Register targetsで2つのインスタンスを設定 elb-tutorila-tgのHealthyステータスが2つになったらOK ロードバランサー作成 load balancer type Application Load Balancer load balancer name elb-tutorail-lb scheme Internet-facing Listeners and routeing Default action elb-tutorial-tgのターゲットグループを選ぶ VPC elb-tutorail-vpc Mappings ap-northeast-1a ap-northeast-1c Security Group elb-tutorail-sg （defaultは削除） 作成後、DNS名をブラウザで開くと。server1 or server2が表示される。 リロードするごとにserver1とserver2が交互に入れ替わりバランシングされていることが確認できる。 試しにEC2を片方停止してみると、どちらかのサーバーのみが表示されるようになる。 server1 server2

はじめに 以前の記事で、ROSA(Red Hat OpenShift Service on AWS) クラスターのデプロイ方法と、Web コンソールのアクセス経路を調査しました。 ROSA(Red Hat OpenShift Service on AWS) を動かしてみた https://qiita.com/sugimount-a/items/73d3ad7864e69cba2cc7 ROSAのコンソールのアクセス経路と提供元Podを調査してみた https://qiita.com/sugimount-a/items/0720c41cba6a1c0b2954 今回は、自分たちで作成した Deployment を外部公開するときの手順を紹介します。「ROSAのコンソールのアクセス経路と提供元Podを調査してみた」で調査した通信経路を理解すると、自分たちの Deployment を公開するときの通信経路の理解が深まります。もしお時間があれば、ざっと目を通すと良いと思います。 ROSA での公開方法は大きく分けて 2パターンがあると思います。 OpenShift に備わっている Route で公開 Kubernetes の機能を使い、Service LoadBalancer などで公開 どちらでも問題はないと思いますが、今回は Route で公開をしてみます。 ネットワーク接続図 今回紹介する Route で公開する手順で実現できる、ネットワーク接続図を載せます。 名前解決は Route 53 で行う Internet に接するコンポーネントは、CLB CLB が、Router Pod にリクエストを投げる Router Pod が これから設定する Route 情報に従い、Nginx にリクエストを投げる Route で公開 独自の Deployment として、Nginx コンテナを使っていきます。また、この Deployment に紐づける形で Service Cluster IP を作成します。 マニフェストファイルは次の通りです。 apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 # tells deployment to run 2 pods matching the template template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 ファイルに保存したうえで、apply でデプロイします。 kubectl apply -f ~/k8s-manifests/nginx.yaml Pod 2個 が Worker Node で稼働しています。 $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-deployment-66b6c48dd5-4d7mb 1/1 Running 0 20s 10.129.2.14 ip-10-0-201-136.ap-northeast-1.compute.internal <none> <none> nginx-deployment-66b6c48dd5-gs9v2 1/1 Running 0 20s 10.128.2.211 ip-10-0-164-3.ap-northeast-1.compute.internal <none> <none> Service nginx-service が Cluster IP として稼働しています。 $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.30.0.1 <none> 443/TCP 8h nginx-service ClusterIP 172.30.179.253 <none> 80/TCP 2m17s openshift ExternalName <none> kubernetes.default.svc.cluster.local <none> 8h Cluster IP を使ってアクセスが出来るか確認をするために、kubectl debug で、動作確認用のコンテナを起動します。curl コマンドなどが既にインストールされている、自分が作成したコンテナを利用します。 kubectl debug nginx-deployment-66b6c48dd5-4d7mb -it --image=sugimount/toolbox:0.0.4 --share-processes --copy-to=myapp-debug nginx-service に ClusterIP 経由でアクセス可能なことがわかります。 # curl nginx-service <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> コンテナから Exit します exit 作成した確認用 Pod を削除しておきます kubectl delete pod myapp-debug oc expose で Route を作成します。これによって、Internet に公開されます。 oc expose service nginx-service 実行例 $ oc expose service nginx-service route.route.openshift.io/nginx-service exposed 作成された Route の確認をします。 $ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nginx-service nginx-service-default.apps.my-rosa02.pkyx.p1.openshiftapps.com nginx-service 80 None コンソール上でも確認できます。 場所の URL が、実際にインターネットから接続可能な URL となります。 Nginx 画面が正常に表示されます。 まとめ ROSA に付属されている Router を使って、Internet に公開する方法を紹介しました。今回は簡単に公開しただけですが、実際のサービスでは任意のドメイン名で公開したいですし、HTTPS を使ったアクセスも行いたいです。このあたりは時間ができたらまた確認したいと思います。