- 1. [AWS]Cloudformationについて調べた結果
- 2. EC2インスタンスのボリュームサイズを変更する
- 3. Amazon SES で独自ドメインのメール受信設定
- 4. AWSChatbotをShared かつ PrivateなSlack Channelに設定する
- 5. [CentOS7]aws cliのインストール
- 6. Cloud Front + Lambda@Edgeでドメイン名でrewriteする
- 7. AWS の Change Calendar が突然 404 になった
- 8. 未経験者がAWS認定SAA試験に合格する方法
- 9. めも CloudFront
- 10. 同じドメイン内でWordpressとWebシステムの両方を共存させる設定をやってみました。
- 11. 【AWS CLoud Watch】EC2のCPU使用率が一定値を超えた場合に、CLoud Watchアラームを起動しAutoScaling内インスタンス数を増加させる
- 12. Capistrano + AWS(EC2) + Rails で簡単デプロイ
- 13. AWSハンズオン実践 〜Amazon Forecast〜
- 14. [Terraform] mapのリストへのアクセスでエラーが出たら、これかも。
- 15. とにかくNginxをインストールする (AWS Amazon Linux 2, CentOS7対応, 公式 ref.あり)
- 16. AWSでサイト間VPNを作成する
- 17. AWS EC2 インスタンスにセキュリティグループを追加する
- 18. EFSでマウントできない時に確認すること
- 19. #3 AWSのEC2インスタンス(ubuntu18.04)でPython(Django)環境を構築する part2
- 20. Amazon API Gatewayが更新されない場合
[AWS]Cloudformationについて調べた結果
# はじめに
仕事でCloudFormationを使うことになったので、ググった検索結果の1ページ目のサイト等を参考に、どのようなものか、どのように使うのか、といったことを調べてまとめてみました。## CloudFormartionとは、、？
AWSにシステム構成をJSON(YAML)形式で記述してテンプレート化し、構成の管理・修正・再利用を用意にするサービスのことです。
テンプレート化して作成した環境群を「スタック」と呼びます。
サンプルテンプレートが多数提供されているので、これらのテンプレートを使用することで簡単に環境構築が出来ます。##メリット
– インフラストラクチャ(※1)とアプリケーションリソース全体を、テキストファイルまたはプログラミング言語のいずれかでモデル化できる。これにより、構成の一貫性、トラブルシューティング時間の短縮に役立つ。
– 安全で繰り返し可能な方法でアプリケーションリソースがプロビジョニング(※2)されるため、手作業やカスタムスクリプト作成を必要とせずにインフラストラクチャとアプリケーションの構築と再構築が可能。
– インフラストラクチャ
EC2インスタンスのボリュームサイズを変更する
社内でRedashのAMIを運用していたのですが、急に動かなくなってしまい、ボリュームサイズの変更が必要になりました。
**/ is using 99.8% of 7.69GB**
げげ〜。
# ボリュームサイズの変更
ボリュームサイズの変更の手順は以下です。– EBSボリュームのサイズを変更する
– EC2内のパーティションを物理のボリュームのサイズに合わせて再設定する# EBSボリュームのサイズを変更する
EC2ダッシュボード > Elastic Block Store > ボリュームに移動し、サイズを変更したいEBSボリュームを選択してボリュームの変更をします。今回は8GBを倍の16GBに変更します。
![スクリーンショット_2020-09-02_10_08_06.jpg
Amazon SES で独自ドメインのメール受信設定
#Amazon SES で独自ドメインのメールを受信する
試験環境で色々作っていくにあたり、独自ドメインを入手して、独自ドメインのメールアドレス当てのメールを受信したいというケースがあると思います（私は結構ありますが皆さんどうなんですかね？(´・ω・｀)）
そんなときに使い捨てのメール環境があれば便利だと思います。ということで今回はAmazon SESで独自ドメインのメールを受信できる環境を構築していきたいと思います。##やりたいこと
Freenomなどで取得した無料独自ドメインのメールアドレス向けのメールを受信できるようにしたい。
例えば、”admin@xxxxx.com” というメールアドレスへメールを、Amazon SESを使って受信したいというケースを想定しています##前提条件
1. 独自ドメインは取得済み
2. DNSはRoute53を利用する
3. メールソフトは利用せず、メールデータファイルの拡張子を変更してブラウザーでメール内容が表示できればOKとする
4. リージョンはus-east1(バージニア北部)とする
※東京リージョンだとメール受信に対応していな
AWSChatbotをShared かつ PrivateなSlack Channelに設定する
詰まったので備忘録
## 要点
– AWSChatbotのSlackのauthorizeおよびchannelsIDの設定は、Shared channelのOwnerに属しているユーザーにやってもらう必要があるかも
– Slack appをchannelに導入する際もOwnerに属しているユーザーにやってもらう必要がある## 経緯
– 顧客のメンバーが弊社の開発メンバーとして参画することになったので、もともと弊社のSlack Channelに流していたCodePipelineの通知を、顧客がOwnerのShared Private Channelに変更する作業をやっていた。
– 自分は対象のchannelにも属していて、AWSChatbotのSlackAppもinviteできたので、いけるだろと思ってた## ハマリポイント1
– 自分でAWSChatbotの設定をする際に、channelID部分でエラーが出て設定が完了できなかった
– authorizeはShareされた側(not Owner)でやってたので、Ownerじゃないからだめなのかなと思って顧客に依頼した。
– ただ
[CentOS7]aws cliのインストール
## aws cliのインストール
– pipのウェブサイトからインストールスクリプトをダウンロード
“`sh
# 移動
cd /var/tmp# インストールスクリプロトをダウンロード
curl “https://bootstrap.pypa.io/get-pip.py” -o “get-pip.py”
sudo python get-pip.py
“`– pipを使用してawscliをインストール
“`sh
sudo pip install awscli
“`– バージョン確認
“`sh
# バージョン確認
aws –version
aws-cli/1.18.128 Python/2.7.5 Linux/3.10.0-1127.19.1.el7.x86_64 botocore/1.17.51
“`– awsコマンドの設定
“`
aws configure
==========
AWS Access Key ID [None]: XXXXXXXXXXXXX
AWS Secret Access Key [None] : XXXXXXXXXXXX
Cloud Front + Lambda@Edgeでドメイン名でrewriteする
WebアプリケーションのCD(継続的デリバリー）で、パスベースのURLを採用したSPAの場合、
`${SHA_HASH}.domain.name -> origin/index.${SHA_HASH}.html`
のようなrewriteをしたいことが良くあります。
`/${SHA_HASH}/**/* -> /${SHA_HASH}/index.html`
にrewriteする方法もありますが、本番とパスの階層が変わってしまって、ステージングテストで苦労することになるので、ドメインベースにしたいわけです。
これは、nginxやApacheでもできますが、このためだけにnginxやApacheを立ち上げるのもばからしいので、Lambda@Edgeでできないかと思うわけです。結論から言うと問題なくできます。
1. Cloud Frontでのワイルドカードドメインの利用
2. デプロイ前に、index.html -> index.${SHA_HASH}.htmlにリネーム。など、面倒なことがいろいろありますが、ソースコードだけで言うと以下のようにすればとりあえず動きます。
AWS の Change Calendar が突然 404 になった
昨日まで使えていた AWS の Change Calendar 機能 ( `aws ssm get-calendar-state` ) が、今日になって突然 404 を返すようになった。
あわてて管理コンソールから見に行ったら、リスト上にはあるように見えるのに、 View details も Edit も Delete も反応しない。なんで？
Create calendar で新しいカレンダーを作るとそちらは反応する(編集も削除できる)ので、AWS 様がなにかやらかしてるようにしか見えないけど…。
個人で使ってるアカウントだから、しょーもない Lambda が1個エラーになっただけで済んだけど、これ、仕事で使ってる人がいたらヤバいんじゃないかなぁ？
未経験者がAWS認定SAA試験に合格する方法
# はじめに
この記事の目的は、どうやってAWS認定SAA試験に合格までたどり着いたか、工程をやプロセスを残すことによって、今後同様の試験があったときの備忘録としての意味合いと、未経験者でも尻込みせずに合格できるあるいは、チャレンジしてみようと思ってもらえるようにすることです。
ただし、同じようにやったからといって**合格を保証するものではありません**ので、あくまで参考として見ていただけたらと思います。
この記事は、参考書・問題集のレビュー、それらの使用例、自宅受験の注意点、勉強時の反省点という構成になっています。# 対象者
AWS認定試験興味あるけど、難しそう！でも、やってみたいという人# 必要なもの
・チャレンジ精神（レジリエンス）
・試験費用、書籍購入費
・インターネット環境（ピアソンvue自宅受験の場合）# オススメ教材のレビュー
・[これだけでOK！ AWS認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）](https://www.udemy.com/course/aws-associate/)
AWSこれなんぞ？って人に
めも CloudFront
originは、同じS3のバケットでも、IDを変えれば複数登録できたのでメモ。
同じドメイン内でWordpressとWebシステムの両方を共存させる設定をやってみました。
WordPressとWebシステムを同一ドメインで共存させるということをやる機会がありましたのでやったことをメモで残しておきます。
WebシステムとWordpressはAWSのEC2で別々のサーバとして動作しており、/mediaへのアクセスはwordpressの方へ捌くということをやっております。
Webシステムの方は既に稼働済でwordpressの方へ新規で構築し、ロードバランサ側でアクセスを捌く設定追加を行っております。# 動作のイメージ
hogehoge.comにアクセス → Webシステムの方へアクセス
hogehoge.com/media → WordPressの方へアクセス# やったこと
やったことは大きく二つ– ロードバランサ(ALBの設定)
– リクエストの入り口
– Webシステム、Wordpressのどちらかにアクセスを振り分けるリバースプロキシのような役割
– Apacheの設定
– 受け付けたリクエストを内部で処理するようにドメインとパス書き換える
– /mediaというパスを排除し、インスタンス内(loca
【AWS CLoud Watch】EC2のCPU使用率が一定値を超えた場合に、CLoud Watchアラームを起動しAutoScaling内インスタンス数を増加させる
##目標
CloudWatchアラームにEC2の標準メトリクス（CPUUtilzation）を監視させ、それが一定値を超えた場合にアラームを起動することで、AutoScaling内のインスタンス数を増加させるシステムを構築する。##前提
・AutoScalingの基本的な概念や作成手順がある程度わかること。
（本記事ではAutoScalingの作成手順は要所のみとさせて頂いております）##CloudWatchとは
各AWSサービス（EC2、ELB、RDS、S3、EBS）のリソース情報（例としてはCPU使用率、ディスクIO、ネットワークIO等など。これをCloudWatchでは**メトリクス**と呼びます。）収集を行い、
それをCloudWatchダッシュボード等で可視化させるサービスです。
**CloudWatchアラーム**を利用することで、メトリクス情報を監視し、監視条件として指定した**しきい値**を超過した場合、
アラームを発砲し**SNSによるメッセージ送信、AutoScalingアクション実行等の処理連携をすることが可能**となります。##構成図
本記事では、参考記事に沿ってエラーで詰まった部分をまとめたので参考になれば嬉しいです。
# 作成するファイル
ローカル側
– Gemfile
– Capfile
– config/deploy.rb
– config/deploy/production.rb
– lib/capistrano/tasks/unicorn.rake
– config/unicorn/production.rbサーバー側(EC2)
– shared/config/settings.yml
– shared/config/database.yml
– shared/.env
– /etc/nginx/conf.d/app.conf
AWSハンズオン実践 〜Amazon Forecast〜
# はじめに
AWS公式のハンズオンシリーズの中から、[Amazon Forecastのハンズオン](https://pages.awscloud.com/event_JAPAN_Hands-on-Amazon-Personalize-Forecast-2019.html?trk=aws_introduction_page)を実施しました。
本記事は自身のハンズオン学習メモとして投稿します。
# 目次
– [Amazon Forecastとは](#Amazon Forecastとは)
– [ハンズオン本編](#ハンズオン本編)
– [おわりに](#おわりに)# Amazon Forecastとは
機械学習を使用して精度の高い予測を行うフルマネージドサービス。
時系列データ (価格、プロモーション、経済的業績指標など) を利用し予測する。### ユースケース
#### Product DemandPlanning
– ウェブサイトや特定の店舗、ロケーションで販売されている製品に対する需要予測
– サプライチェーンの需要予測#### Financial pla
[Terraform] mapのリストへのアクセスでエラーが出たら、これかも。
Terraformのaws_route53_recordで作成したリソースの変数を取得しようとしたら、エラーが出たので解決法を載せます。
使用しているTerraform/probider awsのバージョンは“`Terraform v0.12.5 + provider.aws v3.4.0“`です。# エラー内容
“`terminal
Error: Invalid indexon main.tf line 124, in resource “aws_route53_record” “example_certificate”:
124: name = aws_acm_certificate.example.domain_validation_options[0].resource_rcord_nameThis value does not have any indices.
Error: Invalid index
on main.tf line 125, in resource “aws_route53_record” “example
とにかくNginxをインストールする (AWS Amazon Linux 2, CentOS7対応, 公式 ref.あり)
# 環境
– AWS EC2インスタンスにNginxをインストールすることを想定
– OS: Amazon Linux2もしくはCentOS7 (RHEL7系)**\*後から知りました**
– Nginx: 1.18.0 (latest, stable, 2020.8.31現在)# Nginxをインストール
## Amazon Linux 2 の場合
amazon-linux-extrasリポジトリからインストールします### インストール可能パッケージ一覧
“`
$ amazon-linux-extras…
38 nginx1=latest enabled [ =stable ] #here
39 ruby2.6 available [ =2.6 =stable ]
40 mock available [ =stable ]
41 postgresql11 available [ =11 =sta
AWSでサイト間VPNを作成する
### VPCを作成する
### VPCにサブネットを作成する
# 読後感
– 既存のインスタンスにセキュリティグループを追加することができる。
# 概要
1. aws config設定
1. セキュリティグループの追加
1. 確認# 詳細
1. aws config設定
1. インスタンスにssh接続して下記コマンドを実行する。“`terminal
$ aws configure
“`
1. 下記情報を入力する。
1
EFSでマウントできない時に確認すること
#確認事項
* セキュリティグループが正しいか確認をする
* VPCのDNS設定を確認する
→DNS解決・DNS ホスト名を有効化する
* マウントポイントが作成されているか確認をする無い場合は作成をする。
“`
mkdir /mnt/efs
“`↓EFSのアタッチにあるコマンドをそのまま使う場合はデフォルトでefsでした。
“`
mkdir efs
“`それでも解決できない場合
[マウントの問題のトラブルシューティング](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/troubleshooting-efs-mounting.html)#ECS・FargateでEFSマウント設定後にタスク起動できないとき
タスク設定を完了後、タスク起動が出来ずエラーが出た時
>タスクを実行できません
>One or more of the requested capabilities are not supported.プラットフォームのバージョンを、1.4.0にすることで回避できました。
#3 AWSのEC2インスタンス(ubuntu18.04)でPython(Django)環境を構築する part2
#はじめに
私はプログラミング言語の初学者です。
その為、読み間違いや理解不足の部分があると思います。
その場合はコメントで教えて頂けると幸いです。「ゴール」は事前に作成したPythonのwebアプリケーションをデプロイする所まで行きたいと思います。出来るだけ初学者向けに書くつもりです。
作成手順
* AWSのEC2でインスタンスを構築後に、SSH通信をする
* 構築したインスタンスの中にPythonの環境を構築する
* インスタンスの中に仮想環境を構築し、Django等をインストール（フレームワーク） ←**現在はここです。**
* PostgreSQLを設定する（データベース）
* インターネット上にアプリケーションが接続出来るように設定する（デプロイ前半）
* NginxとGunicornの設定する（デプロイ後半）##仮想環境を構築し、Djangoをインストールします。
* Django等をインストールします。
* Git Hubからファイルをクローンします。###ステップ１（インストール編）
“`
pip3をアップデート
$ sudo -H pip3 i
Amazon API Gatewayが更新されない場合
Amazon API Gatewayがテストではうまくいくのに本番環境が変わらずハマった話
# Amazon API Gateway のデプロイには注意
Amazon API GatewayでエンドポイントのURLを発行したあと、プログラム修正したら反映されずハマってしまったのでメモ。
## API GatewayではテストとステージのエンドポイントURLは切り離されているのでがLamdaと違い手動デプロイが必要
Lamda Node.JSを使っているとテスト・保存が直感的なためデプロイを意識することがない
しかし、API Gatewayではデプロイを指定したあとは、いくら設定変えようが、指定時のデプロイを参照して実行結果が返ってくる。LamdaとAPI Gatewayを交互に作業していると、Lamdaのテスト結果もAPI Gatewayのテスト結果も変更を反映しているのにURLを（再デプロイせずに）叩くと古い結果が返り続け、悩むことになる
タチの悪いことに、API GatewayのエンドポイントURLが確認できるステージという画面内には再デプロイのためのボタンもそれを促
