20210611のAWSに関する記事は20件です。

Amazon LightSailを使ってLAMP環境(Laravel)を構築する

AWSマネジメントコンソールでの作業 LightSailの画面を開く AWSマネジメントコンソールにアクセスしてLightSailを開きます。 インスタンス作成画面を開く 初めてLightSailの画面を開いたらインスタンスを作成する画面が開くと思いますが、もし開いていない場合はインスタンスの作成ボタンを押して画面を開きます インスタンスロケーションを選択する 特に指定がなければデフォルトで大丈夫です。 インスタンスイメージを選択する プラットフォームの選択 linux/Unixを選択します。 設計図の選択 「アプリ + OS」にある「LAMP(PHP7)」を選択します。 インスタンスプランの選択 料金プランを選択します。今回は一番安い$3.5を選択します。 リソース名を入力する リソース名は初期設定だと「LAMP_PHP_7-1」みたいな名前になっていると思います。 試しで環境を作る場合は何でもいいですが、後から変更ができません。 そのため、わかりやすくアプリ名などをつける方がオススメです。 今回は「sample_app」で作成します。 キーオンリータグやキー値タグは、初回では何も入力する必要がありません。 必要であれば後からでも設定可能です。 インスタンス作成ボタンを押す インスタンス作成ボタンを押すとインスタンスが作成されます。 ※ボタンを押すと確認画面を挟まずに即作成されるので注意してください。 作成されるとLightSailのホーム画面に遷移して、インスタンスが作成されているのがわかります。 SSHでインスタンスに接続できるようにする LightSailのコンソール画面からもブラウザ上でSSH接続できるので、「SSHを使用して接続」ボタンを押して下さい。 また自分のSSHクライアントなどを使いたい場合は後述する手順をお試しください。 ↓↓↓↓↓以下は独自クライアントを使いたい人向け↓↓↓↓↓ 独自のSSHクライアントで接続するための情報を取得する 先程作成したインスタンスの名前をクリックして、インスタンスの画面を開きます。 インスタンスの画面を下にスクロールしていくと接続するために必要な情報があります。 ここではIPアドレス、ユーザー名(おそらくほぼ「bitnami」)を控えておき、 またプライベートキーをダウンロードできるリンクがありますので、まだしていない人はダウンロードしておきます。 (ダウンロードすると「LightsailDefaultKey-ap-northeast-1.pem」みたいな名前のファイルがダウンロードできます) ダウンロードしたキーを配置する ※もし初めてプライベートキーをダウンロードして.sshディレクトリなどに配置してください。 (windowsだとほぼ「C:\Users\ユーザー名\ .ssh」だと思います) ターミナルを開き、SSHで接続できるか確認します。 LightSailの画面で控えたおいてIPアドレスやユーザー名を入れて接続してみます。 $ ssh -i C:\Users\ユーザー名\.ssh ユーザ名@ipアドレス 接続できれば以下のような画面が表示されます。 アプリ環境(Laravel)の構築 DBのパスワードを控える アプリケーションとDB接続するためのパスワードが記載されているファイルがあるので、確認します。 $ less /home/bitnami/bitnami_credentials ↓赤色の部分に記載されています。 【補足】 同じ階層に下記のファイルもありますが、記載しているパスワードは一緒です。 /home/bitnami/bitnami_application_password アプリをインストールする場所へ移動 アプリをインストールする場所へ移動します $ cd /opt/bitnami/apache2/htdocs/ Laravelアプリをインストール ※新規のLaravelを構築する場合 LightSail上に新規でLaravelを構築する場合の手順は以下 ---例としてsample_appというアプリ名のLaravelを作る場合 インストールするディレクトリへ移動 $ cd /opt/bitnami/apache2/htdocs laravelをインストールします。(今回は例としてLaravel6を指定してインストールしてみます) $ composer create-project --prefer-dist laravel/laravel sample_app "6.*" composer installを行う $composer install ※gitのソースを持ってくる場合の手順は以下 gitでソースを持ってくる $ git clone ソースのURL git cloneしたソースへ移動 $cd /opt/bitnami/apache2/htdocs/git cloneしたソースのディレクトリ composer installを行う $composer install 【補足】 ※一番安いプランだとメモリが少なくてcomposer installがコケる場合もあるので、何回か試すか難しい場合はプランを上げましょう ドキュメントルートの変更 アプリ用のドキュメントルートを設定します。 デフォルトは/opt/bitnami/apache2/htdocsになっているので変更する必要があります。 bitnami.confを開きます $ vi /opt/bitnami/apache2/conf/bitnami/bitnami.conf bitnami.conf キーボードの「i」を押してINSERTモードにして -- DocumentRoot "/opt/bitnami/apache2/htdocs" <Directory "/opt/bitnami/apache2/htdocs"> -- ↓↓↓↓例えば下記のように変更します↓↓↓↓ -- DocumentRoot "/opt/bitnami/apache2/htdocs/sample_app/public" <Directory "/opt/bitnami/apache2/htdocs/sample_app/public"> -- 終わったら「:wq」で保存する。間違ったら「:q!」でキャンセルして抜ける WEBサーバーの再起動 ドキュメントルートの設定を変更したのでApacheを再起動して再読み込みさせます。 $ sudo /opt/bitnami/ctlscript.sh restart apache Restarted apacheとなっていればOK storageの権限を変更 Laravelの場合、権限を変更しておきます。 $ chmod 777 -R storage/ DBの作成 DBの作成をします。 $ mysql -u root -p Enter password: bitnami_credentialsに書いてあるパスワードを入力 ---今回は例としてsample_dbという名前で作ります。 mysql > create database sample_db; 終わったらexitで抜ける envファイルの作成 新規でLaravel作った場合はenv.exampleをcpコマンドでコピーします。 gitクローンした人も忘れずenvファイルを作成します コピーして.envファイルを作成 $ cp .env.example .env envファイルにDBとの接続情報を入力する DB_CONNECTION=mysql DB_HOST=localhost DB_PORT=3306 DB_DATABASE=sample_db DB_USERNAME=root DB_PASSWORD=[bitnami_credentialsに書いてあるパスワードを入力] キー作成コマンドを入力します。 $ php artisan key:generate マイグレーションしてDBにテーブルを作成します。 $ php artisan migrate 【補足】 migrateやseederを動かした場合に、たまにうまくファイルが読み込めずエラーになる場合があります。 その場合はcomposer dump-autoloadコマンドを流すと解決する場合があります。 アプリに接続してみる ブラウザからインスタンスの画面で控えていたIPアドレスを叩いてつながるか確認して、接続できればOK まとめ Light Sailを使うとかんたんにLAMP環境を作ることができます。 しかも一番安いプランだとかなりお得な価格なので、簡単なデプロイ環境を作りたい場合はぜひお試し下さい。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS FSx for Lustre S3レプリケーションオブジェクトをインポートできない

初めに なぜインポートできないのか理由はわかりません。原因をご存知の方がいらっしゃいましたらご教示頂けますと幸いです。 やってみた Lustreのストレージ構造は、MDT(Meta Data Target) と OST(Object Storage Target) という2つの構造を持っています。MDT はファイルのメタデータを格納し、OST は実データを格納します。 以下の released exists archived となっている状態のファイルは、S3 から透過的に表示されたファイルであることを意味しています。つまりメタデータのみ Lustre に格納され、実データは Lustre にはありません。 実データを Lustre にインポートする方法は2つあります。 ファイルにアクセスする lfs hsm_restore というコマンドを実行する $ sudo lfs hsm_state /mnt/fsx/* /mnt/fsx/sample.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_2.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_3.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_4.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_5.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_6.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload.txt: (0x0000000d) released exists archived, archive_id:1 1 の方法を実行してみます。 $ cat /mnt/fsx/test_upload.txt test upload 再度ファイルの状態を確認してみます。test_upload.txt のみ、exists archived という状態に移行しました。これは Lustre に実データが格納されたことを意味します。 /mnt/fsx/sample.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_2.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_3.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_4.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_5.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_6.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload.txt: (0x00000009) exists archived, archive_id:1 次に 2 の方法を実行してみます。 $ sudo lfs hsm_restore /mnt/fsx/sample.txt 標準出力はありませんが、samle.txt の状態が exists archived に移行しました。 $ sudo lfs hsm_state /mnt/fsx/* /mnt/fsx/sample.txt: (0x00000009) exists archived, archive_id:1 /mnt/fsx/test_upload_2.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_3.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_4.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_5.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_6.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload.txt: (0x00000009) exists archived, archive_id:1 次にレプリケートされたオブジェクトをインポートしてみます。cat でファイルにアクセスすれば(方法 1)、上記のようにファイルの中身を見ることができるはずです。 $ cat /mnt/fsx/test_upload_2.txt cat: /mnt/fsx/test_upload_2.txt: No data available ファイルにアクセスできませんでした。次に 2 方法を実行してみます。 $ sudo lfs hsm_restore /mnt/fsx/test_upload_2.txt 再度状態を確認してみます。lfs hsm_restore を実行しても依然として test_upload_2.txt は released exists archived のままです。インポートができませんでした。 $ sudo lfs hsm_state /mnt/fsx/* /mnt/fsx/sample.txt: (0x00000009) exists archived, archive_id:1 /mnt/fsx/test_upload_2.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_3.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_4.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_5.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload_6.txt: (0x0000000d) released exists archived, archive_id:1 /mnt/fsx/test_upload.txt: (0x00000009) exists archived, archive_id:1 レプリケートされたオブジェクトを直接ダウンロードし、/mnt/fsx にコピーすることは可能です。しかし通常のコピーでは No data available が表示されます。 $ sudo cp test_upload_2.txt /mnt/fsx/ cp: cannot create regular file ‘/mnt/fsx/test_upload_2.txt’: No data available -f オプションを付けるとコピーすることができます。 $ sudo cp -f test_upload_2.txt /mnt/fsx/ 参考記事
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CloudFrontを導入してからブラウザ再読込しないとトップページを表示できなくなった話

ブラウザ再読込をすると表示できるのですが、こういったエラーが出てトップページを表示できなくなってしまいました。 エラーメッセージが示す余分な「<」が問題というより、今回の場合問題箇所のmain.jsはどうやら古いキャッシュのようで、ブラウザ再読込するとこのmain.jsが更新されエラーが消えるというなんとも嫌な状態です。 解決策としては、cloudfrontのBehaviorタブからMinimum TTL・Maximum TTL・Default TTLを0にすることで解決しました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Data Replication Hub を使ってみました

AWS Data Replication Hub とは AWS中国が提供しているデータ転送のためのツールです。 このツールは以下のシーンでの利用を想定しています。 AWS中国リージョン~(中国以外の)AWSグローバルリージョン間のS3のデータ転送 AWS以外のクラウドサービスのオブジェクトストレージ1からS3へのデータ転送 AWS中国リージョン~(中国以外の)AWSグローバルリージョン間のECRイメージの転送 AWS以外のクラウドサービスのパブリックコンテナレジストリからAmazon ECRへのコンテナイメージの転送 中国以外からAWS中国リージョンへデータ転送するときには、ケースによってはインターネットを利用することがあるかと思います。中国~海外間のインターネット通信は、様々な理由により、通信品質が良くなくデータ転送に非常に時間を要することがあります。 本ツールを使用することで、例えば、対象データをAWS東京のS3へ配置するだけで、自動でAWS中国へセキュア且つ、効率良く2転送します。 本ツールは、サーバレス構成でありCloudFormationやCDKで構築できるようになっています。 データ転送元・先のAWSアカウントは、同じ・異なる の両方に対応しています。 構成 本ツールは、専用のWebポータルを用意しています。構成図は以下となります。 ※aws-data-replication-hubより 専用のWebポータルを通じて転送設定を行います。 S3データ転送とコンテナイメージ転送は、それぞれプラグインとして用意されています。構成図は以下となります。 S3 Plugin ※amazon-s3-data-replication-hub-pluginより 「Source Bucket」へデータを配置すると、「Amazon S3(Destination)」へ転送されます。 S3 Plugin ※amazon-ecr-data-replication-hub-pluginより 前提 今回は、S3のデータ転送を行ってみました。 諸々の事情でAWS中国アカウントが利用できないため、グローバルのAWSアカウントを使用します。 Aアカウントの「バージニアリージョン」からBアカウントの「東京リージョン」へのデータ転送とします。 構築 aws-data-replication-hubの「Deploy via CloudFormation」に従って構築します。 AWS中国リージョンへ構築する場合は、以降の手順の前に、中国ルールに従った手順が追加で必要となります。詳しくはこちら参照。 Webポータルの構築 データ転送先のBアカウントを使用してマネージメントコンソールへサインインします。 サインイン後、aws-data-replication-hubの「Deploy via CloudFormation」の「Launch Stack」をクリックします。 [スタックの作成]が表示するため、以下の手順で進めます。 ステップ 1 テンプレートの指定 デフォルトのまま[次へ]をクリック ステップ 2 スタックの詳細を指定 [パラメータ]-[User Pool]-[AdminEmail]へWebポータルの管理者のメールアドレスを入力 ※本メールアドレスがWebポータルログイン時のユーザ名となります。パスワードはツール側で自動作成され、本メールアドレス宛に通知がされます。 ステップ 3 スタックオプションの設定 デフォルトのまま[次へ]をクリック ステップ 4 レビュー ページ最後の[The following resource(s) require capabilities: [AWS::IAM::Role]]へチェックを入れ、[スタックの作成]をクリック しばらくすると、上記で入力したメールアドレス宛にパスワードが届きますので、控えておきます。 スタックの作成が完了した後、[出力]-[PortalUrl]の文字列をコピーし、ブラウザのアドレス欄へペーストし、ポータル画面を開きます。 メールアドレス・パスワードを入力しサインインします。 新しいパスワードを入力します。 [Account recovery requires verified contact information]は[Skip]をクリックします。 以下画面が表示します。 クレデンシャルの作成 BアカウントからAアカウント上のS3へアクセスするために必要なクレデンシャルを作成します。 Aアカウントにて、IAMユーザを作成し、アクセスキー/シークレットアクセスキーを作成します。IAMユーザの権限は、AアカウントのS3バケットに対する読み取り以上 とします。 Bアカウントにて、[Systems Manager]の[パラメータストア]へアクセスし、パラメータを作成します。 作成時のポイントは以下の通りです。 タイプ: [安全な文字列]とします。[KMS キーソース][KMSキーID]はデフォルトで問題ありません。 値:以下の形式で入力します。各キーは、Aアカウントで作成したIAMユーザの情報となります。 { "access_key_id": "xxxxxxxxxxxxxxx", "secret_access_key": "xxxxxxxxxxxxxxx" } レプリケーションタスクの作成&動作確認 S3データ転送用のタスクを作成します。 [Create Replication Task]から[Amazon S3]を選択し[Next Step]をクリックします。 [Engine options]は[Amazon S3]を選択し、[Next Step]をクリックします。 [Source Type]は[Amazon S3]を選択します。 [Source settings]は転送元の(本アカウント若しくは別アカウント上の)S3の指定となります。以下とします。 Bucket Name: バケット名を入力 Bucket Object Prefix- optional: バケット内から特定オブジェクトのみを転送したい場合に入力します。 Is Bucket in this account?: 同じAWSアカウント上のS3を扱う場合は[Yes]とします。今回は[No]とします。 Credentials Store: [クレデンシャルの作成]で作成したパラメータストアを選択します。 Region Name:今回は[N.Virginia(us-east-1)]を選択します。 [Destination settings]は転送先の(本アカウント上の)S3の指定となります。以下とします。 Bucket Name: バケット名を入力 Bucket Object Prefix- optional: バケット内から特定オブジェクトのみを転送したい場合に入力します。 Storage Class: 保存後のストレージクラスの指定となります。[Standard/Standard-IA/One Zone-IA/Intelligent-Tiering]を選択できます。今回は[Standard]とします。 [Advanced Options]はLambdaのリソース(メモリ等)の設定となります。今回はデフォルトとします。 [More]の[Alarm Email]は、エラー発生時の通知先のメールアドレスとなります。 本ツールでは転送に失敗すると、SQS(キュー)に保管し再度リトライを行います。複数回失敗するとDLQ(Dead Letter Queue)へ送られ、結果エラーとして通知が行われるようです。 最後に[Next Step]をクリックします。設定一覧が表示するため問題無ければ[Create Task]をクリックします。 タスクが作成し、自動で構築&転送が開始します。 構築については、裏でCloudFormationにてS3 Pluginのスタック作成が行われます。 [Status]が[In Progress]になると構築が完了し、データ転送が継続して行われる状態になります。 以降、AアカウントのS3へファイルを新規に配置すると、自動3でBアカウントのS3へ転送されるようになります。 転送を止めるには該当タスクを選択した上で[Task Action]-[Stop]をクリックします。Stopが成功すると[Status]が[Stopped]となります。なお、この時にタスク用のCloudFormationスタックの削除が行われるようです。 また、既存のタスクを複製[Clone Task]することもできます。 CloudWatch Metricsにも対応しており、以下のように転送に関する各種メトリクスを確認することができます。 まとめ 本ツールを使用することで、簡単に環境構築とデータ転送を行うことができました。(中国以外の)AWSグローバル間のデータ転送は「S3 クロスリージョン​レプリケーション」等の機能があるため、本ツールを使用することは殆ど無いと思います。一方、対AWS中国とのデータ転送は上記機能に対応していないため、本ツールを利用することで、効率的にデータ転送ができるようになると思います。 本環境の削除 [専用Webポータルの構築]にて作成したCloudFormationスタック(DataReplicationHub)を削除します。 参考 Data Replication Hub - Amazon Web Services Solutions GitHub - awslabs-aws-data-replication-hub- Seamless User Interface for replicating data into AWS- EP34 - AWS Data Replication Hub(ft. Joe Shi) - 4K2160P - YouTube Alibaba Cloud OSS, Tencent COS, Qiniu Kodo ↩ マルチパートアップロードを使用 ↩ デフォルトで1時間毎の転送となります。BアカウントのCloudWatch Ruleに[DRH-S3-xxxx]というルールがあるため、そのルールのスケジュールを修正することで間隔を変更することができます。データ転送元・先が同じアカウントの場合は、S3 Event機能によりオブジェクトの作成・削除のタイミングで転送が行われるようです。 ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CloudFormationでCloudWatchアラームを作成する

はじめに 複数環境への横展開を目的としてCloudWatchアラームをCloudFormationを用いて作成する機会があったので、備忘録として残そうと思います。 CloudWatchアラームに関する知識はあるが、CloudFormationを用いてアラームのリソースを作成したことがない方へ向けての内容になります。 CloudWatchアラームとは?という方は以下をご参照ください。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html また今回はCloudFormationのテンプレートをYAML形式で作成していますが、Visual Studio CodeのプラグインでYAML⇔JSON変換もできるそうなので(試してはいません)、JSON派の方も参考にしていただければと思います。 https://bsblog.casareal.co.jp/archives/4936 早速作ってみる Lambdaのエラーを検知するCloudWatchアラームとそれを通知するためのSNSトピックを作成します。 環境ごとにリソース名を変える為に、環境識別子をパラメータにとり各リソース名の頭につけます。 以下がCloudFormationのテンプレートになります。 CloudWatchAlarm.yaml AWSTemplateFormatVersion: 2010-09-09 Parameters: # 環境識別子毎にリソースの名前を変える必要があるので、環境識別子をパラメータとして用意 EnvironmentIdentifier: Description: Environment Identifier MaxLength: 15 Type: String Resources: # SNS Topic (エラーアラームの通知用) TopicError: Type: AWS::SNS::Topic Properties: TopicName: Fn::Join: - "-" - - Ref: EnvironmentIdentifier - topic-error Subscription: - Protocol: email Endpoint: xxxx@example.com # CloudWatchアラームのリソース AlarmLambdaError: Type: AWS::CloudWatch::Alarm Properties: AlarmName: Fn::Join: - "-" - - Ref: EnvironmentIdentifier - alarm-lambda-error AlarmDescription: Alarm for Lambda Error # アラームのアクションとしてSNSのTopicを指定 AlarmActions: - Fn::Join: - ":" - - 'arn:aws:sns:ap-northeast-1' - Ref: 'AWS::AccountId' - Fn::Join: - "-" - - Ref: EnvironmentIdentifier - topic-error ComparisonOperator: GreaterThanThreshold MetricName: Errors Namespace: AWS/Lambda DatapointsToAlarm: '1' EvaluationPeriods: '1' Period: '300' Statistic: Sum Threshold: '0' CloudFormationスタックの作成 CloudFormationの「スタックの作成」からスタックの作成をします。 実際に作成されたリソースはこちら。 まとめ 今回のシステムでは多い時で10環境程度あり、1環境に100個弱のアラームが存在していたため、コンソールからアラームを作成していたのではとても間に合いませんでした。 CloudFormationによってリソースをIaC化することにより、横展開の工数を大幅に削減することに成功しました。 皆様も環境数の多いシステムではIaC化を検討されてはいかがでしょうか。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Online Summit Japan(2021/512~31)参加レポ ①

はじめに こんにちは、新米プログラマーのYuu_Nです。 業務経験は研修でJavaを使用してECサイトを作成した後、C#を用いた業務アプリの開発の経験を経て今は社内研修(Java)のサブ講師をしています。 以前AWSome Daysの参加レポートを投稿したのですが、先月開催していたAWS Online Summit Japanにも参加したので参加レポートを投稿しようと思います。 参加した目的 4月に開催したAWSome Daysでは体系的にAWSの良さや主要のサービスについて学ぶことができたのでそこから更に基本的なサービスについて深堀して学びたいと思ったためです。 参加したセッション 参加したセッションは以下になります。 本イベントではセッション数が150を超えていたのでどうやって自分が学びたい内容のセッションを探せるか不安だったのですが、セッションの種類やタグで探すことができるようになっていました。 そのため今回は初学者向けのタグのついていたセッションの中からいくつか選択して参加してみました。 参加したセッション ・初学者向け AWS 学習パス ~まずはクラウドプラクティショナー認定資格から~(AWS-64)(当日参加) ・【基本の AWS サービス】今日からはじめる! AWS のデータベースと最適なサービスの選び方(AWS-10)(配信視聴) ・【基本の AWS サービス】Amazon EC2 ことはじめ 〜あらゆるワークロードに対応する豊富な選択肢とコスト最適化オプション〜(AWS-13)(配信視聴) ・【基本の AWS サービス】入門! AWS アイデンティティサービス(AWS-37)(配信視聴) ・【基本の AWS サービス】進化した Amazon S3 を最大限に活用する(AWS-41)(配信視聴) ・【基本の AWS サービス】AWS アカウントを守るためにおさえておきたいセキュリティ対策(AWS-52)(配信視聴) ・【基本の AWS サービス】初心者向け Amazon VPC を中心としたネットワークの構成解説!(AWS-32)(配信視聴) ※公式サイトはこちら その中で特に印象に残った何点かのセッションについて記事を分けて記述したいと思います。 まずは以下セッションです。 初学者向け AWS 学習パス ~まずはクラウドプラクティショナー認定資格から~(AWS-64) こちらはクラウドプラクティショナーに興味があったのと、AWSの豊富な学習コンテンツの中から自分のレベルに合った適切な学習方法を知るために参加しました。 以下箇条書きで自分の感想等交えて記載します。 アジェンダ 1.学習の必要性 2.学習の方法 3.認定資格 4.まとめ 1.学習の必要性 なぜAWSの学習が必要なのか?という理由について3点列挙 ①IT人材が不足することが予測されているため 2030年にはIT人材が45万人も不足すると試算されているため、人材が多く不足する可能性が高い。 ②求められる最先端技術のキャッチアップ 2030年にIot/AIなどの最先端技術を活用したIT市場が全体の56%になると予測されているため、今後最先端技術のキャッチアップ(AWSの最新情報のキャッチアップ)を積極的に行わないとIT技術の流行に乗り遅れてしまう。 ③AWSの新サービス/新機能の数 AWSでは200を超えるサービスを提供しており、2020年だけで2757回もリリースを実施している! →2757回もリリースされているということはそれだけ新サービス、新機能、改修があるのでAWSを使い続ける、使いこなすためにはこまめに情報収集する必要がある。 2.学習方法 ①ステップ1:まず最初に何をするべきなのか? →AWSが選ばれる理由や活用方法・事例を知る AWS が選ばれる10の理由でAWSとは何なのか、どのようなサービスが提供されているのか長所が何なのかを知る ※公式リンク AWS 日本国内のお客様の導入事例: 活用方法・効果を事例で知る※公式リンク AWS マンガ: AWS で何が出来るのか?をストーリー形式で学ぶ※公式リンク AWS Summit 資料: 最新の事例・情報が閲覧可能!※WS JAPAN SUMMIT ONLINE 2020資料 ②AWSサービスの全体像をつかむには? →AWSが提供するイベント、デジタルトレーニングを受講する AWSome Day AWS Cloud Practitioner Essentials(Japanese) →こちらはAWS初心者向けのデジタルトレーニングで無料で受講することができる※公式リンク ③各サービスに詳しくなるには? 各AWSサービスを深堀りした資料に目を通す AWSサービス別資料がSlideShare/PDF/YouTubeで確認できる※サービス別資料 ④最新情報をキャッチアップするには? AWS Japan Blogの週刊AWSをチェックする →こちらの更新情報をチェックするだけで重要な新サービスや機能のアップデートを知ることができる。 ⑤さらに知識を深めるには? 他の人と話す・自ら手を動かすことで知識と実践を結び付けて理解できる ・AWSハンズオン※公式リンク アカウント作成、API構築のところから学習できる 3.認定資格 クラウドプラクティショナーとは →クラウドプラクティショナーはAWSの入門資格という位置付けであり、取りたいIT資格ランキング2020年1位をとっている注目の資格。 試験範囲 →以下、実際によく使われている機能や推奨される使い方が問われる傾向がある。 試験分野 出題割合 クラウドの概念 26% セキュリティとコンプライアンス 25% テクノロジー 33% 請求と料金 16% 試験準備方法① 認定準備ウェビナーのワークショップを選択して参加する 試験準備方法② Exam Readiness 都合に合わせて何度でも受講することができる無料のデジタルトレーニング 参考 クラウドプラクティショナーについて公式サイト クラウドプラクティショナー基礎知識について公式サイト AWS認定に挑戦 クラウドプラクティショナー編
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

S3バケットをインタラクティブに簡単に削除する

はじめに オブジェクトの入ったS3バケットをAWSCLIを使って、インタラクティブに削除する方法です。 S3の削除コマンドって、、 意外と検討段階だったり、AWSサービス使ってると自動的に作られて、あー、消したいなぁって思うことがあります。ありますよね。 で、さすがにGUIはめんどくさいので、CLIで打つんだけど、何が面倒くさいって、バケットの名前って一意にしないといけないので、とても長ったらしくて、コマンド打つのがめんどくさい。ていうかよく間違えて、そんなバケット無いよ、って言われてイライラする。 # バケットを探す aws s3 ls # バケットを消す aws s3 rb aaaabbbbccccdddd-backet --force あー、backetじゃなくて、bucketだったーみたいな。 解決法 インタラクティブに消せたらいいよね。 ということで、こちらを使わせて頂く。 下準備として、sentakuをインストール。 brew tap rcmdnk/rcmdnkpac brew install sentaku 下記スクリプトを準備。 個人的にはこういうオレオレスクリプトをどこかにまとめて作っておいて、環境変数のPATHに追加しておくといつでも使えて便利なのでそれをオススメする。やっていることはシンプルで、s3のリストを取得して、選んだバケットをごそっと消しちゃうというもの。(消えるので使い方には注意を・・責任は負いません。) rm_bucket #!/bin/bash STR=`aws s3 ls | sentaku -s $'\n'` ARR=(${STR// / }) BUCKET=${ARR[2]} BUCKET=`echo ${BUCKET} | tr -d '\n'` if [ -z ${BUCKET} ]; then echo "Error: Cannot find bucket name." exit fi read -p "delete ${BUCKET}? (y/N): " yn if [[ $yn = [yY] ]]; then echo "s3://${BUCKET}" aws s3 rb s3://${BUCKET} --force else echo "Abort." fi 使ってみる こんなふうに使えます。 $ rm_bucket 実行すると、下記のようなS3バケットのリストが表示されます。 バケットを選択してエンターを押すと確認メッセージが表示されて、yを打てば、そのまま強制的に消せます。 delete example-example-2? (y/N): y s3://example-example-2 remove_bucket: example-example-2  まとめ 快適!快適だ! でも--forceで消してるので、気をつけて使ってください。 (既存バケット名をIntelisenseとか出来るなら、そのほうが快適な気がする・・)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIを使ってEC2のインスタンス一覧を取得したり起動したりする

awsコマンドを使ってEC2インスタンス一覧を取得したり、インスタンスを起動したりして遊んでみました。 実行環境は、macOS Catalina 10.15.7です。 1. awsコマンドのインストール Mac版 AWS CLI version.2を以下のリンクから、最新バージョンのpkgファイルをダウンロードします。 2. コマンド起動確認 $ which aws /usr/local/bin/aws $ aws --version aws-cli/2.2.10 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off バージョン情報が表示されれば、インストール成功です。 3. config 以下のコマンドでコンフィギュレーションします。 $ cd $ aws configure 任意のAccess Key ID、Secret Access Keyおよびリージョン名を指定します。output formatはJSONにしておきます。 Access Key ID=<YOUR ACCESS KEY ID> Secret Access Key=<YOUR SECRET ACCESS KEY> region name=<YOUR REGION; 例えば、ap-northeast-1> output format=json コンフィグファイルは以下のコマンドで確認できます。 $ less ~/.aws/config $ less ~/.aws/credentials 4. EC2インスタンスの一覧表示 以下のコマンドで全件取得できます。 $ aws ec2 describe-instances 上記コマンドでは結果の全項目が取得できます。結果の項目をフィルタリングしたいときは、queryオプションを使います。 例えば、InstanceIdとStateだけを取得したい場合は、queryオプションで以下のように指定します。 $ aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,State]" [ [ "<INSTANCE ID1>", { "Code": 80, "Name": "stopped" } ], [ "<INSTANCE ID2>", { "Code": 16, "Name": "running" } ] ] 参考: https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-ec2-instances.html 5. EC2インスタンスの起動 以下のコマンドでインスタンスを起動できます。<INSTANCE ID>のところは起動したいインスタンスIDを指定します。 $ aws ec2 start-instances --instance-id <INSTANCE ID> { "StartingInstances": [ { "CurrentState": { "Code": 0, "Name": "pending" }, "InstanceId": "<INSTANCE ID>", "PreviousState": { "Code": 80, "Name": "stopped" } } ] } 参考: https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html 6. EC2インスタンスの停止 起動と同様に、以下のコマンドでインスタンスの停止もできます。<INSTANCE ID>のところは停止したいインスタンスIDを指定します。 $ aws ec2 stop-instances --instance-id <INSTANCE ID> { "StoppingInstances": [ { "CurrentState": { "Code": 64, "Name": "stopping" }, "InstanceId": "<INSTANCE ID>", "PreviousState": { "Code": 16, "Name": "running" } } ] } 参考: https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html 7. EC2インスタンスの終了 以下のコマンドでインスタンスの終了もできます。<INSTANCE ID>のところは終了したいインスタンスIDを指定します。 ★終了すると再度起動はできなくなるので注意してください。 $ aws ec2 terminate-instances --instance-id <INSTANCE ID> { "TerminatingInstances": [ { "CurrentState": { "Code": 32, "Name": "shutting-down" }, "InstanceId": "<INSTANCE ID>", "PreviousState": { "Code": 16, "Name": "running" } } ] } ちなみに、終了したインスタンスはAWSのダッシュボードからは時間が経つと自動的に消えるようです。 8. インスタンスのライフサイクル インスタンスのライフサイクル(State遷移)は以下のページが参考になります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Perspective の構築

AWS Perspective アーキテクチャー図を自動生成するソリューションです。 自動でアカウントのリージョン全体に存在するAWSサービスを可視化してくれるわけではなく、リソースを選択していくと関係性ををアーキテクチャ図として可視化してくれるものです。 AWS Perspective はサービスとして提供しているものではなく、CloudFormationスタックをデプロイし、Webアプリケーションとして利用します。 CloudFormationスタックがデプロイされたら、Perspectiveを利用するためのURL(CloudFront)にアクセスして利用しWEB上で利用します。数時間Amazon Neptuneがいい感じにデプロイされるぽい。 料金 ?0.79 /hr or ?535.85/mthくらいのコストがかかるので個人で検証目的で利用する場合は注意が必要です。 利用してみた感覚としては、Amazon Neptuneのインスタンスタイプによるのか、リージョンによるのか↑の金額以上が発生していました。 構築手順 a.次のページにアクセスし、「AWS コンソールで起動する」をクリックします。 b.なお、デフォルトでは、バージニア北部リージョンとなっているため、東京リージョンに切り替える。 c.ステップ 1:テンプレートの指定 については気にせず、「次へ」。 d.ステップ 2:スタックの詳細を指定でパラメータを入力して、「次へ」。  今回は、AdminUserEmailAddressの入力と、AlreadyHaveConfigSetupを「No」にする以外はデフォルトです。 パラメータ 値 AdminUserEmailAddress 管理者のメールアドレスを入力、このアドレス宛にアクセス情報が届きます。 AlreadyHaveConfigSetup AWS Config が有効化されているか、今回は既に有効化されているので、「Yes」を選択。 CreateElasticsearchServiceRole AWSServiceRoleForAmazonElasticsearchService ロールを作成します。今回は初めてで作成済ではないので、「Yes」を選択。 CreateNeptuneReplica レプリカは不要なので「No」。 NeptuneInstanceClass アーキテクチャー図描画に必要なデータを保管する Netptune のサイズ。こだわりがなければ「デフォルト」のままとする。 OptOutOfSendingAnonymousUsageMetrics 匿名でメトリクスをAWSへフィードバックを送るか。「No」。 e.ステップ 3:スタックオプションの設定 はそのまま「次へ」。 f.ステップ 4:レビュー は機能と変換にチェックを入れて、「スタックの作成」。 スタックが作成されるまで、約30分程度かかります。 g.先程、AdminUserEmailAddressに入力したメールアドレス宛に、UsernameとPasswordが届くので確認しておきます。 h.次のスタックの出力タブから、WebUI URLを確認し、アクセスする。  aws-perspective-012345678912-ap-northeast-1-CloudFrontDistribution-abcdefghijkl i.メールで届いているUsernameとPasswordを入力する。 j.パスワードの変更が求められるので入力する。 k.verificationのために、「Email」を選択肢、「VERRIFY」をクリック。 l.メールで、Your verification code が届くので入力し、「SUBMIT」をクリック。 m.「Import」をクリック。  なお、↓の「Import an Account」とあるように、別アカウント、リージョンのものをインポートしてくれることもできるようです。(権限周りは必要になるとおもいますが。。。) 以上で構築は完了です。その後の作業はリソースを起動していると個人としてはそこそこ料金が発生してしまうこともあり、スクショはとっていないです。 リソースの削除 この2つを削除すれば、ネストされたスタックも全て削除されます。 aws-perspective aws-perspective-012345678912-ap-northeast-1 ただし、S3バケットが空でないとか諸々綺麗に削除することはできなく、削除されるのにも30分程度かかるので、消し忘れて料金が発生しないようにご注意を。 参考 https://blog.serverworks.co.jp/create-aws-perspective-202010 https://blog.serverworks.co.jp/try-aws-perspective-202010 https://www.youtube.com/watch?v=snTO-k3o3eM https://qiita.com/akanenone/items/aa310ef804058dedd892
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EKSクラスター上で起動したFargateのpodにセキュリティグループを設定してみた

はじめに 以下によると、Fargateのpodへのセキュリティグループの設定が可能になったらしいです。 https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html 実際に設定し、動作を確認しました。 検証方法 nginxのpodをEKSクラスター上に2つ起動し、セキュリティグループ適用前と後で通信を比較しました。 AWSのセキュリティグループについて インバウンド:設定なし(全通信遮断) アウトバウンド:すべて許可 pod情報 podを起動するために使用するmanifest fileの情報は以下です。 nginx1.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx1 labels: name: nginx1 app: nginx1 spec: replicas: 1 selector: matchLabels: app: nginx1 template: metadata: labels: app: nginx1 spec: containers: - name: nginx image: nginx:1.19.2 ports: - containerPort: 80 nginx2.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx2 labels: name: nginx2 app: nginx2 spec: replicas: 1 selector: matchLabels: app: nginx2 template: metadata: labels: app: nginx2 spec: containers: - name: nginx image: nginx:1.19.2 ports: - containerPort: 80 上記manifest fileを使用してpodを起動します。 $ kubectl apply -f nginx1.yaml -f nginx2.yaml deployment.apps/nginx1 created deployment.apps/nginx2 created $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx1-6b86d9bbbf-2q67v 1/1 Running 0 117s 10.2.45.218 fargate-ip-10-2-45-218.ap-northeast-1.compute.internal <none> <none> nginx2-6775f69cc6-fvxpd 1/1 Running 0 117s 10.2.62.78 fargate-ip-10-2-62-78.ap-northeast-1.compute.internal <none> <none> 起動しましたね。 通信確認のため、nginx1 -> nginx2に対してcurlでリクエストを送ります。 $ kubectl exec -it nginx1-6b86d9bbbf-2q67v -- curl 10.2.62.78 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> nginx2 -> nginx1も同様に確認します。 $ kubectl exec -it nginx2-6775f69cc6-fvxpd -- curl 10.2.45.218 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> podへセキュリティグループ設定 次に、podにセキュリティグループを設定するために以下のmanifestをapplyします。 sg-policy.yaml apiVersion: vpcresources.k8s.aws/v1beta1 kind: SecurityGroupPolicy metadata: name: security-policy-test namespace: default spec: podSelector: matchLabels: role: nginx2  ★label名は例なのでroleである必要はないです。 securityGroups: groupIds: - sg-xxxxxxxx .spec.template.metadata.labelsにrole: nginx2を追記し、再度applyします nginx2.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx2 labels: name: nginx2 app: nginx2 spec: replicas: 1 selector: matchLabels: app: nginx2 template: metadata: labels: app: nginx2 role: ngin2 ★追記 spec: containers: - name: nginx image: nginx:1.19.2 ports: - containerPort: 80 applyします。 $ kubectl apply -f sg-policy.yaml securitygrouppolicy.vpcresources.k8s.aws/security-policy-test created $ kubectl get sgp NAME SECURITY-GROUP-IDS security-policy-test ["sg-xxxxxxxx"] $ kubectl apply -f nginx2.yaml deployment.apps/nginx2 created $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx1-6b86d9bbbf-2q67v 1/1 Running 0 117s 10.2.45.218 fargate-ip-10-2-45-218.ap-northeast-1.compute.internal <none> <none> nginx2-7d68c8456-4lbmr 1/1 Running 0 117s 10.2.36.251 fargate-ip-10-2-36-251.ap-northeast-1.compute.internal <none> <none> 動作確認 再度nginx1 -> nginx2へcurlを実行します。 kubectl exec -it nginx1-6b86d9bbbf-2q67v -- curl 10.2.36.251 curl: (7) Failed to connect to 10.2.36.251 port 80: Connection timed out role: nginx2のラベルがついているnginx2のpodに対してセキュリティグループが適用されている状態となります。 セキュリティグループのインバウンドは何も設定されておらず、すべての通信を拒否するので通信はタイムアウトしました! nginx2のmanifestのlabelを修正 nginx2.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx2 labels: name: nginx2 app: nginx2 spec: replicas: 1 selector: matchLabels: app: nginx2 template: metadata: labels: app: nginx2 role: nginx ★修正 spec: containers: - name: nginx image: nginx:1.19.2 ports: - containerPort: 80 再度applyし、nginx1 -> nginx2へcurlを実行します。 $ kubectl apply -f nginx2.yaml deployment.apps/nginx2 created $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx1-6b86d9bbbf-2q67v 1/1 Running 0 125m 10.2.45.218 fargate-ip-10-2-45-218.ap-northeast-1.compute.internal <none> <none> nginx2-7d68c8456-t72zn 1/1 Running 0 4m11s 10.2.63.222 fargate-ip-10-2-63-222.ap-northeast-1.compute.internal <none> <none> $ kubectl exec -it nginx1-6b86d9bbbf-2q67v -- curl 10.2.63.222 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> ラベル名を修正することでnginx2のpodにセキュリティグループが適用されなくなり再度通信が可能になりました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

JPCYBER S3 DriveのACL適用オプションを確認する

はじめに S3をマウントしてエクスプローラーから扱えるようにするJPCYBER S3 Driveですが、その設定オプションの中に「親バケットのACLをアップロードするファイルに適用する」というものがあります。 この動きが良く理解できていなかったので試してみました。 ・JPCYBER S3 Drive https://www.jpcyber.com/ 実行手順 事前準備 以下は事前に準備しています。 ・EC2(Windows) ・JPCYBERインストール ・S3バケット作成 事前確認 開始前のS3バケットACLの設定は以下です。 オプションを設定しない場合 まずは何もオプションを設定しない状態でアップロードした時のオブジェクトACLを確認します。 オブジェクトACLはS3バケットACLと同じものが設定されていました。 S3バケットACLに外部アカウントを1つ追加してみます。 再度ファイルをアップロードします。 ACLは最初のものと特に変わっていません。 オプションを設定した場合 それでは次はオプションを設定して試してみます。 以下の項目にチェックをつけて保存ボタンを押下します。 サービスの再起動が終わったらファイルをアップロードしてみます。 アップロードしたファイルのオブジェクトACLを確認するとS3バケットACLと同じ設定になっていました。 オブジェクト一つ一つに同じACLを設定するのは手間なので、JPCYBER経由でアップロードする時には自動的に設定したいということがあればこのオプションを使えば良さそうです。 注意点 公式のJPCYBER S3 Driveのオプションを設定するページに以下の注意書きが書いてますので、使用する際は理解した上でご使用ください。 有効にした場合は性能が低下します。必要ない場合は、off のままにしてください。 終わりに そもそもACLについての理解も曖昧だったので、前回記事含めて理解のために検証してみました。 過去記事にも書いてますが、JPCYBERのインストール先が別のAWSアカウントの場合は権限の問題で失敗することもあるのでご注意ください。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon流のモノづくり:Working Backwardsとは@ANGEL Dojo

目次 1.概要 2.はじめに 3.Amazonのミッションとは 4.Amazon流のモノづくり-Working Backwards- 5.ワークショップを終えてみて 1-概要 現在弊社で参加しているAWS主催の内製化支援に向けたトレーニング「ANGEL Dojo」内で Amazonのモノづくりの手法 Working Backwards を体験できるワークショップがございましたので、 そちらの内容と得た学びを共有させていただきます。 2-はじめに ANGEL Dojoとは? ANGEL Dojoでは次世代を担うAPNの若手のエンジニアの方々に、擬似プロジェクトを通じてアジャイル、DevOps、モダンなアプリケーション開発などのクラウドネイティブな手法と、様々なInnovationを作ってきたAmazonの文化と考え方を体験いただくことで、お客様にクラウドの価値を100%届けるための基礎的なスキルを実践を通して身につけていただきます。参加者の皆様はここで培ったスキルと、各パートナーの皆様がお持ちのそれぞれの強みを活かすことでお客様のビジネスを成功に導き、日本のITや経済をさらに成長させる主役、すなわち「APN Next Generation Engineer Leader」になっていただきます。 (「日本を元気にする」APN Next Generation Engineer Leaders(ANGEL) Dojo のご紹介 https://aws.amazon.com/jp/blogs/psa/apn-next-generation-engineer-leadersangel-dojo )より  ANGEL Dojoの説明と1日目の様子は一緒に参加している弊社のメンバーが記事を投稿しておりますので是非ご覧ください! (エンド企業とSlerの関わり方:システム開発の内製化のポイント@ANGEL Dojo https://qiita.com/yu_to_15/items/d6055b8382c789f140ec ) 3-Amazonのミッションとは Amazonのミッション「地球上で最もお客様を大切にする企業」 ANGEL Dojo2日目のワークショップの内容はAmazonがサービスを企画する際に使われる手法 Working Backwardsを学ぶ内容でした。 まず、「Working Backwards」を学ぶ上で前提となるとても大切なAmazonのミッション(企業理念)をご説明します。 Amazonのミッションは世界で最もお客様を大切にする企業であるということ。 このミッションがあるからこそ、私たちが普段利用したいような便利で嬉しいサービスをいくつも実現することができるのです。 この考え方は社会に出た自分も大切にしたい考え方だと思いました! Our Leadership Principles(OLP)とは OLPというのは簡単に言うとAmazonの全社員がリーダーであるという考え方のもとで大切にしている14つの信条のことです。 その14つの信条が以下になります。 ・Customer Obsession ・Ownership ・Invent and Simplify ・Are Right, A Lot ・Learn and Be Curious ・Hire and Develop The Best ・Insist on the Highest Standards ・Think Big ・Bias for Action ・Frugality ・Earn Trust ・Dive Deep ・Have Backbone; Disagree and Commit ・Deliver Results ミッション、OLPについて詳しくはこちらをご覧ください AWS カルチャー https://aws.amazon.com/jp/careers/culture/ 4-Amazon流のモノづくり-Working Backwards- Working Backwardsとは このミッション「地球上で最もお客様を大切にする企業」をもとに サービスを考える手法がWorking Backwardsという手法です。 Working Backwardsとは簡単に説明すると 「サービスを企画する際、まずプレスリリースとFAQから作成をすること」を指します! プレスリリースというのは企業、組織が報道機関などに発表する公式文書のことで、 商品・サービスが提供されるときに送られるもの(だと思ってました、、、) プレスリリースとFAQから作成することで、お客様にどんな価値が提供できるのか、 を具体的にイメージすることができるみたいです。 いざワークショップ 今回のワークショップのテーマは「ネットでショッピングするヒトの購買体験の向上」でした。 どんな新しいサービスを提供すればお客様がより買い物をしやすく、したくなるかを考える内容です。 またサービスを考えるうえでこの5つの質問に答えられることを念頭に置いて進めていきます。 1. お客様は誰ですか ? 2. お客様が抱える課題や改善点は明確ですか ? 3. お客様が受けるメリットは明確ですか ? 4. お客様のニーズやウォンツをどのように知りましたか ? 5. お客様の体験が描けていますか ? そこで具体的にワークのフォーマットに当てはめながら私が考えたサービスはこちらです。 1. お客様は誰か ? 名前:山口花子 性別:女性 年齢:25歳 職業:事務職 住まい:神奈川県横浜市 年収:250万円 家族構成:一人暮らし 趣味:服を買う、インスタグラム投稿 よく利用するサイト:インスタグラム/Amazon/メルカリ 購買傾向:おしゃれなもの、世間的におしゃれだと言われている流行していて、さらに使いやすいのものを買う 購買頻度/額:2回/3万円 ECへの願望:実際に部屋に置いたり着たりしたもののイメージができてから購入したい 2. お客様が抱える課題は何か ? 山口花子さんは、家電を購入する際、商品説明、口コミではわからない、自分の部屋に置いたイメージやその家電の騒音などを知ってから購入することをあきらめる必要がある。 3. 課題を解決するアイデアは ? ・既に購入した方アポイントメントを取り、ビデオ通話等で実際の様子を見てから判断できる。サービス利用料として200円ほどを支払い、やり取りを行った既に購入した方にポイントとして送られる。 ・実際に送られてきて、商品を試して気に入らなければ、無料で返品ができる。 4. お客様のメリットは ? 山口花子さんは購入する商品のイメージをより鮮明に想像できてから購入できる。 (既に購入した方は、ポイントを貰うことができる) 正解はありませんが、このような形で具体的にお客様を想定して、どんな課題があるのか、 どのようなサービスを考えたのかを具体的に考えました。 個人的にこだわったポイントは買い物したいお客様はイメージに合った商品が購入でき、 逆にビデオ通話で商品説明に応じた方にはポイントがもらえるため、どちらにもメリットがあるという点です! このアイデアをもとにプレスリリースを作成していきます。 =========================== 購入者と実際に話をして商品を知る「Word of Eye」を開始 ~もう買った後の違和感はありません~ (導入) ARアドバンストテクノロジ株式会社は、2021年10月1日(金)ECサイトにおける新サービスWord of Eyeを開始しました。Word of Eyeは、実際に商品を既に購入された方とビデオ通話を行い、実際に部屋に置いてみてのいい点、悪い点、騒音、違和感、初期設定やおすすめの使い方など事細かに自分の気になることを聞くことができるサービスです。これにより生の声を目で見て理解できるので一度は味わったことのある、「いい商品で返品するほどではないんだけどここが少し気に入らなかった」といった小さなストレスすらも無くすことができます。 (課題) オンラインで家電やインテリアを購入する際に一度は経験する、自分の部屋のイメージに合わなかった、実際に動かしてみると騒音が大きくて少しストレスなどの、商品説明の画像での色合い、レビューや口コミでの「騒音は気になりません」という別の価値観を持った方からの意見だけでは高額な商品には手を出しづらい状況にあります。 (課題解決) Word of Eyeを使えば実際に商品を購入した方とビデオ通話で商品のより詳しい情報、色合い、よかった点、気になる点、騒音、違和感、配置場所、初期設定でのポイントなどを事細かくに聞くことができます。これにより、購入した後の違和感や、すこし気になるポイントなどを解消してから購入することができます。 また、ビデオ通話に応じた方にはお礼として200ポイントが送られます。ポイントは他の商品を購入する際にご使用できます。 (お客様の声) ・早速Word of Eyeを利用された神奈川県に住むYさん「以前Amazonで購入したロボット掃除機は性能は良いのですが、騒音がうるさくて在宅勤務の時には利用できるものではありませんでしたし、色味も画像よりも真っ白で傷がつきやすいもので、少し後悔しましたが、今回のプロジェクターを購入するときはWord of Eyeで実際の購入者から騒音や色合いなどをあらかじめ聞くことができて、後悔なく満足のいく買い物ができました。」 ・既に購入しYさんとビデオ通話でのレビューを行ったTさん「最近購入したプロジェクターでしたが、私には正直起動の音やスピードが気に入るものではありませんでした。ただ、Yさんとビデオ通話で実際に使用する様子を見せたときにYさんは意外と起動スピードや騒音について気にならないとおっしゃっていました。そこだけが少し後悔している面だったのですがYさんは納得して購入されたので良かったと思います。またポイントも即時送られてきたので、もう少し貯めて、日用品の買い物をしたいと思います。」 =========================== サービスや課題に加えて実際にサービスを利用したお客様の感想を想定して書いていきます。 これによりお客様にとってどのようなメリットがあるのかが更にイメージしやすくなります。 FAQを作成するフェーズはありませんでしたが、同じようにお客様からの声を考えながら作成していくそうです。 5-ワークショップを終えてみて 私なりの答えを記載しましたが、実際に考えているとペルソナ設定 (1. お客様は誰か ?) が1番難しい事を感じました。 反対にこれが1番重要なことだとも感じました。 「一人暮らし、女性、インスタグラム投稿が趣味、おしゃれなものが買いたい」などを設定すると、 その人は「おしゃれが好きで少し見栄っ張り」であり、 実際にどのような買い物の仕方をすれば買い物がしたくなるのか、より買ったもののミスマッチが少ないか、 そもそもこのサービスをどのように見つけてもらい、利用をしてもらえるのかなど、 よりニーズに寄り添ったサービスを考えることができたような気がします。 これからANGEL Dojoではチームで1からサービスを作り上げるフェーズに入ります。 今回のワークショップで学んだことを活かして「Working Backwards」の手法を使って お客様が求めるサービスを作ることができるように頑張ります!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS使用してみて

こちらも編集中です。 随時更新してまいります。 編集リクエストはご遠慮下さい
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

別アカウントからS3にアップロードされたファイルのACLを変更する

はじめに 過去に「別アカウントからS3にアップロードされたファイルの所有者を変更する」という記事を書きましたが、今回はアップロードしたファイルのACLをアクセスコントロールポリシーを使用して変更する方法について試してみました。 手順の前に ACL(アクセスコントロールリスト)とは まずACLとは何かといいますと、S3で設定可能なアクセス管理機能の一つで、S3バケットポリシーと同じくS3バケットに設定が可能になっています。 ACLを使用することで別のAWSアカウントやAWSアカウントを持つすべてのユーザー等の単位で読み取りや書き込みなどのアクセスを許可することができます。 多くの場合、S3バケットを保有するAWSアカウントとは別のAWSアカウントからファイルをアップロードされる際にアクセス許可を与えるのに使用されます。 それ以外の細かい制御はIAMとバケットポリシーで行うようにAWSドキュメントにも記載があります。 ACLの種類 ACLには2つ種類があり、1つがS3バケットに紐づくACLで、もう1つがオブジェクトに紐づくACLです。 2つのACLで異なる設定がされていた場合はオブジェクトのACLが優先されるようになってます。 ・S3バケット単位ACL ・オブジェクト単位ACL ACLが設定されるタイミング S3バケットのACLはS3バケットを作成したタイミングで設定されます。 パブリックアクセスを拒否した環境だとデフォルトでバケット所有者アカウントのみアクセスが許可されています。 オブジェクトのACLはアップロード時に特に指定しなければS3バケットのACLと同じものが設定されます。 ただし、S3バケットのACLに別のAWSアカウントのアクセス許可がされていたとしても、それはオブジェクトのACLには反映されません。 その場合は手動でオブジェクトのACLに設定する必要があります。 CLIも準備されているので、手動で設定する場合はコマンドで設定したほうが楽だと思います。 ・put-object-acl 実行手順 事前準備 環境は前回の流用ですが、最低限以下は既に整っていることとします。 ・ファイルアップロードするAWSアカウントとS3のあるAWSアカウントは別 ・アップロード元AWSアカウント上でEC2を準備 ・EC2にアタッチされたIAMロールの権限を使用する ・S3バケットのポリシーでIAMロールを許可 ・アップロード用のサンプルファイルはEC2上に作成済み ファイルアップロード EC2から以下のCLIでファイルをアップロードします。 $ aws s3 cp .\test1.txt s3://test-tmp-20210611/test/ アップロードされたファイルをS3コンソールからみるとアクセス許可がないためエラーが表示されます。 以下のコマンドでアップロードしたファイルに設定されたオブジェクトACLを確認してみます。 $ aws s3api get-object-acl --bucket test-tmp-20210611 --key test/test1.txt 諸事情でモザイクかけてますが、アップロード元のAWSアカウント情報が設定されたACLとなっているようです。 以下のコマンドでアップロード先のS3バケットACLも確認してみましょう。 aws s3api get-bucket-acl --bucket test-tmp-20210611 モザイクかけてますがIDの頭文字が異なることから別のAWSアカウントの情報が設定されたACLであることがわかります。 ACL変更 ACLが異なることが確認できたところでオブジェクトACLを変更していきます。 変更にはAWS CLIのput-object-aclを使用します。 そのコマンドには「--access-control-policy」というオプションがあり、JSON形式でACLを指定することで対象のオブジェクトに指定のACLで更新することができます。 JSON例は以下です。 先ほどコマンドで確認したACLがそのまま使えるので、それをベースに必要な設定だけを追加します。 { "Grants": [ { "Grantee": { "DisplayName": "string", "EmailAddress": "string", "ID": "string", "Type": "CanonicalUser"|"AmazonCustomerByEmail"|"Group", "URI": "string" }, "Permission": "FULL_CONTROL"|"WRITE"|"WRITE_ACP"|"READ"|"READ_ACP" } ... ], "Owner": { "DisplayName": "string", "ID": "string" } } 作成したJSONがこちらです。 Grantsのパラメータにアップロード先のAWSアカウントの名前を正規IDを追加しました。 s3bucket_acl.json { "Owner": { "DisplayName": "アップロード元AWSアカウント", "ID": "アップロード元AWSアカウントID" }, "Grants": [ { "Grantee": { "DisplayName": "アップロード元AWSアカウント", "ID": "アップロード元AWSアカウントID", "Type": "CanonicalUser" }, "Permission": "FULL_CONTROL" }, { "Grantee": { "DisplayName": "アップロード先AWSアカウント", "ID": "アップロード先AWSアカウントID", "Type": "CanonicalUser" }, "Permission": "FULL_CONTROL" } ] } この時の注意点としては、Ownerをアップロード元のAWSアカウントと一致させることです。 どうやらPutObjectACLリクエストを実行するAWSアカウントとACLのOwnerは一致している必要があるようです。 それが異なる場合は403エラーによりコマンドが失敗します。 JSONファイルが作成できたらEC2で以下のコマンドを実行して、オブジェクトACLを変更します。 $ aws s3api put-object-acl --bucket test-tmp-20210611 --key test/test1.txt --access-control-policy file://s3bucket_acl.json ACL変更確認 S3コンソールから確認してみます。 最初はエラーでACL自体が見れませんでしたが、更新したことでオブジェクトACLに外部アカウントが追加されています。 この外部アカウントがアップロード先AWSアカウントのものなので、コンソールからも見えるようになりました。 ちなみに JSONのOwnerをアップロード先AWSアカウントに変更して、同じようにEC2からコマンドを実行してみた結果がこちらです。 「403 Access Denied」が出ていることがわかります。 どうしてもアクセスコントロールポリシーで設定したいという要件がないのであれば、以下の「--acl bucket-owner-full-control」オプションをつけて実行すると同じ結果になるので、こちらの方が簡単で済むと思います。 $ aws s3api put-object-acl --bucket test-tmp-20210611 --key test/test2.txt --acl bucket-owner-full-control 終わりに S3のACLについてよく理解していなかったので調べるついでに試してみました。 複数のAWSアカウントが関わってくると調べるだけだとわかりづらいので、やっぱり手を動かして確認するのが一番ですね。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIを使ったカスタム属性の変更

環境構築   ここではWindowsだけに関しての環境構築について説明する。MacやLinuxに関しては公式サイトをご覧ください。まずは、msiexec.exeをダウンロードして、環境を備える。 Windows-cmd C:\Users\User.Name>msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi C:\Users\User.Name>aws --version aws-cli/2.2.7 Python/3.8.8 Windows/10 exe/AMD64 prompt/off C:\Users\User.Name>aws configure AWS Access Key ID: ACCESSKEYID AWS Secret Access Key:SECRETACCESSKEY Default region name:ap-northeast-1 Default output format:json   基本的にインストールして、バージョン確認する感じ。次に、IAMでユーザーを作成して、必ずSecret Access Keyをダウンロードしてください。次に、ユーザーの権限をAdministratorAccessに変更または追加する。これで環境構築は終わる。 Cognitoに対するアクセス   AWSのサービスに対するアクセスはすべて「aws」で始める必要がある。Cognitoに対するアクセスも同じである。 Windows-cmd C:\Users\User.Name>aws cognito-idp   こんな感じだね!次に、何の操作をするかを考える。カスタム属性の変更をするので、admin-update-user-attributesでカスタム属性を変更しましょう。 Windows-cmd C:\Users\User.Name>aws cognito-idp admin-update-user-attributes   AWS Configureではどのユーザーがアクセスするかを決めたが、ユーザープールはどうするか、ユーザーネームはどうするかをこれから決める。 Windows-cmd C:\Users\User.Name>aws cognito-idp admin-update-user-attributes --user-pool-id ap-northeast-1_userpool --username TestUser   最後はどの属性を変更するかを決める。 Windows-cmd C:\Users\User.Name>aws cognito-idp admin-update-user-attributes --user-pool-id ap-northeast-1_userpool --username TestUser --user-attributes Name="custom:status",Value="1"   これだけで特定のユーザーのカスタム属性を1に変更することができた!ちなみに実行したら、何も返ってこないので、実際にCognitoを起動して確認しましょう。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Symbol] ノード(bootstrap)のバージョンアップ

概要 前回記事で構築したノードのbootstrapのバージョンアップ手順を残します。 本記事は、ubuntu 20.04、symbol-bootstrap (v1.0.3 -> v1.0.6 へ更新)で確認しています。 委任してもいいよという方は「13.230.96.240 (Ninja Hi-performance Symbol-Node)」まで 投げXYMは「NDLS6GYOIPHATATNAVVOUNJXBD6X4BXU6IRBHIY」まで 事前準備 最新バージョンの確認 GitHUb nemtech / symbol-bootstrap バックアップ # target(一番大事なのはharvesters.dat)をバックアップ $ cp -r ~/symbol-bootstrap/target ~/target_bak_v103_20210611 最悪ノードが壊れてしまった場合は、新規構築してharversters.datを置き換えれば、委任状態を保持して復旧可能です。 バージョンアップ作業 # symbol-bootstrapの停止 $ cd ~/symbol-bootstrap/ $ symbol-bootstrap stop # rootユーザーにスイッチ $ sudo su - # bootstrapのアップデート $ npm update -g symbol-bootstrap $ symbol-bootstrap -v ---- symbol-bootstrap/1.0.6 linux-x64 node-v14.16.1 ---- # rootユーザーから抜ける $ exit # 設定反映 $ symbol-bootstrap config -p mainnet -a dual -c my-preset.yml --upgrade $ symbol-bootstrap compose --upgrade # 起動 $ symbol-bootstrap run -d # 起動確認 $ symbol-bootstrap healthCheck _ _ _ _ _ ___ _ _ _ __ ___ | |__ ___ | | | |__ ___ ___ | |_ ___ | |_ _ __ __ _ _ __ / __|| | | || '_ ` _ \ | '_ \ / _ \ | | _____ | '_ \ / _ \ / _ \ | __|/ __|| __|| '__|/ _` || '_ \ \__ \| |_| || | | | | || |_) || (_) || ||_____|| |_) || (_) || (_) || |_ \__ \| |_ | | | (_| || |_) | |___/ \__, ||_| |_| |_||_.__/ \___/ |_| |_.__/ \___/ \___/ \__||___/ \__||_| \__,_|| .__/ |___/ |_| 2021-06-11T07:18:40.541Z info Container db is running 2021-06-11T07:18:40.542Z info Container node is running 2021-06-11T07:18:40.547Z info Container broker is running 2021-06-11T07:18:40.548Z info Container rest-gateway is running 2021-06-11T07:18:40.550Z info Container node port 7900 -> 7900 is open 2021-06-11T07:18:40.551Z info Container rest-gateway port 3000 -> 3000 is open 2021-06-11T07:18:40.552Z info Testing http://localhost:3000/node/health 2021-06-11T07:18:40.574Z info Rest http://localhost:3000/node/health is up and running... 2021-06-11T07:18:40.574Z info Network is running! 参考情報 Symbol Bootstrap更新手順 NEM Symbol bootstrap のバージョンアップ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

特定のタグが設定されていないAWSリソースの作成を拒否するIAMポリシー

はじめに IAMポリシーで「特定のタグが設定されている場合はリソース作成を許可する」という内容の記事はよく見かけるのですが「特定のタグが設定されていない場合はリソース作成を拒否する」パターンを見かけなかったのでやってみました。 IAMポリシー 今回はEC2作成時にインスタンスにownerというKeyのタグが設定されていない場合は作成を拒否するという内容にしました。 ConditionでNull条件演算子を使用してownerタグの存在を確認している箇所がポイントです。 ※以下のサンプルでは先頭でフル権限を付与していますが実際の運用では必要最小限の権限を付与することが好ましいです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "Null": { "aws:RequestTag/owner": "true" } } } ] } テスト 以下4パターンのテストを行いました。 パターン①:タグ無しでEC2を作成 パターン②:Key=hogehogeというタグを設定してEC2を作成 パターン③:Key=ownerというタグを設定してEC2を作成 パターン④:Key=ownerとKey=hogehogeという2つのタグを設定してEC2を作成 EC2の作成はポリシーをアタッチしたIAMユーザの権限でAWSCLIで実行することにします。 各テストパターンの実行結果は以下の通りとなりました。 パターン①:タグ無しでEC2を作成 結果:EC2作成 失敗 ・実行コマンド aws ec2 run-instances \ --image-id ami-abcd026eaf697efgh \ --count 1 \ --instance-type t2.micro \ --key-name ec2-test-key ・実行結果 An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation. Encoded authorization failure message: pTr0TjJdNIjcdcmjoPjkI94_N8qzQripyTsnR9grts3estiIgfAM5-txSLA-0yXXamJ-Tf4qn_NuJg2CAddyZGNl-KRJ6sK3rYtsIWBRpab9lom5Mh3FCPAMu9YoT7fAp9Q-t0Dy8NoIe3gMXZQfOdRbapNC-4Ce8w82OuL1YvSwRlQiLBNAbpJtkEys1ugkLnGtcKUz3RwIho0MCgv7BeW9IuOIQ5mvkg2ze9Okw-ObSffLjwkknT7NZJ1Q4imf6KBHZWqKGklplQGToUqnfSRzIXhaUilY7iyrmN62r2LBZhdadNDYWslHyb1537mnS7MvGp_Shr-TgiuXWJO1ToxjOEF5xEeGKNIDbk7aSvcIcctTkve9rFhzVBNHmDSDeb2UdONu0hPUBgfKaklcuuLKnd8pyVD3C8_KJZSHQKElOiXHAR3OJXPbKvKjSfGy053NPawOf3EF4khPagAKUzXC3ivcoFF5ztdPOFZ2dJjgrXfT0gLogrJGVD_p7lRxJyzyrs0z3QBwNyE5iZY-fItW7q5O_VSxUmrlPRiLLpUbxvAdUWoY19wwlr3UaySvzrBqXgJ2ZFnMi-xn3DyoKxMKDZZd8D4CiQi-xsZLX8iMAvnJE1ZVGbaYlLGV_6pHw6ZzbeOy56FhTDjqyDqTr4ALhZ3sxXxl7AyigBq3X4H2E9964F9falptIrMrCyDXpIu6qP-W7k1771JxjBedILPQjJ7A0h2SuapJ9OG1C_qojYLBWtvmE65HCUTO4303fqxj1-2g-u23BOJ05--nzA パターン②:Key=hogehogeというタグを設定してEC2を作成 結果:EC2作成 失敗 ・実行コマンド aws ec2 run-instances \ --image-id ami-abcd026eaf697efgh \ --count 1 \ --instance-type t2.micro \ --key-name ec2-test-key \ --tag-specifications 'ResourceType=instance,Tags={Key=hogehoge,Value=test-user}' ・実行結果 An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation. Encoded authorization failure message: VYezoTqMW-lgRuRVAjlJj7YVePPOnoLlTqCucIts1IdWv2bN44CAiaaR7Nxs-S3fKfyf9R9kIDJflU0WmM5psufI87A1SSXLIGtoTsBxXChoCN3uIVBMiuubiFXOS0Z0nHUn6aVLqJhg0FdYv2NiFurA0eUbxvCfmT8Cx_AbFo-PYDDyFo9_MN_2GOGLdnZw6ytTxwby-CHg487bgjp_Hp9rx1h40ymWZaQ9wIab7EFRjPcghV_gobVM2u57G01tXuW_7jbeamhy0XExJdhO7qQ7cFXst9ZQmsrODvI0yK03WhXopczmrVpPaAPujZ1KRR_C1wfS69vlecUFHHoQ7JOduOlqS3YTmKG5LrMQyQg8NFwEbhFwT_wGg4y9NXg9Mxogk3V_XKLsEgW7dNyA0zfBvLIRHUnLkjsiIJLoD1csDq_HMvNskvjws_7SESxfpbxBP20ji1SESK9BbhtrqYwFGEI7TVstol3C26NCTeKXl2D1r6ijwVrDY8AWZ2dKMVajyetW9VuPBgypdH3NAyYeS-4_V8sSBpQNgG25p39vdjHqLBdjsPba_gkhXWEoGYTeNs6wX7oeBCMhbJFbUpunleVOlPl-tTAixvLehryy5hvzKKIBqs0vEyYjfMtbNATI2kG6tjbPgltfwhC7zWAKkFslXHYOvQhPjpQwLsjE8afGeCw-Li9OcUXeYQDE7TITQbA5JRDItJgnOaY6UKsslmoaWSNZXrmmLE-0AyPleET5qrlfYzypBN90ofNixnYOpdyUuZk_mvp_g4b3 パターン③:Key=ownerというタグを設定してEC2を作成 結果:EC2作成 成功 ・実行コマンド aws ec2 run-instances \ --image-id ami-abcd026eaf697efgh \ --count 1 \ --instance-type t2.micro \ --key-name ec2-test-key \ --tag-specifications 'ResourceType=instance,Tags={Key=owner,Value=test-user}' ・実行結果 { "Instances": [ { "Monitoring": { "State": "disabled" }, ~中略~ "Hypervisor": "xen", "BlockDeviceMappings": [], "Architecture": "x86_64", "RootDeviceType": "ebs", "RootDeviceName": "/dev/xvda", "VirtualizationType": "hvm", "Tags": [ { "Value": "test-user", "Key": "owner"  ※Key=ownerタグが設定されている } パターン④:Key=ownerとKey=hogehogeという2つのタグを設定してEC2を作成 結果:EC2作成 成功 ・実行コマンド aws ec2 run-instances \ --image-id ami-abcd026eaf697efgh \ --count 1 \ --instance-type t2.micro \ --key-name ec2-test-key \ --tag-specifications 'ResourceType=instance,Tags=[{Key=owner,Value=test-user},{Key=hogehoge,Value=test-hoge}]' ・実行結果 { "Instances": [ { "Monitoring": { "State": "disabled" }, ~中略~ "Hypervisor": "xen", "BlockDeviceMappings": [], "Architecture": "x86_64", "RootDeviceType": "ebs", "RootDeviceName": "/dev/xvda", "VirtualizationType": "hvm", "Tags": [ { "Value": "test-hoge", "Key": "hogehoge"  ※Key=hogehogeタグが設定されている }, { "Value": "test-user", "Key": "owner"  ※Key=ownerタグが設定されている } まとめ タグはAWSリソースの管理を行う上で重要ですが、設定をうっかり忘れてしまうこともあります。 IAMポリシーで設定忘れを防止することが可能ですので是非お試しください。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

QuickSightでAthenaと接続するデータソースとデータセット作成をコマンドで行う

メモ書きです $AWSACCOUNT:AWSアカウントです。自身の情報に置き換えて読んでください リージョンも置き換えて読んでください。 今回の構成 QSからAthenaに接続 QSで設定するデータセットとデータソース データセットとデータソース作成をコマンドで行う Athenaクエリ結果 今回使うテーブルへのselect * はこんな感じ。 SELECT * FROM se2.se2_in0 12月のみ抽出クエリ。このあと、QSのカスタムクエリでこちらのクエリを使う SELECT * FROM se2.se2_in0 where year = 2017 AND month = 12 データソース作成 作成するデータソースの定義となるJSON { "AwsAccountId": "$AWSACCOUNT", "DataSourceId": "Tmp-0611-Data-Source", "Name": "Tmp 0611 Data Source", "Type": "ATHENA", "DataSourceParameters": { "AthenaParameters": { "WorkGroup": "primary" } }, "Permissions": [ { "Principal": "arn:aws:quicksight:us-east-1:$AWSACCOUNT:user/default/uehara", "Actions": [ "quicksight:UpdateDataSourcePermissions", "quicksight:DescribeDataSource", "quicksight:DescribeDataSourcePermissions", "quicksight:PassDataSource", "quicksight:UpdateDataSource", "quicksight:DeleteDataSource" ] } ] } データソース作成 作成したJSONを元にcreate-data-sourceでデータソース作成 $ aws quicksight create-data-source --cli-input-json file://create-data-source.json { "Status": 202, "Arn": "arn:aws:quicksight:ap-northeast-1:$AWSACCOUNT:datasource/Tmp-0611-Data-Source", "DataSourceId": "Tmp-0611-Data-Source", "CreationStatus": "CREATION_IN_PROGRESS", "RequestId": "b735d88f-35cf-496f-8047-1e53d54e4491" } データソース確認 作成したデータソースの確認 $ aws quicksight describe-data-source --aws-account-id $AWSACCOUNT --data-source-id 'Tmp-0611-Data-Source' { "Status": 200, "DataSource": { "Arn": "arn:aws:quicksight:ap-northeast-1:$AWSACCOUNT:datasource/Tmp-0611-Data-Source", "DataSourceId": "Tmp-0611-Data-Source", "Name": "Tmp 0611 Data Source", "Type": "ATHENA", "Status": "CREATION_SUCCESSFUL", "CreatedTime": "2021-06-11T08:49:32.169000+09:00", "LastUpdatedTime": "2021-06-11T08:49:34.113000+09:00", "DataSourceParameters": { "AthenaParameters": { "WorkGroup": "primary" } }, "SslProperties": { "DisableSsl": false } }, "RequestId": "dc0d3fc9-2d59-431c-97d2-98215f9b7b88" } QSの画面から作成したデータソース確認 データセット作成 作成するデータセットの定義となるJSON 昼夜というカラム名で、以下の計算フィールドを追加 "ifelse(hour >= 18,\"夜\", hour <= 17, \"昼\", null)" 以下のカスタムクエリを追加 "SELECT * FROM se2.se2_in0 where year = 2017 AND month = 12" { "AwsAccountId": "$AWSACCOUNT", "DataSetId": "Tmp-0611-Data-Set", "Name": "Tmp 0611 Data Set", "PhysicalTableMap": { "AthenaPhysicalTable": { "CustomSql": { "DataSourceArn": "arn:aws:quicksight:ap-northeast-1:$AWSACCOUNT:datasource/Tmp-0611-Data-Source", "Name":"Tmp-CustomSQL", "SqlQuery":"SELECT * FROM se2.se2_in0 where year = 2017 AND month = 12", "Columns":[ { "Name": "deviceid", "Type": "STRING" }, { "Name": "uuid", "Type": "STRING" }, { "Name": "appid", "Type": "STRING" }, { "Name": "country", "Type": "STRING" }, { "Name": "year", "Type": "STRING" }, { "Name": "month", "Type": "INTEGER" }, { "Name": "day", "Type": "INTEGER" }, { "Name": "hour", "Type": "INTEGER" } ] } } }, "LogicalTableMap": { "AthenaPhysicalTable": { "Source": { "PhysicalTableId": "AthenaPhysicalTable" }, "Alias": "Group 1", "DataTransforms": [ { "CreateColumnsOperation": { "Columns":[ { "ColumnName": "昼夜", "ColumnId": "test", "Expression":"ifelse(hour >= 18,\"夜\", hour <= 17, \"昼\", null)" } ] } } ]}}, "ImportMode": "DIRECT_QUERY", "Permissions": [ { "Actions": [ "quicksight:UpdateDataSetPermissions", "quicksight:DescribeDataSet", "quicksight:DescribeDataSetPermissions", "quicksight:PassDataSet", "quicksight:DescribeIngestion", "quicksight:ListIngestions", "quicksight:UpdateDataSet", "quicksight:DeleteDataSet", "quicksight:CreateIngestion", "quicksight:CancelIngestion" ], "Principal": "arn:aws:quicksight:us-east-1:$AWSACCOUNT:user/default/uehara" } ] } データセット 作成したJSONを元にcreate-data-setでデータセット作成 $ aws quicksight create-data-set --cli-input-json file://create-data-set.json { "Status": 201, "Arn": "arn:aws:quicksight:ap-northeast-1:$AWSACCOUNT:dataset/Tmp-0611-Data-Set", "DataSetId": "Tmp-0611-Data-Set", "RequestId": "7b323396-c373-4cfd-bf4b-08f85de4ac43" } データセット確認 作成したデータセットの確認 $ aws quicksight describe-data-set --aws-account-id $AWSACCOUNT --data-set-id 'Tmp-0611-Data-Set' { "Status": 200, "DataSet": { "Arn": "arn:aws:quicksight:ap-northeast-1:$AWSACCOUNT:dataset/Tmp-0611-Data-Set", "DataSetId": "Tmp-0611-Data-Set", "Name": "Tmp 0611 Data Set", "CreatedTime": "2021-06-11T08:54:42.203000+09:00", "LastUpdatedTime": "2021-06-11T08:54:42.203000+09:00", "PhysicalTableMap": { "AthenaPhysicalTable": { "CustomSql": { "DataSourceArn": "arn:aws:quicksight:ap-northeast-1:$AWSACCOUNT:datasource/Tmp-0611-Data-Source", "Name": "Tmp-CustomSQL", "SqlQuery": "SELECT * FROM se2.se2_in0 where year = 2017 AND month = 12", "Columns": [ { "Name": "deviceid", "Type": "STRING" }, { "Name": "uuid", "Type": "STRING" }, { "Name": "appid", "Type": "STRING" }, { "Name": "country", "Type": "STRING" }, { "Name": "year", "Type": "STRING" }, { "Name": "month", "Type": "INTEGER" }, { "Name": "day", "Type": "INTEGER" }, { "Name": "hour", "Type": "INTEGER" } ] } } }, "LogicalTableMap": { "AthenaPhysicalTable": { "Alias": "Tmp-CustomSQL", "DataTransforms": [ { "CreateColumnsOperation": { "Columns": [ { "ColumnName": "昼夜", "ColumnId": "test", "Expression": "ifelse(hour >= 18,\"夜\", hour <= 17, \"昼\", null)" } ] } } ], "Source": { "PhysicalTableId": "AthenaPhysicalTable" } } }, "OutputColumns": [ { "Name": "deviceid", "Type": "STRING" }, { "Name": "uuid", "Type": "STRING" }, { "Name": "appid", "Type": "STRING" }, { "Name": "country", "Type": "STRING" }, { "Name": "year", "Type": "STRING" }, { "Name": "month", "Type": "INTEGER" }, { "Name": "day", "Type": "INTEGER" }, { "Name": "hour", "Type": "INTEGER" }, { "Name": "昼夜", "Type": "STRING" } ], "ImportMode": "DIRECT_QUERY", "ConsumedSpiceCapacityInBytes": 0 }, "RequestId": "231c0c8b-cd39-48a6-9706-db0c1225dd0f" } QSの画面から作成したデータセット確認
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

図でざっくり理解する Amazon ECS Anywhere

はじめに 2021/5/27 Amazon Elastic Container Service Anywhereが一般利用開始になりました? オンプレミス環境で AWS のサービスを使用してコンテナをデプロイするオプションとして、これまでも AWS Outposts 上で Amazon ECS を利用するという選択肢はありましたが、気軽に導入できるものではありませんでした。Amazon ECS Anywhere はユーザーが所有する任意のインフラ環境で、ECS のコントロールプレーンを利用して簡単にコンテナを実行することができる機能です。 詳細な利用手順は他の記事に譲るとして、ECS Anywhere がどのような仕組みで動いているのかや他クラウドの類似サービスと比較したときの違いなどについて書いていきたいと思います。 ざっくり理解する ECS Anywhere ECS Anywhere でコンテナを実行するために必要な環境や設定をざっくり説明していきます。 実行環境の準備 サポートされる OS は以下です。CPU のアーキテクチャは x86_64 と ARM64 をサポートしています。 CentOS 7, CentOS 8 RHEL 7 openSUSE Tumbleweed Ubuntu 18, Ubuntu 20 Debian 9, Debian 10 SUSE Enterprise Server 15 OS 要件を満たし、Amazon ECS のエンドポイントおよび AWS Systems Manager のエンドポイントと通信できる環境であれば、文字通りどこでも実行できます。ECS のエンドポイントとしては以下のドメインと通信します。 ecs-a-*.<region>.amazonaws.com ecs-t-*.<region>.amazonaws.com ecs.<region>.amazonaws.com ecs-a と ecs-t のエンドポイントについては PrivateLink に対応していないため、DirectConnect を使用して完全な閉域 NW 経由で実行することは現時点で難しそうです (Public VIF を利用している場合を除く)。 Docker のインストール 実行環境となるサーバー、仮想マシンには Docker がインストールされている必要があります。 SSM Agent のインストール 実行環境となるサーバー、仮想マシンに AWS Systems Manager の SSM Agent をインストールし、ハイブリットアクティベーションによりマネージドインスタンスとして登録する必要があります。マネージドインスタンスは Systems Manager に以前から存在する機能で、オンプレミスのマシンに SSM Agent をインストールし、アクティベーションコードを登録すると、AWS 上からマネージドインスタンス (プレフィックス「mi-」が付いたマシン) として管理できるようになります。 マネージドインスタンスを使用すると、オンプレミスのマシンに対してハイブリット環境用の IAM サービスロールを割り当てることができます。この IAM ロールを通じて提供される一時クレデンシャルを利用することで、Amazon ECS やその他の AWS サービスと通信できるようになるわけです。オンプレミス環境ごとにアクセスキーを発行して、定期的にローテーション、、、というような面倒でリスクのある作業は不要です。 参考 ECS Agent の起動 Amazon ECS コンテナエージェントをインストール、起動します。ECS Agent はマネージドインスタンスに割当られた IAM ロールの認証情報を利用して ECS のコントロールプレーンと接続します。これで ECS API 経由でコンテナを起動できるようになります。 長々と説明してしまいましたが、準備が面倒そうだなと感じましたか? ECS で External インスタンスを登録する際に表示されるスクリプトを実行すると、Docker のインストール、SSM Agent のインストールとマネージドインスタンスの登録、ECS Agent の起動まで 1 発でセットアップしてくれるため、実はめちゃくちゃ簡単です。 これが ECS Anywhere だ!! セットアップが完了したらマネージドコンソール、CLI、使い慣れたデプロイツールなどからサービスやスタンドアロンタスクを起動できるようになります。これらのコンテナが NLB や RDS といった VPC 上のリソースと通信する必要がある場合は、Direct Connect または Site-to-Site VPN 接続が必要です。 利用料金 ECS Anywhere の利用料金として、External インスタンス 1 台ごとに1 時間あたり、$0.01025 かかります。External インスタンス=登録するホスト環境なので、コンテナの台数ではありません。1 台あたり月約 800 円といったところでしょうか。 Systems Manager は基本的には無料で利用可能ですが、マネージドインスタンスのアドバンスドインスタンス層を使用する場合は料金が発生します。ECS Anywhere としては無料の標準インスタンス層で問題ありませんが、以下のケースではアドバンスドインスタンス層を利用する必要があります。 マネージドインスタンスの管理台数が1アカウント、リージョンで 1,000 台を超える場合 Session Manager でマネージインスタンスにリモート接続したい場合 アドバンスインスタンス層はインスタンスごとに 1 時間あたり $0.00695 かかります。1 台あたり月 500 円くらいです。 ECS Anywhere の利点とユースケース ECS Anywhere の製品ページには以下のような利点とユースケースが記載されています。 利点 フルマネージドなコントロールプレーン 自前でコンテナオーケストレーションの仕組みを構築、運用する必要がに オペレーションの統一 AWS でもオンプレミスでも、同じツールを用いて運用することができる ハイブリット対応 1つのクラスターで EC2, Fargate, External インスタンスを同じクラスター内に配置可能 ユースケース コンプライアンス & ビジネス要件 既存のオンプレミスワークロードのコンテナ化 エッジコンピューティング (低レイテンシーが要求されるワークロード) 既存の設備投資を活用 オンプレミスで実行しつつ追加容量はクラウドにバースト 注目すべきはオンプレミスにおけるコンテナワークロードに特化している点だと考えています。AWS としてマルチクラウドのユースケースは (現時点で) 謳っていません。これは他社とは異なる傾向です。 類似サービスとの違い Microsoft や Google Cloud もオンプレミスやクラウド環境でコンテナ化したアプリケーションを実行可能にする Azure Arc や Anthos といったサービスを提供しています。また AWS は 2021年にAmazon EKS Anywhere を提供予定です。これらのサービスは一見 ECS Anywhere と同じような機能を提供するようにも見えますが、根本的に異なる点が 2 つあります。 ECS Anywhere はフルマネージドコントロールプレーンである マルチクラウドで実行される Kubernetes を統合管理可能な Azure Arc enabled Kubernetes やオンプレミスおよびマルチクラウド環境で Google Kubernetes Engine を動作させることができる Anthos クラスタ は Kubernetes をベースとしている関係で、コントロールプレーンもユーザー環境で動作することになります。 例えば Anthos clusters on AWS の場合、ざっくりと以下のような構成になります。 ECS Anywhere の場合、AWS 上でフルマネージドされている ECS のコントロールプレーンを利用してコンテナをオーケストレーションできます。つまりユーザーは External インスタンス上でコンテナを稼働させることだけに集中できると言えます。 マルチクラウドで AWS サービスを展開することはできない 自明なことではあるのですが、ECS Anywhere 上では AWS のサービスを実行することはできません。Azure や Google Cloud は他社クラウドやハイブリット環境で動作する自社サービスを提供することで、クラウド間でのデータ移動を必要とせずにあらゆる環境で一貫性のあるエクスペリエンスを提供する方向性です。ECS Anywhere は前述のとおりオンプレミス環境でのコンテナワークロードの実行に特化しており、この点からも AWS は現時点でマルチクラウドには注力していない状況が伺えます。 Google Cloud は Anthos クラスタ上で動作する BigQuery Omni や Cloud Run for Anthos といったサービスをリリースしています。 Microsoft は先日の Microsoft Build 2021 で Azure App Service や Functions, Logic Apps, API Magement, Event Grid といった Azure サービスをどの Kubernetes 環境でも実行できるようにする Azure Arc enabled application services を発表しています。 現時点で ECS Anywhere でサポートされない機能 Service Load Balancing Service Discovery ECS Exec Capacity Provider UpdateContainerAgent API によるリモートでの ECS Agent アップデート AWS AppMesh との統合 一番大きいのはサービス負荷分散に対応していない点ではないでしょうか。サービス負荷分散は ELB といい感じに連携してタスク間でトラフィックを分散する機能です。サービスの作成、更新時に「ネットワーク、ロードバランシング、オートスケーリングの設定は、EXTERNAL 起動タイプでは使用できない」というメッセージが表示されます。 External インスタンスの IP アドレスとコンテナが使用するポートを手動で ELB に登録することはできますが、本番ワークロードでの Web サービスの実行は現実的ではありません。この点はドキュメントにも明確に記載されています。 引用 & 参考訳 Amazon ECS 外部インスタンスは、アウトバウンド トラフィックを生成したり、データを処理したりするアプリケーションを実行するために最適化されています。アプリケーションで Web サービスなどのインバウンド トラフィックが必要な場合、Elastic Load Balancing のサポートがないため、これらのワークロードをロードバランサーの背後に配置することがサポートされていないため、これらのワークロードの実行効率が低下します。 まとめ Amazon ECS Anywere のいいところ コントロールプレーンを一切管理せずに、コンテナをオーケストレーションできる 普段 AWS で使用しているものと同じツール群で運用できる これからに期待するところ Web サービスの実行には向かない ECS Anywhere が ELB をサポートしておらず、Service Load Balancing を利用できないため 現時点ではデータ処理系のアプリケーションの実行に最適化されている マルチクラウドを想定したサービスではない オンプレミスにおけるコンテナワークロードに特化 もちろん他クラウドの VM を External インスタンスとして登録してコンテナ実行することは可能 参考 以上です。 参考になれば幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Lambdaトリガー「Kinesis」にある再試行(Retry attempts) パラメタ が「-1」の場合どういう挙動をするか

内容 Lambda関数のトリガーの1つに「Kinesis」がある. 「Kinesis」を選択した場合, 関数がエラーを返すときに再試行する最大回数を指定する "再試行(Retry attempts) パラメタ" を指定することが出来る. このパラメタを明示的に設定しない場合,「-1」が設定される. 「-1」が設定された際の挙動が知りたい. 結論 レコードの期限が切れるまで無限回再試行される. (Streams only) Discard records after the specified number of retries. The default value is infinite (-1). When set to infinite (-1), failed records are retried until the record expires.
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む