目的 CodeDeployにて過去のデプロイのリビジョンを用いてロールバックデプロイを行う方法を先輩から教えてもらったので忘れないようにメモする。 方法 下記のようにAWSのサービス上で操作を行う。 CodeDeployのホームを開く サイドメニューの「アプリケーション」をクリックする。 デプロイしたいアプリ名をクリックする。 「リビジョン」をクリックする。 デプロイしたいリビジョンを選択後、「アプリケーションをデプロイする」をクリックする。 「デプロイグループ」を選択、「リビジョンファイルの種類」を選択する(※リビジョンファイルの種類は基本zipを選ぶ) デプロイタイプなどのデプロイ設定に表示されている内容に問題が無いことを確認する。 「デプロイの作成」をクリックする。 指定したリビジョンを使ってデプロイが開始される。 先輩に教えてもらった用語 リビジョン： 過去デプロイの履歴 リビジョンファイル： 過去デプロイ時のソースコードなどのファイル

プログラミング勉強日記 2021年6月3日 S3の暗号化 　S3のデータの暗号化は保管時に暗号化形式として以下の4つの形式から選択する。 SSE-S3 　SSEはepicor server side encryptionの略。標準的に使うもので、S3の標準暗号化式で簡単に利用できる。サーバーサイド側(S3側)で暗号化をする。暗号化キーの作成・管理をS3側で自動的に実施してくれる。 　ブロック暗号の1つである256ビットのAdvanced Encryption Standard(AES-256)という強固な暗号化の仕組みを使ってデータを暗号化する。 SSE-KMS 　SSE-S3の次によく使われるもので、KMSはkey management serviceの略。AWS KMSに設定した暗号化キーを利用した暗号化を実施する。KMSは暗号キーを作って管理するS3ではない別のサービス。このサービスで鍵を作成し、その上でこの鍵を使ってS3で暗号化する。 　ユーザ側でAWS KMSを利用して暗号化キーを作成・管理することができる。クライアント独自の暗号キーを利用することもできる。そのため、独自に暗号化キーを作って管理をしたい場合に使う。 SSE-C 　ユーザが指定したキーによるサーバー側の暗号化(SSE-C)を利用することができる。ユーザ独自のキーをSDKなどを介して設定し、S3に使うということをアプリケーション上で組み込むといった複雑な設定ができる。利用設定が管理が複雑になる。 　KMSとS3はマネージメントコンソールのS3の標準機能で使うが、SSE-CはSDKツールを使いながらアプリケーション上で構築するなど複雑な設定になるので基本はあまり使わない。しかし、ユーザが指定した独自のキーを独自に使いたい場合などに使用する。 クライアントサイド暗号化(CSE) 　クライアントサイド側の暗号化では、S3に送信する前にデータを暗号化する方式。サーバーサイド側の暗号化では、データの送信後に暗号化する。 　KMSなどを利用して暗号化キーを作成・実施することができる。アプリケーション内に保存したマスターキーを利用して、事前に暗号化してそのあとにS3に送るということをアプリケーション上で組み込んで作れる。

動機 　javascriptの学習が進み、簡単なコンテンツの形が出来てきたので、とりあえずwebサーバを立ち上げようと思い立った。 　自前でサーバを用意するとなると、仮にVMやコンテナだったとしても連続稼働させるのは電気代かかるし、インフラをどうしようか考えていた時にAWSの無料枠がある事を偶然知った。 　 　正直、AWSは一切勉強したことも触ったこともなかったが、仕事柄クラウドサービスに触れる機会がある為、「まあなんとかなるだろう。」と思いつきで利用することにしてみた。 雑記/やったこと ①EC2について ●　AWSのクラウドコンピューティングサービス 12か月は無料で使える（ただし、OSイメージやCPUやメモリのリソースなどは無料枠の制限がある） →　OSは馴染みのあるRHEL8を選択 ●セキュリティグループ設定 →　インバウンド設定（ssh(22)とhttp(80)のみ） （とりあえずコンテンツのパーミッションを設定するまでは接続元をマイIPのみに絞る） ●　ssh接続は秘密鍵認証 インスタンス作成時にダウンロードする。teratermで対象IPにssh。 （動的IPなので再起動したら、変わるので注意。elastic ipの設定をすれば固定できるようだが、とりあえず放置。固有ドメイン必要になったら考える。） ●　ユーザはec2-user rootは基本使わない、sudoersには入ってる。たまにsudoつけ忘れ。 →　useraddで一応作業用ユーザを追加。passwdでパスワード設定 ●　apacheが入ってなかったのでyum install。 　 systemctl enable して再起動 ●　コンテンツをscpでローカルPCからサーバへ転送。DocumentRootに配置 →　chown、chmodで所有権とパーミッションを設定 ●webアクセス試すも403エラー →　Forbiddenになるので、確認したらSELinuxが原因だった。 一旦、enforcing=disableにしてサーバ再起動でアクセスOK

概要 CoudWatchカスタムメトリクスって知ってますか？ 通常のCloudWatchメトリクスは使ったことがある人が多いと思いますがカスタムメトリクスはそうでもないかもしれません 通常のメトリクスがAWSが用意したリソースしか監視できないのに対し、CloudWatchカスタムメトリクスは何でも監視してグラフ化出来る優れものです どうやって監視するか 監視といってもカスタムメトリクスは変動する値を継続的に読み込んでくれるわけではありません CLIやSDK等を使って監視したい値をその都度メトリクスに送信してグラフを作成するわけです 今回はAWSCLIを使用する方法とLambdaを使用する方法を紹介します AWSCLIを使う まずCLIを使える環境を用意しましょう 私はローカルに導入するのが面倒だったのでEC2インスタンスを立てました アクセスキーの作成 認証情報にアクセスキーが必要なので作成しておきましょう IAMコンソール→ユーザー→認証情報→アクセスキーの作成ボタンをクリックです IDが二つ表示されますのでメモしといてください CLIのセットアップ SSHで接続したらaws configureコマンドで簡単に設定しちゃいましょう $ aws configure --profile produser AWS Access Key ID [None]: さっきメモしたやつ AWS Secret Access Key [None]: さっきメモしたやつ Default region name [None]: ap-northeast-1 Default output format [None]: json これでawsコマンドがちゃんと使えるようになりました カスタムメトリクスを登録する AWSCLIのセットアップが終わったところで早速カスタムメトリクスを登録してみましょう 次のコマンドを叩いてください $ aws cloudwatch put-metric-data --namespace CustomMetrics --metric-name Test --dimensions CLI=RandomNum --value 100 なんだかオプションがたくさん並んでいますが実は簡単です namespace,metric-name,dementionsは全て識別子なので好きな名前を付けちゃってください 大事なのはvalueだけです。これが実際にメトリクスに登録される値です 今回は100という数値を登録しました 早速メトリクスを見てみましょう しっかり送信されていますね 見にくいですが青い点が今登録した値です しかしこんな点を登録したところで何の役にも立たないのでグラフにしていきましょう #!/bin/bash while true do NUM=$(($RANDOM % 100)) aws cloudwatch put-metric-data --namespace CustomMetrics --metric-name Test --dimensions CLI=RandomNum --value $NUM sleep 60 done & 今回は0~100のランダム数値を送信する簡単なスクリプトを書きました これをEC2上で実行してみましょう いい感じのグラフが出来ましたね Lambdaを使う Lambdaを使った登録も可能です 大体の流れは一緒ですがLambdaではランタイム毎に用意されたSDKを使うことになります 今回はNode.jsで実装してみましょう IAMロールの作成 CloudWatchにアクセスするロールをLambdaにアタッチする必要があります ユースケースからLambdaを選んでCloudWatchFullAccessを含んだロールを作成します Lambda関数の作成 ロールを作成したらLambda関数を作成します 先程作成したロールを作成時にアタッチしましょう サンプルコード const AWS = require('aws-sdk'); exports.handler = (event, context, callback) => { const rundom_num = Math.floor(Math.random() * (100)) const params = { MetricData: [ { MetricName: 'Test', Dimensions: [ { Name: 'Lambda', Value: 'Random_num' } ], Timestamp: new Date, Unit: 'Count', Value: rundom_num, } ], Namespace: 'CustomMetrics' }; const cloudwatch = new AWS.CloudWatch({ region: 'ap-northeast-1' }); cloudwatch.putMetricData(params, function (err, data) { if (err) console.log(err, err.stack); else console.log(data); }); } 今回も0~100のランダム数値を登録します Lambda関数ではオプションをMetricDataに記述してputMetricDataで送信します CLIで登録した時と同じようなオプションが並んでいるので難しくないですね Timestampはメトリクスに登録される時刻です 基本的には現在時刻を登録することになると思いますがそれ以外も指定することが可能です unitは登録する値の単位です 以下の中から選択できますが今回はCountを選択しました "Seconds" "Microseconds" "Milliseconds" "Bytes" "Kilobytes" "Megabytes" "Gigabytes" "Terabytes" "Bits" "Kilobits" "Megabits" "Gigabits" "Terabits" "Percent" "Count" "Bytes/Second" "Kilobytes/Second" "Megabytes/Second" "Gigabytes/Second" "Terabytes/Second" "Bits/Second" "Kilobits/Second" "Megabits/Second" "Gigabits/Second" "Terabits/Second" "Count/Second" "None" 任意の値を登録、監視するにはこれで十分ですが他のパラメータも用意されています 今回使用しなかったパラメータの詳細は公式ドキュメントを参照してください さて、実際にコードを走らせてみましょう ちゃんと登録されていますね 関数を定期実行させる Lambdaの場合シェルスクリプトみたいにWhileで定期実行させられないのでEventBridgeの機能を使っていきます 設定から「トリガーを追加」ボタンをクリックです トリガーにEventBridgeを選択してルールを決めます 今回は一分毎に実行させるrate(1 minute)を設定しました ここら辺を詳しく知りたい方はEventBridgeの公式ドキュメントを読んでください 最後にメトリクスを見に行きましょう ちゃんとグラフになっていますね さいごに 今回はただの乱数を使用しましたがValueさえ変えてしまえば様々なことに応用できます みなさん独自のオレオレメトリクスを作って自慢してやりましょう

これは何 3000文字Tipsイベントの参加記事です。 はじめに 本記事では、AWS SSO利用時にネックとなりやすい、ロール連鎖における1時間のセッション時間上限による使い勝手の悪さをマシにする方法についてご紹介します。 Webサービスプロバイダである弊社では複数のAWSアカウントを管理しており、IT運用部門と開発部門が協力してAWS SSOの導入を進めています。 運用概要は上記のようにしております。 AWS SSOの機能で、各AWSアカウントに一律でアクセス権限セットにより定義したロール(RoleA)がプロビジョンされます。 各AWSアカウントを管理する各チームが、実運用に必要なポリシーと、利用を許可するユーザーのprincipalを付与したロール(RoleB)を定義します。 これにより、実運用に必要なユーザーのみがRoleBのCredentialを得て活動できる、ということになります。 ただ、この運用ではCLI利用時に問題が起こります。 AWS SSOコンソールで発行されるCLI向け認可情報は、ロールベースの一時Credentialです。このCredentialを元にさらにAssume Roleで別のCredentialを発行しようとする場合、上で紹介したロール連鎖扱いになるため、指定できるdurationsecondsの上限は3600秒です。 最終的に利用するCredentialを発行するまでの流れとしては、 AWS SSOコンソールにアクセス 目的のAWSアカウントを探し、"Command line or programmatic access"から踏み台となるロール(RoleA)のCredentialを入手。クリップボードにコピー ターミナルでCredentialを貼り付け、aws sts assume-roleコマンドで本命のロール(RoleB)のCredentialを発行 アクセスキー、シークレット、セッショントークンをシェル環境変数にセット となります。 特に開発環境において、上記の流れをセッションが切れる度に行うのはあまりにも面倒だ、ということで、今回のやり方を考えました。 ソリューション ざっくりと以下3つの段階で実現します。 .aws/credentialにRoleAのCredentialを保存 このCredentialはセッション時間を12時間まで伸ばせる .aws/credentialに保存したRoleAのCredentialを呼び出してAssume Roleし、得た認証情報を.aws/credentialに保存 AWS SSOコンソールで発行される一時Credentialはロール連鎖扱いになっていないため、セッション時間を最大12時間まで延長できます。 このセッション時間はAWS SSO側の設定に依存します。 このソリューションのポイントとしては、手順1.を実施した後は最大12時間、RoleBのセッションが切れる度に「シェルを一つ実行するだけでよい」ことです。 .aws/credentialにRoleAのCredentialを保存 setSSOCredential.sh setSSOCredential.sh #!/bin/bash aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID --profile SSOCredential aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY --profile SSOCredential aws configure set aws_session_token $AWS_SESSION_TOKEN --profile SSOCredential echo "Finished to set SSO credential to env and .aws/credentials." AWS SSOコンソールからRoleAのCredentialを入手し、ターミナルにペースト bash setSSOCredential.sh を実行 aws configure setコマンドは、.aws/credentialファイルにCredentialを保存するコマンドです。 ここでは、RoleAのCredentialを保存するためのプロファイルを"SSOCredential"という名前に指定して、そこにCredentialを取っておきます。 .aws/credentialに保存したRoleAのCredentialを呼び出してAssume Roleし、得た認証情報を.aws/credentialに保存 setRoleCredential.sh setRoleCredential.sh #!/bin/bash output=$(aws sts assume-role --role-arn arn:aws:iam::999999999999:role/RoleB --duration-seconds 3600 --role-session-name cold-wisteria@works-hi.com --profile SSOCredential) export AWS_ACCESS_KEY_ID=$(echo $output | jq .Credentials.AccessKeyId -r) export AWS_SECRET_ACCESS_KEY=$(echo $output | jq .Credentials.SecretAccessKey -r) export AWS_SESSION_TOKEN=$(echo $output | jq .Credentials.SessionToken -r) aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID --profile default aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY --profile default aws configure set aws_session_token $AWS_SESSION_TOKEN --profile default echo "Finished to set role credential to env and .aws/credentials." (assumerole対象のロールやrole-session-name、profileは適宜書き換えてください) setSSOCredential.sh の実行後は、SSOCredentialのセッション時間中はsetRoleCredential.shを実行するたびにdefaultプロファイルに新しいCredential情報を書き込むことができます。 timeout 36000 watch -n 3500 bash setRoleCredential.sh みたいなコマンドで繰り返し処理にしておいてもいいかもしれません。 この状態になれば、後はdefaultプロパティに保存されたCredentialを使ってAWS CLIでの作業を行うことが可能です。 最後に 本記事の執筆途中で、aws configure ssoコマンドの存在に気づきました。 が、こちらは以下の理由からそこまで使いやすくない/利用しづらいケースもあるかな、と思います。 AWS CLI v2が必要 結構CLIの対話フローが長い 結局CLIのフローの中で、一部ブラウザアクセスとブラウザ上での操作を要求される 以下のように、対話の中で対象のAWSアカウントをCLI上で選択させられる SSOコンソールでなら検索が可能だが、CLIではキーボードの上下で選択するしかなく、多くのAWSアカウントがSSO対象になっていると選択が辛い

Security Hub から Slack に通知させる SecurityHubで評価　>> Event Bridge をトリガーに SNSトピックに通知 >> SNSトピックに設定されているChatbotに情報送信 >> ChatbotがSlackに通知 というのを CloudFormation でデプロイしていこうと思います。 Security Hubの有効化 こちらの手順で、Security Hub を有効化する。 基本的に有効化するだけですので、手順はドキュメントに任せます。 なお、AWS Security Hub の概要については下記の記事でも纏めているので参考程度に。 Security Hub、EventBridge、SNS、Chatbot（Cloudformatinスタック） EventBridge のカスタムルールは以下の記事のもの採用する。 例3: 「通知済み」にしたものは除外する ポイントは評価に失敗したものは、何度も通知させないようにすることである！ テンプレートは、重要度が「重要」もしくは「高」のものかつ、ワークフローステータスが「新規（NEW）」のものだけを通知する。 「新規（NEW）」で通知されたものは、「通知済み（NOTIFIED）」もしくは「（抑制済み（SUPPRESSED）」に変更しておくことで、失敗し続ける項目を何度も通知させないようにすることが可能である。 重要度 ワークフローステータス SecurityHub.yaml AWSTemplateFormatVersion: 2010-09-09 Description:Slack notifications for security hub Parameters: SnsTopicName: Type: String Default: SecurityHubTopic SlackWorkspaceId: Type: String Default: XXXXXXXXX SlackChannelId: Type: String Default: YYYYYYYYY Resources: #SNS# SNST: Type: AWS::SNS::Topic Properties: TopicName: SecurityHubTopic SNSTP: Type: AWS::SNS::TopicPolicy Properties: PolicyDocument: Id: default_policy_ID Version: "2012-10-17" Statement: - Sid: default_statement_ID Effect: Allow Principal: AWS: "*" Action: - "SNS:GetTopicAttributes" - "SNS:SetTopicAttributes" - "SNS:AddPermission" - "SNS:RemovePermission" - "SNS:DeleteTopic" - "SNS:Subscribe" - "SNS:ListSubscriptionsByTopic" - "SNS:Publish" - "SNS:Receive" Resource: !Ref SNST Condition: StringEquals: "AWS:SourceOwner": !Ref "AWS::AccountId" - Sid: AWSEvents_SecurityHubFindings_Id123 Effect: Allow Principal: Service: - "events.amazonaws.com" Action: "sns:Publish" Resource: !Ref SNST Topics: - !Ref SNST #EventBridge# ER: Type: AWS::Events::Rule Properties: Name: SecurityHubFindings EventPattern: { "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "Compliance": { "Status": [ { "anything-but": "PASSED" } ] }, "Severity": { "Label": [ "CRITICAL", "HIGH" ] }, "Workflow": { "Status": [ "NEW" ] }, "RecordState": [ "ACTIVE" ] } } } State: ENABLED Targets: - Arn: !Ref SNST Id: SNST EventBusName: default #Chatbot用 IAMロール SecurityHubIamRole: Type: AWS::IAM::Role Properties: RoleName: SecurityHubIamRole AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: "chatbot.amazonaws.com" Policies: - PolicyName: SecurityHub-NotificationsOnly-Policy PolicyDocument: Version: "2012-10-17" Statement: - Action: - "cloudwatch:Describe*" - "cloudwatch:Get*" - "cloudwatch:List*" Effect: "Allow" Resource: "*" #Chatbot SecurityHubConfiguration: Type: AWS::Chatbot::SlackChannelConfiguration Properties: ConfigurationName: SecurityHub-Chatbot-SlackChanel IamRoleArn: !GetAtt SecurityHubIamRole.Arn LoggingLevel: ERROR SlackChannelId: !Ref SlackChannelId SlackWorkspaceId: !Ref SlackWorkspaceId SnsTopicArns: - !Sub 'arn:aws:sns:ap-northeast-1:${AWS::AccountId}:${SnsTopicName}'

概要 AWS LambdaにC#プロジェクトをデプロイする場合、 Windows版のVisual StudioであればGUIからボタンぽちぽちで完了するので良いのですが(要AWS Toolkit for Visual Studio)、 Visual Studio for Macの場合はできません。 そのため、Macの場合はCUIからデプロイする必要があるので、本記事でその方法についてまとめておきます。 事前準備 ●AWS CLIをインストール brew install awscli ●Amazon.Lambda.Tools .NET Core Global Tool .NETアプリケーションをAWS Lambdaへデプロイするために必要です。 dotnet tool install -g Amazon.Lambda.Tools ●プロファイル作成 ローカルPCからAWSへCLIで操作を行う場合、都度「プロファイル」を指定して接続する形になります。 ※あらかじめAWSでCLIで使用するためのIAMを設定し、AccessKey及びSecretAcccessKeyを取得しておきます。 aws configure --profile {プロファイル名} # 例: aws configure --profile user1 AWS Access Key ID: {設定したIAMから払い出されたキーをコピー} AWS Secret Access Key: {同上} Default region name: {東京の場合は ap-northeast-1 を指定} Default output format: JSON C#プロジェクトの準備 ●設定ファイル デプロイコマンドを実行する前に、C#プロジェクトに 「どのリージョン」に「どのプロファイル」を使用して、「どのLambda関数」にデプロイする、等といった設定ファイルをJSON形式で用意しておく必要があります。 ファイル名: aws-lambda-tools-defaults.json 階層: 「.csproj」ファイルと同階層に配置 { "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": "SearchConnpassLineBot::SearchConnpassLineBot.Function::FunctionHandler", // Lambda実行時にコールするメソッドを指定 "function-name": "SearchConnpassLineBot", // Lambda名称 "function-role": "arn:aws:iam::000000000000:role/MyLambdaRole" // AWSロール名 } デプロイ方法 ●デプロイコマンド 簡単です。 デプロイしたい「.csproj」ファイルがある改装で以下コマンドを実行します。 dotnet lambda deploy-function 以上でデプロイ完了です！ お疲れ様でした！

はじめに こんちには！今、シェアハウスに住んでいるのですが、 共用で使っている洗濯機を使おうとすると もう誰かが使っていて使えないことがあります、、 わざわざ洗濯機を使っているか確認しに行くのもめんどい、、 ということで洗濯機が稼働しているかどうかがわかるWebシステムを作ってみました！ 作ったもの urlを叩くとシェアハウスの洗濯機が稼働しているかわかる 使っているとき 使っていないとき システム構成 電流データを取得 → 洗濯機とコンセントに下記のIoT機器(スマートプラグ)を設置電流データを取得する あとはこの電流データを公開しているAPIをフロント側から叩いてその結果をもとに洗濯機を使っているか否かを表示すればOK！簡単じゃんと思っていたが、、 IoTデバイスのスマートプラグのAPIの使用しすぎは、APIシステムへの課金がされてしまう 洗濯機を使っていても、脱水時は電流データが0になるタイミングがある という状況に対応するため AWSのLambda(Node.js)でIoTデバイスが提供しているAPIは5分に1回だけ取得するようにしデータをAWSのDynamoDBに保存する 保存されたDynamoDBから電流データを取得し、使っているかどうかを判定(最新電流データから過去3回分中、電流仕様が2/3だったら使用中とする)し、APIで返すAPIサーバーをLambdaとAPIGatewayで作成 上記のAPIを叩くフロント側(S3)を作成し、シャアハウス住民のれとるときゃりー(@retoruto_carry)が作成したデジタルサイネージシステムに乗せて2分間に1回ぐらい定期的に表示する(もちろん直接url叩いても見れます！) というサーバレスなシステムにしました。 システム構成図はこんな感じ！ 開発の流れ ① アーキテクチャ設計、言語設定 とりあえず安価なことを含め、環境構築が不要なサーバーレスでアーキテクチャを組むことに、 最初は、GCPとAWS組み合わせて作ろかと模索していましたが、それぞれの相性を考慮して AWSに統一してLambda、APIGateway、DynamoDBで構築することに！ Lambdaで使った言語ですが、日頃、業務ではRubyを使用しているのですが、Nodeに興味があったのでNode.jsで書くことにしました。 また、ローカルでvimを使って開発したいのと、githubでソースコードを管理したかったので、AWS cliを使って開発しました！ 最初はシェアハウスの同居人とあーだこーだいいながらアーキテクチャを考えました 業務で使っていないNode.jsと触ったことがなかったLambda ApiGeteway DynamoDBに苦戦する日々 ② 熱海で開発合宿 熱海のゲストハウスでシェアハウス同居人の@retoruto_carry、@wamisnet、@ryosk7に参加して、要件定義、アーキテクチャ設計の見直し、そして、ひたすら開発する。 業務では主にRubyを使っているので、Node.jsで書くのにいろいろと苦労しました、、その分勉強になった！ お酒や熱海のうまい海鮮料理、温泉に寄り道しすぎてここでの開発進捗は30％ぐらい、、 最後はお互いに成果を発表しました！ ③ 業務が休みの日にひたすら開発 AWSのAPIGateway、Dynamoを構築するのが大変だった、、とくにDynamoDBは、初めて使ったので、特に苦労した、、 時間をかけながらも、ひたすら開発した。ちゃんと動いたときは、嬉しかったですね！ まとめ AWSのLambda、APIGateway、DynamoDBの連携が楽で快適。コストも低く、このサーバレスシステムは5分に一回24時間稼働していますが、ほぼ0円です。 誰かのためになるシステム開発は、やりがいがある！ IoTで電流がとれるデータが取れるものなら、いろんなことで家?をハックできそう！ 終わりに ここまで読んでいただきありがとうございます！ まだまだ、色んなものを作って成長していきたいと思っています！SNSでのシェアやLGTMしてくださると 今後の開発の励みになります！ Twitterもやってます！(@tanayu7777)よかったらフォローしてくださいね！

はじめに こんにちは、WEBアプリ開発系企業に20卒で入社した新米プログラマーのYuu_Nです。 業務経験は研修でJavaを使用してECサイトを作成した後、C#を用いた業務アプリの開発の経験を経て今は社内研修（Java）のサブ講師をしています。 社内SNSに投稿したことはあるのですが、そこからより多くの方に見ていただこうということでこちらのQiitaに初投稿してみます。技術的な記事はまだ恐れ多かったのでイベントの参加レポから投稿していきたいと思います（いつか技術的な記事を颯爽と投稿したい）。 AWSome Day Online Conferenceに参加した理由・目的 こちらのイベントに参加した目的としては、業務でAWSに触れる機会があり、一部機能（AWS LambdaやEC2、RDSなど）の使用方法について学ぶ機会があったので体系的に学ぶことで今後の業務に役立てたいと考えたためです。 セッションの紹介 AWS 認定クラウドプラクティショナー準備コースとなる「AWS Cloud Practitioner Essentials」をベースとしたトレーニングです。 ※AWSome Dayの公式サイトはこちら 本当は「はじめての AWS ～初級者から中級者への道筋。クラウドアーキテクチャの理解を深める～」について聞きたかったのですが今回のセッションには含まれないとのことで、以下4点のセッションについて学びました。 ・AWS のグローバルインフラストラクチャとネットワークおよびコンピューティング ・ストレージとデータベース ・AWS のセキュリティの基本 ・Well-Architected Framework と料金の話 以下学んだ内容を箇条書きします。 AWS のグローバルインフラストラクチャとネットワークおよびコンピューティング ・オンプレからクラウドへの移行 グローバルインフラストラクチャとは？ オンプレの場合→データセンター リージョン（地域）、アベイラビリティゾーン（AZ） オンプレでいうとデータセンター群が仮想で存している ・リージョンがなぜ最低2つ以上のAZからなっているのか 1つのAZが使えなくなっても他のAZでも使えるようにしている＝可用性が高い →データセンターを2つたてた、複数たてたのと同等 ・VPC=仮想プライベートネットワーク 　ネットワークを司る機能を提供する 　・コンピューティングシステム＝仮想サーバのシステム 　　・EC2＝仮想サーバのシステム 　　　オンプレでいうVM 　　　インスタンスタイプのバリエーションが豊富 　　　要件に合わせて作成でき、後から変えることが可能 　　・ELB 　　　複数のインスタンスにトラフィックを分散してくれる 　　　負荷分散はELBがあれば自動で対応してくれる 　　　・ALB　リクエストレベルで動作する（レイヤー7）、細かく振り分けられる、柔軟性がある 　　　・NLB　接続レベルで動作する（レイヤー4）、ALBと比べるとレイヤーが少し下がるうえ、細かいレイヤで振り分けることはできないものの、パフォーマンスが高い 　　　・CLB　今あまり使っていない 　　　 　　・EC2 Auto Scaling 　　　トラフィックを救うために用意したキャパシティーのほとんどが使われていないという事態を無くすことができる、しかも自動 　　　スケールアウトとスケールインを行ってくれる 　　　ELBと一緒に使う 　　・Lambdaを作成しCloudWatchでモニタリング。ELBと一緒に使用してアプリケーションの負荷を処理するのに適切な数のEC2インスタンスを生成、削除することで必要なコンピューティング容量を守りつつ、障害への対応、コスト面も最適化することができる ストレージとデータベース データストアとは＝データを保管しておく場所 EBS(Elastic Block Store) EBSで使用可能、オンプレの場合は外付けストレージ 自動でレプリケートしてくれる ・S3(Simple Storage Service) オブジェクトストレージ、オンラインストレージ 容量無制限 ・RDS(Relational Database Service) 　データがリレーショナルデータ 　オンプレの場合→二次元の表形式、何かの形式でつながっている状態 　DBは運用、管理が大変→楽にできる 　クリック一回自動で同期の取得、マルチAZ配置によって一個RDSが落ちても使える ・複数のサーバーからアクセスできる AWSマネージドデータベースサービス 　・Amazon RDS 　　マネージド型で、セットアップ、運用、拡張が容易なリレーショナルデータベースサービス 　・Amazon DynamoDB 　　完全マネージド型で、高速なパフォーマンス、シームレスな拡張性と信頼性をもつNoSQLサービス 　・Amazon Redshift 　　マネージド型で、高速で管理も万全なペタバイト規模のデータウェアハウスサービス 　・Amazon ElastiCache 　　マネージド型で、セットアップ、運用、拡張が容易なキャッシュサービス セキュリティの基本 ・AWSセキュリティの紹介 ・AWS責任共有モデル ・ネットワークセキュリティ ・AWSの認証とアクセス管理 セキュリティはAWSの最重要事項 ・責任共有モデルとは？ AWS側、AWSを利用する側それぞれでデータを守る＝責任共有 暗号化等機能の提供は行うけれど設定するのは利用者側となる つまり、セキュリティ対策をしっかり行うためには提供されている暗号化機能を理解しておかないといけない IAM＝AWSの認証とアクセス管理 ・ユーザー　ログインする時使用し、種類としてはRootとIAMユーザーがある ・権限（ポリシー）　EC2触ってもよいのか？RDS起動できるのかなど設定できる ・グループ　対応したグループに入っていればユーザーをまとめてEC2閲覧だけ、触れるなど設定できる ・ロール　ポリシーをつけて人やサービスに渡すことができるため、この機能で柔軟な設定ができる アカウントルートユーザー Eメール、パスワード、AWSアカウント名等でログインするアカウント できれば常日頃から使わない！ →そんな時使うのがIAMユーザー、必要最低限のユーザーを作成する AWS IAM ポリシーを作成して権限を割り当てる 基本拒否、明示的に許可を書かないと使えないようになっている ログイン方法についてはAWSコマンドでもログインすることができる AWS STS(一時的セキュリティ認証情報) 15分～36時間の間で一時的にログインできるようにすることができる クロスアカウントアクセスやフェデレーション、モバイルユーザーやEC2ベースのアプリケーションのキー更新の際などに使うことができる MFAとは？ 多要素認証 ワンタイムパスワードを発行して守る ログインのセキュリティを上げることができる Well-Architected Framework Well-Architected Framework＝クラウド最適化のためのフレームワーク ※Well-Architected Frameworkの公式サイトはこちら オンプレの既存構成をリフト＆シフトすると？ オンプレからそのまま持っていく＝リフト →クラウドの長所が活かせない シフト＝最適化 →コストの最適化できている？ これらの問題をWell-Architected Frameworkが解決できる 障害の対策への興味深い試み 障害を避けるためには障害を起こし続けること ゲームデー 本番環境で突然回線を落とす等行う TCOで比較 TCO計算ツールという便利なものがあるらしい ※TCO計算ツールの公式サイトはこちら 感想 　業務で少し触れる機会があったのでそうなんだと思えるところが多々あったので思っていたよりも難しく感じずに最後まで聞くことができました。 なので、業務で触れたことがあるけれどあまり詳しく知らない方にはとても良い内容だと思います。 　EC2、RDSやIAMについて業務で使用していたので復習することができ、その中で知らなかった機能についても学ぶことができてよかったです。 特にIAMについてはルートアクセスキーがあるAWSアカウントは削除することが望ましいことや、 なるべく個々のIAMユーザーを作成したうえでグループを使用して権限を割り当てること、 強力なパスワードポリシーを設定すること、権限のあるユーザーに対してMFAを有効にすることによりセキュリティを上げる対策を行うことを知り、 業務でも実際にそのような対応を行っていて特に疑問に思わず使用していたのですが、セキュリティの観点で必要（いわゆるベストプラクティス）だったのだと理解できてよかったです。 　また、思っていたよりもAWSは充実していることが理解でき、これからはクラウド！となっている理由が理解できたような気がします。

クラウドを学び始めてしばらくすると、インフラをコード化できることを知りました。 Infrastructure as Code（IaC）ってやつですね。 IaCのツールは様々です。 AWSであればCloudFormation、AzureであればARMTemplate、 そして、マルチクラウドに対応しているIaCのツールがHashiCorp社のTerraformです。 前に少しだけ触ったことはあったTerraformを改めて学んで、知見がたまってきたのでまとめてみたいと思います。題材は、学習のためにAWSCLIで作った環境をTerraformで再現することにしました。 作りながら覚えるTerraform入門シリーズ インストールと初期設定 => 今回はコチラ 基本編 VPC編（準備中） EC2編（準備中） Route53 + ACM編（準備中） ELB編（準備中） RDS編（準備中） ※シリーズ化して順番に書いていければと思います。 システム構成 ELB、EC2、RDSなどの一般的な3層アーキテクチャの構成です。 ソースコードは以下にあります。 環境 macOS BigSur 11.3.1 Homebrew 3.1.9 Terraformインストール Homebrewで簡単にインストールできます。 brew install terraform 現時点での最新バージョン0.15.5がインストールされました。 実態は/usr/local/bin/にあるのでPATHを通す必要もありませんでした。 terraform --version Terraform v0.15.5 ちなみに、tfenvを使ってインストールする方法もあります。 tfenvを使うと、複数のバージョンを切り替えたり、チーム開発においてバージョンを固定するのに便利そうです。ただ、tfenv経由でterraformコマンドを実行すると遅かったので、現時点では使うのを控えています^^; # tfenvのインストール brew install tfenv # tfenvを使ってterraformをインストール tfenv install 0.15.4 tfenv install 0.15.5 # デフォルトバージョンを指定 tfenv use 0.15.4 # 一覧を表示(0.15.4を使う設定になっている) tfenv list 0.15.5 * 0.15.4 (set by /usr/local/Cellar/tfenv/2.2.2/version) # バージョン確認 terraform --version Terraform v0.15.4 # バージョン切り替え tfenv use 0.15.5 # バージョンが切り替わった tfenv list * 0.15.5 (set by /usr/local/Cellar/tfenv/2.2.2/version) 0.15.4 # バージョン確認 terraform --version Terraform v0.15.5 tfenvを利用する場合、カレントディレクトリに.terraform-versionというファイル名でバージョンを書いてあげると、指定バージョンの利用を強制できます。tfenv installだけで(引数なしに)指定バージョンをインストールすることもできるようになります。 .terraform-version 0.15.5 VSCode拡張機能 以下の2つをインストールしました。 HashiCorp Terraform Terraform Autocomplete 「HashiCorp Terraform」で構文チェック、シンタックスハイライト、候補表示ができるようになりますが、リファレンスにジャンプしたい場合に「Terraform Autocomplete」が便利そうだったので試験的に使っています。 それと、リンクページにも記載のあるとおり「HashiCorp Terraform」には自動フォーマットの機能がありますので、"editor.formatOnSave": trueを追記して有効にしておくと便利です。保存のたびにインデントを整えてくれます。 Formatting To enable formatting, it is recommended that the following be added to the extension settings for the Terraform extension: settings.json "[terraform]": { "editor.formatOnSave": true } エイリアス設定 terraformを使い始めると次のようなコマンドを頻繁に入力することになります。 terraform plan terraform apply terraform destroy 毎回terraformと打つのが面倒なので、.zshrcにエイリアスを登録しておくと便利です。 ~/.zshrc alias tf="terraform" alias tfp="terraform plan" alias tfv="terraform validate" alias tff="terraform fmt -recursive" alias tfa="terraform apply -auto-approve" alias tfd="terraform destroy -auto-approve" applyやdestroyは作成・更新・削除するためのコマンドです。 -auto-approveをつけているのでyes/noの確認の入力を求められませんが、実際の業務で使用するのはとても危険なので、必要に応じてカットするようにしましょう。慣れるまではエイリアスを使わずに手入力して、planの結果を確認してからyes/noという流れのほうが良いかもしれません。 git-secretsのインストール terraformを使ってAWSにアクセスするには、あらかじめ認証情報を登録しておく必要があります。 認証情報を定義する方法はいくつかありますが、そういった機密情報を誤ってGitのソース管理に含めてしまわないようにgit-secretesをインストールしておきます。 # インストール brew install git-secrets # git-secretsの設定 git secrets --register-aws --global git secrets --install ~/.git-templates/git-secrets git config --global init.templatedir '~/.git-templates/git-secrets' AWSCLIのインストール AWSへアクセスするための認証情報を登録するためにAWSCLIをインストールします。 公式ページ の「MacOS」のリンクからPKGをダウンロードしてインストールすることができます。 AWSCLIがインストールできたら、IAMユーザーのアクセスキーを登録します。 このユーザーのアクセス権に従ってterraformでリソースの作成・更新・削除などが行われますので、通常はAdministratorAccessの権限を持つユーザーを作成して割り当てます。 aws configure set aws_access_key_id <アクセスキーID> aws configure set aws_secret_access_key <シークレットアクセスキー> ~/.aws/credentialsを確認して、認証情報が登録できていることを確認します。 ~/.aws/credentials [default] aws_access_key_id = <アクセスキーID> aws_secret_access_key = <シークレットアクセスキー> 試しに動作確認を行ってみます。 以下のコマンドを実行して、利用するIAMユーザーの情報が表示されればOKです。 aws sts get-caller-identity { "UserId": "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/terraform" } これでterraformを利用するための準備は完了です。 次回は、VPCの作成と削除のコマンドを通じて、terraformの基本的な使い方を書いてみたいと思います！ 参考リンク AWS コマンドラインインターフェイス 【初心者向け】MacにTerraform環境を導入してみた

Sumerianとは？ Amazon Sumerian(以下Sumerian)とは、Amazonが提供する ブラウザベースの 3D、拡張現実 (AR)、仮想現実 (VR) アプリケーションを簡単に作成し実行 できるサービスです。 ⇨ 公式 今回はこちらのSumerianで簡単なデモを制作しました。 Qiita用デモ　 *右下のアイコンから音声をONにしてください。矢印キーで視点を動かすことができ、hostをクリックすると挨拶をしてくれます。 達成 Sumerian Hostがお出迎えの挨拶をしてくれる 通路を作る 道路を歩き、壁にぶつかる Sumerian Hostがお出迎えの挨拶をしてくれる こちらに関しては、参考書に載っているをそのまま参考にしています。 Cognitoを設定する必要があるのでちょっと手間ですが、難しいことはありませんでした。 参考書で書かれている(私が参考にした)方法とは異なるのですが、公式のチュートリアルを参考に載せたいと思います。こちらはCloudFormationを利用した方法が紹介されています。 Sumerian Host Course こちらCognito Identity Pool IDの設定方についての参考になります。 Amazon Sumerian で作成したシーンに AWS リソースへのアクセス許可を与える Cognitoを使えばSumerianとAWS各種サービスを連携させることができます。 通路を作る 平面を繋いで箱を作り、それぞれに画像をインポートしています。 こちらのチュートリアルを参考にしています。 Crash Course: Creating a Industrial Machinery Training Application (Amazon Sumerian) 道路を歩き、壁にぶつかる 移動する・壁にぶつかる(衝突判定)は下記を参考にしています。 Amazon SumerianでRoll a Ballを作ってみた 参考として私のオブジェクト、ステートマシンの設定を載せたいと思います。 オブジェクト Camera Collider : 衝突判定のため必要。 Rigid Body： 重力を加える。 ステートマシン：CameraMove(仮称) Key Down & Key Up：　キー(今回は矢印キー)にステートアクション(Apply force on rigid body)を紐付ける。 Apply force on rigid body：　物理エネルギーを対象に与えて動かす。 ⇨矢印キーでキャラクターを動かす(前後の動き、左右へ振り向き) 通路出口 Collider：壁や障害物となるよう通路壁面に追加(衝突判定)。 課題 ピタッと動きを止めることができない(ステートマシンApply force on rigid body使用時) 例えば「ゴール地点からスタート地点へワープ」するように、「AからBへ移動する」ことができない(スクリプトを使ってアップデートすると、その地点で固定されてしまう)。 感想 まだまだわからないことだらけですが、Sumerianは楽しいです。 今後は特にBooleanを使った展開、スクリプトの活用を学びたいと思います。

はじめに 複数アカウントを運用していると別アカウントからS3にファイルをアップロードされることがあると思います。 その場合、デフォルトでは元のアカウントを所有者としてファイルがアップロードされてしまいます。 S3バケットとアップロードされたファイルの所有者が異なる場合はコマンドによる復元操作ができないなどの問題が発生するため、今回はその対応方法について試してみました。 実施手順 ファイルのアップロード 別アカウントからS3バケットにファイルをアップロードします。 ※アップロードはEC2にアタッチしたIAMロールを使用して行いました ※アップロード先のS3バケットのポリシーでIAMロールを許可しています。 アップロード方法は以下のブログで書いているので、そちらをご参照ください。 https://www.capybara-engineer.com/entry/2021/05/20/120604 所有者はアップロード元のAWSアカウントになっていました。(諸事情でモザイクかけてます) その状態だとS3バケット所有者のアカウントからオブジェクトにアクセスする権限が足りていないので、このようにエラーが発生します。 アップロード時にオブジェクトの所有者を変更する 2020年10月にAWSから以下のUpdateがありました。 簡単に言うとS3バケット側の設定で「Object Ownership」を設定し、アップロード時に[bucket-owner-full-control]を指定することで所有者をS3バケットのアカウントに変更できるようになりました。 https://aws.amazon.com/jp/blogs/aws/amazon-s3-update-three-new-security-access-control-features/ 設定内容は↑のリンクに書いてますが、順番に実施していきます。 対象のS3バケットのアクセス許可タブを押下します。 オブジェクト所有者の設定の部分で編集ボタンを押下します。 デフォルトはオブジェクトライターになっているので、これをバケット所有者に変更します。 更新が完了すると画面に表示されます。 変更できたので、再度別アカウントからファイルをアップロードしてみます。 まずは[bucket-owner-full-control]を指定しないアップロードです。 オブジェクトを見ると所有者は特に変わってません。 次は[bucket-owner-full-control]を指定してアップロードしてみます。 $ aws s3 cp .\test3.txt s3://test-tmp-20210603/test/ --acl bucket-owner-full-control 所有者がS3バケットを所有しているAWSアカウントになっています。 設定前ではエラーが出ていたアクセス許可とサーバサイド暗号化の設定もエラーなく確認することができました。 ちなみに 今回のS3バケットでの設定をせずに[bucket-owner-full-control]を指定してアップロードしてもエラーは発生しないようにできます。 ただ、所有者は元のアカウントのままなので、もし指定をせずにアップロードされた場合は思いがけず操作できないということが発生する可能性があります。 その時はバケットポリシーに"s3:x-amz-acl": "bucket-owner-full-control"を指定するなどして、アップロード時に制限するのをオススメします。 おわりに 簡単ではありますが今まで知らなかったのでやってみました。 複数アカウントからファイルをS3にアップロードするときは気を付けましょう。

昼休み、昼飯を終え一息ついているとスマホに通知が。 「Visaデビットご利用通知　Amazon web services 2.57USD」 AWSリソースの消し忘れで$2.57が徴収されたようです... 勉強も兼ね、どこで発生したのか調査しよう。 利用料金の確認 ググったところ、 - 請求情報とコスト管理コンソール - Cost Explorer この辺りが使えそう、クラウドプラクティショナーの勉強でも出てきたやつだ。 請求情報とコスト管理コンソール 月毎の利用料がグラフになっている。 $2.57は昨月の利用料だったことが判明 なるほど翌月頭に徴収のシステムなんですね、知らなかった。 更に、 今月の予想利用料$2.84 まじで？こっちも調べないと ちなみに既に$0.43発生している模様、WAFとConfigらしい。 まだ今月３日だぞ... Cost Explorer 過去６ヶ月の請求金額とその内訳が確認できる。 ４月にも$0.69発生していることが判明 なんで気づかなかったんだ。 肝心の５月分の内訳は、 WAFが\$2.26、EC2その他が\$0.07、税金\$0.24 WAFの課金は5/20から毎日$0.2 EC2は何度も立ち上げたり消したりしてるからいいとして、WAFってなんだっけ... そして5/20に何をしたんだろう。 更に今月分はWAF（5/20から継続）とConfigで発生している模様、Configも調べないと。 WAFの課金 WAFはWeb Application Firewallの略。 AWS WAF は、可用性、セキュリティ侵害、リソースの過剰消費に影響を与えるような、ウェブの脆弱性を利用した一般的な攻撃やボットから、ウェブアプリケーションまたは API を保護するウェブアプリケーションファイアウォールです。 https://aws.amazon.com/jp/waf/ よく覚えてないけど確かに触った気がする、どこで課金されたのだろう。 作成する各 Web ACL および Web ACL ごとに作成する各ルールに対して請求されます。さらに、Web ACL によって処理された Web リクエストの数に対して請求されます。 https://aws.amazon.com/jp/waf/pricing/ Web ACL ルール リクエスト の3つで課金が発生するらしい。 AWS WAFのダッシュボードからWeb ACLを確認するとリソースは無さそう。 あれ？でも、WAFの課金止まってないよな。 CloudTrailを遡る CloudTrailで5/20を確認してみる。 CreateWebACL May 20, 2021, 16:53:57 (UTC+09:... これか。 削除のログも確認しないと。 DeleteWebACLで検索したがヒットしない、おかしい CreateWebACLを確認するとus-east-1での記録になっている。 AWS WAFのページに戻りus-east-1を確認、WebACLは残っていない。 もちろんap-northeast-1にもWebACLなし。 ここまでをまとめると Cost Explorer : 5/20からWAFに課金、今も継続中 CloudTrail : 5/20にus-east-1にてCreateWebACL、以降のDeleteの記録なし AWS WAF : us-east-1にWebACLは無し ???? ここでギブアップ、上司のWさんに相談。 「CloudFrontとWAFで使ったんじゃない？」 騙されたポイント CloudFrontとWAF連携させる場合、WebACLはグローバルで作成しなければならないらしい。 そのため、WebACLダッシュボードでの表示はGlobal。 しかし実際にはus-east-1のサーバに作成されるため、CloudTrailでの記録はus-east-1に残る。 ここで騙されたようです。 確認してみると、WebACLのダッシュボードでリージョン名に並んでGlobalの選択肢がある。 無事Web ACLを発見、削除しました。 Web ACL名がhandson-wafなので、AWSハンズオンをやったときの残りだ、消し忘れてた... AWS Configの課金 AWS Config では、アカウントの記録された設定項目の数、アクティブな AWS Config ルールの評価数、コンフォーマンスパックの評価数に基づいて課金されます。 https://aws.amazon.com/jp/config/faq/ ルールの評価数 コンフォーマンスパックの評価数 で課金されるらしい。 configの課金は6/1だけだった、適当に触っていたのでどこかで$0.08課金されたらしい。 ともかく課金は止まっているようなのでよかった。 振り返り CloudTrailはほぼ初めて触ったし、WAFについても少し知れた。 何より無駄な課金を止めれてよかった。

概要 モバイルアプリ向け DynamoDB 設計ハンズオンをやってみました。 このハンズオンでは、モバイルアプリ向けの DynamoDB の設計方針を学ぶことができます。 せっかくなので、学んだことをアウトプットします。 以下公式説明です。 このラボでは、DynamoDB により提供するモバイルアプリケーションを構築しながら、Amazon DynamoDB での高度なデータモデリングパターンを学びます。DynamoDB を使用する場合、データをモデリングする前にデータへのアクセス方法 (アクセスパターン) を検討することが重要になります。ここではそういったパターンを学ぶために、ソーシャルネットワークを内臓したサンプルのモバイルアプリケーション用に、データモデルを構築していきます。DynamoDB で素早く一貫性のあるパフォーマンスを実現するための、データモデルの設計法を習得できます。 データモデリングについて DynamoDB などの NoSQLDB は RDB 等と異なり、速度とスケールの為に設計されています。 そのため、以下の点に注意してモデリングする必要があります。 アクセスパターンを検討する まず、DynamoDBをどのような使い方をするのかを検討する。(どういうアプリなのか、どういうリクエストが多いのか等) とっかかりとしては、まずエンティティを抽出し、多重度をつける。 次に、アクセスパターンを検討する。エンティティがどういったデータにどういう操作を行うかを検討する。 SNSを例に挙げると、ユーザが他のユーザのプロフィールを参照する等。 DynamoDB へのリクエスト数を最適化する 1で検討したアクセスパターンごとにリクエスト数を最小限に抑えるようにテーブルを設計する。 理想は各アクセスパターンに必要なリクエストを1つのみにすること。 最適化を行う為に、DynamoDBのコアコンセプトを理解する。 プライマリキー セカンダリインデックス DynamoDB トランザクション リレーショナルモデルの考え方をしない DynamoDB にリレーショナルモデルの考え方を持ち込むと DynamoDB の利点がほとんど失われる。一般的なアンチパターンは以下である。 正規化： DynamoDB はテーブルが多くなるにつれて速度が遅くなるため、正規化を行わないほうが良い。 テーブルごとに 1 つのデータ型にまとめる： DynamoDB テーブルには単一のテーブルに様々なタイプのデータが含まれる。 セカンダリインデックスを大量に作る：属性の柔軟性を使用してテーブル内の複数のデータ型にかけて単一のセカンダリインデックスを再利用する。 プライマリキーの設計 プライマリキーは各エンティティを明確に識別できる必要がある。そのため,個々のアイテムのコアアクションを実行できること確認する。 プライマリキーはプレフィックスを使用することにより、コンフリクトを防ぐことができる。 同一のテーブルに顧客と従業員がある場合、以下のようにプレフィックスをつけ、エンティティを区別することにより、IDの衝突がなくなる。 顧客：CUSTOMER#<CUSTOMERID> 従業員：EMPLOYEE#<EMPLOYEEID> 多対多のマッピングが存在する場合、2つのクエリパターンが必要となる。この場合、パーティションキーとソートキーという二つの値を使う複合プライマリキーを使用する。 SNSを例に挙げると、フォロー、フォロワーを管理しているエンティティは、フォローしているユーザを取得するアクセスパターンとフォローされているユーザを取得するアクセスパターンが存在する。 インデックスの置きかえ 置換インデックスは一般的なセカンダリインデックスのデザインパターンである。置換インデックスを使用して、テーブルのプライマリキーの逆であるセカンダリインデックスを作成する。 置換インデックスは 2 つのシナリオで役に立つ。 多対多関係の「反対側」をクエリする場合。 それ自体が一対多関係の対象であるエンティティの多対一関係をクエリする場合 非正規化 DynamoDB ではデータを非正規化することがよくある。非正規化は、結合を回避し、クエリのパフォーマンスを向上させるのに役立つ。非正規化を行うには、クエリ中に両方のアイテムをフェッチしないようにするために、アイテムの属性をそのアイテムを参照する別のアイテムにコピーする。 ただ、非正規化によってデータを持ちすぎるとデータモデルが複雑になる場合があるので注意が必要。 まとめ それぞれについてより詳しく知りたい場合には実際にハンズオンを行ってみてください。 手を動かしながら理解することができます。 また、以下にベストプラクティスが載っています。一度参照されると設計がより楽になると思います。

最近色々と忙しく、約1か月ぶりの投稿になります。 今回の内容は、Node.js（Express）で作成したAPIを、AWSのLambdaで環境構築を行うという内容です。 そこまで難しくは無いのですが、権限の部分で少し躓いたので、次回からは躓かないように記事を書いていきます。 はじめに まず初めに必要なパッケージをインストーしておきましょう！ npm i @vendia/serverless-express express ローカル環境構築 次に、以下のようにプロジェクト直下にファイルを作成していきましょう。 touch app.js server.js lambda.js app.js const express = require("express"); const app = express(); // ルーティングの設定 app.get("/", (req, res) => { return res.send("Hello"); }); // 他にルーティングなどの設定を行っていたらここに書いてください module.exports = app; server.js const app = require("./app"); const port = 3000; // HTTPサーバを起動する app.listen(port, () => { console.log(`listening at http://localhost:${port}`); }); lambda.js const serverlessExpress = require('@vendia/serverless-express') const app = require('./app') const server = serverlessExpress.createServer(app) exports.handler = (event, context) => serverlessExpress.proxy(server, event, context) このように設定したら、まずはローカルで動くかの検証をしてください。 node server ここで動かなかったらLambdaにアップロードしてもエラーが起きるので、今一度ご確認ください。 Lambdaへアップロード 権限 ここまできたらあとはデプロイすだけなのですが、人によっては権限のエラーの種類が違うと思うので、必要な権限を書いておきます。 ・AmazonS3FullAccess ・CloudWatchLogsFullAccess ・AmazonAPIGatewayAdministrator ・AWSCloudFormationFullAccess ・AWSLambda_FullAccess serverless.yml サーバーレスでデプロイするにはserverless.ymlを作成し、以下のように設定してください。 touch serverless.yml serverless.yml service: example provider: name: aws runtime: nodejs12.x region: ap-northeast-1 package: exclude: - .git/** - test/** - README.md functions: exampleFunction: handler: lambda.handler events: - http: ANY / - http: 'ANY {proxy+}' デプロイ npx serverless deploy EndpointのURIが表示されればOK 権限を追加してもエラーが出る場合 上の権限を追加してもエラーが出る場合以下の2つを試してください。 まず、エラー名にCreatRoleやPutRolePolicyの権限がありません的なエラーが発生した場合は「IAM」から今デプロイしようとしているユーザーを選択。 「アクセス権限」の「インラインポリシーの追加」をクリック。 「JSON」タブを選択し、以下のコードをコピペ。 { "Version": "2012-10-17", "Statement": [ { "Sid": "OperationRole", "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:PutRolePolicy" ], "Resource": "*" } ] } 「ポリシーの確認」をクリックし、名前は適当に入力。 デプロイする前に以下のコマンドを入力 npx serverless remove この時にエラーが起きたら、AWSコンソールから手動で消去してください。 npx serverless deploy AWSは権限周りが色々と面倒くさいですね。 でも権限にうるさいのは逆にありがたいことなのかも？？ こんな感じで実装することができました！ 以上、「【2021年6月最新版】ExpressをserverlessでAPI GatewaykaraLambdaを使ってWeb APIを使用する方法」でした！ Thank you for reading 参考記事 serverless-expressでAPI GatewayからLambdaを実行する

最近色々と忙しく、約1か月ぶりの投稿になります。 今回の内容は、Node.js（Express）で作成したAPIを、AWSのLambdaで環境構築を行うという内容です。 そこまで難しくは無いのですが、権限の部分で少し躓いたので、次回からは躓かないように記事を書いていきます。 はじめに まず初めに必要なパッケージをインストーしておきましょう！ npm i @vendia/serverless-express express ローカル環境構築 次に、以下のようにプロジェクト直下にファイルを作成していきましょう。 touch app.js server.js lambda.js app.js const express = require("express"); const app = express(); // ルーティングの設定 app.get("/", (req, res) => { return res.send("Hello"); }); // 他にルーティングなどの設定を行っていたらここに書いてください module.exports = app; server.js const app = require("./app"); const port = 3000; // HTTPサーバを起動する app.listen(port, () => { console.log(`listening at http://localhost:${port}`); }); lambda.js const serverlessExpress = require('@vendia/serverless-express') const app = require('./app') const server = serverlessExpress.createServer(app) exports.handler = (event, context) => serverlessExpress.proxy(server, event, context) このように設定したら、まずはローカルで動くかの検証をしてください。 node server ここで動かなかったらLambdaにアップロードしてもエラーが起きるので、今一度ご確認ください。 Lambdaへアップロード 権限 ここまできたらあとはデプロイすだけなのですが、人によっては権限のエラーの種類が違うと思うので、必要な権限を書いておきます。 ・AmazonS3FullAccess ・CloudWatchLogsFullAccess ・AmazonAPIGatewayAdministrator ・AWSCloudFormationFullAccess ・AWSLambda_FullAccess serverless.yml サーバーレスでデプロイするにはserverless.ymlを作成し、以下のように設定してください。 touch serverless.yml serverless.yml service: example provider: name: aws runtime: nodejs12.x region: ap-northeast-1 package: exclude: - .git/** - test/** - README.md functions: exampleFunction: handler: lambda.handler events: - http: ANY / - http: 'ANY {proxy+}' デプロイ npx serverless deploy EndpointのURIが表示されればOK 権限を追加してもエラーが出る場合 上の権限を追加してもエラーが出る場合以下の2つを試してください。 まず、エラー名にCreatRoleやPutRolePolicyの権限がありません的なエラーが発生した場合は「IAM」から今デプロイしようとしているユーザーを選択。 「アクセス権限」の「インラインポリシーの追加」をクリック。 「JSON」タブを選択し、以下のコードをコピペ。 { "Version": "2012-10-17", "Statement": [ { "Sid": "OperationRole", "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:PutRolePolicy" ], "Resource": "*" } ] } 「ポリシーの確認」をクリックし、名前は適当に入力。 デプロイする前に以下のコマンドを入力 npx serverless remove この時にエラーが起きたら、AWSコンソールから手動で消去してください。 npx serverless deploy AWSは権限周りが色々と面倒くさいですね。 でも権限にうるさいのは逆にありがたいことなのかも？？ こんな感じで実装することができました！ 以上、「【2021年6月最新版】ExpressをserverlessでAPI GatewaykaraLambdaを使ってWeb APIを使用する方法」でした！ Thank you for reading 参考記事 serverless-expressでAPI GatewayからLambdaを実行する

アカウント作成 AWS Educate(https://aws.amazon.com/jp/education/awseducate/) 登録にクレジットカード不要 オンライン動画などがある 以下理由のため個人アカウントと併用して使うのがオススメ． 共有アカウントの1ユーザー?的振る舞いで，制限されるサービスがあります 情報収集先 AWSに関する情報収集(日本語)は，日本の APN プレミアティアパートナーが発する情報がだいぶ正確です 中でもオススメは，DevelopersIOで知られるクラスメソットとサーバーワークスのブログです． クラスメソッド発「やってみた」系技術メディア | DevelopersIO サーバーワークスエンジニアブログ あまり知られていませんが，AWS公式ブログのbuilders.flashというのもあります(登録必要) https://aws.amazon.com/jp/builders-flash/?awsf.filter-name=*all 無料動画 (以下は学生向けというより，AWSの導入中や検討中の場合に見ることが多いのですが一応) 得体の知れないサービスの概観を掴みたいときはBlackBeltSeminarの動画がオススメ 資料が公開されている場合もあります． 【AWS Black Belt Online Seminar】 https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/ 【Amazon Web Services Japan 公式 YouTubeチャンネル】 https://www.youtube.com/channel/UCnjKWUK2t5QJYfeqqilhJhQ よくある質問の解決方法 [AWS ナレッジセンター] https://aws.amazon.com/jp/premiumsupport/knowledge-center/

環境 macOS: Big Sur Ver11.2.3 Rails: 6.1.1 Ruby: 2.6.5 インフラ：AWS(EC2) Webサーバ：Unicorn 困っていること AWSのEC2を使ってポートフォリオをデプロイし、さらにACMで証明書取得, Route53でドメイン取得後、SSL化まで行ったところ、Googleマップが表示されなくなった。 ブラウザのコンソールを確認すると「Google Maps JavaScript API error: InvalidKeyMapError」と表示されている。 したがって、APIキーをEC2上で設定できていないのではと推測。 解決方法 ①EC2にSSHで接続し、Vimを開く % cd .ssh % SSH接続のコマンド（ssh -i hoge.pem ec2-user@アプリのIPアドレス） 接続後、 [ec2-user@ip-172-31-0-160 ~]$ sudo vim /etc/environment ②環境変数を記述する 内容を変更するには「i」を押して編集モードにする。 変更し終わったら「esc」を押して編集モードを終了してから「:wq」で保存して終了すること。 export GOOGLE_MAPS_API_KEY='APIキーを貼り付け' ③設定できたか確認 一度EC2から抜けます。 [ec2-user@ip-172-31-0-160 ~]$ exit ログアウトしたらもう一度EC２にログインし、以下のコマンドを実行 [ec2-user@ip-172-31-0-160 ~]$ env | grep 環境変数の名前 これで設定した環境変数が表示されればきちんと設定できています。 ④Webサーバを一度ストップさせ、再起動させる 一度EC2を抜けて、ローカルのターミナル上でアプリケーションのフォルダに移動します。 以下のコマンドを実行し、Unicornをストップさせる。 % bundle exec cap -t production unicorn:stop 次に、もう一度EC2にSSH接続してログインし、アプリのフォルダに移動します。 Unicornの起動状況を確認するとmasterプロセスなどが起動されていないと思います。 [ec2-user@ip-172-31-0-160 take_out_app]$ ps aux | grep unicorn ec2-user 16164 0.0 0.0 119436 916 pts/0 S+ 03:05 0:00 grep --color=auto unicorn ここまで確認できたら、Unicornを再起動しましょう！ [ec2-user@ip-172-31-0-160 take_out_app]$ RAILS_SERVE_STATIC_FILES=1 unicorn_rails -c config/unicorn.rb -E production -D →特に何も表示はされませんが成功しています。 もう一度プロセスを確認！ masterとworkerという名前のプロセスが実行され、再起動できているのがわかります。 [ec2-user@ip-172-31-0-160 take_out_app]$ ps aux | grep unicorn ec2-user 16196 1.0 12.6 486816 127348 ? Sl 03:08 0:01 unicorn_rails master -c config/unicorn.rb -E production -D ec2-user 16204 0.3 12.3 488336 123972 ? Sl 03:08 0:00 unicorn_rails worker[0] -c config/unicorn.rb -E production -D ec2-user 16216 0.0 0.0 119436 948 pts/0 S+ 03:10 0:00 grep --color=auto unicorn これでブラウザでアプリケーションにアクセスしてみると、無事にGoogleマップが表示されていました！ おまけ（Vimから抜けるコマンドまとめ） ① :w → 作成・編集したファイルを保存 ② :q → vimをそのまま終了 ③ :q! → 編集した内容を保存しないでvimを終了 ④ :wq → 編集した内容を保存してvimを強制終了

コンテナイメージを用いたlambda 概要 2020/12からlambdaとしてECR上のコンテナイメージをデプロイできる 今までのzip形式との大きな違いはアーティファクトサイズ制限(250 MB -> 10 GB) ローカルでテストするのが簡単 (Lambda コンテナイメージをローカルでテストする) デプロイ方法 zipとコンテナイメージの両方を簡単な図で示すと以下のようになる。 lambda_flow.png terraformによるデプロイ terraformによりlambdaの作成のみを行い、作成後のイメージ管理は行わない。 この場合、github actions等を用いて、イメージのbuild, push, lambdaの更新までを行うと管理が楽になる。 resource "aws_lambda_function" "function" { function_name = "<Function name>" description = "<Description>" package_type = "Image" image_uri = "<Account id>.dkr.ecr.<Region>.amazonaws.com/<ECR>:<Tags>" timeout = <Timeout> lifecycle { ignore_changes = [image_uri] } role = <Role arn> } terraformでイメージ管理を行わない場合、イメージ更新の際はupdate-function-codeを用いると良い。 コマンド例は以下の通り。 aws lambda update-function-code --function-name "<Function name>" --image-uri "<Account id>.dkr.ecr.<Region>.amazonaws.com/<ECR>:<Tags>" 気づき パブリックイメージは使用できない パブリックイメージは使用できず、自アカウントのイメージを指定する必要がある。 このことに気づいたのは、ダミーとして適当なイメージを使おうとして、パブリックイメージが指定できなかったためである。 terraformによりイメージを管理しないと、lambda生成時にはダミーイメージを用いたら以下の二点が便利である。 簡素なmoduleが用意できる (必要な引数はfunction_name, description, roleで、あとはデフォルト値を設定) lambdaとecrを一度に作成できる (ダミーを使わない場合、lambdaを作る前にecrを作り、イメージをpushしておく必要がある) サクッとダミーイメージを用意する そこでダミーイメージを簡単に作れるようにした (yoshi65/lambda_hello_world_image)。 以下の手順で、ecrにdummy:latestが生成できる。事前に、認証情報は設定しておく必要がある。 git clone https://github.com/yoshi65/lambda_hello_world_image.git cd lambda_hello_world_image ./hello_world.sh もし消したくなったら、以下の通り。 sh ./hello_world.sh -d この生成に、terraformを使うか考えたけど、 ダミーイメージ自体はコンソールやcliから作る際にも活用できる ecrをterraformで作ったところで、結局イメージプッシュのためのスクリプトは必要 などにより、使わなかった (気が向いた時に追加するかも)。 update-function-code後、すぐinvokeできない lambdaを使用する際に、$LATESTを使わず、aliasを指定して、invokeすることは多い。 そこで、動作確認のためにinvokeし、正常終了を確認してから、aliasを更新しようとした。 その時、invokeにおいて $LATESTを指定すると前のバージョンが使われる update-function-codeでパブリッシュされたバージョンを使うとResourceConflictExceptionが生じる invokeできないわけ この理由としては、イメージの最適化が挙げられる。 コンソール上でイメージ更新を確認したことがあればわかると思うが、更新後すぐは更新中といった旨が上部に表示され、しばらくしたら完了の旨が表示される。 invokeするために 解決法としては、ステータスの更新を待てばいい。 以下のコマンドで解決する。 sh aws lambda wait function-updated --function-name "<Function name>" lambdaの更新、待機、起動をまとめると、 sh aws lambda update-function-code --function-name "<Function name>" --image-uri "<Image uri>" --publish aws lambda wait function-updated --function-name "<Function name>" aws lambda invoke --function-name "<Function name>":\$LATEST response.json 感想 好みはありそうだが、コンテナイメージの方がzipより使い勝手はよかった。 コンテナイメージで設定していることが多いため、lambdaを作る際に必要な設定が減る。 Ref. コンテナ利用者に捧げる AWS Lambda の新しい開発方式 ! New for AWS Lambda – Container Image Support Lambda コンテナイメージをローカルでテストする

はじめに クラウドネイティブを勉強する際には避けては通れないのはKubernetes。そしてKubernetesを学ぶ上で避けては通れないのがDockerです。 しかし、Kubernetesを勉強する上で全てのdockerの知識が必要かと問われるとそうではありません。 この記事ではKubernetesを扱う上で必要最低限知っておきたい知識をまとめました。 この記事が次のステップKubernetesの世界への第一歩となれば幸いです。 また、この記事は日本のKubernetesの第一人者であるサイバーエージェントの青山さんが執筆しているKubernetes完全ガイドという非常に有名な本を参考にして書きました。 Kubernetes勉強本の中では1番メジャーです。 本格的に勉強していく方は早い段階で手に取っておくことをお勧めします。 Dockerとは Dockerとはコンテナを実行するための実行環境（コンテナランタイム）およびツールキットのこと。 今回の最終ゴールはKubeflowへの理解なので、Kubernetesを利用する際に必要なDockerの機能のみに焦点を絞ることにする。 Kubernetesを利用する際に知っていた方がいい知識は以下の通りです。 Dockerコンテナの設計 Dockerfileの書き方 Dockerイメージのビルド Dockerレジストリへのイメージのプッシュ Dockerコンテナとは DockerコンテナはDockerイメージカラ実行されるプロセスです。 Dockerイメージさえあれば様々な環境で起動可能なことからポータビリティ、再利用性が高いという特徴があります。また、dockerコンテナは仮想マシンに比べて軽量で高速です。これは仮想マシンがハイパーバイザーを利用してゲストOSを起動させるのに対し、Dockerはホストマシンのカーネルを利用するような作りになっているため、OSの起動時間を待つ必要がなくなるからです。 Dockerコンテナの設計 Dockerコンテナを作成する際に気をつけなければならない点が4つあります。 １コンテナにつき１プロセス Immutable Infrastructureなイメージにする 軽量なDockerイメージにする 実行ユーザをRoot以外にする この中で最も大切なのは「１コンテナにつき１プロセス」のみを起動するように作成することです。なぜなら、Dockerコンテナが1つのアプリケーションを実行するという思想のもと作られているので、この思想に反して複数のプロセスをイメージに組み込んでしまうと周辺のエコシステムとの相性が悪くなったり管理性が低くなったりしてしまいます。 次に大切なこととして、Immutable Infrastructureを実現するイメージにすることです。 これは、「環境を変更する際は古い環境は捨て新たに作る」、「1度作られた環境は変更されないことを徹底する」ということを意味します。前者はKubernatesでは自動で再生成されるので意識する必要はないですが、後者は開発者が意識してイメージの設計をしなければなりません。例えば、コンテナを起動後にパッケージをインストールしたりすると、外部の要因によってそのコンテナイメージの実行結果に変化が生じてしまいます。DockerコンテナではDockerfileでバージョン管理ができるため、アプリケーションの実行バイナリや関連リソースは可能な限りDockerイメージ内に埋め込むことがベストプラクティスです。 3番目にDockerイメージをなるべく軽量に保つことです。コンテナ実行時にノード上に使用するDockerイメージをpullして取得する必要があるため、Dockerイメージはなるべく軽量にすることでDockerを使う利点である軽量で高速な起動を最大限に生かすことができます。すぐにできる処置としてはdnf/yumやaptなどでパッケージをインストールした後のキャッシュファイルの削除などです。そのほか、ベースイメージが軽量なイメージを使うことも考えられます。極めていくと、Dockerfileの最適化やsquashなどで軽量化が可能ですが、今回の趣旨から大きくズレるため本記事では省略します。 最後にコンテナ内でプロセスを起動する実行ユーザの権限を最小化することです。 これはLinux運用でも同じですが、Rootユーザの利用はセキュリティ的なリスクが高いので極力控えた方がいいでしょう。 Dockerfileの書き方 DockerイメージはDockerfileを元にビルドされます。Dockerfileというのは以下のようの形式で記述する作成手順書のようなもの。 # どのイメージを基にするか FROM centos # 作成したユーザの情報 LABEL maintainer="Admin <admin@admin.com>" # RUN: docker buildするときに実行される RUN echo "now building..." # CMD: docker runするときに実行される CMD echo "now running..." Dockerfileの基本的な流れとしては、FROMで指定したベースイメージに対してRUNやCOPYなどを用いてパッケージのインストールなどの様々な処理を行いイメージを作成します。 RUNはDockerfileでおそらく最もよく使う命令です。RUN命令はビルド時に実行する命令で、yumやaptコマンドによるパッケージのインストールなどビルド時に必要なコマンドを実行するために用いられます。 それに対して、ENTRYPOINTとCMDはコンテナ起動時に実行するデフフォルトのコマンドを指定するために用います。例えば、ENTRYPOINT=/bin/echo, CMD='Hello'であるとすると、/bin/echo 'hello'が実行されます。要するに、$ENTRYPOINT $CMDが実行されるという認識で問題なさそうです。 そのほかコマンドを実行する作業ディレクトリを指定するWORKDIRやコンテナ起動時のListenポートを指定するEXPOSEなどありますがここでは割愛します。 Dockerイメージのビルド dockerイメージをビルドするコマンドはdocker image buildです。 カレントディレクトリにあるsample:0.1というイメージをビルドする際には、 docker image build -t sampel:0.1 . とします。-tオプションではイメージの名前の指定とタグの指定が行えます。 マルチステージビルド Dockerコンテナの作成に際して注意しなければならないポイントの1つとして”軽量なイメージにする”とありました。マルチステージビルドは複数のコンテナを用いてビルドするコンテナと実行するコンテナを分けることで実行コンテナのイメージサイズを減らす手法です。 以下の例はマルチステージを用いない場合のDockerfileです。 FROM node:lts-alpine WORKDIR /app COPY . ./ RUN npm install -g http-server && \ npm install && \ npm run build EXPOSE 8080 CMD [ "http-server", "dist" ] マルチステージビルドを用いると以下のようになります。 --fileタグを用いてビルド用コンテナから必要なファイルのみを取得することでコンテナのイメージサイズを減らすことができます。 FROM node:lts-alpine AS build-stage WORKDIR /app COPY . ./ RUN npm install && \ npm run build #実行コンテナ FROM nginx:stable-alpine AS production-stage # --fromタグを用いてビルドコンテナから必要なファイルのみをコピーする COPY --from=build-stage /app/dist /usr/share/nginx/html EXPOSE 80 CMD [ "nginx", "-g", "daemon off;" ] Dockerレジストリ DockerレジストリはDockerイメージを保存しておくリポジトリサーバです。 Docker HubやGoogle Container Registry、Amazon ECRなどが有名です。 Docker Hubでは公開されているDockerイメージが置かれています。その中には、「公式イメージ」と「有志が作成した非公式なイメージ」があるため、利用の際には信頼できるイメージなのかどうか注意する必要があります。 基本的には「公式イメージ」を使うことがベストプラクティスです。 しかし、公式の中にもセキュリティアップデートのされていないイメージが含まれていることがあり得ます。 実運用に際してはコンテナのセキュリティスキャンツールを利用することを検討しましょう。 Docker Hubへのプッシュ Docker Hubへのプッシュではまず最初にDockerレジストリへログインする必要があります。以下のコマンドでログインできます。 docker login ユーザ名とパスワードが要求されるのでそれぞれDocker Hubのアカウントのものを入力（なければDocker Hubのページで作成）。 以下のコマンドでプッシュできます。ユーザ名とDockerイメージ名は適切なものを指定してください。 # イメージのタグを付け替える docker image tag sample:0.1 DOCKERHUB_USERNAME/sample:0.1 docker image push DOCKERHUB_USERNAME/sample:0.1 以上でDocker HubのWebページで公開されていることが確認できると思います。 タグ付けについては以下の図が非常にわかりやすいです。 Dockerイメージのタグ付けについては以下のサイトにわかりやすくまとめてありました。 （図もこちらのものを参照しています。） 終わりに 以上でKubernetesを扱う上での最低限のdockerの知識は紹介できました。 Docker自体はまだまだ奥が深く、ここでは紹介しきれない知識がありますが、必要に応じて身につけていきたいですね。

はじめに 概要 ParallelClusterではクライアントPC上にクラスタ作成の設定等を行う環境を作成し，クラスタの作成を行う．クラスタを作成するとEC2の新しいインスタンスとしてMasterノードが作成される．Masterノードでジョブを実行すると，ジョブの規模に合わせてSlaveノードが作成されジョブが実行される． ここではクライアントPC（ParallelClusterのインストール先）にもローカルPCではなくAWSのインスタンスを使用しました．ちなみに，ローカルPC（上記のクライアントPCへの接続元）の環境はmacOS Catalinaです． つまり，（ローカルPC：mac）→（クライアントPC：EC2）→（クラスタ：Masterノード，Slaveノード）のような関係です． この記事ではクラスタの作成（Masterノードの作成）を行うところまでをまとめておきます． クライアントPCとしてのEC2インスタンス作成 インスタンスの作成 お試しなので一番小さいt2.nano(micro)を選択する． また，セキュリティグループの設定では自宅のPCから接続できるように公開範囲（ソース）をマイIPとしておく．またssh接続のためにキーペアを作成しておき，公開鍵をダウンロードし~/.ssh/keysにでもコピーしておく． インスタンスへ接続 macの場合terminalから接続できる． パブリックIPv4アドレス（またはパブリックIPv4 DNS）を確認し，公開鍵を指定してssh接続する． Ubuntuの場合，初期ユーザ名はubuntuである． Red Hat系の場合，初期ユーザ名はec2-userである terminal ssh ec2-user@ec2-18-181-84-119.ap-northeast-1.compute.amazonaws.com -i ~/.ssh/keys/20210520_keypair.pem 環境構築 rootユーザのパスワードを変更する sudo su - passwd パッケージ用リポジトリの追加 sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y sudo yum -y install epel-release python および pipのインストール なぜかpython3.7はリポジトリにないと言われたので3.8にした． curlコマンドでpipをインストールするためのスクリプトを入手し実行． yum install python38 curl -O https://bootstrap.pypa.io/get-pip.py python3 get-pip.py --user When you use the --user switch, pip installs AWS ParallelCluster to ~/.local/bin. とのことで，パスを追加しておく． ~/.bash_profile export PATH=~/.local/bin:$PATH リロード source ~/.bash_profile ParallelClusterのインストールと設定 ようやくparallel clusterをインストール． python3 -m pip install aws-parallelcluster --upgrade --user parallel clusterの設定をしようとpcluster configureとすると次のように怒られた． [root@ip-xxx-xx-xx-xxx ~]# pcluster configure ERROR: You must specify a region Run `aws configure`, or add the `-r <REGION_NAME>` arg to the command you are trying to run, or set the `AWS_DEFAULT_REGION` environment variable. INFO: Configuration file /root/.parallelcluster/config will be written. Press CTRL-C to interrupt the procedure. Failed with error: You must specify a region. ERROR: No options found for AWS Region ID AWS CLIを使用するためのIAMユーザの作成 pcluster configureで怒られたメッセージを読むと，You must specify a region.とある．regionの設定はAWS CLI（AWSのコマンドラインツール）を使用して行う必要があるが， そのためには適切なアクセス権限（ポリシー）を持ったIAMユーザーが必要みたいです． ので，以下のサイトを参考にIAMユーザを作成しました awscliをインストール pip install awscli　 AWS CLIを使用する権限を持ったIAMユーザの作成 マネジメントコンソールからIAMユーザを新規作成する． アクセスの種類はとりあえず「プログラムによるアクセス」と「AWSマネジメントコンソールへのアクセス」の両方をONにしておいたけど，後者はいらない気がする． 次に作成したIAMユーザにグループポリシーを適用する． ここでは新しくEC2-userというグループを作成し， AmazonEC2FullAccess PowerUserAccess の２つのポリシーを追加した． 参考サイトには２つ目しか載っていなかったので１つ目はいらないかも． 後ほど説明するが，この設定ではclusterの作成時に権限が足りなくてエラーが出た． エラーを解消するにはAdministratorAccessのポリシーを追加する必要があった． また，PowerUserAccessはいらなかった． ユーザの作成を完了し，最終画面でアクセスキーやシークレットアクセスキーをメモるか，.csvをダウンロードしておく． AWS CLIの設定 aws configureを実行しAWS CLIの環境設定を行う． [root@ip-xxx-xx-xx-xxx ~]# aws configure AWS Access Key ID [None]: # 先程作成したユーザのAccess Key AWS Secret Access Key [None]: # 先程作成したユーザのsecret Access Key Default region name [None]: # リージョンを選択します。東京の場合は「ap-northeast-1」となります。 Default output format [None]: # jsonやtable等のコマンド出力結果の表示形式を指定します。ここではjsonを入力します。 Parallel Clusterのセットアップ AWS CLIの設定ができたので，再度Parallel Clusterの設定にチャレンジします． 今度はエラーなく実行できました． 参考サイト [root@ip-172-31-44-147 ~]# pcluster configure INFO: Configuration file /root/.parallelcluster/config will be written. Press CTRL-C to interrupt the procedure. Allowed values for AWS Region ID: 1. ap-northeast-1 2. ap-northeast-2 ~中略~ 16. us-west-2 AWS Region ID [ap-northeast-1]: Allowed values for EC2 Key Pair Name: 1. hoge_keypair # キーペアを選ぶ EC2 Key Pair Name [20210520_keypair]: Allowed values for Scheduler: 1. sge 2. torque 3. slurm #　これにした 4. awsbatch Scheduler [slurm]: slurm Allowed values for Operating System: 1. alinux 2. alinux2 3. centos7 # これにした 4. centos8 5. ubuntu1604 6. ubuntu1804 Operating System [alinux2]: centos7 Minimum cluster size (instances) [0]: 0 Maximum cluster size (instances) [10]: 2 Head node instance type [t2.micro]: Compute instance type [t2.micro]: Automate VPC creation? (y/n) [n]: y Allowed values for Network Configuration: 1. Head node in a public subnet and compute fleet in a private subnet 2. Head node and compute fleet in the same public subnet Network Configuration [Head node in a public subnet and compute fleet in a private subnet]: Beginning VPC creation. Please do not leave the terminal until the creation is finalized Creating CloudFormation stack... Do not leave the terminal until the process has finished Stack Name: parallelclusternetworking-pubpriv-20210526144159 Status: parallelclusternetworking-pubpriv-20210526144159 - CREATE_COMPLETE The stack has been created Configuration file written to /root/.parallelcluster/config You can edit your configuration file or simply run 'pcluster create -c /root/.parallelcluster/config cluster-name' to create your cluster [root@ip-172-31-44-147 ~]# 設定した内容はcat ~/.parallelcluster/configで確認することができる． Clusterの起動 cluster create <cluster name>でクラスタを作成できる． が，エラーが起こった． pcluster create mycluster Beginning cluster creation for cluster: mycluster Creating stack named: parallelcluster-mycluster Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS Cluster creation failed. Failed events: - AWS::EC2::SecurityGroup MasterSecurityGroup Resource creation cancelled - AWS::CloudFormation::Stack CloudWatchLogsSubstack Resource creation cancelled - AWS::CloudFormation::Stack EBSCfnStack Resource creation cancelled - AWS::IAM::Role RootRole API: iam:CreateRole User: arn:aws:iam::263374027013:user/ryu is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::263374027013:role/parallelcluster-mycluster-RootRole-1L9URXAMCS519 - AWS::IAM::Role CleanupResourcesFunctionExecutionRole API: iam:CreateRole User: arn:aws:iam::263374027013:user/ryu is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::263374027013:role/parallelcluster-mycluster-CleanupResourcesFunction-1DC1FOLRTY4YT どうも，IAMユーザのpermmisionがうまく設定できていないみたいだ． Default settings for cluster creation When you use the default settings for cluster creation, an IAM role for Amazon EC2 is created by the cluster. The user that creates the cluster must have the right level of permissions to create all of the resources required to launch the cluster. This includes an IAM role for Amazon EC2. Typically, the IAM user must have the permissions of an AdministratorAccess managed policy. For information about managed policies, see AWS managed policies in the IAM User Guide. 公式ぺーじ（２つ目のサイト）にこのような記載してあったので，設定していたIAMユーザにAdministratorAccessの権限を付与した． また，PowerUserAccessはいらなさそうなので消しておいた． 気を取り直して再度pcluster create mycluster pcluster create mycluster Beginning cluster creation for cluster: mycluster Creating stack named: parallelcluster-mycluster Status: MasterServerSubstack - CREATE_IN_PROGRESS Status: parallelcluster-mycluster - CREATE_COMPLETE ClusterUser: centos MasterPrivateIP: 10.0.0.91 すると今度はうまく作成できた． EC2のインスタンス一覧にはMasterという名前のインスタンスが作成されていた． スクリーンショット 2021-06-03 0.11.07 クラスタ（Master）にログインする． クラスタに入るための秘密鍵を用いてクラスタにログインする． pcluster ssh mycluster -i ~/.ssh/keys/<your key name>.pem The authenticity of host '176.34.3.56 (176.34.3.56)' can't be established. ECDSA key fingerprint is SHA256:EmNrdPAjWDncAWivlXvmrqOejzH4sQxV8swpN5VwGfc. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '176.34.3.56' (ECDSA) to the list of known hosts. Last login: Wed Jun 2 15:06:51 2021 squeueなど実行してみるとslurmのmasterノードであることを確認できる． （おまけ）Parallel Clusterの各コマンド pcluster list # 一覧を表示 pcluster delete <cluster name> # 削除 おわりに 今回はクラスタ（Masterノード）の作成まででした． 次回はクラスタを用いてジョブを実行してみたいと思います． P.S. 会社でもこれがつかえたらめちゃくちゃ便利だなあ．．．