What's New Qiita

20200526のAWSに関する記事は30件です。

  • 投稿日：2020-05-26T23:23:34+09:00

Route 53のレコードをタブ区切りで出力するワンライナー

必要になったので書きました。必要なものはAWS CLI v2とjq v1.6です。

aws route53 list-resource-record-sets --hosted-zone-id ZXXXXXXXXXXXX | \
  jq '.ResourceRecordSets [] | if has("ResourceRecords") then [.Name, .Type, .TTL, ([.ResourceRecords[] .Value] | join(","))] else [.Name, .Type, -1, (.AliasTarget .DNSName)] end | @tsv' -r

1レコードに複数の値があるもの（TXTレコードとかMXレコードとか）はカンマ区切りで横に並びます。

出力例

example.com.    MX  3600    1 aspmx.l.google.com,5 alt1.aspmx.l.google.com,5 alt2.aspmx.l.google.com,10 aspmx2.googlemail.com,10 aspmx3.googlemail.com
example.com.    NS  172800  ns-1411.awsdns-99.org.,ns-999.awsdns-99.net.,ns-9999.awsdns-99.co.uk.,ns-999.awsdns-99.com.
dev1.example.com.   A   300 203.0.113.1
dev2.example.com.   A   -1  dualstack.alb-name-999999999.ap-northeast-1.elb.amazonaws.com.

対応できないレコードなどありましたらご指摘ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T23:01:13+09:00

【学習メモ】AWS（SSH　EC2インスタンスへの接続）

1.目標成果物

image.png

2.サーバー構築の作業手順

1.EC2インスタンスを設置する
2.Apacheをインストールする←今回はここ
- SSHでサーバーにログイン←今回はここ
- Apacheをインストール
3.ファイアウォールを設定する

サーバーにログインするとは？

（離れた場所にある）サーバーに入って、自分のPCから操作すること

スクリーンショット 2020-05-26 21.30.39.png

SSHとは？

サーバーと自分の目の前のPCをセキュアに繋ぐサービスのこと。通信内容が暗号化された遠隔ログインシステム。
スクリーンショット 2020-05-26 21.31.41.png

ログインする側：SSHクライアント
ログインされる側：SSHサーバー

ただ、サーバー作成者本人だけがログインできるよう、EC2ではSSHログイン時に公開鍵認証を行っている

スクリーンショット 2020-05-26 21.33.55.png

公開鍵暗号の「暗号」とは？

他の人には内容をわからないようにしてメッセージのやり取りを行うのが暗号

公開鍵暗号のイメージは”南京錠”
スクリーンショット 2020-05-26 21.36.42.png

ソフィー：「ハリーの公開鍵で暗号化」し暗号文をハリーに送付
ハリー：「ハリーの秘密鍵で復号化」

スクリーンショット 2020-05-26 21.38.50.png

＜イメージ＞
1.自分のPCからEC2にログインしたいのでサーバーにリクエスト
2.サーバーから暗号文をPCに
3.もらった暗号文を秘密鍵で復号化し、サーバーに復号化したデータを送付
4.サーバーが元のデータと会っているか検証する
5.ログインOK！

3.いざ、SSHでEC2インスタンスに接続を！

サーバーに入る時はターミナルから

$ chmod 600 [ ssh-key.pem の保存場所]
$ ssh -i [ ssh-key.pem の保存場所 ec2-user@IPアドレス（パブリックIP）]

コマンドの意味
ssh：ssh接続
-i [ ssh-key.pem の保存場所 ec2-user@IPアドレス（パブリックIP）]
：秘密鍵の設定
ex2-user：ユーザー名
@IPアドレス：接続するIPアドレス

こんな感じでログイン完了する。
スクリーンショット 2020-05-26 22.55.42.png

サーバーとの接続をきる時は、「exit」

4.ポート番号について

ポート番号は、プログラムのアドレス。同一コンピュータ内で通信を行うプログラムを識別する時に利用される（＝SSH接続する、HTTP接続するなどの判断をする役割がある）。

スクリーンショット 2020-05-26 22.12.12.png

実際は、ターミナルを下記のように操作する。

スクリーンショット 2020-05-26 22.13.50.png

ssh -i ~/（Desktop　※保存場所）/設定したpem ec2-user@IPアドレス

サーバーにSSH接続できたら、下記の通りに入力

[ec2-user@ip-XX-XX-XX-XX ~]$ sudo lsof -i -n -P

解説
lsof:どのポート番号でどのプログラムが待ち受けているか確認するコマンド
-i:ネットワークソケットファイルを開くオプション。サーバーの待機ポートとプロセスを一覧表示
-n:IPアドレスをホスト名に変換しないオプション
-P:ポート番号をサービス名に変換しないオプション

LISTEN：他のコンピュータから待ち受けているポート
ESTABLISHED：相手と現在通信中のもの

例：
22(LISTEN)について
→SSHDと言うプログラムが22番ポートで待ち受けていると意味
「:」：どのIPアドレスでも接続元として受け付けるという意味

ファイアウォールの設定などは明日アウトプット

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T22:34:46+09:00

AWS 利用方法メモ(サインアップ～セキュリティ設定)

書いてあること

  • AWSサインアップ～セキュリティ設定の手順メモ

ルートユーザーでやること

多要素認証(MFA)を設定

  1. 画面右上のアカウント名
  2. マイセキュリティ資格情報
  3. 多要素認証
  4. MFAの有効化
  5. 仮想MFAデバイス
  6. 続行
  7. QRコードの表示
  8. Authenticatorでスキャン
  9. MFAコードを2回入力
  10. MFAの割り当て
  11. 閉じる

20200525_001.png
20200525_001.png
20200525_002.png
20200525_003.png
20200525_004.png

ルートアクセスキーを削除

  1. 画面右上のアカウント名
  2. マイセキュリティ資格情報
  3. アクセスキー(アクセスキーIDとシークレットアクセスキー)
  4. アクセスキーが表示される場合は削除(デフォルトでは作成されていないはず)

20200525_002.png

パスワードポリシー

  1. IAM
  2. アカウント設定
  3. パスワードポリシーを設定する
  4. 必要な設定をチェック
  5. 変更の保存

20200525_001.png
20200525_002.png

支払通貨

  1. 画面右上のアカウント名
  2. マイアカウント
  3. お支払通貨の設定
  4. 編集
  5. JPY
  6. 更新

20200525_001.png
20200525_002.png

IAMユーザーの請求アクセスを有効化

  1. 画面右上のアカウント名
  2. マイアカウント
  3. IAMユーザー/ロールによる請求情報へのアクセス
  4. 編集
  5. IAMアクセスのアクティブ化にチェック
  6. 更新

20200525_001.png
20200525_002.png

IAMグループを作成

  1. IAM
  2. グループ
  3. 新しいグループの作成
  4. グループ名を入力
  5. 次のステップ
  6. 必要なポリシーをチェック
  7. 次のステップ
  8. グループの作成

20200526_001.png
20200526_002.png
20200526_003.png
20200526_001.png

IAMユーザーを作成

  1. IAM
  2. ユーザー
  3. ユーザーを追加
  4. 必要事項を入力
  5. 次のステップ
  6. 追加するIAMグループをチェック
  7. 次のステップ
  8. 次のステップ
  9. ユーザーの作成

20200526_001.png
20200526_002.png
20200526_003.png
20200526_004.png
20200526_005.png

サインインエイリアスを設定

  1. IAM
  2. カスタマイズ
  3. エイリアスを入力
  4. はい、作成する

20200526_001.png
20200526_002.png

IAMユーザーでやること

多要素認証(MFA)を設定

ルートユーザーと同じ手順で設定

Cost Explorerを有効化

  1. Billing
  2. Cost Explorer
  3. コストエクスプローラーを有効化

請求アラートを設定

  1. Billing
  2. Budgets
  3. 予算を作成する
  4. コスト予算
  5. 予算の設定
  6. 必要事項を入力
  7. アラートの設定
  8. 必要事項を入力
  9. 予算の確認
  10. 作成

image.png
image.png
image.png
image.png

CloudTrail（操作履歴）の設定

  1. CloudTrail
  2. 証跡情報
  3. 証跡の作成
  4. 必要事項を入力
  5. 作成

image.png

AWS Config（リソースの変更履歴）の設定

  1. Config
  2. 今すぐ始める
  3. S3バケット名を変更
  4. 次へ
  5. 次へ
  6. 確認
  7. 「リソースを検出中です」が消えると利用可能となる

image.png
image.png

GuardDuty（驚異の検知・防止）の設定

  1. GuardDuty
  2. 今すぐ始める
  3. GuardDutyの有効化
  4. 設定
  5. 結果サンプルの生成

CloudWatch

  1. CloudWatch
  2. バージニア北部
  3. 請求
  4. アラームの作成
  5. CURRENCYをJPに変更
  6. 以上
  7. 1000
  8. 次へ
  9. 新しいトピックの作成
  10. billing-alerm
  11. 次へ
  12. billing-alerm
  13. 次へ
  14. アラームの作成
  15. メールを確認
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T22:34:46+09:00

AWS サインアップ～セキュリティ設定

書いてあること

  • AWSサインアップ～セキュリティ設定の手順メモ

ルートユーザーでやること

多要素認証(MFA)を設定

  1. 画面右上のアカウント名
  2. マイセキュリティ資格情報
  3. 多要素認証
  4. MFAの有効化
  5. 仮想MFAデバイス
  6. 続行
  7. QRコードの表示
  8. Authenticatorでスキャン
  9. MFAコードを2回入力
  10. MFAの割り当て
  11. 閉じる

20200525_001.png
20200525_001.png
20200525_002.png
20200525_003.png
20200525_004.png

ルートアクセスキーを削除

  1. 画面右上のアカウント名
  2. マイセキュリティ資格情報
  3. アクセスキー(アクセスキーIDとシークレットアクセスキー)
  4. アクセスキーが表示される場合は削除(デフォルトでは作成されていないはず)

20200525_002.png

パスワードポリシー

  1. IAM
  2. アカウント設定
  3. パスワードポリシーを設定する
  4. 必要な設定をチェック
  5. 変更の保存

20200525_001.png
20200525_002.png

支払通貨

  1. 画面右上のアカウント名
  2. マイアカウント
  3. お支払通貨の設定
  4. 編集
  5. JPY
  6. 更新

20200525_001.png
20200525_002.png

IAMユーザーの請求アクセスを有効化

  1. 画面右上のアカウント名
  2. マイアカウント
  3. IAMユーザー/ロールによる請求情報へのアクセス
  4. 編集
  5. IAMアクセスのアクティブ化にチェック
  6. 更新

20200525_001.png
20200525_002.png

IAMグループを作成

  1. IAM
  2. グループ
  3. 新しいグループの作成
  4. グループ名を入力
  5. 次のステップ
  6. 必要なポリシーをチェック
  7. 次のステップ
  8. グループの作成

20200526_001.png
20200526_002.png
20200526_003.png
20200526_001.png

IAMユーザーを作成

  1. IAM
  2. ユーザー
  3. ユーザーを追加
  4. 必要事項を入力
  5. 次のステップ
  6. 追加するIAMグループをチェック
  7. 次のステップ
  8. 次のステップ
  9. ユーザーの作成

20200526_001.png
20200526_002.png
20200526_003.png
20200526_004.png
20200526_005.png

サインインエイリアスを設定

  1. IAM
  2. カスタマイズ
  3. エイリアスを入力
  4. はい、作成する

20200526_001.png
20200526_002.png

IAMユーザーでやること

多要素認証(MFA)を設定

ルートユーザーと同じ手順で設定

Cost Explorerを有効化

  1. Billing
  2. Cost Explorer
  3. コストエクスプローラーを有効化

請求アラートを設定

  1. Billing
  2. Budgets
  3. 予算を作成する
  4. コスト予算
  5. 予算の設定
  6. 必要事項を入力
  7. アラートの設定
  8. 必要事項を入力
  9. 予算の確認
  10. 作成

image.png
image.png
image.png
image.png

CloudTrail（操作履歴）の設定

  1. CloudTrail
  2. 証跡情報
  3. 証跡の作成
  4. 必要事項を入力
  5. 作成

image.png

AWS Config（リソースの変更履歴）の設定

  1. Config
  2. 今すぐ始める
  3. S3バケット名を変更
  4. 次へ
  5. 次へ
  6. 確認
  7. 「リソースを検出中です」が消えると利用可能となる

image.png
image.png

GuardDuty（驚異の検知・防止）の設定

  1. GuardDuty
  2. 今すぐ始める
  3. GuardDutyの有効化
  4. 設定
  5. 結果サンプルの生成

CloudWatch

  1. CloudWatch
  2. バージニア北部
  3. 請求
  4. アラームの作成
  5. CURRENCYをJPに変更
  6. 以上
  7. 1000
  8. 次へ
  9. 新しいトピックの作成
  10. billing-alerm
  11. 次へ
  12. billing-alerm
  13. 次へ
  14. アラームの作成
  15. メールを確認
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T20:49:45+09:00

Qiitaはじめました。

概要

４月から新社会人になった駆け出しエンジニアです。
研修も全面リモートワークということもあり、何かはじめてみようと思い、自分がやってみた（やらなきゃいけない）ことをQiitaにアウトプットしていくことにしました。

初投稿は自分のモチベーションのために、技術的な内容ではなく、これからやってみたいこととか書いていければと思います。

これから何するの？

やっていきたいことは多々あるんですけど、なかでもバックエンドにフォーカスしていければと思います。（とか言いながら最近はVueに挑戦している）

と言うのも、就活をしていたときぐらいから何となくバックエンドの技術に興味があり、ちょっと調べているうちにやってみたいと思うようになったからで。

また、会社の配属先の部署で自動化やネットワークプログラマビリティなどのような高度な技術が必要とのことで、そこらへんに関連するバックエンドを中心に勉強していけたらと思っております。

具体的には？

具体的に取り組んでみたい内容を簡単に書き出してみました。

・Ruby on Rails(Javaの復習がてら)
・AWSのLambdaとかGreengrassとラズパイ
・Dockerでコンテナ型の仮想化を理解
・Kubernetes(ムズい）
などなど。。。

挙げだしたらキリがないです。。。
若干独学で出来るのか不安なところはありますが、会社に詳しい人がいると思うので、色々手を動かしながらやっていきたいです。

おい、資格の勉強はどうした？

資格て応用情報のことですよね。結論としては多分受けないです。
その代わり(?)といっては何ですが、今年から始まったCiscoのDevNet認定に今興味があり、色々調べています。

というのも、カリカリ勉強するよりパチパチコード書いてアウトプットしていったほうが圧倒的にスキルになるなと最近感じ始めたからで。

DevNet認定ではネットワークの基礎知識だけではなく、冒頭に申し上げたネットワークプログラマビリティや自動化が範囲としてあり、Python/Git/APIなどの幅広いモダンな開発知識が求められます。
個人的にIoT/IoEやDevOpsに興味があるので、ピッタリな内容かなと思いました。

お前、英語のこと忘れてるだろ

はい、最近気付きました。
チリツモを信じて毎朝Duoのチャプターひとつやるようにしてます。。。頑張ります。。。

最後に一言

これから長い長いエンジニア人生がはじまりますが、クリエイティブな思考を忘れないようにしたいものです。

ということで、これから触ってみた技術や知見をQiitaに書き留めていきたいと思います。
はじめはクオリティ低いと思いますが、よろしくお願いします。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T19:55:55+09:00

AWS SAA-C02 合格体験記

0. はじめに

今人気のIT資格、AWS 認定ソリューションアーキテクト アソシエイトの新試験版（SAA-C02）に（ぎりぎり）合格しました。

スクリーンショット 2020-05-26 19.40.21.png

本当にぎりぎりの合格だったので、このような記事を書くことにおこがましさも感じなくはないですが、受験記録として残しておきます。

以下について振り返ります。

  1. 受験動機
  2. 学習期間
  3. 学習方法
  4. 試験の感想

1. 受験動機

まず、受験を決めた動機には、

  • 周りのエンジニアの友人が続々と合格していた
  • 本業のプロジェクト全体像の把握のためにAWSの理解を深める必要性を感じた

というのがあります。

特に後者についてはその必要性を強く感じていました。

SAAの試験勉強を開始するまで、実際に利用したことのあるAWSのリソースといえば、EC2やS3くらいでした。
担当することになったサービスでは、DynamoDBやLambda、Kinesis、RDS、Auroraなどが使われていました。
各種AWSリソースがどのような意図で使われているかが分からないために、アプリケーション側の実装ですら詰まってしまうこと、先輩エンジニア間の会話についていけないこと等の問題がありました。

このような問題を解消するために受験を決めました。

2. 学習期間

学習開始日: 2020年2月11日
試験日: 2020年5月24日

計算してみると合計102日間でした。

102日間毎日根詰めて勉強していたわけではなく、特に最初の方は1日平均1時間程度の学習で、時に一切試験学習を行わない週もあったりと、ばらつきはあったかと思います。

少なく見積もって合計100時間、多くて200時間くらいかけたという気がします。

他の合格体験記を見ると、合格するまでの期間は、3週間だったり1年だったりと様々でした。
僕の場合はどちらかというと時間がかかった方なのかなと思います。

3. 学習方法

振り返ってみると、以下の3ステップに分かれていた気がします。
書籍は以下に記載していない分も購入しましたが、僕が実際に行った対策としてはこれで全てです。

  1. ハンズオン学習

  2. 書籍学習

  3. 模擬試験演習

3-1. ハンズオン学習

こちらの記事で推されていた教材でした。

これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）

良かった点と悪かった点についてまとめます。

良かった点

  • 教材としてまとまっている。
  • 最新版に対応するよう日々アップデートされている。
  • ハンズオン学習が行える（特にこの教材の最初の方の、VPC周りのハンズオンはやっておいて良かったと思いました。しかしやらなくても合格は可能だと思います）。
  • スライドがダウンロードできる。
  • 模擬試験がついている。

悪かった点

  • ハンズオンを全て行おうとすると時間がかかる（RDSの章の途中でやめた気がします）。

SAAの試験の特徴として、ベストプラクティスとWell Architected Frameworkの実践？があるので、ハンズオン自体はテストにも有効でした。ただ律儀にハンズオンをやっていくと、RDSの作成が完了するのを待っているだけで1時間くらいかかったりするので、心が折れた記憶があります。

この教材だけで合格できる人もいるようですが、レビューを見るとそうでない人の方が多いようです。

SAAの学習法として、問題を解けるようになっていく中でAWSのサービス、ベストプラクティスを理解していくことが大事だと思います。
今僕が0から勉強するのであれば、ハンズオンは行わず、2倍速再生で動画を進め、小テストと模試を全て解けるようになることを目指して繰り返す、という感じで進めるのもいいかなと感じています。

付属の模擬試験については1と2について3周づつ行いました。結果は以下でした。

模擬試験①
1回目: 50%, 2回目: 84%, 3回目: 76%

模擬試験②
1回目: 36%, 2回目: 80%, 3回目: 80%

3-2. 書籍学習

ブログやQiita、Amazonのレビューを見て選びました。

それぞれ良かった点と悪かった点についてまとめます。

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

良かった点

  • ページ構成が分かりやすいので、サービスの全体像がつかみやすい。

悪かった点

  • 各サービスの説明は単調なので、黒本等に比べて分かりやすくはないと思う。
  • ページ量が多い。
  • ↑にも関わらず最新の頻出問題を一部カバーしていない。(Amazon FSx、など)

一夜漬け AWS認定ソリューションアーキテクト アソシエイト 直前対策テキスト

良かった点

  • 書籍の中では、カバー範囲が最新の問題傾向に最も近い気がする。

悪かった点

  • 本のタイトルにもあるように仕上げ用の教材なので、サービスの全体像がわかっていない段階で読んでも身につかなさそう。

SAA受験者のブログ記事等を読むと、書籍は1冊ではカバーできないという声が多い気がします。僕の場合は結果としてUdemy模擬試験中心の学習になりましたが、書籍中心の学習で試験に臨む場合は、Blackbeltやホワイトペーパーをしっかり読み込むというハードな学習が必要な気がします。

3-3. 模擬試験演習

教材のレビューで合格者が多かったことと、こちらのブログから、僕のSAA試験学習は、以下Udemy模擬試験の問題演習が中心でした。

【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

良かった点

  • 6回分の問題がついているので、演習量が確保できる。
  • 最新版に対応するよう日々アップデートされている。
  • 解説がAWS公式ドキュメントの引用。
  • 問題難易度が適切。

悪かった点

  • 誤植が多め。
  • 模擬試験の点数が低くても合格できるため、合否の参考にはならない。

僕の場合、1回目はどの模擬試験も約50点。
2, 3回目は70~90点（問題を覚えているだけの場合もあり）でした。

周回の仕方ですが、1回目を解いた後、解説を読んだり書いたりし、すぐに2回目を解き、解き終わったら再度解説を読んだり書いたりしました（正解の問題に対しても行いました）。
試験直前の1週間で、1日に模擬試験1つのペースで3回目を解き、総復習を行いました。

こちらの模擬試験で学習し合格しました、というレビューをたびたび見返しモチベーションにしたりしていました。

模擬試験①
1回目: 72%, 2回目: 87%, 3回目: 83%

模擬試験②
1回目: 49%, 2回目: 95%, 3回目: 75%

模擬試験③
1回目: 52%, 2回目: 86%, 3回目: 86%

追加模擬試験⑥
1回目: 52%（試験前日に解いた）

4. 試験の感想

試験中は、手応え的にUdemyの模擬試験問題集を解いている時と近かったため、50%くらいの正解率で不合格になるんじゃないかと常に感じていました。

Udemyの模擬試験問題集と比較すると、問題文から回答になる選択肢を選びやすかった気がします。そのため、じっくり問題文を読んで厳密に選択肢を選んでいけば得点は上がるのかなと思います。

※ 受験者スコアが100-1000の間になるようなので、実質的な問題の正解率は本当に50-60%くらいだったかもしれません。

中にはUdemyの模擬試験問題集からの的中問題も複数ありました。

オンプレからAWSクラウドへの移行に関する問題（Snowball, Direct Connect等）も、対策本ではあまり触れられていない内容な気がしますが、最近頻出なのでしょうか？

よく言われていることではありますが、Well Architectedフレームワークに則してサービス（またはサービスの組み合わせ）を選ぶ問題が中心です。可用性について聞かれているのにパフォーマンスを優先した解答を選んだりしないなど、それぞれのサービスがWell Architectedフレームワークのどの柱に当てはまるかを、学習時から覚えていく必要があります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T18:31:49+09:00

AWS CodeCommit

AWS CodeCommit とは

CodeCommit は、セキュアでスケーラブル性が高いマネージド型ソースコントロールサービスで、プライベート Git リポジトリをホストします。CodeCommit では、ソース管理システムを管理したり、そのインフラストラクチャをスケールしたりする必要がありません。CodeCommit を使用してコードからバイナリまであらゆるものを保存します。Git の標準機能がサポートされているため、既存の Git ベースのツールをシームレスに使用できます。

AWS CodeCommit に移行する

Git リポジトリを CodeCommit リポジトリ に移行するには、クローニング、ミラーリング、ブランチの全部または一部の移行などさまざまな方法があります。また、コンピュータ上のローカルでバージョン管理されていないコンテンツを CodeCommit に移行することもできます。

  • Git リポジトリを AWS CodeCommit に移行
  • コンテンツを CodeCommit に移行する
  • リポジトリの段階的移行

Git リポジトリを AWS CodeCommit に移行

既存の Git リポジトリ CodeCommit リポジトリ に移行できます。

スクリーンショット 2020-05-26 18.18.37.png

コンテンツを CodeCommit に移行する

ローカルまたはバージョン管理対象外のコンテンツを AWS CodeCommit に移行する

スクリーンショット 2020-05-26 18.20.15.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T17:52:14+09:00

Amazon AWS Cloud9環境(EC2)でHTTP/2プロトコルに対応する(Apache)

HTTP/2 対応に必要な条件

私のCloud9環境はほぼ全て対応済だったのでだいぶ楽でした。
これからの時代はAWSですね。

Apache Ver 2.4.17以上であること

$ httpd -v

Server version: Apache/2.4.41 (Amazon)
Server built:   Oct 15 2019 22:21:35

OpenSSL Ver 1.0.2以上であること

$ openssl version

OpenSSL 1.0.2k-fips  26 Jan 2017

mod_http2をインストールしていること

$ httpd -M | grep http2

http2_module (shared)

$ less /etc/httpd/conf.modules.d/00-base.conf | grep 'mod_http2'

LoadModule http2_module modules/mod_http2.so

SSL対応していること(任意?)

こちら私の環境は未対応でした。
このためだけにRoute53でドメイン取得したりすんのはだるいので、
オレオレ証明書で対応することにしました。

以下の記事に書いてある通りに進めれば、
特にトラブルもなく対応できました。

https://qiita.com/abetd/items/d8ef4767ff1ac8284aa8

もしかすると、SSL対応しなくても
HTTP/2対応できるかもしれませんが試してません。

https://qiita.com/horizontal/items/ca350bd8a4f15d1f4fbc

特筆すべき点

私の環境はmod_sslをインストールしてなかったみたいなので、
yumでインストールしました

sudo yum install mod24_ssl.x86_64

上のモジュールをインストールし、オレオレ証明書でSSL対応して、
curlコマンドでHTTP/2になったかを確認してみたところ、
なってませんでした。

理想
curl -I --http2 ---insecure https://XX.XXX.XXX.XX/

HTTP/2 200 <-- これが出るはず

現実
curl -I --http2 ---insecure https://XX.XXX.XXX.XX/

HTTP/1.1 200 <-- あれ～～？？

「mpmでpreforkモジュールが設定されているとHTTP2が無効化される」らしいです。
自分でも何を言っているのかわかりません。ごめんなさい。

とりあえず以下のサイトにある通り、
00-mpm.conf から mpm_prefork_module をコメントアウトし、
mpm_event_module を有効化して、Apache再起動したらHTTP/2で読み込まれました。

https://www.kannon.link/fuku/index.php/2018/09/01/01-49/

$ sudo vi /etc/httpd/conf.modules.d/00-mpm.conf

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
LoadModule mpm_event_module modules/mod_mpm_event.so

動作確認

curlコマンドを叩くことで確認できます。
私の環境はオレオレ証明書を使っているので --insecure オプションが必要です

curl -I --insecure --http2 https://XX.XXX.XXX.XX

HTTP/2 200

あるいは、ブラウザからでも簡単に確認することもできます

https://nelog.jp/http2-browser-extensions

なぜ対応したのか？

Burp Suiteを用いて自分の開発環境で脆弱性診断を実施したところ、
「HTTPリクエストスマグリング」という脆弱性があることがわかったからです。

そして、その解決策は
「通信プロトコルをHTTP/1.1からHTTP/2にアップグレードすることである」
と書いてあったので、そうした次第です

BurpSuiteに書いてあった文章を翻訳したものを下記します。

問題の背景

HTTP リクエストの密輸の脆弱性は、
ウェブサイトが HTTP のパースが一貫していないウェブサーバを介して
HTTP リクエストをルーティングするときに発生します。

異なるサーバによって異なる長さと解釈されるリクエストを提供することで、
攻撃者はバックエンドの TCP/TLS ソケットを毒し、
次のリクエストに任意のデータを追加することができます。

ウェブサイトの機能にもよりますが、
フロントエンドのセキュリティルールを迂回したり、
内部システムにアクセスしたり、
ウェブキャッシュを毒したり、
サイトを積極的に閲覧しているユーザーに対して
様々な攻撃を仕掛けたりすることができます。

問題の修正

この脆弱性のすべてのバリエーションを解決するには、
フロントエンドサーバがバックエンドシステムとの通信に
HTTP/2 を排他的に使用するように設定するか、
バックエンド接続の再利用を完全に無効にする必要があります。

あるいは、チェーン内のすべてのサーバが同じ設定で
同じウェブサーバソフトウェアを実行していることを確認することもできます。

この脆弱性の特定のインスタンスは、
フロントエンドサーバを再設定して
曖昧なリクエストを正常化してからルーティングするか、
バックエンドサーバが曖昧なリクエストに遭遇したときに
メッセージを拒否して接続を閉じるように設定することで解決できます。

コマンド履歴

未来の自分のために、どんなコマンドを叩いたのかを記します

openssl version
yum list installed | grep openssl
httpd -v
sudo cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
sudo vi /etc/httpd/conf/httpd.conf
sudo service httpd restart
httpd -M | grep http2
less /etc/httpd/conf.modules.d/00-base.conf | grep 'mod_http2'
ls -l /etc/httpd/modules/ | grep ssl
sudo yum list available | grep ssl
sudo yum install mod24_ssl.x86_64 
ls -l /etc/httpd/modules/ | grep ssl
mkdir ~/ssl
cd ~/ssl
openssl genrsa -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
sudo cp -p ca.crt /etc/pki/tls/certs/
sudo cp -p ca.key /etc/pki/tls/private/
sudo cp -p ca.csr /etc/pki/tls/private/
restorecon -RvF /etc/pki/
sudo cp /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.bak
sudo vi /etc/httpd/conf.d/ssl.conf
sudo service httpd restart
curl -I --insecure --http2 https://XX.XXX.XXX.XX
sudo less /etc/httpd/logs/error_log
sudo cp /etc/httpd/conf.modules.d/00-mpm.conf /etc/httpd/conf.modules.d/00-mpm.conf.bak
sudo vi /etc/httpd/conf.modules.d/00-mpm.conf
sudo service httpd restart
history

参考URL

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T17:50:25+09:00

KEDAを使って、SQSのMessage数に応じたAutoScaleを実装してみる。

はじめに

4/6に「KEDA」（Kubernetes Event-driven Autoscaling）がCloud Native Computing Foundation（CNCF）プロジェクトに採用されたことが発表されました。

KEDAとは、Kubernetes-based Event Driven Autoscaling Componentの略で、SQSのメッセージ数などに応じてpodをscaleさせる機能を提供します。

そこで今回は、KEDAを使ってEKS上のpod数を、SQSのメッセージ数に応じてAutoScale In/Outさせてみようと思います。

構成図

構築手順

事前準備

今回、helmを使ってKEDAをデプロイするため、kubectlを発行する環境にAWSの公式ドキュメントに従ってhelmをインストールしておきます。

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

helmでKEDAをデプロイ

こちらを参考にさせていただきました。
https://keda.sh/docs/1.4/deploy/
https://www.slideshare.net/tsukasakatou9/kubernetes-keda

1.helm repoを追加

$ helm repo add kedacore https://kedacore.github.io/charts
"kedacore" has been added to your repositories

2.helm repoをアップデート

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "kedacore" chart repository
Update Complete. ⎈ Happy Helming!⎈

3.KEDAのhelm chartをインストール
helmのバージョンを確認します。

$ helm version
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

versionが3.xの場合は下記。

$ kubectl create namespace keda
namespace/keda created
$ helm install keda kedacore/keda --namespace keda
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
NAME: keda
LAST DEPLOYED: Wed May 20 13:08:49 2020
NAMESPACE: keda
STATUS: deployed
REVISION: 1
TEST SUITE: None

4.keda-operator podが起動したことを確認

$ kubectl get pods -n keda
NAME                                               READY   STATUS    RESTARTS   AGE
keda-operator-5895ff46b9-vswhs                     1/1     Running   0          3m58s
keda-operator-metrics-apiserver-6774776dbc-p5m2j   1/1     Running   0          3m58s

SQSに紐づける

こちらを参考にしました。
https://github.com/patnaikshekhar/KEDA-AWS-SQS-Python

1.namespaceの作成
SQSのscaleout用namespaceを作成します。

$ kubectl create namespace keda-aws-sqs-test-01
namespace/keda-aws-sqs-test-01 created

動作確認

最後に

結構大変でしたが、SQSの数でAutoScaleIn/Outさせることができました。
しかし、CoolDownTimeの設定など今回説明できなかった部分もあるので、次回は詳細なパラメータを調べて説明しようと思います。
（まだ調べていないので、設定項目が無い可能性もあります。何が大変かって、日本語のドキュメントがないんだもの。）

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T17:50:25+09:00

KEDAを使って、SQSのMessage数に応じたAutoScaleを実装してみる。　-構築編-

はじめに

4/6に「KEDA」（Kubernetes Event-driven Autoscaling）がCloud Native Computing Foundation（CNCF）プロジェクトに採用されたことが発表されました。

KEDAとは、Kubernetes-based Event Driven Autoscaling Componentの略で、SQSのメッセージ数などに応じてpodをscaleさせる機能を提供します。

そこで今回は、KEDAを使ってEKS上のpod数を、SQSのメッセージ数に応じてAutoScale In/Outさせてみようと思います。

今回は、環境構築までの流れを説明します。

構築手順

事前準備

今回、helmを使ってKEDAをデプロイするため、kubectlを発行する環境にAWSの公式ドキュメントに従ってhelmをインストールしておきます。

$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

helmでKEDAをデプロイ

こちらを参考にさせていただきました。
https://keda.sh/docs/1.4/deploy/
https://www.slideshare.net/tsukasakatou9/kubernetes-keda

1.helm repoを追加

$ helm repo add kedacore https://kedacore.github.io/charts
"kedacore" has been added to your repositories

2.helm repoをアップデート

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "kedacore" chart repository
Update Complete. ⎈ Happy Helming!⎈

3.KEDAのhelm chartをインストール
helmのバージョンを確認します。

$ helm version
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

versionが3.xの場合は下記。

$ kubectl create namespace keda
namespace/keda created
$ helm install keda kedacore/keda --namespace keda
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
manifest_sorter.go:192: info: skipping unknown hook: "crd-install"
NAME: keda
LAST DEPLOYED: Wed May 20 13:08:49 2020
NAMESPACE: keda
STATUS: deployed
REVISION: 1
TEST SUITE: None

4.keda-operator podが起動したことを確認

$ kubectl get pods -n keda
NAME                                               READY   STATUS    RESTARTS   AGE
keda-operator-5895ff46b9-vswhs                     1/1     Running   0          3m58s
keda-operator-metrics-apiserver-6774776dbc-p5m2j   1/1     Running   0          3m58s

これで、KEDAが動作するために必要なpodが起動していることが分かります。

最後に

今回は、一旦KEDAを動作させるための環境を用意するところまで説明しました。
次回は実際にSQSと連携さえてpodをAutoScaleIn?Outさせてみようと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T17:34:23+09:00

AWS OpsWorks とは

AWS OpsWorks とは

AWS OpsWorks は、Puppet または Chef を使用して、クラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービス

AWS OpsWorks スタックおよび AWS OpsWorks for Chef Automate を使用して、Chef クックブックとソリューションを設定管理に使用できます。また、OpsWorks for Puppet Enterprise を使用すると AWS 内で Puppet Enterprise マスターサーバーを設定できます。Puppet は、インフラストラクチャの目的の状態の強化、およびオンデマンドタスクの自動化のための、一連のツールを提供します。

AWS OpsWorks サービス

  • AWS OpsWorks for Puppet Enterprise
  • AWS OpsWorks for Chef Automate
  • AWS OpsWorks スタック

AWS OpsWorks for Puppet Enterprise

OpsWorks for Puppet Enterprise を使用して、AWS マネージド Puppet マスターサーバーを作成できます。Puppet マスターは、インフラストラクチャ内のノードを管理し、それらのノードに関する情報を保存し、Puppet モジュールの中央リポジトリとして機能します。モジュールは、インフラストラクチャの設定方法に関する手順が格納された Puppet コードの再利用および共有が可能なユニットです。Puppet Forge からコミュニティモジュールをダウンロードすることも、Puppet 開発キットを使用して独自のカスタムモジュールを作成することもできます。その後、Puppet Code Manager を使用してデプロイを管理できます。

OpsWorks for Puppet Enterprise では Puppet Enterprise ソフトウェアが管理されるため、ユーザーが選択した時間に自動的にサーバーをバックアップでき、サーバーでは常に最新の AWS 対応バージョンの Puppet が実行され、常に最新のセキュリティ更新プログラムが適用されています。新しい Amazon EC2 Auto Scaling グループを使用して、新しい Amazon EC2 ノードを自動的にサーバーと関連付けることができます。

AWS OpsWorks for Chef Automate

AWS OpsWorks for Chef Automate により、Chef Automate のプレミアム機能が含まれる AWS によって管理される Chef サーバーを作成でき、Chef DK など Chef ツールを使用してそれらを管理できるようになります。Chef サーバーは、環境内のノードを管理し、それらのノードに関する情報を保存し、Chef クックブックの中央リポジトリとして機能します。クックブックには、Chef を使用して管理する各ノードに対して Chef Infra クライアント (chef-client) エージェントによって実行されるレシピが含まれています。knife や Test Kitchen などの Chef ツールを使用して、AWS OpsWorks for Chef Automate サービスの Chef サーバー上でノードおよびクックブックを管理できます。

Chef Automate は、継続的デプロイおよびコンプライアンスチェックのための自動化ワークフローを提供する、付属のサーバーソフトウェアパッケージです。AWS OpsWorks for Chef Automate では Amazon Elastic Compute Cloud の 1 つのインスタンスを使用して、Chef Automate、Chef Infra、Chef InSpec がインストールされて管理されます。AWS OpsWorks for Chef Automate を使用すると、AWS OpsWorks に固有の変更を行うことなく、コミュニティ作成またはカスタムの Chef クックブックを使用できます。

AWS OpsWorks for Chef Automate では 1 つのインスタンスで Chef Automate コンポーネントが管理されるため、お客様が選択した時間に自動的にサーバーをバックアップでき、サーバーでは常に最新のマイナーバージョンの Chef が実行され、常に最新のセキュリティ更新プログラムが適用されています。新しい Amazon EC2 Auto Scaling グループを使用して、新しい Amazon EC2 ノードを自動的にサーバーに関連付けることができます。

AWS OpsWorks スタック

クラウドベースのコンピューティングには通常、EC2 インスタンスや Amazon Relational Database Service (RDS) インスタンスなどの AWS リソースのグループが関与します。たとえば、ウェブアプリケーションでは通常、アプリケーションサーバー、データベースサーバー、ロードバランサー、その他のリソースが必要です。このインスタンスのグループは通常、スタックと呼ばれます。

オリジナルのサービスである AWS OpsWorks スタックでは、スタックとアプリケーションを作成および管理するためのシンプルで柔軟な方法が提供されています。AWS OpsWorks スタックによって、スタック内のアプリケーションをデプロイおよびモニタリングできます。レイヤーと呼ばれる、特別なグループ内のクラウドリソースの管理に役立つスタックを作成できます。レイヤーは、アプリケーションへのサービス提供やデータベースサーバーのホスティングなどの特定の目的を果たす一連の EC2 インスタンスを表します。レイヤーでは、Chef レシピに基づいて、インスタンスへのパッケージのインストール、アプリケーションのデプロイ、スクリプトの実行などのタスクが処理されます。

AWS OpsWorks for Chef Automate とは異なり、AWS OpsWorks スタックでは Chef サーバーは不要であり、Chef サーバーは作成されません。AWS OpsWorks スタックは Chef サーバーの機能の一部を実行します。AWS OpsWorks スタックは、インスタンスのヘルスチェックをモニタリングし、自動ヒーリングおよび Auto Scaling を使用して、必要な場合に新しいインスタンスのプロビジョンを実行します。シンプルなアプリケーションサーバースタックの例を次の図に示します。

AWS OpsWorks スタック

スクリーンショット 2020-05-26 17.13.19.png

  • スタック
    • スタックは AWS OpsWorks スタックの中心となるコンポーネントです。これは基本的に AWS リソース (Amazon EC2 インスタンス、Amazon RDS データベースインスタンスなど) 用のコンテナです。目的が共通で、論理的に一括して管理されます。スタックにより、ユーザーはこれらのリソースをグループで管理することができます。また、インスタンスのオペレーティングシステムや AWS リージョンなどの一部のデフォルトの構成設定もスタックにより定義されます。ユーザーの直接操作から分離する必要のあるスタックコンポーネントがある場合、そのスタックを VPC 内で実行することもできます。
  • Layer
    • 1 つ以上の Layer を追加することにより、スタックのコンポーネントを定義します。Layer は、アプリケーションへのサービス提供やデータベースサーバーのホストのような特定の目的を果たす一連の Amazon EC2 インスタンスを表します。

  • レシピおよびライフサイクルイベント

    • 1 つのインスタンスが複数のレイヤーに属している場合、AWS OpsWorks スタックはレイヤーごとにレシピを実行するため、たとえば、PHP アプリケーションサーバーと MySQL データベースサーバーをサポートする 1 つのインスタンスを作成できます。

  • インスタンス

    • インスタンスとは、Amazon EC2 インスタンスなどの 1 つのコンピューティングリソースを意味します。インスタンスは、オペレーティングシステムやサイズなど基本的な設定を定義します。Elastic IP アドレスや Amazon EBS ボリュームなどのその他の設定は、インスタンスの Layer によって定義されます。Layer のレシピは、パッケージをインストールして設定したりアプリケーションをデプロイしたりするタスクを実行することで設定を完了します。
    • AWS OpsWorks スタックを使用してインスタンスを作成し、それをレイヤーに追加できます。インスタンスを起動すると、AWS OpsWorks スタックによって、インスタンスとそのレイヤーで指定されている設定を使用して Amazon EC2 インスタンスが起動されます。Amazon EC2 インスタンスの起動後、AWS OpsWorks スタックはインスタンスとサービス間の通信を処理するエージェントをインストールし、ライフサイクルイベントに応じて適切なレシピを実行します。
    • AWS OpsWorks スタックは、起動方法と停止方法によって区別される以下のインスタンスタイプをサポートしています。
      • 24/7 インスタンスは、ユーザーが手動で起動し、ユーザーが停止するまで実行されます。
      • 時間ベースのインスタンスは、指定した日単位や週単位のスケジュールに応じて AWS OpsWorks スタックによって実行されます。
      • 負荷ベースのインスタンスは、CPU 使用率などの負荷のメトリクスに基づいて AWS OpsWorks スタックによって自動的に起動および停止されます。

AWS OpsWorks スタックでは、インスタンスの自動ヒーリングがサポートされています。エージェントとサービスの間の通信が途絶えると、AWS OpsWorks スタックは自動的にインスタンスの停止と再起動を行います。

アプリケーション

ユーザーは Amazon S3 バケットなどのリポジトリにアプリケーションおよび関連ファイルを保存します。各アプリケーションは、アプリケーションタイプを指定した App として表されます。App には、リポジトリからインスタンスにアプリケーションをデプロイするために必要な情報 (リポジトリ URL、パスワードなど) も指定します。アプリケーションをデプロイすると、AWS OpsWorks スタックによって Deploy イベントがトリガーされ、スタックのインスタンスで Deploy レシピが実行されます。

  • 自動
    • インスタンスを起動すると、AWS OpsWorks スタックによってインスタンスの Deploy レシピが自動的に実行されます。
  • 手動
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T17:16:28+09:00

CloudFormationでVPC、サブネット、インターネットゲートウェイを作成する

はじめに

現在CloudFormationを学習しており、備忘録として記事を書きます。

  • CidrBlockが既存のVPCと重複してなければどのリージョンでも作成出来ます。
  • プライベートサブネットにはRDSしか設置する予定がないため、NATゲートウェイは作成しません。

コード

Create-vpc.yml
AWSTemplateFormatVersion: "2010-09-09"
Description: VPC & subnet create

Resources:
  MyFirstVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.1.0.0/16
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      InstanceTenancy: default
      Tags:
        - Key: Name
          Value: CloudFormation-VPC
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyFirstVPC
      Tags:
        - Key: Name
          Value: CloudFormation-VPC-PublicRT

  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyFirstVPC
      Tags:
        - Key: Name
          Value: CloudFormation-VPC-PrivateRT

  PublicSubnet0:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyFirstVPC
      CidrBlock: 10.1.0.0/24
      AvailabilityZone: !Select
        - 0
        - Fn::GetAZs: !Ref "AWS::Region"
      Tags:
        - Key: Name
          Value: CloudFormation-public-subnet-0

  PubSubnet1ARouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet0
      RouteTableId: !Ref PublicRouteTable

  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyFirstVPC
      CidrBlock: 10.1.2.0/24
      AvailabilityZone: !Select
        - 1
        - Fn::GetAZs: !Ref "AWS::Region"
      Tags:
        - Key: Name
          Value: CloudFormation-public-subnet-1

  PubSubnet1CRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet1
      RouteTableId: !Ref PublicRouteTable

  PrivateSubnet0:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyFirstVPC
      CidrBlock: 10.1.1.0/24
      AvailabilityZone: !Select
        - 0
        - Fn::GetAZs: !Ref "AWS::Region"
      Tags:
        - Key: Name
          Value: CloudFormation-private-subnet-0

  PriSubnet1ARouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet0
      RouteTableId: !Ref PrivateRouteTable

  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyFirstVPC
      CidrBlock: 10.1.3.0/24
      AvailabilityZone: !Select
        - 1
        - Fn::GetAZs: !Ref "AWS::Region"
      Tags:
        - Key: Name
          Value: CloudFormation-private-subnet-1

  PriSubnet1CRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet1
      RouteTableId: !Ref PrivateRouteTable

  myInternetGateway:
    Type: "AWS::EC2::InternetGateway"
    Properties:
      Tags:
        - Key: Name
          Value: CloudFormation-ING
  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyFirstVPC
      InternetGatewayId: !Ref myInternetGateway
  myRoute:
    Type: AWS::EC2::Route
    DependsOn: myInternetGateway
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref myInternetGateway

Outputs:
  StackVPC:
    Description: The ID of the VPC
    Value: !Ref MyFirstVPC
    Export:
      Name: !Sub "${AWS::StackName}-VPCID"

  StackPublicSubnet0:
    Description: The ID of the VPC Subnet
    Value: !Ref PublicSubnet0
    Export:
      Name: !Sub "${AWS::StackName}-PublicSubnet0"

  StackPublicSubnet1:
    Description: The ID of the VPC Subnet
    Value: !Ref PublicSubnet1
    Export:
      Name: !Sub "${AWS::StackName}-PublicSubnet1"

  StackPrivateSubnet0:
    Description: The ID of the VPC Subnet
    Value: !Ref PrivateSubnet0
    Export:
      Name: !Sub "${AWS::StackName}-PrivateSubnet0"

  StackPrivateSubnet1:
    Description: The ID of the VPC Subnet
    Value: !Ref PrivateSubnet1
    Export:
      Name: !Sub "${AWS::StackName}-PrivateSubnet1"

AWS CLIでスタックの登録

AWS CLIで登録します。 

% aws --version
aws-cli/2.0.10 Python/3.7.4 Darwin/19.4.0 botocore/2.0.0dev14

% aws cloudformation create-stack \
--tags Key="name",Value="test" \
--stack-name TESTSTACK \
--template-body file://Create-vpc.yml

成功したか確認します。

% aws cloudformation list-stacks \
--stack-status-filter CREATE_COMPLETE \
| jq -r ".StackSummaries[].StackName" | head -n1
TESTSTACK

要らなくなったら削除します。

% aws cloudformation delete-stack --stack-name TESTSTACK
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T16:29:33+09:00

AWS初心者が在宅勤務中にAWSの資格を取る記録 まとめ ～CLF編～

はじめに

およそ1か月に渡り「AWS初心者が在宅勤務中にAWSの資格を取る記録」というタイトルで記事を投稿し続けてきました。
こちらで軽い自己紹介や経緯などを書いておりますので、ご一読いただければと思います。
https://qiita.com/t_fuku/items/86711474e83a739bfde4

上記の記事には書いていないのですが、なぜCLFの方から手を付けたのかと言うと
SAAから入ると時間がかかって、ダレてくるかもしれないと危惧したからです。

SAAから入って結果的にSAAを取得できたとしても、ダラダラと取得するよりは有意義かなと思いました。
実際、SAAの前段階としてCLFを取得した時は中々いいスコアで合格できたのでとても嬉しかったですし、
何より結果が目に見えるのでそれが一番モチベーションになりました。（認定バッジカッコいいですよね）

どうやって勉強進めてた？

4/2より在宅勤務になったのですが、以下のように進めていました。
具体的に書いた方が自身の立場に置き換えてイメージしやすいかと思いますので、出来るだけ詳細に書いていきます。

長くなってしまいます、ご了承下さい。

■4/2～4/13週（およそ2週間）

★Udemyで以下のコースを受講して、実際にサービスに触れることでAWSとは何たるかのイメージを掴む作戦

「手を動かしながら2週間で学ぶ AWS 基本から応用まで」
https://www.udemy.com/course/1706378

大体、1日に1～2セクション程のペースで進めていました。
ハンズオンが中心なので、毎日PCと向き合いながら社内の検証環境を触ってました。

こちらは私が欲しい情報と内容が非常にマッチしており、イメージを掴むのには最高でした。
また、かなり個人的な意見になりますが、講師の方の声が心地よく快適に理解を進めることができました。
（こういうのもメチャメチャ大事な要素ですよね）

現在は販売していないのがかなり惜しまれます。

■4/20～4/27週（およそ2週間）

★以下の参考書をサラッと読んで、各サービスの概要を掴もう作戦
①「図解即戦力　Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書」
　https://www.amazon.co.jp/dp/B08147GCLS/ref=cm_sw_r_tw_dp_U_x_1W2YEb1Q8TEDT

②「AWS認定資格試験テキスト　AWS認定 ソリューションアーキテクト-アソシエイト」
　https://www.amazon.co.jp/dp/B07R1H87Y1/ref=cm_sw_r_tw_dp_U_x_1W2YEbSFPSMZ9

当初、上記の参考書は毎日数十ページ程、パラパラと読むだけで進めていました。
後々、この勉強法は自分には合ってないなと気付きます。

★koiwaclubで問題に取り組む作戦
　https://aws.koiwaclub.com/

CLFやSAAの問題がかなりの問題数掲載されており、詳しめの解説も掲載されています。

問題数は多いですが、毎日やって最終的に2周しました。
また、問題を解きながら不明点やまとめはメモを取っていました。

個人差はあると思いますが、取り組んでみての感想です。

・難易度で言うと簡単な部類かも
・図が少なくてイメージが定着し辛い

こちらで最終的に正答率が80%以上になって手応えを掴めたところで、Udemyの模擬問題集に取り組むことにしました。

■5/1～5/6（およそ1週間）

5/7にCLFを受験することにしたので、GW返上で毎日数時間を勉強に充てました。
この期間はひたすら模擬問題集の解答と見直しをしていました。

また、SAAの学習も並行して進めることにしました。

★GWでUdemyの模擬試験解きまくるぞ作戦
「この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問）」
　https://www.udemy.com/course/aws-4260

こちらもkoiwaclubと同じで、解く→見直しの反復で進めていき、正答率が80%以上になるまで取り組みました。
参考までに取り組んだ時の記録を載せておきます。

【1回目】
　基本①：80% 52/65
　基本②：67% 44/65
　応用①：49% 32/65
　応用①：60% 39/65

【2回目】
　基本①：92% 60/65
　基本②：86% 56/65
　応用①：61% 40/65
　応用①：66% 43/65

【3回目】
　基本①：96% 63/65
　基本②：93% 61/65
　応用①：92% 60/65
　応用①：89% 58/65

3回目を解答する頃にはだいぶ自信がついていました。

★並行してSAAの勉強も進める作戦
「これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）」
https://www.udemy.com/course/aws-associate

1～2セクションを1日に消化していました。
1セクションのボリュームがなかなかあったので、消化に時間がかかりました。

CLFで学習したベースがあったので、特に詰まることなく進めることができました。

■5/7

本試験の日です。
昼過ぎに仕事を終えて、テストセンターを利用して受験をしました。
距離を取る、マスクをする、手の消毒をする等しっかりとコロナ対策がなされていました。

本試験での解き方等は人それぞれだと思いますが、私の方法を記載しておきます。

①選択肢を見て何についての問題なのかを何となく頭に入れる
　→パッと見て、CloudWatchについてかとかS3についてかとかを把握するくらいです
②問題文をじっくり読んで、イメージする
　→テスト時にはホワイトペーパーとペンが配布されるので、随時書き込んでイメージを掴みます
　（マネジメント系のサービスだとイメージしにくいかもですが）
③2択に絞れる、全く分からない問題には「後から見直す」ボタンをクリックして、そんなに時間をかけずに次の問題へ
　→自信をもって答えられる問題以外にはそんなに時間をかけずにサクサク進めていきます
④最後まで解答出来て時間があれば、あとから見直す問題の見直し
　→ギリギリまでちゃんと見直しをします

数十問程、自信のない問題や見たことのない問題が出題されましたが結果は合格でした。
スコアレポートを見ると、874/1000で個人的には満足出来る得点かなと思います。

最後に

CLFを受験してよかったと思います。
合格した次の日から本格的にSAAの勉強に取り組むのですが、取り組む際の心持ちがよく、自信をもってスタートできました。
インフラエンジニアとして数年の経験があるといえども、AWSについてはほとんど素人だったので、取っ掛かりとしては成功でした。

ただ、完全に主観になりますが、勉強の進め方に関しては反省点があります。

・koiwaclub必要だったか？
　→結局、Udemyと参考書が理解の大部分を占めていたので必要性については疑問です
・参考書での勉強の進め方
　→パラパラ読むだけでは頭に入っていなかったです
　　私の場合は、読みながらの書き込みが必要みたいで、SAAの勉強をしている際に気が付きました。

長くなってしまったので、SAA編は別記事として今週中に投稿します。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T16:13:49+09:00

AWS SAA 曖昧な箇所についてまとめてみた①

背景

ポートフォリオにAWSの主要機能を盛り込みたい動機から、各機能についての網羅的な学習が必要であると考え、AWS SAAの学習をはじめました。

AWS SAA対策教材、学習手順については、下記の記事を非常に参考にしました。

最も本試験の難易度に近いと言われているのが、
【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）であり、
この記事では、自分が解いていてつまづいた箇所をピックアップしました。

◆ スケールイン/スケールアウト

用語 意味
スケールイン サーバ台数を減らしてパフォーマンスを低下させること
スケールアウト サーバ台数を増やしてパフォーマンスを向上させること

◆ スケールアップ/スケールダウン

用語 意味
スケールアップ 上位スペックへの変換(メモリ/HDD)
スケールダウン 下位スペックへの変換(メモリ/HDD)

◆ Amazon API Gateway/AWS Storage Gateway

用語 意味
Amazon API Gateway Lambda、EC2でAPIとして公開する際に使用する
AWS Storage Gateway オンプレミス環境とクラウド環境を接続する際に使用する

◆ HVM/HSM

用語 意味
HVM インスタンスの仮想化方式。 ※ParaVirtualとセットで出てくる
HSM 暗号鍵や電子署名の管理を行う。　※Certificate ManagerはSSL証明書管理

◆ SQS/SWF

用語 意味
SQS FIFOキュー(1度きりの送信/順不同)
SWF 処理を複数サーバに分散可能

◆ ゲートウェイエンドポイント/インターフェースエンドポイント

用語 意味
ゲートウェイエンドポイント S3・DynamoDBでVPCピアリング接続する際に使用
インターフェースエンドポイント Privatelinkを使用

◆ AWS config/EC2 config

用語 意味
AWS config リソースの評価/監査を行うサービス
EC2 config Windowsインスタンスの設定に使用

◆ SSE-S3/SSE-KMS/SSE-C

用語 意味
SSE-S3 AES-256を利用した暗号化方式
S3がマスターキー/データキーを管理
SSE-KMS KMS(Key Management Service)でCMK(カスタマーマスターキー)を管理する
SSE-C ユーザー側でマスターキー、データキーを両方管理

◆ one-time/persistent

用語 意味
one-time スポットインスタンス起動で、リクエスト失効する
persistent 任意でキャンセルするまで、リクエスト維持する

◆ バケットポリシー/IAMポリシー

用語 意味
バケットポリシー バケット/オブジェクト単位のアクセス権をJSONで定義する
IAMポリシー ※バケットポリシー/IAMポリシーが同じアカウントの場合：どちらかの許可でOK
※バケットポリシー/IAMポリシーが異なるアカウントの場合：両方の許可が必要
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T16:00:05+09:00

文章力向上のためにブログを始めます

１．はじめに

最近、文章を書くのが下手すぎる（うまく表現できない、時間がかかりすぎる）ことを痛感したので、
少しでもレベルアップしたくて、ブログを書き始めました。

為になったことや資格勉強内容、ただの日記など、初めは気張らず継続重視で書いていきます。

２．自己紹介

文系出身の5年目SEです。

4月から部署が変わりAWSに関わり始めました。

これまではネットワークにつながらない部屋でCOBOLの保守開発をしていたので、
やることが大きく変わり、勉強の毎日です。

1ヶ月半勉強してAWS SAAを取得したので
次はAWS SOAの勉強を始めようかなと思ってます。

今まで使ったことある言語

  • COBOL

保有資格

基本情報技術者、Oracle Master Bronze、AWS プラクティショナー、AWS SAA

趣味

旅行（電車）、オンラインゲーム（FPS)、競馬

最近気になってること

  • AWS（特にCloud Formation）
  • 競馬予想システム

３．おわりに

今後は資料作成が増えてくるみたいなので、少しでも文章が書けるように
がんばってブログ続けます。

目標：週1ペースで記事投稿

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T15:57:08+09:00

既存のログイン認証基盤からCognitoに移行するために調べてわかったこと

既存のID&パスワード認証のシステムに加え、新たにシステムを作り、SSO(シングルサインオン)を実装するために、Cognitoを使う。

その際に、既存のユーザー情報を移行しないといけないので、調べてみました。

マサカリ待ってます。

前提

AWS CLIは使わず、マネジメントコンソールから操作します。

既存の認証基盤仕様

ログインするためにユーザーが入力するもの

  • ユーザーID(またはメールアドレス)
  • パスワード

移行について

[懸念点]ユーザーにパスワードの変更をしてもらう必要がある

[モバイルアーキテクチャ ] Cognitoにどこまで任せるべきか？研究してみた - Qiita

既存のメール認証システムから移行する場合、name, email, phone numberなどはcsvでimportできるが、passwordだけはimportできないので、ユーザーにpasswordの再設定を依頼する必要がある。そのため、移行コストは高い

CSVでユーザーをインポートする

既存のユーザー情報を定められた形式のCSVファイルからインポートできる。

既存システムから、CSVを作る仕組みは別途用意しなければなりません。

ユーザーインポート .csv ファイルの作成 - Amazon Cognito

フォーマットはユーザープールで設定した属性に依るので、「CSVヘッダーのダウンロード」からヘッダーファイルをダウンロードします。
image.png

ダウンロードされるヘッダー例.csv
name,given_name,family_name,middle_name,nickname,preferred_username,profile,picture,website,email,email_verified,gender,birthdate,zoneinfo,locale,phone_number,phone_number_verified,address,updated_at,cognito:mfa_enabled,cognito:username

インポートするには上記ヘッダーに合わせて必要な情報を作っていく必要がある

インポートのソース.csv
name,given_name,family_name,middle_name,nickname,preferred_username,profile,picture,website,email,email_verified,gender,birthdate,zoneinfo,locale,phone_number,phone_number_verified,address,updated_at,cognito:mfa_enabled,cognito:username
tanaka,,,,,,,,,tanaka@example.com,TRUE,,,,,,FALSE,,,FALSE,tanaka
suzuki,,,,,,,,,suzuki@example.com,TRUE,,,,,,FALSE,,,FALSE,suzuki
yamamoto,,,,,,,,,yamamoto@example.com,TRUE,,,,,,FALSE,,,FALSE,yamamoto

このCSVファイルを、「インポートジョブの作成」から選択してジョブを作成します。

image.png

(試行錯誤の跡がありますが)、ステータスがCreatedの状態で、開始を押します。
成功するとSuccessedの状態になります。

Too many users have failed or been skipped during the import.
というエラーは、CSVの内容を見直してください。具体的なエラー内容は、CloudWatchLogsに吐き出されています。

image.png

インポートが成功すると、下記の通りインポートされます。
image.png

あとはアプリクライアントからパスワードのリセットを促すように対応すれば移行できるかと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T15:24:31+09:00

ElasticbeanstalkでAmazon Linux 2のプラットフォームブランチを選択するとebextensionsが動かない

AWS BeanstalkでPHPプラットフォームを選択するとき、最新のプラットフォームブランチだとAmazon Linux2を使うようになっている。
Amazon Linuxのときに使っていた、ebextensionsがそのままだと動かなかったのを書き換えたのでメモ。
/var/app/ondeckで動いていた部分を変更。

一応ログを見る限り、composer installは自動で走っているみたいなので、00-composerはいらないかもしれないと思う。
ここのコマンドのエラーログは、/var/log/cfn-init-cmd.logに出力される

変更前

.ebextensions/*.config
commands:
  01-updateComposer:
    command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update

option_settings:
  - namespace: aws:elasticbeanstalk:application:environment
    option_name: COMPOSER_HOME
    value: /root

  - namespace: aws:elasticbeanstalk:container:php:phpini
    option_name: document_root
    value: /public

container_commands:
  00-composer:
    command: "php /opt/elasticbeanstalk/support/composer.phar install"
    cwd: "/var/app/ondeck"
  01-environment:
    command: "mv /var/app/ondeck/$ENV_FILE /var/app/ondeck/.env"
  02-migrate:
    command: "php artisan migrate"
    cwd: "/var/app/ondeck"

変更後

.ebextensions/*.config
commands:
  01-updateComposer:
    command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update

option_settings:
  - namespace: aws:elasticbeanstalk:application:environment
    option_name: COMPOSER_HOME
    value: /root

  - namespace: aws:elasticbeanstalk:container:php:phpini
    option_name: document_root
    value: /public

container_commands:
  00-composer:
    command: "php /usr/bin/composer.phar install"
    cwd: "/var/app/staging"
  01-environment:
    command: "mv /var/app/staging/$ENV_FILE /var/app/staging/.env"
  02-migrate:
    command: "php artisan migrate"
    cwd: "/var/app/staging"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T15:16:56+09:00

AWSで ssh -i 〇〇.pem ec2-user@☓☓☓が通らない理由

AWSで 

ssh -i 〇〇.pem ec2-user@☓☓☓

が通らない理由についてです。

僕がハマった2つの原因についてお伝えします。

原因１：〇〇.pemのパス指定が間違っている。

解決策：〇〇.pemが存在するディレクトリに移動する。あるいは、現在いるパスから〇〇.pemが存在するディレクトリまでのパスを指定しましょう。（例えば△△/□□/〇〇.pemのように）

原因2:セキュリティグループでSSH接続に自分のIPアドレスを登録していない。

解決策：シンプルに自分のセキュリティグループで登録しましょう。

AWS→EC2→インスタンス→セキュリティグループ（右の方にあります。）
→インバウンドルール（下側）→インバウンドルールを編集のところでタイプをSSHにする。そして自分のIPアドレスを入力する。

で、実は、はまる理由はこの登録を忘れているからではなく、自分のIPアドレスが変わっていることに気づかないことなんです。

IPアドレスはインターネット環境によっては接続のたびに変わります。
詳しくは以下をご覧ください。
https://quoinexjp.zendesk.com/hc/ja/articles/360016319111-IP%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%8C%E6%AF%8E%E5%9B%9E%E5%A4%89%E3%82%8F%E3%82%8B

自分のIPアドレスはこちらで確認できます。もしやと思ったらこちらで確認して再度セキュリティグループに登録しましょう！
https://www.cman.jp/network/support/go_access.cgi

以上です！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T13:59:44+09:00

lamdaを使ってslackに通知する　覚書

コンタクトページの内容をslackに通知させたい

静的サイトのコンタクトページをslackに通知させたいという話しです。
最初のwebhookとかの設定は既にやっていたので、あとはlamdaで関数を作成して、apiゲートウェイを設定していきました。

lamdaで関数を作る

lamdaの画面で関数を作成ボタンを押すと関数が作成できます。
下の方にエディタの画面がでてくるので、そこに入力していきます。

こんな感じで作成しました。

index.js
const https = require('https');

exports.handler = (event, context, callback) => {
  const payload = JSON.stringify({
    text: `\n\n会社名： ${event.company}\n 所在地： ${event.address}\n 担当者： ${event.name}\n メールアドレス： ${event.email}}`,
  });

  const options = {
    hostname: "****.****.com",
    method: "POST",
    path: "/services/*******/*******",
  };

  const req = https.request(options,
      (res) => res.on("data", () => callback(null, "OK")))
  req.on("error", (error) => callback(JSON.stringify(error)));
  req.write(payload);
  req.end();
}

export.handlerとは:handlerはイベントを処理するlamda関数内のメソッド。関数を呼び出すとメソッドが実行され、レスポンスが返ってきたら、別の処理をするようになる。
export.handlerの引数について、ハンドラーの引数は全部で三つあります。
1. event :最初の引数は呼び出し元からの情報を含むeventオブジェクトです。
2. context :
3. callback :
callbackとは
res.onはdataを指定して使用することで、パース処理を開始している。
req.writeとは：サーバ側へHTTPリクエストのボディデータは送信されます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T13:25:14+09:00

初心者でもAWSプロダクトをさわってみたい！（AWS Batch編）

スクリーンショット 2020-05-26 13.21.33.png
スクリーンショット 2020-05-26 13.21.48.png
スクリーンショット 2020-05-26 13.21.57.png
スクリーンショット 2020-05-26 13.22.06.png
スクリーンショット 2020-05-26 13.22.14.png
スクリーンショット 2020-05-26 13.22.22.png
スクリーンショット 2020-05-26 13.22.31.png
スクリーンショット 2020-05-26 13.22.39.png
スクリーンショット 2020-05-26 13.22.48.png
スクリーンショット 2020-05-26 13.22.56.png
スクリーンショット 2020-05-26 13.23.04.png
スクリーンショット 2020-05-26 13.23.14.png

今回はecho投げるだけでしたが、、、もっと深くAWS Batchを知る＆他リソース連携の確認がしたいですね

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T13:02:24+09:00

AWS ELBのアクセスログをS3に保存する

AWSのELBのアクセスログをS3に保存した手順をメモ代わりに残します。
参考になれば幸いです。

あと、間違いがあれば指摘ください。

  1. S3設定
  2. ELB設定
  3. アクセスログの確認

S3の設定

  1. バケットを作成する
    image.png

  2. バケット名を入力して次へ
    image.png

  3. 「オプションの設定」と「アクセス許可の設定」は特に設定せずに次へ
    ※各自好きな設定をどうぞ
    image.png

  4. バケットが作成されたことを確認
    image.png

  5. 作成したバケットをクリックして開く
    image.png

  6. 必要に応じてディレクトリ作成（「フォルダの作成」クリック）
    ※各自好きな設定をどうぞ
    image.png

  7. 作成されたディレクトリを確認
    image.png

  8. 「アクセス権限」タブをクリックして「バケットポリシー」を開く
    image.png

  9. バケットポリシーを設定
    ※下記AWSドキュメントの「バケットのアクセス許可」に記述されてる設定内容を丸っと貼り付ける
    https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-access-logs.html?icmpid=docs_elbv2_console
    image.png

  10. バケットポリシー設定の赤字部分を書き換える

  • elb-account-id ※上記AWSドキュメントに現リージョンに対応するIDが一覧表で用意されている
    (以下の表には、バケットポリシーで elb-account-id の代わりに使用するアカウント ID が含まれています。 の部分)
  • bucket-name
  • prefix
  • your-aws-account-id

※elb-account-idは東京リージョンなので一覧表を確認した値に書き換える（582318560864）
※your-aws-account-id/は設定しなかったため削除（認識誤ってるかもしれません）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::582318560864:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::accesslogs-test/staging/AWSLogs/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::accesslogs-test/staging/AWSLogs/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "delivery.logs.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::accesslogs-test"
    }
  ]
}

⭐︎S3の設定完了⭐︎

ELBの設定

  1. サイドメニューからロードバランサーを選択

    image.png

  2. 下部に表示される説明タブを選択

    image.png

  3. 属性の編集をクリック
    image.png

  4. アクセスログのチェックボックスにチェック

    image.png

  5. チェックすると設定欄が表示される
    image.png

  6. さきほど作成したS3のバケット名を入力して保存(ディレクトリが存在するなら、ディレクトリも含めたもの)
    image.png

    ※この時、作成したS3にバケットポリシーを設定していないとエラーになる

    image.png

  7. 属性に設定値が反映される
    image.png

⭐︎ELBの設定完了⭐︎

アクセスログの確認

  1. S3にアクセスログが作成されてることを確認
    ※最初はTestFileのみ
    image.png

  2. 日付ごとに分類されたディレクトリが作られてアクセスログが格納されることを確認
    image.png

⭐︎きちんとアクセスログが出力されてれば完成です⭐︎

ハマった点としてはバケットポリシーの設定です。
少しAWSと仲良くなれた気がします。

以上です。お疲れ様でした。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T12:53:49+09:00

Lambdaまとめ

概要

触る機会があったので、知ったことをまとめていく。

Lambdaとは

AWSサービスのイベントをトリガーに自身がアップロードしたコードを動作させることができるというサービス

料金

料金は月額であり、「lamdaへのリクエスト数」と「lamdaを動かすときに消費したメモリサイズ(時間計算)」で計算される。

料金表はあらかじめ確保するメモリサイズに依存する

言語

コーディングできる言語は多岐にわたるが、「継続的なアクセスがなくCPUもそんなに使わない」のであれば「python」がいいらしい

ライブラリ

Python3でAWS環境を操作するには、boto3と呼ばれるライブラリが必要。

一時ディレクトリ

/tmpという一時ディレクトリがある。ファイルの受け渡しをしたいときとかに使う。
なお、同じファイル名を使うと、前の実行時のものが残っていてなおかつユーザー名が違っていてパーミッションエラーというのが起こりうるらしいので、毎回使い終わったらファイルを削除するのがいいらしい。

環境変数

lamdaに設定できる。
pythonだと、import osを宣言した上で、os.envion['<環境変数名>']で呼び出せる。

タイムアウト

処理のタイムアウトはMAX15分。
python3.8だとデフォルトで3秒らしい。

ロール

lambda関数にはIAMロールを設定する必要があるが、トリガーとなるAWSサービスへのアクセス権限は不要。イベントを受けてコード上でアクセスするAWSサービスへのアクセス権限が必要。

使い方

参考：https://dev.classmethod.jp/articles/lambda-my-first-step/

Lambda関数の新規作成

空の関数作成

Lamdaのコンソールへアクセス > 「関数の作成」ボタンを押下
→「関数の作成」ページが表示される
スクリーンショット 2020-05-29 20.48.05.png

「一から作成」を選択 > 「基本的な情報」セクションで「関数名」(=目的)を入力し、「ランタイム」(=言語)を選択 > 「アクセス権限 - 実行ロール」で「AWSポリシーテンプレートから新しいロールを作成」を選択 > 「ロール名」に任意のロール名を設定 > ポリシーテンプレートは未選択で「関数の作成」ボタンを押下
スクリーンショット 2020-05-29 20.49.53.png
→「Lamda関数設定」ページが表示される
スクリーンショット 2020-05-29 20.51.13.png

Lambda関数に設定を追加

「Lambda関数設定ページ」でそれぞれ実施。

トリガーの設定

「トリガーを追加」を押下
→「トリガーを追加」ページが表示される
スクリーンショット 2020-05-29 20.53.37.png

Lambda関数を起動するトリガーとなるAWSサービスを選択し、トリガーとなる条件を設定して「追加」ボタンを押下

実行するコードの設定

Lambda関数名を押下 > 下のコード編集領域へ実行するコードを記述し、画面右上の「保存」を押下

ロール

新規作成時に空っぽ(CloudWatch Logへの書き込み権限があるポリシーのみアタッチされている)のロールを作って当該Lambda関数へアタッチしている。
なので、IAMコンソールから空っぽのロールに対してlambda関数が操作する対象のAWSサービスへのアクセス権限を持つポリシーをアタッチしてやる。

「アクセス権限」タブを選択 > ロール名のリンクを押下 > 「ポリシーをアタッチします」ボタンを押下 > lambda関数を実行するために必要なポリシーを選択 > 「ポリシーのアタッチ」を押下

付与されたアクセス権限の確認はlambdaコンソールの「アクセス権限」タブを選択 > リソースの概要のドロップダウンで操作対象のAWSサービスが選択できるようになっており、選択すると操作可能なsリソース、アクションが確認できる。

環境変数

環境変数セクションの「編集」から設定できる。

メモリ上限、タイムアウト値

基本設定セクションの「編集」から設定できる。

テスト

テストイベントの作成

画面右上の「テスト」ボタンを押下 > 新しいテストイベントの作成を選択 > イベントテンプレートから任意のイベントを選択 > イベント名を任意で設定して「保存」を押下

テストの実行

画面右上の「テスト」ボタンの横にあるドロップダウンで作成したテストイベントを選択し、「テスト」ボタンを押下

実行確認

ちゃんとトリガーに引っかかってlambda関数が反応していればCloudWatchで確認できる。

  • ロググループ名:/aws/lambda/
# 参考
https://qiita.com/leomaro7/items/5b56ae9710d236545497
http://acro-engineer.hatenablog.com/entry/2016/08/02/120000
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T10:35:42+09:00

Shopify アプリを AWS に SPA + Serverless 構成でデプロイする – React + Amplify / Node.js + Serverless Framework –

前回の「Shopify でテーマとアプリを開発する – ThemeKit / Shopify App CLI –」では、Shopify が提供する公式ツールを使った開発方法を解説しました。Shopify App CLI はとても便利なツールなのですが、2020年5月時点では本番環境は heroku へのデプロイのみ提供しています。AWS / GCP / Azure などのクラウドで稼動させる場合は別途 CICD パイプラインを構築する必要があります。また Shopify App CLI で生成されるアプリは koa / Node.js をベースとしており Web サーバーを必要とします。本記事では AWS に SPA + Serverless 構成でデプロイする方法を解説します。

アーキテクチャ構成

Shopify Dev Template のサンプルコードを元に解説します。AWS とサーバーレスの説明については割愛します。

  • フロントエンド（react-amplified）

    • React を Amplify Hosting で S3 + Cloudfront へデプロイします。Shopify アプリは HTTPS 必須です。

  • バックエンド（api-serverless）

    • Node.js / aws-serverless-express を Serverless Framework を使い API Gateway – Lambda – DynamoDB をデプロイします。こちらも HTTPS にします。 アーキテクチャ事例_最小.png

Shopify でアプリ認証し、アクセストークンを元に Shopify API を呼び出す

まずはアプリを作る上で必要になるアプリ認証について解説します。公式が解説している Authenticate with OAuth のフローを熟読してください。Authorization Code Grant のフローに準拠しています。

  • 用語の解説
    • MERCHANT：アプリを入れるショップです
    • APP：拡張機能を開発するアプリです
    • SHOPIFY：アプリが通信する Shopify の API です

oauth-code-grant-flow.png

Step 1: Get client credentials

shopify partners アカウントで「アプリ管理」から「アプリを作成する」を押します。次に、公開アプリ・カスタムアプリを選択します。この２つは１つのショップのための拡張開発を行うか、汎用的な拡張機能をアプリとして販売するかの差があります。
アプリ作成.JPG
次にアプリURLとホワイトリストに登録されたリダイレクトURLを登録します。ここは Shopify App CLI を利用すると自動で設定してくれるのであまり意識する必要が無いのですが、使わない場合は設定が必要になります。

  • アプリURL（/auth）
    • ショップがアプリをインストールするためのリンク。 Shopify の認証を行います。
  • ホワイトリストに登録されたリダイレクトURL（/callback）
    • Shopify の認証が行われた後に、利用する API の権限等を確認し、権限を付与した後にリダイレクトされる URL

権限や API バージョンなど必要な情報を設定したら、アプリで利用する API キーとシークレットキーを取得出来ます。シークレットキーは公開してはいけません。
リダイレクト.JPG

Step 2: Ask for permission

ショップがアプリをインストールするためのリンク（/auth）を押した後に、権限の確認と付与を行う Shopify の画面が表示されます。アプリをインストールすると指定の URL へリダイレクト（ /callback ）します。

上記の実装は react-amplified/src/Auth.js を参照して下さい。やっていることは以下の Shopify の oauth/authorize へリクエストを送っているだけです。

https://{shop}.myshopify.com/admin/oauth/authorize?client_id={api_key}&scope={scopes}&redirect_uri={redirect_uri}&state={nonce}&grant_options[]={access_mode}

アプリ権限付与.png

Step 3: Confirm installation

リダイレクトされた画面（ /callback ）には URL パラメータとして code, hmac, shop, timestamp が送られてきます。取得した認証コードとアプリ作成時に得た API キーとシークレットキーを Shopify の oauth/access_token へ渡します。

POST https://{shop}.myshopify.com/admin/oauth/access_token

  • client_id: The API key for the app, as defined in the Partner Dashboard.
  • client_secret: The API secret key for the app, as defined in the Partner Dashboard.
  • code: The authorization code provided in the redirect.

正しく処理された場合はアクセストークンを取得できます。

{ “access_token“: “this_is_sample_access_token“, “scope“: “write_orders,read_customers“ }

上記の実装は react-amplified/src/Callback.js と api-serverless/functions/app.js の /oauth を参照して下さい。シークレットーキーの扱いや hmac の検証はバックエンドで行っています。

Step 4: Making authenticated requests

アクセストークンを取得したら HTTP の ヘッダーに X-Shopify-Access-Token: {access_token} を付けて REST API 通信を行って下さい。

Shopify アプリを AWS 上で動かす

Step 1-4 を実施することで Shopify のデータを API 経由で取得する準備が出来ました。それでは AWS 上にアプリを準備しましょう。

  • フロントは React で開発し Amplify で S3 + Cloudfront にホスティングします。（react-amplified/README.md 参照）
  • バックエンドは Node.js / aws-serverless-express で開発し Serverless Framework で API Gateway – Lambda にデプロイします。（api-serverless/README.md 参照）

実装は react-amplified/src/Top.js と api-serverless/functions/app.js の /products を参照して下さい。React から直接 Shopify API を呼び出しても構いませんが、本サンプルでは今後の拡張性のために間に Lambda を挟んでいます。

Shopify の API を利用できるようになったことで、管理画面内外のいずれでも商品データを扱うことが出来るようになります。API を経由することで機能の一部分だけを切り出して拡張開発をすることが出来ます。本サンプルでは薄く作ることを意識していますが、Shopify アプリの開発ライブラリとして app-bridge や polaris がありますのでぜひご活用下さい。

本記事では実施しませんでしたが Shopify App CLI が生成する koa や Next.js を Lambda@Edge や aws-serverless-express でラッピングしていくことで Serverless 構成を実現出来るだろうと見込んでいます。

アプリ構成.png

まとめ

本記事では Shopify アプリを AWS で動かす方法を解説しました。次回以降はより実践的な開発を深堀りしていきます。

<本記事に関するお問い合わせ>
NRIデジタル株式会社　担当　吉田・倉澤・萩村 and Developers　marketing-analytics-team@nri-digital.jp

本記事は NRI digital TECH BLOG からの転載です。
Shopify アプリを AWS に SPA + Serverless 構成でデプロイする – React + Amplify / Node.js + Serverless Framework –

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T10:07:08+09:00

GW明けからSAA合格に向けて学習したが不合格だったので振り返り

4/30まででLinuxの研修が終わり、GW明け5/7~本格的にSAAの学習に入りました。

書籍とUdemyの教材を使いながら学習を進め、教材付属の模擬試験を何度か受験しました。

模擬試験の2週目まで行う時間がなかったのが反省点であり、次回に向けた取り組みでもあります。

4月末に投稿したこちらの記事で、スケジュールや目的は記載してあります。

コロナウイルスの影響でリモート勤務が長引く為、AWS資格(SAA)取得計画

結果

不合格でした。(点数はAWSから送られてきたら記載します)

感覚的には、35問目くらいの時点で、受かったと思いましたが…油断は禁物ですね。

実は、前職在籍中(ITとは無縁)1回受験したことがあり、その時とは手応えが全然違いました。

なので、確実に知識・理解は向上しているかと思います。

SAA学習期間,受験日

5/7~(GW明けから)から本格スタートで、5/25(月)に受験しました。

約2週間強の学習期間でした。

学習スケジュールの進歩状況

スケジュールを添付します。
黒本での学習スケジュールです。

スクリーンショット 2020-05-26 9.23.17.png

Udemyハンズオンでの学習スケジュールです。
Well Architected Framework,信頼性設計,CloudFormationについては、時間の関係上、模擬試験と教材のみで学習。

スクリーンショット 2020-05-26 9.24.21.png

使用教材一覧

使用した学習教材を下記します。

・書籍2冊
・Udemy AWSハンズオン
・Udemy SAA模擬試験

<教材>
徹底攻略AWS認定ソリューションアーキテクトアソシエイト教科
最短突破AWS認定ソリューションアーキテクトアソシエイト合格教本
UdemyこれだけでOK!ソリューションアソシエイトアーキテクト試験突破講座
【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）

振り返り

徹底攻略AWS認定ソリューションアーキテクトアソシエイト教科 模擬試験1回分
最短突破AWS認定ソリューションアーキテクトアソシエイト合格教本 模擬試験2回分
Udemy高難易度模擬試験4回分

模擬試験をいくつか受験して、2週目の復習ができずに当日受験をしたので、模擬試験で間違えたところとその周りをしっかりと定着させてから望む為に教材を2週取り組む時間は確保したかったと反省です。

次の受験は、模擬試験の2週目をしっかりとこなした上で14日経過以降(受験日から14日後に受験できる)受験したいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T08:36:02+09:00

【AWS】IAMロールとIAMポリシーの違いが分かり難かったのでまとめてみた

SAA受験に向けてAWSについて学習中です。

IT未経験からエンジニアになりましたが、英語多すぎ…カタカナ多すぎ…というのが最初の感想です。

恐らく同じような感想を持たれているIT未経験→エンジニアの方もいらっしゃるのではないでしょうか。

そんな中で、自分なりに噛み砕いて理解していっております。

とても単純で簡単な例なのですがIAMのロールとポリシーが理解し難かったので、まとめてみました！

IAMとは？(Identify and Access Management)

IAMには4つのサービスが有ります。

・グループ
・ユーザー
・ロール
・ポリシー

今回は、ロールとポリシーについてまとめていこうと思います。

◆IAMロール

AWSリソースにリソースに付与するもの。
IAMロールにIAMポリシーが付与される。

◆IAMポリシー

IAMロールに内包されるもの。
AWSリソースにアクセスする為の権限設定であり、AWS側で用意がされているもの。

図で表してみた

こんな感じです！
IAMロールという大きい入れ物に、IAMポリシーという各リソースへの権限を選択して入れてあげるイメージです。

ロール=包むモノ と覚えると個人的にわかりやすかったです！

スクリーンショット 2020-05-26 8.15.53.png

最後に

IT未経験からエンジニアになっているので、カタカナや英語が多すぎてわけわからない…

というのが正直な最初の感想です。

しかし、1つ1つ調べていくと初見のイメージほど難しい内容でもないことがほとんどです。

一見して難しそうなIT用語にモチベーションを失ってしまわないようにするとインプットも捗るかと思います。

今回は簡単な内容ですが、自分なりに分解して簡単に理解できるようにした１つの例としてあげておきました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T07:48:23+09:00

AWS EC2インスタンスのlocalhostにアクセスする

この記事で、AWSのEC2のインスタンスからコードを編集するように環境構築したんですけど
yarn devしたときにGoogle Chromeからlocalhostにつながらない問題が発生

同じ人がいたら:arrow_down:をやれば一瞬で解決するのでやってみてください〜

手順

:one: AWS EC2のコンソールを開く

:two: localhostに接続したいインスタンスの行の"Security Group"をクリック

image.png

:three: すでにあるSecurity Groupのinbound rulesを編集する

image.png

:four: "Add rule"ボタンを押して:arrow_down:のruleを追加

画像はlocalhost:3000に接続したい場合
8000番に接続したいとか、3000と3004に接続したいとかだったら、Port rangeのところに8000とか3000-3004とか入れる
image.png

:five: "Save rules"を押して終了
ブラウザでインスタンスのIPv4 Public IPに接続すればいける
（SSHを接続し直す必要はない）

image.png

例: localhost:3000にWebアプリが立ち上がってる→18.217.xxx.xxx:3000をブラウザに入れる

参考: https://stackoverflow.com/questions/55729337/how-can-i-connect-to-a-http-localhost4200-using-browser-which-is-a-aws-ec2/55740099

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T07:22:48+09:00

AWSのサービス語句まとめ

試験で覚えるためのAWSサービスのまとめ

1.API GAteway
2.Aurora
3.Auto Scaling
4.CloudFront
5.CloudTrail
6.CloudWatch
7.Data Pipeline
8.Direct Connect
9.DynamoDB
10.EBS(Elastic Block Store)
11.EC2(Elastic Comppute Cloud)
12.ElasticCache
13.ELB(Elastic Load Balancing)
14.EMR
15.Glacier
16.IAM(Identity and Access Management)
17.Kinesis
18.Kinesis Data Firehose
19.Kinesis Data Streams
20.Lambda
21.RDS(rekational Database Service)
22.RedShift
23.Route 53
24.S3(Simple Storage Service)
25.SNS(Simple Notification Service)
26.SQS(Simple Queue Service)
27.VPC(Virtual Private Cloud)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T05:45:44+09:00

【AWS】S3(Simple Storage Service)とは？

はじめに

AWS SAA取得に向けて学習を進めています。
今回はS3とは何か？ということをアウトプットしていきたいと思います。

S3とは？

別名:Amazon Simple Storage Service(S3)

インターネット経由で利用できるオブジェクトストレージサービス

2006年からサービスを開始していて、安価で高い耐久性をもっているAWSの代表的なサービスの一つ。

S3の特徴

  • イレブンナイン(99.999999999%)の耐久性
    保存されたファイルをリージョン内の3か所以上のアベイラビリティーゾーンにあるデータセンターに自動的に複製して保持している。
    イレブンナイン(99.999999999%)というのは、S3に1万個のオブジェクトを保存したとして、そのうちの1つが障害によって失われるのに平均で1000万年ほどかかるレベルとのことです。
    　　

  • 結果整合性モデル
    データを更新・削除した際に順次データが更新されていく仕組み。
    「一つの更新はそのうち全体に反映される」という考え方。
    データの更新直後など読み取りのタイミングによっては古いデータを読み込む可能性がある。

  • 容量無制限
    S3に保存できるデータ容量やファイル数には制限がない。
    初期費用は0円で使用した分のみ支払う従量課金制。

  • 安価
    S3の標準ストレージの利用料金(東京リージョンの場合)は、最初の50TBまでが「月額3円($0.025)/GB」。
    次の450TBも「月額3円($0.024)/GB」である。

参考

この１冊で合格！　AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集
Amazon S3の耐久性は99.999999999％。こんなに高い耐久性がいらない人向けのオプションが登場
Amazon S3 の結果整合性と読み取り一貫性
Amazon S3 の料金

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T02:44:07+09:00

JAWS-UG CLI専門支部 #154R S3入門参加 まとめ

S3入門編に参加してみて

JAWS-UG　CLI専門支部　#154R S3入門に参加。
S3の操作をAWS CLIを通して学んだ。1時間遅れで参加したけど、なんとか全ての操作をやりきった。
茅場町開催で一度参加したことあるけど、なかなか時間があわずに2回目以降はいけていない。
オンライン開催になってから今のところ毎回参加できているので本当に嬉しい。:relaxed:
運営者の波多野さんありがとうございます！
★JAWS-UG CLI専門支部 #154R S3入門 イベントページ

できるようになったこと

  • S3バケットの構築S3バケットを作成
  • S3オブジェクトの操作（確認、アップロード、ダウンロード、移動、削除）　
  • S3バケットの同期
  • webサイトホスティング
  • 署名付きURLの発行

★教材ページ

S3バケットの構築

aws s3 mb s3://${S3_BUCKET_NAME} --region ${AWS_DEFAULT_REGION}
\${S3_BUCKET_NAME}=バケットネームを指定。一意である必要がある。
\${AWS_DEFAULT_REGION}=バケットを作成するリージョン。東京リージョンは'ap-northeast-1'。

S3オブジェクトの操作

・オブジェクトの確認
aws s3 ls s3://${S3_BUCKET_NAME}/

・オブジェクトのアップロード
aws s3 cp ${FILE_UPLOAD} s3://${S3_BUCKET_NAME}/
\${FILE_UPLOAD}=コピー元を指定

・オブジェクトのダウンロード
aws s3 cp s3://${S3_BUCKET_NAME}/${S3_OBJECT_NAME} ${FILE_DOWNLOAD}
\${S3_BUCKET_NAME}/${S3_OBJECT_NAME}=S3内のオブジェクトを指定。
\${FILE_DOWNLOAD}=ローカルのダウンロード先を指定

・オブジェクトの削除
aws s3 rm s3://${S3_BUCKET_NAME}/${S3_OBJECT_NAME}

・オブジェクトの移動
aws s3 mv s3://${S3_BUCKET_NAME_SOURCE}/${S3_OBJECT_PREFIX_SOURCE} \
s3://${S3_BUCKET_NAME_DESTINATION}/${S3_OBJECT_PREFIX_DESTINATION}
\${S3_BUCKET_NAME_SOURCE}/\${S3_OBJECT_PREFIX_SOURCE}=移動元のオブジェクトを指定
\${S3_BUCKET_NAME_DESTINATION}/\${S3_OBJECT_PREFIX_DESTINATION}=移動先のオブジェクトを指定

・オブジェクトの削除（パス単位）
aws s3 rm --recursive s3://${S3_BUCKET_NAME}/${S3_OBJECT_PREFIX}
recursive指定でパス含めて削除。

S3バケットとの同期

事前にgitリポジトリからローカルにcloneしてデータをアップロードしておく
cd ${DIR_S3_TRANSFER} \
&& aws s3 sync . "s3://${S3_BUCKET_NAME}/" \
--exclude "${S3_SYNC_EXCLUDE}" --acl public-read
exclude ${S3_SYNC_EXCLUDE}=同期の対象から外すファイルを指定。（".git*")
acl public-read =オブジェクトの公開読み取りを許可

仮想ホスティングエンドポイントの取得
S3_BUCKET_ENDPOINT=" \
${S3_BUCKET_NAME}.s3.$( \
\ aws s3api get-bucket-location \
--bucket ${S3_BUCKET_NAME} \
--output text \
).amazonaws.com" \
&& echo ${S3_BUCKET_ENDPOINT}

仮想ホスティングエンドポイントにオブジェクトのパスを追加
S3_OBJECT_NAME='img.jpg'
URL_S3_OBJECT="${S3_BUCKET_ENDPOINT}/${S3_OBJECT_NAME}" \
&& echo ${URL_S3_OBJECT}
\${URL_S3_OBJECT}をブラウザで参照するとオブジェクトのimgファイルを確認できる

S3バケットのWebサイトホスティング設定

Webサイトホスティング
aws s3 website "s3://${S3_BUCKET_NAME}" \
--index-document ${S3_DOC_INDEX} \
--error-document ${S3_DOC_ERROR}
index-document \${S3_DOC_INDEX}　正常表示するページを指定
error-document \${S3_DOC_ERROR}　4XX系のエラーが発生する際に表示するページを指定

エンドポイントを取得
S3_BUCKET_WEBSITE_ENDPOINT=" \
${S3_BUCKET_NAME}.s3-website-$( \
aws s3api get-bucket-location \
--bucket ${S3_BUCKET_NAME} \
--output text \
).amazonaws.com" \
&& echo ${S3_BUCKET_WEBSITE_ENDPOINT}
※リージョンによってエンドポイントの形式が変わるので注意
　昔からあるリージョン：s3-website（バージニア北部や東京）
　新しめのリージョン：s3-website.（ソウルや大阪）
詳細は以下のリンクを
★ウェブサイトエンドポイントについて
★リージョン別エンドポイント

署名付きURLの発行

aws s3 presign s3://${S3_BUCKET_NAME}/${S3_OBJECT_NAME} \
--expires-in ${S3_PRESIGN_SECONDS}
presign s3://\${S3_BUCKET_NAME}/\${S3_OBJECT_NAME} 署名対象のオブジェクト名を指定
expires-in \${S3_PRESIGN_SECONDS}　署名の有効期限。単位は秒。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-05-26T02:02:31+09:00

１つのALBでWebサーバとAPIサーバをドメインで出し分ける

やりたいこと

  • 図のようにWebサーバとAPIサーバを１つのALBで出し分けてほしい
  • 各サーバは負荷分散を行う可能性もあるため複数台登録にも対応してほしい
  • IPは固定していないので，IPが変化しても大丈夫なようにする

Untitled Diagram (1).png

今回やること

  • Route 53でWebサーバとAPIサーバ用のドメインを用意する
  • ALBでドメインによってWebサーバ及びAPIサーバのターゲットグループを切り替えるように設定
  • 今回は便宜上，Webサーバ用のドメインをhoge.com，APIサーバ用のサブドメインをapi.hoge.comとして説明します

Untitled Diagram.png

前提条件

  • Webサーバ及びAPIサーバのEC2がある
  • ALB及びRoute 53でドメインが用意されていることとします

→ ドメインの登録方法はこちらを参考にしましょう

ロードバランサーの設定

まずは，ALBの作成を行います．
AWSのコンソールからEC2を選択し，
ロードバランサー -> ロードバランサーの作成を押します

0-2.png

今回はロードバランサーとしてALBを選択
0-1.png

名前：hoge-alb
VPC：作成したパブリックサブネットを選択
アベイラビリティーゾーン：今回はaとcのパブリックサブネットを選択
1.png

セキュリティーグループの設定

セキュリティグループの割当：新しいセキュリティグループを作成するを選択
セキュリティグループ名：hoge-sg
説明：hoge-sg
※名前は適切なものを書きましょう

2.png

ルーティンググループの設定

ターゲットグループ：新しいターゲットグループを選択
名前：hoge-web-tg
※ 適切な名前を書きましょう

3.png

Webサーバのターゲットグループの設定

ターゲットの登録を行います

Webサーバを選択 -> 登録済みに追加

4.png

最後に確認を押してALBの作成及びWebサーバへのターゲットグループを作成します．

APIサーバのターゲットグループ作成

次に，APIサーバのターゲットグループを作成します．

EC2のコンソールから，
ターゲットグループ -> ターゲットグループの作成を選択

名前：hoge-api-tg
※ 適切な名前を書きましょう

作成を押してターゲットグループを作ります

5.png

APIサーバのターゲットグループの設定

作成したターゲットグループを選択してAPIサーバを登録します．

hoge-api-tgを選択 -> ターゲット -> 編集

6.png

APIサーバを選択 -> 登録済みに追加 -> 保存
7.png

Route 53の設定

ドメインとALBを紐付ける

すでにドメインhoge.comがある状態でALBと紐付けます

コンソールからRoute 53を選択 -> 作成したドメインを選択 -> レコードセットの作成
14.png

エイリアスではいを選択 -> 作成したALB(hoge-alb)を選択

最後に作成を押しましょう
18.png

APIサーバのサブドメイン作成

API用のサブドメインを作成してALBと紐付けます

名前：api
エイリアス：はい
エイリアス先：作成したALB(hoge-alb)を項目の中から選択します

最後に作成を押してサブドメインを作ります
15.png

ルーティングの設定

APIサーバのルーティングをALBに設定

EC2のコンソールから
ロードバランサー -> 作成したhoge-albを選択 -> ルールの表現/編集
8.png

プラスボタンを選択 -> ルールの挿入
9.png

条件の追加 -> ホストヘッダー
10.png

Route 53で作成したAPI用のサブドメインを入力します
ホストヘッダー：api.hoge.com

次に，入力したホストヘッダーからの通信があった場合の転送先を設定します
アクションの追加 -> 転送先
11.png

hoge-api-tgを選択 -> 保存
12.png

最終的にはこのようになっています
13.png

結果

hoge.comでwebページが表示され，api.hoge.comでAPIサーバと通信することが出来ました

19.PNG

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧