目次 はじめに（目的とか環境とか） CodeStarでプロジェクトを作成 CodeのClone 新規関数の作成 デプロイ はじめに 概要 　この記事ではCodeStarでPython×LambdaのWeb系プロジェクトを作成し、新規にLambda関数を作成する場面を想定して手順の備忘を記載します。 随時キャプチャが登場しますが全て2021/06/10前後時点のものなので、サービスアップデートに伴い変更される可能性があります。 目標 CodeStarプロジェクトをローカルにCloneしてVSCodeで開発し、新規Lambdaを作る 環境 ローカル環境 マシン：Mac ※Intel CPU OS：macOS Big Sur ver11.4 テキストエディタ：Visual Studio Code インストール済みライブラリ：Git CLI, AWS CLI AWS環境 アカウント：プライベートアカウント 作業リージョン：Tokyo (ap-northeast-1) 作業IAMユーザー名：work Access type：Programmatic access AWS Management Console access Group：Administrator CodeStarでプロジェクトを作成 　細かい説明は こちら をご覧ください。 　本記事では検証用に作成した下記プロジェクトを用います。 設定項目名 設定値 CodeStarテンプレート Python / Web service / AWS Lambda Project name private-work-codestar Project ID private-work Repository name private-work-codestar なお不要なアクセスを防ぐため上記プロジェクト作成後に自動作成されたAPI Gatewayを削除しています。 CodeのClone 　プロジェクトの作成により、CodeCommitやCodeBuild、CodeDeploy、CodePipeline等一連のCI/CDのツールチェーンが作成されています。 　続いて作成されたCodeCommitリポジトリをCloneして手元で編集できる環境を作ります。 （参考）作成したCodeStarプロジェクトのIDEタブ： 　上記の通りCodeStarプロジェクトでもClone方法はいくつか紹介されていますが、今回はAWSのCredential情報を用いてHTTPSでローカルにCloneする方法を用います。 なお一番簡単なのはCloud9を用いたCloneです。この場合CodeCommit→clone→Cloud9とAWS環境内で作業が閉じるため、IAMの権限不足等不要なエラーが起こりづらい印象です。 Cloneがうまく行かなかった場合の最終手段としてお試しください。 以後Git CLIとAWS CLIはインストール済みの前提で記述となりますのでご注意ください。 HTTPS経由でのCode Clone手順 作業は下記ドキュメントに従って実施していきます。 ※MFAを設定している場合この手順のみでは対応できません、ご注意ください。 https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-https-unixes.html 1. AWSCodeCommitPowerUserポリシーのアタッチ 　開発を行うユーザー（ここではwork）にAWSCodeCommitPowerUserポリシーを付与します。 しかしAdministratorで作成したユーザーはデフォルトでCodeCommitにFull Accessできるはずなので、この作業は（おそらく）不要です。 以下CodeCommitのFull Access権がないユーザーに対する記述です。 AWSコンソールトップからIAMを開き、ユーザーメニューから作業対象ユーザーを選択します。 続いてAdd permissionsを押下します。 ViewをAttach existing policies directlyに切り替え、CodeCommitを検索して表示される「AWSCodeCommitPowerUser」にチェックを入れ、Nextを押し、次の画面でAdd permissionsを押します。 以上で付与権限が付与されているはずです。 2. AWS Configure 　この作業ではIAMユーザーのAWS Credential情報が必要になりますので、お持ちでない場合はアカウントの管理者にお問い合わせください。 まずローカルのターミナルで下記を実行し、aws cliのconfig情報を書き換えます。 $ aws configure 実行すると下記の通りAccess KeyとSecret Keyの入力が求められるので入力します。 region nameはこの記事の場合「ap-northeast-1」、Default output formatは「json」と入力します。 AWS Access Key ID [None]: Type your target AWS access key ID here, and then press Enter AWS Secret Access Key [None]: Type your target AWS secret access key here, and then press Enter Default region name [None]: Type a supported region for CodeCommit here, and then press Enter Default output format [None]: Type json here, and then press Enter 続いて下記コマンドを入力します。 これを実行することでgitコマンド実行時にaws configureで設定した認証状を用いてCodeCommitにアクセスするようになります。 $ git config --global credential.helper '!aws codecommit credential-helper $@' $ git config --global credential.UseHttpPath true 以上で設定は完了です。 3. Codeのclone 下記URLからCodeCommitのHomeにアクセスします。 https://console.aws.amazon.com/codesuite/codecommit/home 表示されているリポジトリ一覧からCloneしたいプロジェクトを選択します。 続いてClone URLのプルダウンからClone HTTPSを選択すると、URLがコピーできます。 上記でコピーしたリポジトリを任意のパスにcloneします。下記のhttps移行はご自身のコピーしたURLに置き換えてください。 $ git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/private-work-codestar Cloning into 'private-work-codestar'... remote: Counting objects: 12, done. Unpacking objects: 100% (12/12), done. 以上でCodeのCloneは完了です。 新規関数の作成 　続いて新規関数を作成していきます。 既存コードの確認 まずはCloneしたプロジェクトをテキストエディタで開いてください。下記のような構造になっているはずです。 ここでは簡単な紹介に留めますが、それぞれ下記のような役割です。 ファイルまたはディレクトリ名 役割 tests/ CodeBuild時に実行される単体テストコード群 buildspec.yml CodeBuild用設定ファイル デフォルトではライブラリインストールや単体テストの実行、デプロイパッケージの作成についての設定が記述されている index.py デプロイされているLambda関数本体のコード README.md CodeCommitリポジトリの説明文 template-configuration.json CloudFormationによるアプリ更新時に用いConfig情報？詳細不明 template.yml Lambda関数の環境設定ファイル環境変数やLambdaの実行時間等が設定可能 プロジェクト構造のアップデート: 関数がもう一つできるので見通しをよくするため、まずプロジェクトの構造を下記の通り変更します。 変更点は下記の通りです。 HelloWorldディレクトリの作成 同ディレクトリへのindex.pyの移動 NewFuncディレクトリの作成 同ディレクトリへのindex.pyのコピー testsディレクトリ以下のアップデート test_handler.pyの複製 test_HelloWorld_handler.pyおよびtest_NewFunc_handler.pyへ名前の変更 コードのアップデート 　続いて稼働確認時にわかりやすいようNewFunc/index.pyのコードを下記の通りアップデートします。 ./NewFunc/index.py import json import datetime from logging import getLogger, StreamHandler, DEBUG, Formatter def handler(event, context): logger = getLogger(__name__) handler = StreamHandler() handler.setLevel(DEBUG) formatter = Formatter('%(asctime)s:%(lineno)d:%(levelname)s:%(message)s') handler.setFormatter(formatter) logger.setLevel(DEBUG) logger.addHandler(handler) logger.propagate = False logger.info('NewFunc handler start') data = { 'output': 'Hello New Func', 'timestamp': datetime.datetime.utcnow().isoformat() } logger.debug('data: {}'.format(data)) response = {'statusCode': 200, 'body': json.dumps(data), 'headers': {'Content-Type': 'application/json'}} logger.debug('response: {}'.format(response)) logger.info('NewFunc handler complete') return response 続いてtests/以下のコードを下記の通り変更します。 ./tests/test_HelloWorld_handler.py import unittest from HelloWorld import index ### アップデート class TestHandlerCase(unittest.TestCase): def test_response(self): print("testing response.") result = index.handler(None, None) print(result) self.assertEqual(result['statusCode'], 200) self.assertEqual(result['headers']['Content-Type'], 'application/json') self.assertIn('Hello World', result['body']) if __name__ == '__main__': unittest.main() ./tests/test_NewFunc_handler.py import unittest from NewFunc import index ### アップデート class TestHandlerCase(unittest.TestCase): def test_response(self): print("testing response.") result = index.handler(None, None) print(result) self.assertEqual(result['statusCode'], 200) self.assertEqual(result['headers']['Content-Type'], 'application/json') self.assertIn('Hello New Func', result['body']) ### アップデート if __name__ == '__main__': unittest.main() template.ymlのアップデート 続いて新規関数用の設定を記述していきます。 template.ymlを開き、下記の様に編集します。 ./template.yml AWSTemplateFormatVersion: 2010-09-09 Transform: - AWS::Serverless-2016-10-31 - AWS::CodeStar Parameters: ProjectId: Type: String Description: CodeStar projectId used to associate new resources to team members CodeDeployRole: Type: String Description: IAM role to allow AWS CodeDeploy to manage deployment of AWS Lambda functions Stage: Type: String Description: The name for a project pipeline stage, such as Staging or Prod, for which resources are provisioned and deployed. Default: '' Globals: Function: AutoPublishAlias: live DeploymentPreference: Enabled: true Type: Canary10Percent5Minutes Role: !Ref CodeDeployRole Resources: HelloWorld: Type: AWS::Serverless::Function Properties: FunctionName: !Sub 'awscodestar-${ProjectId}-lambda-HelloWorld' CodeUri: ./HelloWorld ### 新規追加 ### Handler: index.handler Runtime: python3.7 Role: Fn::GetAtt: - LambdaExecutionRole - Arn # Events: # GetEvent: # Type: Api # Properties: # Path: / # Method: get # PostEvent: # Type: Api # Properties: # Path: / # Method: post ### 新規追加 ここから ### NewFunc: Type: AWS::Serverless::Function Properties: FunctionName: !Sub 'awscodestar-${ProjectId}-lambda-NewFunc' CodeUri: ./NewFunc Handler: index.handler Runtime: python3.7 Role: Fn::GetAtt: - LambdaExecutionRole - Arn ### 新規追加 ここまで ### LambdaExecutionRole: Description: Creating service role in IAM for AWS Lambda Type: AWS::IAM::Role Properties: RoleName: !Sub 'CodeStar-${ProjectId}-Execution${Stage}' AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: Service: [lambda.amazonaws.com] Action: sts:AssumeRole Path: / ManagedPolicyArns: - !Sub 'arn:${AWS::Partition}:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole' PermissionsBoundary: !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/CodeStar_${ProjectId}_PermissionsBoundary' デフォルトのtemplate.ymlからの変更点は下記3点です。 Resources>Helloworld>Properties に 「CodeUri: ./HelloWorld」を追加： これは先程アップデートしたディレクトリ構造を反映させるためのものです。 これをしないままだと存在しない./index.pyを読みに行こうとし、一方でHelloWorld/index.pyを読めずにエラーとなります。 Resources>Helloworld>Properties のEventsをコメントアウト： 前述の通りAPI Gatewayは削除済みのため不要な設定のためコメントアウトしました。 API Gatewayを削除せず利用している場合、コメントアウトは不要です。 Resources に 「NewFunc」を追加： この項目を記述することでデプロイ時に新規Lambda関数として「NewFunc」が認識されます。 単体テスト 最後にプロジェクトディレクトリ下で単体テストを行いましょう。 $ python -m unittest discover tests testing response. {'statusCode': 200, 'body': '{"output": "Hello World", "timestamp": "2021-06-10T11:31:37.461334"}', 'headers': {'Content-Type': 'application/json'}} .testing response. 2021-06-10 20:31:37,461:15:INFO:NewFunc handler start 2021-06-10 20:31:37,462:21:DEBUG:data: {'output': 'Hello New Func', 'timestamp': '2021-06-10T11:31:37.462032'} 2021-06-10 20:31:37,462:26:DEBUG:response: {'statusCode': 200, 'body': '{"output": "Hello New Func", "timestamp": "2021-06-10T11:31:37.462032"}', 'headers': {'Content-Type': 'application/json'}} 2021-06-10 20:31:37,462:28:INFO:NewFunc handler complete {'statusCode': 200, 'body': '{"output": "Hello New Func", "timestamp": "2021-06-10T11:31:37.462032"}', 'headers': {'Content-Type': 'application/json'}} . ---------------------------------------------------------------------- Ran 2 tests in 0.001s OK 以上でコードの編集は完了です。 デプロイ いよいよデプロイです！ cloneしたディレクトリ下に移動してpushします。 $ git add . $ git commit -m "first commit" $ git push pushするとCodePipelineがCodeCommitの変化を検知し、Pipelineが動き出します。AWSコンソールよりCodePipeline→作成したプロジェクトIDのPipilineを開くと様子が確認できます。 CodeBuildの「Details」をクリックするとbuildspec.ymlに記述されたコマンドが実行されていった様子が確認できます。先程ローカルで行った単体テストも無事通りました。 PipelineのフローがExecuteChangeSetに差し掛かると大体Lambdaのデプロイが完了しているので、Lambdaコンソールで確認します。 Lambdaコンソールを開くと作成したLambdaが存在することが確認できます。この関数を開いて稼働の確認を行っていきます。 開いた画面で「Test」タブをクリックし、「Name」に適当なテスト名を入力し、「Test」ボタンを押下します。このタイミングで入力するkey valueは何でも良いです。 実行した結果ローカルでの単体テストと同じような形で出力されていれば成功です。またログの実態はCloudWatch Logsにあり、添付キャプチャの「Click here」から遷移できます。 Lambdaのテスト時に表示されたLog outputと同じものが確認できます。 長くなりましたが以上です！ 文は長いですがやってみると意外とあっさりなはず・・。

はじめに EICAR のテストウイルスが HTTP でダウンロードできなくなってしまったので、Amazon S3 の静的ウェブサイトを使ってテストウイルスのダウンロード環境を作ってみました。 （以前 Lambda 版を公開していましたが、今回は CloudShell 版です） ※HTTS ではダウンロードできるんですが、HTTP でテストしたい時があるんです！ CloudShell にて S3バケット作成 $ aws s3 mb s3://[バケット名] 公開設定 $ aws s3api put-public-access-block --bucket [バケット名] --public-access-block-configuration "BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false" 確認 $ aws s3api get-public-access-block --bucket [バケット名] 以下の結果であればOK { "PublicAccessBlockConfiguration": { "BlockPublicAcls": false, "IgnorePublicAcls": false, "BlockPublicPolicy": false, "RestrictPublicBuckets": false } } バケットポリシーを設定し匿名ユーザーへアクセス許可します $ cat << EOS > bucket-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::[バケット名]/*" } ] } EOS $ aws s3api put-bucket-policy --bucket [バケット名] --policy file://bucket-policy.json 必要ないと思いますが、index ファイルの設定も行っておきます $ aws s3 website s3://[バケット名] --index-document index.html CloudShell のローカルにテストウイルスを作成します $ cat << EOS > eicar.com X5O!P%@AP[4\PZX54(P^)7CC)7}\$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!\$H+H* EOS 作成したテストウイルスを S3 にアップロードします $ aws s3 cp eicar.com s3://[バケット名]/ S3 にアップロードできたか確認します $ aws s3 ls [バケット名] 2021-06-10 00:00:01 69 eicar.com ブラウザなどから実際にダウンロードしてみます http://[バケット名].s3-website-ap-northeast-1.amazonaws.com/eicar.com アンチウイルスソフトや UTM などがあれば、正しくブロックされるかもしれませんし、何もなければダウロードできるかと思います！

何がしたいか AWS CloudWatch Logs Insight で、一定時間以上の処理に時間かかってるリクエストの割合を抽出したい。 どうやるか > は真の時は 1, 偽の時は 0 になるので、 sum で数えられる。 例えば @duration が 2000ms よりかかったログの全体の割合を抽出したいときはこんな感じ。 fields @duration, @duration > 2000 as slow_res | stats count(@duration) as cnt, sum(slow_res) as slow_cnt, (slow_res / cnt) as slow_ratio 注意 公式の記述によると 1 とか 0 ではなくブール値を返すって書いてあるので使えなくなる時が来るのかも。 比較オペレーション 比較オペレーションは、filter コマンドで使用できます。また、他の関数の引数としても使用できます。比較オペレーションは、すべてのデータ型を引数として受け入れ、ブール値の結果を返します。 (強調は筆者による)

【Route53 ヘルスチェックタイプ】 業務内で少し耳にした内容になります。その備忘録です。 3種類のヘルスチェックタイプ エンドポイントをモニタリング IPアドレス、ドメイン名で特定するエンドポイントをモニタリングする。 指定された一定の間隔で、自動リクエストをインターネット経由でアプリケーションやサーバーなどのリソースに送信して、そのリソースが到達可能、使用可能、機能中であることを確認する。 CloudWatchアラームをモニタリング DynamoDBへのスロットル読み込みイベント数や正常と推測されるELB数など、CloudWatchメトリクスのステータスをモニタリングする。 他のヘルスチェックを監視 他のヘルスチェックが正常あるいは異常であるかを判断する時にモニタリングする。 複数のWebサーバーなどの同じ機能を実行する複数のリソースがあるときに、最低限のリソースが正常であるかを確認する。 ヘルスチェックの通知設定をせずに、各リソースにヘルスチェックを作成できる。 Webリソース数が指定する閾値を下回る場合に通知を行うように設定することも可能。

はじめに 前回以下の記事を書きましたが、JPCYBERのACL設定が正常に適用されるかは確認ができませんでした。 https://qiita.com/handy-dd18/items/8bd91eba22d46ab66ba9 そこで今回はJPCYBERの通信をWiresharkで見て、どのような処理をしているのかを追ってみようと思います。 パケットレベルのネットワークはそこまで理解していないので、変な表現があってもご了承ください。 Wireshark確認 事前確認 環境は前回の流用ですが、最低限以下は既に整っていることとします。 ・ファイルアップロードするAWSアカウントとS3のあるAWSアカウントは別 ・アップロード元AWSアカウント上でEC2(JPCYBER)を準備 ・JPCYBERはEC2にアタッチされたIAMロールの権限を使用する ・S3バケットのポリシーでIAMロールを許可 ・EC2にはWiresharkをインストール済み 確認内容 前回記事ではJPCYBERは想定通りにできず、CloudBerryDriveは想定通りにできました。 CloudBerryDriveの設定では、S3へ送信するリクエストヘッダにx-amz-aclを追加したことで、AWS CLIと同じように設定がされたのだと思います。 そのため、今回はJPCYBERのオプション設定のACL項目にチェックを入れたときに、リクエストヘッダに同じパラメータが設定されるかを確認します。 JPCYBER設定 検証用に作成したS3バケットをJPCYBERでマウントします。 この時の注意点は「SSL/TLS暗号化通信を使用する」チェックを外しておくことです。 そうすることで復号しなくてもWiresharkでパケットを確認することができます。 ※検証される場合は自己責任でお願いします。 サービス状態が実行中で割り当て済みドライブに名前があれば設定完了です。 エクスプローラーからS3の中身が確認できました。 オプション設定の「親バケットの～」のチェックをつけておきます。 ファイルアップロード まずは普通にファイルをアップロードしてみます。 チェックは付けていたはずですが、親バケットのACLは適用されていないようです。 Wireshark起動 Wiresharkを起動してイーサネットを選択します。 パケットのキャプチャがスタートします。 今回はHTTPのパケットだけ確認出来たらよいので、フィルタで絞っておきます。 ファイル再アップロード Wiresharkの設定ができたところでファイルを再度アップロードします。 操作時のパケットは以下のようです。思ったよりも出ているようです。 順番に見ていきます。 最初にdesktop.iniのヘッダ情報を取ろうとしていますが、当然そんなファイルがないので404エラーで返されています。 次にGETリクエストが投げられています。 demlimiterに2F(/)、list-typeとmax-keysがあり、Prefixがブランクであることから、S3バケット配下のリストしていると思われます。 その後アップロードするファイルが既に存在しているか確認しています。 testフォルダの配下にアップロードしたので、併せてtestフォルダ配下に対してリストが実施されているようです。 既存ファイルがなく、リストリクエストも問題ないことが確認出来た段階でファイルをアップロードしています。 これを見る限りはアップロード→ACL設定の順番でリクエストが送られているようです。 ただ、ACL設定のリクエストで403エラーが発生しており、アップロードだけが成功している状態のようです。 見る限り2回試行してダメであれば終了するようです。 ACL設定のリクエストではQuery Parameterにaclが設定されています。 CloudBerryDriveではリクエストヘッダにX-Amz-Aclパラメータがありましたが、JPCYBERのリクエストではありませんでした。(当然ですが) レスポンスを確認しましたが、権限ではじかれたことぐらいしかわかりませんでした。 CloudBerryDriveと比較してみる限りだと、リクエストがアップロードとACL設定で分かれているので、そもそもの設定方法が異なるようでした。 終わりに S3をマウントするツールを使用した場合にどのようにリクエストされているかは今まで曖昧だったので、今回具体的に確認できたのは良かったです。 また、CLIだとオブジェクトアップロード時にACLオプションを設定していますが、JPCYBERの場合はアップロードとALC設定を別々に実行していることがわかったので、その処理の違いも理解できました。 S3のALC周りは理解しきれていないところがあるので、今度はその辺りをもう少し勉強してみることにします。

概要 自分でLINE botを作成した際、C#+AWS(Lambda)環境で実装してみたのですが、 この技術スタックでの情報が全く見つかりませんでした。 (自分の探し方が悪かっただけかもしれませんが…) そこで、今後C#+AWS(Lambda)で作成したい！という方のために手順をまとめておきます。 本記事では、LINEから送信された文字をオウム返しするbotが作成できます。 このベースさえ作ってしまえば、LINE公式ドキュメントを参考に色々いじって楽しめると思います！ 内容としては、LINE Developers登録からLambda関数のプログラミング、AWSへのデプロイから最終的に実際にLINEで確認するところまでやってしまいます。 ※AWS Lambdaへのデプロイは、Windowsの場合、Visual Studioを使用すればGUIポチポチで完了するので簡単ですが、 Visual Studio for Macの場合はそうはいかないので、 今回はどの環境でも対応できるようCUIからデプロイする操作を記載しております。 事前準備編(LINE Developers登録) LINE Developers登録及びチャンネル作成 LINE botを作成するにあたり、「LINE Developers」に登録する必要があります。 手順は簡単で、申請待ち時間も無いので数分で登録可能です。 下記サイトを参考に、アカウントの作成及びチャンネルの作成まで行います。 ※1アカウントで「チャンネル」を複数作成することが可能で、「チャンネル」ごとに別のbotを作成できます。 チャンネルアクセストークンの発行 LINE botを作成するにあたり、最低限「チャンネルアクセストークン」は発行する必要があります。 チャンネルの作成まで完了したら、Line Develpersにログインし、作成したチャンネルのページにアクセスします。 「Messagin API設定」タブをクリックします。 ページ下部までスクロースし、「チャネルアクセストークン」の発行ボタンをクリックします。 発行されたキーは後ほど使用するのでどこかにメモをしておいて下さい。 ※後ほど再度このページにアクセスして発行済のキーを確認することは可能です。 プログラング編 無事アクセストークンの発行が完了したら、続いてプログラミングを行っていきます。 C#でのLambda関数プログラミングは、Windowsの場合はVisual Studioを使用すればあらかじめテンプレートが用意されているので簡単ですが、 Visual Studio for Macには用意されていないため、gitにテンプレートを用意しておきました。 ※AWSへデプロイするための設定ファイル等も同梱してあります。 ローカルにプロジェクトの準備が完了したら、「Function.cs」ファイルを開きます。 この中の「FunctionHandler()」メソッドがLambda実行時に呼び出されるメソッドです。 つまり、LINEのMessagingAPIからWebhookで呼び出されることになります。 今回はサンプルでbot利用ユーザが入力された文章をそのままオウム返しするようにしてみます。 ●LINEからLambdaへのリクエスト内容をモデリング WebHookRequestModel.cs using System.Collections.Generic; using Newtonsoft.Json; namespace LambdaSample.Models { public class WebHookRequestModel { [JsonProperty("events")] public List<EventModel> EventModels { get; set; } } } EventModel.cs using Newtonsoft.Json; namespace LambdaSample.Models { public class EventModel { [JsonProperty("message")] public MessageModel Message { get; set; } [JsonProperty("replyToken")] public string ReplyToken { get; set; } } } MessageModel.cs using Newtonsoft.Json; namespace LambdaSample.Models { public class MessageModel { [JsonProperty("type")] public string Type { get; set; } [JsonProperty("text")] public string Text { get; set; } } } ●LambdaからLINEへのリプライモデル ReplyRequestModel.cs using System.Collections.Generic; using Newtonsoft.Json; namespace LambdaSample.Models { public class ReplyRequestModel { [JsonProperty("replyToken")] public string ReplyToken { get; set; } [JsonProperty("messages")] public List<MessageModel> Messages { get; set; } /// <summary> /// true: ユーザに通知されない(デフォルト) /// false: ユーザに通知される /// </summary> [JsonProperty("notificationDisabled")] public bool NotificationDisabled { get; set; } } } ●メインの処理 Function.cs using System; using System.Collections.Generic; using System.Net.Http; using System.Net.Http.Headers; using System.Text; using Amazon.Lambda.APIGatewayEvents; using Amazon.Lambda.Core; using BasicExtension; using LambdaSample.Models; [assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))] namespace LambdaSample { public class Function { public Function() { _httpClient = new HttpClient(); _httpClient.DefaultRequestHeaders.AcceptCharset.Add(new StringWithQualityHeaderValue("utf-8")); _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", Environment.GetEnvironmentVariable("CHANNEL_ACCESS_TOKEN")); } public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest input, ILambdaContext context) { WebHookRequestModel webHookRequestModel = input.Body.ToObject<WebHookRequestModel>(); string replyToken = webHookRequestModel.EventModels[0].ReplyToken; MessageModel message = webHookRequestModel.EventModels[0].Message; ReplyToLine(replyToken, message.Text); return CreateLambdaApiResponse(); } private void ReplyToLine(string replyToken, string inputText) { string stringRequest = CreateReplyRequestModel(replyToken, inputText).ToJson(); StringContent stringContent = new StringContent(stringRequest, Encoding.UTF8, "application/json"); _httpClient.PostAsync("https://api.line.me/v2/bot/message/reply", stringContent).Wait(); } private ReplyRequestModel CreateReplyRequestModel(string replyToken, string inputText) { ReplyRequestModel replyRequestModel = new ReplyRequestModel(); replyRequestModel.ReplyToken = replyToken; replyRequestModel.Messages = new List<MessageModel>() { new MessageModel() { Type = "text", Text = inputText } }; replyRequestModel.NotificationDisabled = false; return replyRequestModel; } private APIGatewayProxyResponse CreateLambdaApiResponse() { return new APIGatewayProxyResponse { StatusCode = 200, Body = null, IsBase64Encoded = false, Headers = new Dictionary<string, string>() { { "Content-Type", "application/json" } } }; } private readonly HttpClient _httpClient; } } AWSへデプロイ こちらの記事をご参考下さい。 https://qiita.com/ryohei0109_develop/items/ff05cfad2cb276af1169 今回の例ではjsonファイルはこのようになります。 ※「function-role」だけはどうしても書き換えて下さい！ aws-lambda-tools-defaults.json { "Information": [ "This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.", "To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.", "dotnet lambda help", "All the command line options for the Lambda command can be specified in this file." ], "configuration": "Release", "framework": "netcoreapp3.1", "profile": "default", // AWS CLI プロフィール "region": "ap-northeast-1", // AWSリージョン指定 "function-runtime": "dotnetcore3.1", // Lambbda実行ランタイム "function-memory-size": 512, // Lambdaメモリ(MB) "function-timeout": 30, // Lambdaタイムアウト時間(seconds) "function-handler": "LambdaSample::LambdaSample.Function::FunctionHandler", // Lambda実行時にコールするメソッドを指定 "function-name": "LambdaSample", // Lambda名称 "function-role": "arn:aws:iam::123456789012:role/xxxxxRole" // AWSロール名 } Lambda環境変数にチャンネルアクセストークンを設定 チャンネルアクセストークンを環境変数に設定しておくと、今後チャンネルアクセストークンの変更があった際、 プログラムを変更することなくGUIから操作するだけで対応可能になります。 AWSマネジメントコンソールにログイン->Lambda->先程デプロイした関数を選択->「設定」タブをクリック LambdaをAPI化 Lambda関数を作成しただけでは、まだLINEからのWebhookを受けることができません。 そこで「API Gateway」を行い、先程作成したLambda関数をAPI化します。 AWSのApiGatewayにアクセスし、「APIを作成」ボタンをクリックします。 少し下にスクロールし、「REST API」の「構築」ボタンをクリックします。 任意の「API名」を入力し、「APIの作成」ボタンをクリックします。 APIの大枠が作成できたら、続いてリソースを作成していきます。 「アクション」から「リソースの作成」をクリックします。 任意のリソース名を入力し、「API Gateway CROSを有効にする」にチェックを入れ、「リソースの作成」ボタンをクリックします。 作成したリソースにPOSTメソッドを追加していきます。 「アクション」から「メソッドの作成」をクリックします。 プルダウンから「POST」を選択し、 チェックアイコンをクリックすると、POSTメソッドが作成できます。 「Lambdaプロキシ統合の使用」にチェックし、 先程作成したLambda関数名を入力します。(※サジェストしてくれます) 完了したら「保存」ボタンをクリックします。 「Lambda 関数に権限を追加する」というダイアログボックスが表示されるので、 「OK」ボタンをクリックするとPOSTメソッドの作成が完了します。 POSTメソッドの作成が完了したので、続いてデプロイを行います。 「アクション」から「APIのデプロイ」をクリックします。 「デプロイされるステージ」に「新しいステージ」を選択し、 「ステージ名」に任意の名前を入力し、「デプロイ」ボタンをクリックします。 これでAPI化の準備は完了です！ 「POST」を選択し、「URLの呼び出し」に表示されているURLがAPIのエンドポイントになるので、メモしておきます。 自動応答メッセージをOFF デフォルトの設定では、ユーザがLINEで文章を送ると自動的にメッセージが返信される設定になっています。 今回は作成したbotから返信を行うので、デフォルトの自動応答メッセージ機能をOFFにする必要があります。 LINE Official Account Managerにログインします。 作成したチャンネルをクリックします。 画面右上の「設定」をクリックします。 レフトナビの「応答設定」をクリックします。 ※ちなみにこの画面でアカウント名やプロフィール画像を変更できます。 ・応答モード: 「Bot」    「チャットモード」にすると、Webhookが利用できません。 ・あいさつメッセージ: 「オン」or「オフ」    友達登録時の初回自動送信メッセージのON/OFF切り替えになります。    こちらは好みで良いと思います。 ・応答メッセージ: 「オフ」    今回は自分で作成したプログラムから応答するので、オフにしておきます。 ・Webhook: 「オン」    オンでないとLINE botが作成できないですね！ これでこの画面での設定は完了です。 あともう少しです！がんばりましょう！ Webhook登録 先程発行したAPIのエンドポイントを、LINE DevelopersにてWebhook URLとして登録します。 LINE Developersにアクセスし、 作成したチャンネルのページにアクセスし、 「Messaging API設定」タブを選択します。 ・ページ下部までスクロールし、Webhookの利用をON ・Webhook設定の「編集」をクリックし、先程発行したAPIのURLを登録します。 Webhook URLの設定が完了したら、「検証」ボタンをクリックし、疎通確認を行います。 正常に疎通できている場合は、「成功」と表示されます。 LINEアプリで最終確認 最後は先程の画面に表示されているQRコードを読み取って友達登録を行い、 LINEアプリからも正常に動作するか確認してみましょう！ 以上です！お疲れ様でした！ 蛇足 参考までに今回私が作成したconpassのイベント検索ができるLINE botも紹介させて下さい。

ログの調査の流れ よく業務でCloudWatchでログ調査することがあって、効率的にログが出せるように使い方を調べたのでまとめてみました。 こんな感じで調査しています。 エラー発覚。発生時間や現象等を教えてもらう。 ↓ エラーが発生したと思われるサービスのロググループを開く。 ↓ ログイベントの中から、時間、and検索、除外検索でエラーログを特定していく。 ↓ エラーログを発見。前後のログ見たり、共有したり。 その方法を以下にまとめてみたので、興味のある方は読んでみてください。 ロググループの検索 まず該当のロググループを検索したいのだが、そのフィルタールールが使いにくいので挙動をまとめました。 具体例で示すと、 検索ワード: abc abc.def ○ ab.c ○ a.b.c ○ cba × cba.bc ○ このようにロググループの検索は、 「１文字ずつのor検索に加えて、文字の順番(？)が考慮されてるフィルター」のようです。 完全一致にチェックを入れた場合 完全一致にチェックを入れる項目がありあますが、検索ワードをひとかたまりとして検索をかけれるようです。(googleの""を使った完全一致検索と同じ) 完全一致にチェックを入れた場合 検索ワード: abc abc.def ○ ab.c × a.b.c × cba.bc × ※スペースは検索対象文字として扱われるので、and検索とかはできない ログイベントの検索 ロググループを選択したらログストリームで該当のものを選択。 該当のものがわからないときは「Search all」を選択した方が早い。 ログの検索については公式ドキュメントに全てが載っている。 簡単にまとめるとこうなる。 スペース区切りでand検索 「?」を前につけるとor検索 「-」を前につけると除外 「_」以外の記号を使う場合は「""(ダブルクォーテーション)」で囲う 「[]」「{}」はスペース区切りフィルター、JSONフィルターという検索方法があるらしく検索ワードに含めない方が良い。使い方は公式ドキュメントを参照してください。 例 and検索: abc def or検索: ?abc ?def 除外: -abc 記号を含む: "/abc/def" ログストリームの表示 エラーの原因のログを見つけたら、前後の処理を見たかったり、共有したいことありますよね。 そういうときは「ログストリーム名」を表示させておきます。 該当のログを探して、そのログストリーム名のリンクを開きます。 そうすると、該当のログを基準にフィルターがかかってない状態で前後を見ることができます。 また、そのリンクを共有することでログの共有が簡単にできます。 まとめ 最初は検索の仕方に癖があるなと思って使いづらいと思っていたが、規則を理解したら効率良く調査できるようになった。 コンソールを完全に使いこなせているとは思えないので、もっと便利な機能があれば使ってみたい。 インサイトも便利なのでまとめようと思う。

事前準備: CentOS7.x パッケージのアップデート command yum update -y Session Managerのインストール インストール command REGION="ap-northeast-1" sudo yum install -y https://s3.${REGION}.amazonaws.com/amazon-ssm-${REGION}/latest/linux_amd64/amazon-ssm-agent.rpm systemdによるssmのデーモンの有効化/再起動/確認 systemdによるssmのデーモンの有効化/再起動/確認 3行目のレスポンスとして、Active (running) になっていることを確認する。 command sudo systemctl enable amazon-ssm-agent sudo systemctl restart amazon-ssm-agent sudo systemctl status amazon-ssm-agent Session Manager によるインスタンス接続確認 対象となるインスタンスのインスタンスに接続画面右下の接続ボタンがクリック可能なことを確認する クリック後、ブラウザにターミナルが開くことを確認する AWS CLI 用の Session Manager plugin のインストール (接続元、必要に応じて) 下記はLINUXの場合です。 AWS CLIのインストール command curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install pluginのインストール command curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm" -o "session-manager-plugin.rpm" sudo yum install -y session-manager-plugin.rpm インストールの確認 以下のコマンドを実行 command session-manager-plugin 以下のようなメッセージが得られていればインストール成功 response The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

~/.ssh以下のファイルを書き換えてしまった為に、Cloud9がバーストしてアクセスできなくなってしまった。 エラー文は下記の通り。 This is taking longer than expected. The delay may be caused by high CPU usage in your environment, or your T2 or T3 instance is running out of burstable CPU capacity credits, or there are VPC configuration issues. Please check documentation. これには予想以上に時間がかかっています。遅延の原因としては、環境内の CPU 使用率が高いか、T2 または T3 インスタンスでバースト可能な CPU 容量クレジットが不足しているか、VPC 構成に問題があることが考えられます。ドキュメントを確認してください。 何時間待っても インスタンスタイプを変更しても、開くことは出来なかった。 その時の解決方法を備忘録として残しておく。 （結論から言うと、そのCloud9はもう二度とアクセス出来ない） 参考にした記事など https://qiita.com/ataru_mix/items/757dadc453a8d399b470 解決手順 ・AMIイメージの作成 ・作成したAMIからEC2インスタンスを作成 ・Cloud9作成時にssh接続で作成 https://qiita.com/rockhopper-penguin/items/d5042b71230eb94955d0 要は開発の中身のデータが消えてしまったら困るので、どうしてもCloud9を復活させたかったわけ。 しかし今回の復活に際し EIPの取得が必須になってくるので開発中はEC2の料金が、停止中はEIPの料金がかかるし、コストがかかる。 Cloud9はプライベートでのアクセスも可能らしいが、その辺りはまた今度調べることとする。

S3バケットに画像がアップロードされるとその画像をLambdaが取りに行ってあらかじめ立ててあるSageMaker推論エンドポイントに投げ、結果を取得するという仕組みを作ります。 結果をAWS SNSに送信させるやり方と、LambdaをCRONを使って定期実行させるやり方もさわりだけ紹介します。 前準備 S3バケット作成 SageMaker推論エンドポイントの作成 inference-endpointとしましょう。 作り方は以下の記事を参考にしてください。 SNSトピックの作成 以下を参考にして作りました（日本語対応はまだみたいです）。 1.Lambdaの作成 トリガーを追加をクリック。 トリガーにはS3を選択。 以下の画像のようにイベントタイプは全てのオブジェクトCreateイベント PrefixはPictures/を（これで他のフォルダにアップロードされたときは無視できる） Suffixは.jpgを入れる（これで例えばテキストファイルがアップされたときは無視できる） inference.py import logging import boto3 import json import urllib.parse # Initialize logger customer_logger = logging.getLogger(__name__) client = boto3.client('sagemaker-runtime') # バケット名 AWS_S3_BUCKET_NAME = 'gazou-ageru-bucket' s3 = boto3.resource('s3') bucket = s3.Bucket(AWS_S3_BUCKET_NAME) # オブジェクト名（キー） #GET_OBJECT_KEY_NAME = 'image.jpg' #obj = bucket.Object(GET_OBJECT_KEY_NAME) #objbody = obj.get()['Body'].read() def handler(event, context): # S3にアップロードされたファイルをオブジェクトとしてGETしたいとき # トリガーイベントから渡された情報からS3のバケット名とアップロードされたオブジェクト名を取得する bucketname = event['Records'][0]['s3']['bucket']['name'] bucket = s3.Bucket(bucketname) key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'], encoding='utf-8') obj = bucket.Object(key) objbody = obj.get()['Body'].read() response = client.invoke_endpoint( EndpointName='inference-endpoint', Body= objbody, ContentType='image/jpeg', Accept='application/json' ) body = response['Body'] result=json.load(body) return(result) # S3バケット内の全てのオブジェクトに対して実行したい場合 ''' for obj in bucket.objects.all(): key = obj.key body = obj.get()['Body'].read() ''' RuntimeはPython3.7, ハンドラーはinference.handlerとしました。 2.結果をAWS SNSへプッシュ 画像のようにdestinationの追加を押します。 以下のようにあらかじめ作成したAWS SNSトピックに対して非同期(Asynchronous)かつ成功時(On success)の設定で保存します。 SNSのメッセージを整形したい場合 この設定だと推論結果等がJSON形式でSNSにプッシュされます。メッセージを整形したい場合はもう一つLambdaをかませます。以下を参照してください。 3.実行テスト 以下のどちらかの方法でPCやラズパイから画像をアップロードします。 python(boto3)でやる場合の雛形 S3Upload.py import boto3 s3= boto3.resource('s3') def function(): # 画像ファイルの場合 #data = open(filePath, mode='rb') #s3.Bucket(bucketName).put_object(Key = s3Key, Body = data) # テキストファイルの場合 #data = open(filePath, mode='r') #s3.Bucket(bucketName).put_object(Key = s3Key, Body = data.read()) return AWS CLIでやる場合 example.sh aws s3 cp filename.jpg s3://bucket-name 参考： CloudWatchlogsに保存してあるLambdaのlogか、SNSにプッシュしている場合はSNSに登録しているメールアドレスやSMS等をチェックします。メッセージ整形のLambdaを噛ませていないと長文のJSONが届くはずです。 CRONによる定期実行 ※これは今回の例だと直接使えないのでおまけです。CRONでトリガーするとeventとしてS3バケットの名前やオブジェクト名を引いて来れなくなるのでコードを変える必要があります。 トリガーを追加をクリックしてEventBridge(CloudWatch Events)を選びます。 画像のように新しいルールの作成を選びSchedule Expressionの箇所にCRON形式で実行日時を打ち込みます（画像だと毎日午前3時30分に実行する）。 参考： 以上です。

はじめに 以下のようにCloudShellでAWS CLIコマンドを並列実行する際、同時実行数が20を超えてくるとError when retrieving credentials from container-roleというエラーが発生するようになる。 こちらの対処方法について調べても見つからなかったので、AWSに問い合わせてみた。 # このくらいであればエラー無し $ for i in {1..5}; do (aws ec2 describe-regions > /dev/null && echo $i) & done ~略~ 3 2 4 1 5 # 20件を超えると発生しやすくなる $ for i in {1..30}; do (aws ec2 describe-regions > /dev/null && echo $i) & done ~略~ 27 2 ~略~ 28 Error when retrieving credentials from container-role: Error retrieving metadata: Received non 200 response (503) from ECS metadata: <html><head><title>Timeout</title></head><body><h1>Timeout</h1></body></html> Error when retrieving credentials from container-role: Error retrieving metadata: Received non 200 response (503) from ECS metadata: <html><head><title>Timeout</title></head><body><h1>Timeout</h1></body></html> Error when retrieving credentials from container-role: Error retrieving metadata: Received non 200 response (503) from ECS metadata: <html><head><title>Timeout</title></head><body><h1>Timeout</h1></body></html> ~略~ 回答 Cloud Shell の内部仕様により、一定回数以上のAWS CLIコマンドを実行すると、実行に必要な認証情報の取得に失敗するとのこと。 また、こちらの緩和申請もできないとのこと。 そのため、Cloud Shellで並列実行する際は、xargsのPオプション等で実行回数を制限した方が良い。 # 同時実行回数を実行回数と同等(=30回)にする (-P 30) seq 30 | xargs -P 30 aws ec2 describe-regions --query "Regions[0].RegionName" ; ~略~ Error when retrieving credentials from container-role: Error retrieving metadata: Received non 200 response (503) from ECS metadata: <html><head><title>Timeout</title></head><body><h1>Timeout</h1></body></html> ~略~ # 同時実行回数を10回に制限する (-P 10) seq 30 | xargs -P 10 aws ec2 describe-regions --query "Regions[0].RegionName" ; # エラーなし get-user の例 list-usersで取得した全ユーザーでget-userを行う場合。 # for文だと、ユーザー数によってはエラーになる $ for u in `aws iam list-users --query 'Users[*].UserName' --output text`; do aws iam get-user --user-name $u & done ~ Error when retrieving credentials from container-role: Error retrieving metadata: Received non 200 response (503) from ECS metadata: <html><head><title>Timeout</title></head><body><h1>Timeout</h1></body></html> # xargs ## -P 100 だとエラー $ aws iam list-users --query 'Users[*].UserName' | jq -r '.[]' | xargs -I NAME -P 100 aws iam get-user --user-name NAME ~ Error when retrieving credentials from container-role: Error retrieving metadata: Received non 200 response (503) from ECS metadata: <html><head><title>Timeout</title></head><body><h1>Timeout</h1></body></html> ## -P 20 だとエラーなし $ aws iam list-users --query 'Users[*].UserName' | jq -r '.[]' | xargs -I NAME -P 20 aws iam get-user --user-name NAME

概要 EC2のUserDataで以下のコマンド実行により自動インストールしたNICE DCVサーバーでは、自動起動されるセッションのオーナーが ContainerAdministrator となるため Administrator でアクセスしようとしても認証されない。 msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/2021.1/Servers/nice-dcv-server-x64-Release-2021.1-10557.msi ADDLOCAL=ALL AUTOMATIC_SESSION_OWNER=Administrator /quiet /norestart /l*v dcv_install_msi.log 以下のように AUTOMATIC_SESSION_OWNER を明示的に指定して自動インストールさせることで Administrator で認証されるようになる。 msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/2021.1/Servers/nice-dcv-server-x64-Release-2021.1-10557.msi ADDLOCAL=ALL AUTOMATIC_SESSION_OWNER=Administrator /quiet /norestart /l*v dcv_install_msi.log 詳細 経緯 Windows Server 2019のEC2インスタンス作成時、CloudFormationテンプレートで以下のようなUserDataを指定して、NICE DCVの仮想ディスプレイドライバーとサーバーをインストールした。 <script> msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/Drivers/nice-dcv-virtual-display-x64-Release-38.msi /quiet msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/2021.1/Servers/nice-dcv-server-x64-Release-2021.1-10557.msi ADDLOCAL=ALL /quiet /norestart /l*v dcv_install_msi.log </script> またNICE DCVの動作要件に合わせて、セキュリティグループで 8443 ポートのインバウンド通信を許可し、次のようなステートメントを持つポリシーをロールにより付与している。 Effect: Allow Action: s3:GetObject Resource: !Sub arn:aws:s3:::dcv-license.${AWS::Region}* CloudFormationによりデプロイされたEC2インスタンスにまずRDPで接続し、Administratorでサインインできること、DCV Serverサービスが立ち上がっていることを確認した。この後、NICE DCVクライアントでこのEC2インスタンスに接続し、Administratorでサインインしようとしたところ、以下のエラーが表示された。 connection authentication failed 問題の調査 NICE DCVサーバーは以下にログを出力している（「ログファイルの使用 - NICE DCV」参照）。 Windows … C:\ProgramData\NICE\dcv\log\server.log Linux … /var/log/dcv/server.log 確認したところ、次のようなログが記録されていた。 2021-06-09 13:56:06,108929 [ 2736:2812 ] WARN frontend-handler - Cannot create connection from client 'xxx.xxx.xxx.xxx:xxxxx' to session 'console': User 'Administrator' not authorized on any channel 構築時に参考にしたページに次のような記述がある。 DCV Session Management Configurationではセッションを自動/手動での作成を選択できます。セッションが無いと接続が出来ないため、今回は自動で作成しました。 （リモートでのゲーム開発にオススメ？EC2にNICE DCVを導入してみた | DevelopersIO） 自動インストールの説明では次のように書かれており、この辺りは問題ないつもりでいた。 自動コンソールセッションを作成します。 コンソールセッションの所有者を、インストールを実行するユーザーに設定します。 でもエラーメッセージと合わせて考えると、セッションがどんなふうになっているかが気になる。スタートメニューとか見ても管理画面らしきものがないなと思ってドキュメントを探したところ、NICE DCVサーバーでのセッション管理はコマンドラインのみらしい。 コマンドラインツールを使用した NICE DCV セッションの管理 - NICE DCV セッション情報を表示してみる。 C:\Users\Administrator> cd "C:\Program Files\NICE\DCV\Server\bin" C:\Program Files\NICE\DCV\Server\bin> dcv list-sessions Session: 'console' (owner:ContainerAdministrator type:console) オーナーが ContainerAdministrator になっている…これは Administrator のことなのか、それともここが間違ってるのか？ 切り分け 既存セッションを停止し、オーナーが Administrator のセッションを起動して試してみることにする。まず既存の console セッションの停止。 C:\Program Files\NICE\DCV\Server\bin> dcv close-session console 次に新規セッションの開始。 C:\Program Files\NICE\DCV\Server\bin> dcv create-session --name console --owner Administrator console もう一度、セッション情報を表示。 c:\Program Files\NICE\DCV\Server\bin>dcv list-sessions Session: 'console' (owner:Administrator type:console name:console) オーナーが Administrator に変わった。やはり ContainerAdministrator は別物らしい。 この状態でNICE DCVクライアントで接続し Administrator でサインインを試みたところ、今度は成功した。 解決策 ここまでで、以下のことが確認できている。 オーナーが Administrator のセッションがないとサインインできない。 CloudFormationのUsetDataでNICE DCVの自動インストールを指定したEC2インスタンスデプロイでは、 ContainerAdministrator でセッションが作成されてしまう。 ひとまずのワークアラウンドとしては、セッションをオーナー Administrator で再作成すると、サインイン可能になる。 自動インストールでは、この自動起動されるセッションのオーナーをコマンドラインオプションで指定できる。 インストールコマンドに次のオプションを追加することで、デフォルトのアクションを上書きすることができます。 ・(略) ・AUTOMATIC_SESSION_OWNER=owner_name - 自動コンソールセッションの別の所有者を指定します。 （自動インストール - Windows での NICE DCV サーバのインストール - NICE DCV） NICE DCVサーバーのインストーラーの実行行に、以下のように AUTOMATIC_SESSION_OWNER の指定を追加することで、問題が解消される。 <script> msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/Drivers/nice-dcv-virtual-display-x64-Release-38.msi /quiet msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/2021.1/Servers/nice-dcv-server-x64-Release-2021.1-10557.msi ADDLOCAL=ALL AUTOMATIC_SESSION_OWNER=Administrator /quiet /norestart /l*v dcv_install_msi.log </script> 実際にこのUserDataでデプロイされたEC2インスタンスでは、そのまま administrator ユーザーで認証された。 参考 リモートでのゲーム開発にオススメ？EC2にNICE DCVを導入してみた | DevelopersIO 自動インストール - Windows での NICE DCV サーバのインストール - NICE DCV Windows クライアントを使用した NICE DCV セッションへの接続 - NICE DCV NICE DCV セッションの開始 - NICE DCV コマンドラインツールを使用した NICE DCV セッションの管理 - NICE DCV 新規セッションの開始 セッションの停止 セッション情報を表示 ログファイルの使用 - NICE DCV

概要 EC2のUserDataでサイレントインストールしたNICE DCVサーバーでは、自動起動されるセッションのオーナーが ContainerAdministrator となるため Administrator でアクセスしようとしても認証されない。以下のようにして既存セッションを終了、オーナーが Administrator のセッションを作成すると認証されるようになった。 C:\Users\Administrator> cd "C:\Program Files\NICE\DCV\Server\bin" C:\Program Files\NICE\DCV\Server\bin> dcv close-session console C:\Program Files\NICE\DCV\Server\bin> dcv create-session --name console --owner Administrator console 詳細 経緯 Windows Server 2019のEC2インスタンス作成時、CloudFormationテンプレートで以下のようなUserDataを指定して、NICE DCVの仮想ディスプレイドライバーとサーバーをインストールした。 <script> msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/Drivers/nice-dcv-virtual-display-x64-Release-38.msi /quiet msiexec.exe /i https://d1uj6qtbmh3dt5.cloudfront.net/2021.1/Servers/nice-dcv-server-x64-Release-2021.1-10557.msi ADDLOCAL=ALL /quiet /norestart /l*v dcv_install_msi.log </script> またNICE DCVの動作要件に合わせて、セキュリティグループで 8443 ポートのインバウンド通信を許可し、次のようなステートメントを持つポリシーをロールにより付与している。 Effect: Allow Action: s3:GetObject Resource: !Sub arn:aws:s3:::dcv-license.${AWS::Region}* CloudFormationによりデプロイされたEC2インスタンスにまずRDPで接続し、Administratorでサインインできること、DCV Serverサービスが立ち上がっていることを確認した。この後、NICE DCVクライアントでこのEC2インスタンスに接続し、Administratorでサインインしようとしたところ、以下のエラーが表示された。 connection authentication failed 問題の調査 NICE DCVサーバーは以下にログを出力している（「ログファイルの使用 - NICE DCV」参照）。 Windows … C:\ProgramData\NICE\dcv\log\server.log Linux … /var/log/dcv/server.log 確認したところ、次のようなログが記録されていた。 2021-06-09 13:56:06,108929 [ 2736:2812 ] WARN frontend-handler - Cannot create connection from client 'xxx.xxx.xxx.xxx:xxxxx' to session 'console': User 'Administrator' not authorized on any channel 構築時に参考にしたページに次のような記述がある。 DCV Session Management Configurationではセッションを自動/手動での作成を選択できます。セッションが無いと接続が出来ないため、今回は自動で作成しました。 （リモートでのゲーム開発にオススメ？EC2にNICE DCVを導入してみた | DevelopersIO） サイレント（自動）インストールの説明では次のように書かれており、この辺りは問題ないつもりでいた。 自動コンソールセッションを作成します。 コンソールセッションの所有者を、インストールを実行するユーザーに設定します。 でもエラーメッセージと合わせて考えると、セッションがどんなふうになっているかが気になる。スタートメニューとか見ても管理画面らしきものがないなと思ってドキュメントを探したところ、NICE DCVサーバーでのセッション管理はコマンドラインのみらしい。 コマンドラインツールを使用した NICE DCV セッションの管理 - NICE DCV セッション情報を表示してみる。 C:\Users\Administrator> cd "C:\Program Files\NICE\DCV\Server\bin" C:\Program Files\NICE\DCV\Server\bin> dcv list-sessions Session: 'console' (owner:ContainerAdministrator type:console) オーナーが ContainerAdministrator になっている…これは Administrator のことなのか、それともここが間違ってるのか？ 切り分け 既存セッションを停止し、オーナーが Administrator のセッションを起動して試してみることにする。まず既存の console セッションの停止。 C:\Program Files\NICE\DCV\Server\bin> dcv close-session console 次に新規セッションの開始。 C:\Program Files\NICE\DCV\Server\bin> dcv create-session --name console --owner Administrator console もう一度、セッション情報を表示。 c:\Program Files\NICE\DCV\Server\bin>dcv list-sessions Session: 'console' (owner:Administrator type:console name:console) オーナーが Administrator に変わった。やはり ContainerAdministrator は別物らしい。 この状態でNICE DCVクライアントで接続し Administrator でサインインを試みたところ、今度は成功した。 TBD ひとまず、以下のことは確認できた。 オーナーが Administrator のセッションがないとサインインできない。 CloudFormationのUsetDataでNICE DCVのサイレントインストールを指定したEC2インスタンスデプロイでは、 ContainerAdministrator でセッションが作成されてしまう。 ひとまずのワークアラウンドとしては、セッションをオーナー Administrator で再作成すると、サインイン可能になる。 とは言え原因がはっきりしているのだし、これでは使い勝手が悪い。次のようなオプションが指定できるようなので、CloudFormationテンプレートを修正してデプロイしなおすところから、修正を試みたい（ASAP）。 インストールコマンドに次のオプションを追加することで、デフォルトのアクションを上書きすることができます。 ・(略) ・AUTOMATIC_SESSION_OWNER=owner_name - 自動コンソールセッションの別の所有者を指定します。 （自動インストール - Windows での NICE DCV サーバのインストール - NICE DCV） 参考 リモートでのゲーム開発にオススメ？EC2にNICE DCVを導入してみた | DevelopersIO 自動インストール - Windows での NICE DCV サーバのインストール - NICE DCV Windows クライアントを使用した NICE DCV セッションへの接続 - NICE DCV NICE DCV セッションの開始 - NICE DCV コマンドラインツールを使用した NICE DCV セッションの管理 - NICE DCV 新規セッションの開始 セッションの停止 セッション情報を表示 ログファイルの使用 - NICE DCV

概要 Udemyの講座である、「AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得」を受講し終えたので、学習内容を振り返ります。 手順 仮想ネットワーク（VPC）を構築する 仮想ネットワークをパブリックサブネットとプライベートサブネットに分割する パブリックサブネット上にWebサーバー、プライベートサブネット上にDBサーバー（RDS）を構築する WebサーバーからDBサーバーにアクセスする WordPress用のデータベースを作成する WordPressのインストール・設定 VPC作成 VPCとは？ Virtual Private Cloud：AWS上の仮想ネットワーク。VPCとサブネットの組み合わせによってネットワーク空間を構築する。 VPCは単一リージョンに対して作成される。 複数のAZにサブネットを設置することで、冗長性を高めることができる。 VPCの作成 マネジメントコンソールの画面より「VPC」を選択します。 デフォルトでVPCが作成されていますが、今回は新規で作成します。 VPC設計のポイント 拡張性を考慮して、VPCの範囲を大きめにとる（後から追加するのは困難）→推奨範囲は/16 大きめに作ったVPCをサブネットで分割する オンプレミス環境のアドレスと重複しないようにする サブネットの作成 VPCのメニュー画面より「サブネット」を選択します。 Webサーバーを設置するパブリックサブネットとDBサーバーを設置するプライベートサブネットを作成します。 サブネット設計のポイント ルーティングとAZを基準にしてサブネットを分割する インターネットに接続する必要がある場合はパブリックサブネット DBサーバーは外部のネットワークからアクセスされたくないので、プライベートサブネット上に設置する 推奨範囲は/24 複数のAZを利用して冗長性を高めたい→サブネットを分割する パブリックサブネットの作成 まずはWebサーバー用のパブリックサブネットを作成します。 作成画面にあるように、サブネットはAZ単位で作成します。 この段階では、このサブネットはインターネットに接続できません。 後述するように、ルーティング設定でインターネットゲートウェイをアタッチすることでインターネットに接続できるようになります。 つまり、サブネットはデフォルトでは全てプライベートサブネットとして作成されるということです。 プライベートサブネットの作成 続いてDBサーバー用のプライベートサブネットを作成します。 パブリックサブネットとは違うアドレス範囲を指定します。 ルーティング設定 インターネットゲートウェイの作成 サブネットをインターネットに接続するには、インターネットゲートウェイが必要です。 VPCから「インターネットゲートウェイ」を選択し、「インターネットゲートウェイの作成」を押下します。 名前を入力して「作成」をクリックすれば作成完了です。 作成後、「アクション」から「VPCにアタッチ」を選択し、作成したVPCに割り当てます。 ルートテーブルの作成 IPアドレスの接続先を設定していきます。 VPCを作成すると、デフォルトのルートテーブルが作成され、サブネットにはそのルーティング設定が適用されています。 「サブネット」からパブリックサブネットとして作成したサブネットを選択し、「詳細」欄内の「ルートテーブル」をクリックすると、割り当てられているルートテーブルの設定を確認することができます。 デフォルトの設定では、接続先が「10.0.0.0/16」しかない状態だと思います。 この状態ではインターネットに接続することができません。10.0.0.0/16以外の宛先のパケットは全て破棄されてしまう状態だからです。 デフォルトの転送先（デフォルトゲートウェイ）を先ほど作成したインターネットゲートウェイに設定することで、パブリックサブネットはインターネットと接続できるようになります。 左のメニューから「ルートテーブル」をクリックし、「ルートテーブルの作成」をクリックします。 作成画面でルートテーブルの名前（ここではパブリックサブネット用として作成しますので、わかりやすく"public"などつけておきましょう）と対象のVPCを選択し、作成をクリックします。 次に作成したルートテーブルをパブリックサブネットに割り当てます。 ルートテーブルの一覧から今作成したルートテーブルを選択し、「サブネットの関連付け」タブをクリックします。 「サブネットの関連付けの編集」をクリックすると、サブネットの一覧が表示されるので、パブリック用として作成したサブネットにチェックを入れて、「保存」を押します。 続いてデフォルトゲートウェイをインターネットゲートウェイに設定していきます。 パブリック用のルートテーブルを選択し、「ルート」タブから「ルートの編集」を選択します。 「ルートの追加」を選択し、新しい送信先の入力画面で「送信先」を0.0.0.0/0、 ターゲットを作成したインターネットゲートウェイに設定して「ルートの保存」を押します。 正しく設定できたか確認しましょう。 「サブネット」からパブリックサブネットを選択し、「ルートテーブル」タブをクリックします。 ルートテーブルにインターネットゲートウェイに転送する接続先が追加されていればOKです。 EC2の作成 ここではサーバーの構築を行います。 EC2とは? Elastic Cloud Computingの略 EC2で立てられたサーバーを「インスタンス」と呼ぶ 従量課金 「インスタンスタイプ」でサーバーのスペックを定義する EC2インスタンスの作成 EC2の画面から「インスタンスの起動」を選択します。 「Amazon Linux 2 AMI (HVM), SSD Volume Type」を選択します。 「インスタンスタイプ」はt2.microを選択し、「インスタンス詳細の設定」に移動します。 詳細設定画面で、先ほど作成したVPCとパブリックサブネットを選択します。 自動割り当てパブリックIPは「有効」を選びます。 ここではWebサーバーを作成します。 ネットワークインターフェイスのプライマリIP欄に10.0.10.10と入力します。 次のステップをクリックし、ストレージの追加設定に移動します。 今回は無料枠の範囲内で設定するため、ストレージの設定はデフォルトのままにします。 次のステップをクリックし、タグの追加に移動します。 タグの追加をクリックし、タグ付けを行います。 Webサーバーであることがわかるよう、適当な名称を設定します。 次のステップをクリックし、セキュリティグループの設定に移動します。 「新しいセキュリティグループを作成する」をクリックし、Webサーバー用のセキュリティ設定であることがわかるよう、適当な名称を設定します。 「確認と作成」ボタンをクリックし、内容に問題がなければ「起動」ボタンを押します。 次にインスタンスにアクセスするためのキーペアを作成する画面に移動します。 今回は新規でキーを作成するので、適当な名称を入力し、キーペアをダウンロードします。 なお、ここでPCに保存されるのはサーバーの秘密鍵（.pemファイル）です。 EC2インスタンス側は公開鍵を保持していますので、ログインする際にはこの秘密鍵を使って認証を行います。 これでサーバーを構築することができました。 SSH接続 作成したインスタンスにSSHでログインします。 以下のようにコマンドを入力してください。 $ chmod 600 ~/mykey.pem 秘密鍵ファイルへのアクセス権を付与 $ ssh -i ~/mykey.pem ec2-user@xxx.xxx.xxx.xxx IPアドレスはインスタンスの画面で確認できます Are you sure you want to continue connecting (yes/no)? 初回接続時のみ表示されるので、ここではyesと入力します ログインに成功すると、以下のような画面が表示されます。 Apacheのインストール サーバーにログインした状態でコマンドを実行してください。 まずは、インスタンスのパッケージを更新します。 [ec2-user@ip-10-0-10-10 ~]$ sudo yum update -y 続いてApacheをインストールします。 [ec2-user@ip-10-0-10-10 ~]$ sudo yum -y install httpd Apacheがインストールされたのを確認したら、次のコマンドでApacheを起動します。 [ec2-user@ip-10-0-10-10 ~]$ sudo systemctl start httpd.service [ec2-user@ip-10-0-10-10 ~]$ sudo systemctl status httpd.service 起動しているか確認するコマンド。active(running)と表示されれば起動している サーバー起動時にApacheも自動で起動するよう設定します。 [ec2-user@ip-10-0-10-10 ~]$ sudo systemctl enable httpd.service [ec2-user@ip-10-0-10-10 ~]$ sudo systemctl is-enabled httpd.service 自動的に起動する設定になっているか確認するコマンド。enabledと表示されればOK ファイアウォールの設定 AWSでは、インスタンスに対して割り当てるセキュリティグループがファイアウォールとしての機能を果たします。 インバウンド通信（サーバーへのアクセス許可）は必要なものだけ許可し、アウトバウンド通信（サーバーから外部へのアクセス）は全て許可するのが基本となります。 初期設定ではポート22（SSH）しか許可されていないので、HTTP接続（ポート80）はできません。 先ほど作成したインスタンスの設定画面から、当該インスタンスのセキュリティグループ設定画面に移動します。 「インバウンドルールを編集」をクリックし、続いて「ルールの追加」をクリックします。 ここでタイプ：HTTPを選択して設定を保存すると、ポート80を開放することができます。 ポート80が開放された状態で、インスタンスのIPアドレスをブラウザのURL欄に入力すると、Apacheのデフォルトページが表示されるようになります。 Elastic IPアドレスの割り当て EC2インスタンスのIPアドレスは、デフォルトでは動的に割り当てられます。 つまり、停止・起動の度に異なるIPアドレスが割り当てられます。 Elastic IPアドレスを割り当てることで、インスタンスのIPアドレスを固定することができます。 ただし、Elastic IPアドレスは使用されていない間は料金が発生してしまうので、使用しない場合は「解放」しておくようにしましょう。 「使用していない」とは、次のような状態を指します。 1. 作成したElastic IPアドレスをどのインスタンスにも割り当てていない 2. Elastic IPアドレスを割り当てたインスタンスを停止している 特に2の状態を見落としがちなので注意しましょう。 EC2メニュー内の「Elastic IP」をクリックし、「Elastic IPアドレスの割り当て」をクリックします。 これでElastic IPアドレスを作成できます。 次に、Elastic IPアドレスを割り当てる対象を指定します。 作成したElastic IPアドレスを選択した状態で「アクション」→「Elastic IPアドレス関連付け」をクリックします。 関連付けの設定画面で「インスタンス」を先ほど作成したインスタンスを選択し、プライベートIPアドレス欄に「10.0.10.10」と入力します。 必要事項を入力したら、「関連付ける」をクリックします。 これで、IPアドレスを固定できました。 作成したElastic IPアドレスをブラウザ入力し、Apacheの起動画面が表示されるか確認しましょう。 RDSの作成 ここでは、AWSの「RDS」というサービスを使って、データベースサーバーを構築します。 EC2インスタンス上に自分でDBMSをインストールして設定する方法もありますが、RDSは「マネージドサービス」なのでアップデートやバックアップなどの管理タスクをAWS側に任せることができ、何かと便利です。 2つ目のプライベートサブネットの作成 冗長化のため、プライベートサブネットをもう一つ作成します。 こちらのサブネットは、最初に作成したプライベートサブネット（private-subnet-1a）とは異なるAZに作成します。 セキュリティグループの設定 データベースサーバーはプライベート領域に設置し、インターネットからのアクセスを遮断することでセキュリティを確保します。 EC2インスタンスからのアクセスのみ許可するよう設定していきます。 EC2のメニューから「セキュリティグループの作成」をクリックし、設定画面に移動します。 名称、説明欄に任意の内容を入力し、VPCは今回作成したVPCを選択します。 続いて、インバウンドルールの設定です。 今回はMySQLを使用するので、タイプを「MYSQL/Aurora」に設定し、ソース欄に先ほど作成したWebサーバーのセキュリティグループを入力します。 これでWebサーバーからデータベースにアクセスできるようになります。 サブネットグループの作成 今回の構成では、冗長化のために複数のAZにRDSを設置します。 これらのプライベートサブネットをまとめるために「サブネットグループ」を作成します。 RDSのメニューから「サブネットグループ」を選択し、「DBサブネットグループを作成」をクリックします。 名称、説明欄には任意の内容を入力し、VPCは今回作成したVPCを選択します。 「サブネットを追加」の欄では、先ほど作成した二つのプライベートサブネット（private-subnet-1aとprivate-subnet-1c）を選択します。 パラメータグループの作成 RDSを使用する場合、データベースの設定値（DBMSのバージョンなど）を直接編集することができません。 そのため、パラメータグループというものを使用してデータベースの設定を行います。 RDSのメニューから「パラメータグループ」→「パラメータグループの作成」と移動します。 パラメータグループファミリーで「mysql8.0」と入力し、名称および説明欄には任意の内容を入力します。 後でパラメーターを編集したい場合は、「パラメーターグループアクション」→「編集」と移動すると設定値の編集画面に移動することができます。 オプショングループの作成 データベースのオプション設定を行います。 名称、説明は任意の内容を入力します。 エンジンはmysqlを選択し、バージョンは8.0を選択します。 RDSの作成 RDSのメニューから「データベース」→「データベースの作成」へと進みます。 作成方法：標準を選択し、データベースのエンジンおよびバージョンを選択します。 料金を抑えるため、テンプレートは「開発／テスト」を選択します。 インスタンスの識別子およびデータベースへのアクセス情報は任意の内容を入力します。 続いて、ストレージの容量を設定します。 料金を抑えるため、自動スケーリングを解除しておきます。 次にマルチAZの設定ですが、料金を抑えるため「スタンバイインスタンスを作成しないでください」を選択します。 次に接続設定を行います。 VPCは自分で作成したVPCを選択し、サブネットグループも先ほど作成した物を選択します。 VPC外部からのアクセスは必要ないので、「パブリックアクセス可能」欄はなしを選択します。 セキリュティグループ、AZなどは既に作成済みの物を選択します。 追加設定欄では、先ほど作成したパラメータグループ、オプショングループを選択します。 これ以降の設定内容は任意となります。 必要事項を全て入力したのち、「データベースの作成」をクリックするとRDSを作成することができます。 WebサーバーからDBサーバーへの接続 WebサーバーからRDSへmysqlコマンドでアクセスできるようにします。 まずは、WebサーバーにMySQLをインストールします。 WebサーバーのIPアドレスを確認し、sshコマンドでサーバーにログインします。 サーバーにログインした状態で下記のコマンドを入力し、EC2インスタンスにMySQLをインストールします。 [ec2-user@ip-10-0-10-10 ~]$ sudo yum -y install mysql 続いてRDSのダッシュボードから作成したRDSのエンドポイントを確認しておきます。 下記のコマンドでMySQLに接続します。 [ec2-user@ip-10-0-10-10 ~]$ mysql -h {your_endpoint} -u {your_user_name} -p これでデータベースサーバーへ接続できればOKです。 WordPress構築 WordPress用のデータベース構築 WebサーバーからデータベースサーバーにMySQLで接続しておきます。 下記のコマンドでデータベースを作成します。 CREATE DATABASE {your_db_name} DEFAUTL CHARACTER SET utf8 COLLATE utf8_general_ci; 作成できているか確認します。 SHOW DATABASES; WordPress用のユーザーを作成します。 @以降はホスト名を表します。 %は任意のホストから接続可能であることを意味しています。 CREATE USER '{your_user_name}'@'%' IDENTIFIED BY '{your_password}'; ユーザーにデータベースを操作する権限を付与します。 GRANT ALL ON {your_db_name}.* TO '{your_user_name}'@'%'; MySQLに設定の変更を反映させます。 FLUSH PRIVILEGES; ユーザーの作成に成功したか、確認してみましょう。 SELECT user, host FROM mysql.user; WordPressのインストール まずはWebサーバーにphpをインストールします。 [ec2-user@ip-10-0-10-10 ~]$ sudo amazon-linux-extras install -y php7.2; php関連のライブラリをインストールします。 [ec2-user@ip-10-0-10-10 ~]$ sudo yum install -y php php-mbstring Webサーバーのホームディレクトリに移動し、　WordPressをダウンロードします。 ダウンロードしたファイルは圧縮されているので、解凍しておきます。 [ec2-user@ip-10-0-10-10 ~]$ cd ~ [ec2-user@ip-10-0-10-10 ~]$ wget https://ja.wordpress.org/latest-ja.tar.gz [ec2-user@ip-10-0-10-10 ~]$ tar xzvf latest-ja.tar.gz 解凍すると、wordpressというディレクトリができるので、wordpress内に移動します。 wordpress内にある全てのファイルをApacheが参照するディレクトリにコピーします。 また、ファイルの所有権をApacheに変更します。 [ec2-user@ip-10-0-10-10 ~]$ cd wordpress/ [ec2-user@ip-10-0-10-10 wordpress]$ sudo cp -r * /var/www/html/ [ec2-user@ip-10-0-10-10 wordpress]$ sudo chown apache:apache /var/www/html/ -R Apacheを再起動して設定の変更を反映させます。 [ec2-user@ip-10-0-10-10 wordpress]$ sudo systemctl restart httpd.service WordPressを設定する ブラウザからWebサーバーにアクセスすると、WordPressの初期設定画面が表示されます。 あとは手順に従い、必要な項目を入力します。 データベース名、ユーザー名などはRDSで設定した名前を入力します。 ホスト名はRDSのエンドポイントを入力します。 これ以降の入力項目は、サイト名やログインパスワードの設定など任意の内容となります。 全て入力し、WordPressの管理画面に移行したら作業は完了です。 学んだこと ネットワーク構築〜サーバー構築までの基本的な手順 ネットワークの基礎的な知識：IPアドレス、ルーティング、サブネット etc. サーバーを操作するための基本的なコマンド：ssh接続、パッケージのインストールおよびアップデート etc. ファイアウォール（セキュリティグループ）の設定 データベースサーバーの構築 セキュリティ上の理由から、データベースはインターネットに接続しないプライベート領域に作成する