- 1. AWS Route53で無停止サブドメイン委任(すでにサブドメイン以下にCNAME等のレコードが存在するケース)
- 2. AWS Route53でサブドメインを取得し、SESで使用する
- 3. Cloudwatchのチュートリアルを読み解く
- 4. Development on AWS受講までの事前準備 in MacPC
- 5. ~S3(Simple Storage Service)~ AWS学習メモ ~
- 6. Terraformのtfstateファイルを消すとどうなるか
- 7. AWS SAA 備忘録
- 8. 鍵を埋め込んだ EC2 インスタンスから取得した AMI に別の鍵を指定して起動しても以前の鍵が残るので対処します。
- 9. Route53のレコードセットに AWS CloudFormation を利用しました
- 10. S3にCSVファイルがアップロードされるとLambdaがDynamoDBへデータを挿入します
- 11. EC2インスタンスをAnsibleで操作するための事前準備
- 12. Node.jsで常時フォルダを監視してS3へファイルをアップロードする
- 13. 【Nuxt.js】AWS ECR/FargateにデプロイするためのDockerイメージ作成方法
- 14. AWS Beanstalk環境における、Blue/Greenデプロイの実装によるデプロイ作業の簡略化
- 15. AWSソリューションアーキテクト アソシエイトに合格したので振り返り
- 16. AWSでWordPressを始めてハマった話
- 17. 今日から始めるSAM CLI【API Gateway + Lambda + DynamoDB】
- 18. 【AWS SDK for Ruby】タグが大量にあるリソースの取得処理は非常に時間がかかることがある話
- 19. AWS CLIのqueryの使い方(基本)
- 20. AuroraServerlessのDataAPIの返値をいい感じに整形する
AWS Route53で無停止サブドメイン委任(すでにサブドメイン以下にCNAME等のレコードが存在するケース)
免責: DNSの専門家ではないので、よりよい方法があればぜひ教えてください!
# 背景
親ドメイン(例: hiroga.cc)のHosted Zone内でサブドメイン(例: sub.hiroga.cc)に関するレコードを管理していましたが、Hosted Zone内の見通しが悪くなってしまったので、サブドメインを分割します。
すでにレコードがあるケースの手順が調べても見当たらなかったため、備忘録とします。# 手順
1. サブドメイン用のHosted Zoneの作成
2. サブドメイン用のHosted Zone内へ、親ドメインのHosted Zone内のレコードをコピー
3. サブドメインのHosted Zoneに対するNSレコードの作成
4. 親ドメインのHosted Zone内の、2.でサブドメイン側にコピーしたレコードの削除# 注意点
– 手順2.の段階で親ドメイン内のレコードを削除すると、名前解決ができない時間が発生します。
# 参考資料:
[クラスメソッド – Route 53でサブドメインを別のHosted Zoneに権限委譲する](https://dev
AWS Route53でサブドメインを取得し、SESで使用する
## 参考記事
https://qiita.com/tanakaworld/items/94f1ba66801100f6a44f## Route53でサブドメインの取得
### Route53レコードセットの作成
– 名前:適当な値を入力
– タイプ:Aを選択
– 値:192.168.0.1と192.168.0.2(環境に合わせてください)を入力し、レコードセットの保存を選択### SES設定
– Identity Management => Domains を選択– Verify a New Domain を選択
– Generate DKIM Settingsにチェックを入れる。
– Domain:先ほど作成したサブドメインの値を入力
– Verify This Domain を選択– Use Route 53を選択
– Create Record Setsを選択しばらく待ってから
– Identity Management => Domains を選択
– サブドメインを選択
– Verification Status、DKIM Status、Enable
Cloudwatchのチュートリアルを読み解く
# はじめに
DVAの試験範囲でもあるということで、今日はCloudwatchのチュートリアルをやってみました。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/PublishMetrics.html
# 用語の解説
Cloudwatchを語る上で覚えておく必要のある用語をまとめます。
– データポイント :
– 個々のデータ(CPU使用率で言うと10%、20%のような具体的な値)– メトリクス :
– データポイントを時系列順にまとめたセット– ネームスペース(名前空間) :
– 発行されたメトリクスを格納するコンテナ(論理的な入れ物)
– 任意の名前に設定可能(デフォルトのネームスペースは無し)
– ただしAWSサービスのメトリクスではAWS/のネームスペースが使用される(例:AWS/EC2) – ディメンション :
– メトリクスを一意に識別する名前と値のペアネームスペースとディメンションの使い分けがいつも混同するの
Development on AWS受講までの事前準備 in MacPC
# 概要
AWSトーニング受講にあたり、事前準備として自前のMac端末に色々導入した時のログを残す# 目的
・最低限の開発環境をここで揃えるようにする
・開発の初歩の初歩で詰まる方向け
・アウトプットの練習# 何ができればよいのか
まず、事前に用意すべき環境は
①RDPクライアントからWindowsサーバーへの接続
②Linuxサーバーへの接続その他用意した方が良さそうなもの
③Homebrewのインストールとりあえず上記3つができればよい事にする
# ①RDPクライアントからWindowsサーバーへの接続
こちらを参考にダウンロードと手順に従い、MacからWindowsへリモートデスクトップ接続をできるようにする。詰まりポイントは特にないはず。
# ②Linuxサーバーへの接続
こちらも、Windowsの場合はTeratermなどの専用のターミナルを用意する必要があるが、幸いMacには標準のターミナルが用意されている
そのため、以下を参考にsshロ
~S3(Simple Storage Service)~ AWS学習メモ ~
#S3の特徴、保存形式
【特徴】
・ユーザーがデータを保存しても自動でAWS側で拡張してくれる。
・高い耐久性
・通信やデータ保存時に暗号化【保存形式】
・バケット = オブジェクトの保存場所で名称はユニーク
・データサイズは0KB~5TBまで保存可能## ストレージの種類
【オブジェクトストレージ(S3、Glacier)】
・安価で高い耐久力をもつオンラインストレージ
・オブジェクト形式でデータを保存【ブロックストレージ(EBS、インスタンスストアなど)】
・EC2にアタッチして活用するディスクサービス
・ブロック形式でデータをする
・高速・広帯域幅【ファイルストレージ(EFS)】
・複数のEC2インスタンスから同時にアタッチ可能な共有ストレージサービス
・ファイル形式でデータを保存##整合性モデルの特徴
・データの更新・削除に整合性モデルを採用している
・同時書き込みはタイムスタンプ処理を実施する##S3のアクセス管理
【IAM、ユーザーポリシー】
・IAMユーザーに対してアクセス権限を設定
・一時的にユーザー権限を管理【バケットポリシー】
Terraformのtfstateファイルを消すとどうなるか
Terraformを実行してリソースを作成するとtfstateというファイルが作成されます。
以下公式ドキュメントより
https://www.terraform.io/docs/state/purpose.html
https://www.terraform.io/docs/state/index.html>Terraformは、管理対象のインフラストラクチャと構成に関する状態を保存する必要があります。Terraformはこの状態を使用して、実世界のリソースを構成にマッピングし、メタデータを追跡し、大規模なインフラストラクチャのパフォーマンスを向上させます。
>Terraformは通常、構成を使用して依存関係の順序を決定します。ただし、Terraform構成からリソースを削除する場合、Terraformはそのリソースを削除する方法を知っている必要があります。Terraformは、構成にないリソースのマッピングが存在することを確認し、破棄する予定です。ただし、構成が存在しないため、構成のみから順序を決定することはできません。
>正しい動作を保証するために、Terrafor
AWS SAA 備忘録
#AWS SAA まとめ
AWS SAA受けるにあたり、一旦知識をまとめてみました。
個人の勉強用のため、読みづらかったり、情報が誤っている可能性もあるのであまり信用せず。。※ちなみに自分は受験登録時に名前登録間違えて受験すらできませんでした。。。(0次試験敗退)お金も帰ってこないのでみなさん気をつけてね。。。来週リベンジしよう。。
##ネットワーク
###VPCについて####IGW
– インターネット側への出口
– 各VPCに一つだけアタッチ可能
– 単一障害点とはならない
– ルーティングでIGW(0.0.0.0)と繋がっているものがパブリックサブネット####NATゲートウェイ
– プライベートIPをグローバルに変換
– NATインスタンスとの違いは冗長化されている点####VGW
– オンプレミスとの接続点
– 各VPCに一つだけアタッチ可能
– 一つで複数のDirectConectやVPNと接続可能####サブネット,ルートテーブル
– サブネット作成後にAZを指定する。作成後は変更できない
– サブネット一つに対し、一つのルートテーブルを作成する
鍵を埋め込んだ EC2 インスタンスから取得した AMI に別の鍵を指定して起動しても以前の鍵が残るので対処します。
★AWS 備忘録シリーズ
共通ミドルウェアやアプリケーションを Amazon EC2 へ事前インストールを行い、 Amazon Machine Image(AMI)を取得するという営みをしていると思います。
その際、鍵を埋め込んで EC2 インスタンスの起動をしていると、以前の鍵の情報が残り続けることはご存知でしょうか。
特に、本番や開発といった環境ごとや EC2 に割り当てている機能ごとに鍵を分けている場合に直面しやすい問題です。
※本稿では AWS 提供の AMI に何がしかの設定を入れて、いろんな機能を設定するためのもとになる AMI を**ベース AMI** と呼称します
## 鍵が複数埋め込まれる流れ
1. ベース AMI を作成する担当者は定期的に AWS 提供の AMI に AMI 作成担当者用の鍵を使って EC2 を起動(**1本目**の鍵が埋め込まれる)
2. その EC2 インスタンスに必要なミドルウェアなどをインストール
3. AMI を取得
4. 3で取得した AMI をインフラ構築担当者に伝達
5. インフラ構築担当者はその AMI の ID と
Route53のレコードセットに AWS CloudFormation を利用しました
# 背景
いつもは、Route53 レコードセットをマネージドコンソールから手動設定しています。
先日、EC2インスタンスの構成をAWS CloudFormationでテンプレート化したこともあり今回もテンプレート化にチャレンジした記録です。* [[軽作業用インスタンス構築に AWS CloudFormation を利用しました]](https://qiita.com/yodyman/items/48897045807f225a362d)
# 今回実現したいこと
「sample.com.」の各種レコードセットを実施したい
* Aレコード設定
* IPアドレス指定
* エイリアス指定
* CNAMEレコード設定
* 加重レコード設定
* 位置情報レコード設定公式サイトの「[Route 53 テンプレートスニペット](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/quickref-route53.html)」を参照
# テンプレート
今回もYAML形式で記述しました[[AW
S3にCSVファイルがアップロードされるとLambdaがDynamoDBへデータを挿入します
#概要
S3へjsonファイルがアップロードされるとLambdaがそのファイルの中身を解析して、DynamoDBへデータを挿入します。#jsonファイルの構成
`data`キーに配列があり、配列の要素はオブジェクトとなっています。“`json
{
“data”: [
{
“item1”: “sample data1”,
“item2”: 123,
“item3”: “test data1”
},
{
“item1”: “sample data2”,
“item2”: 1234,
“item3”: “test data2”
},
]
}
“`#主な流れ
1. S3へファイルがアップロードされるとLambdaが起動
2. アップロードされたファイルの中身を取得
3. `data`キーから配列を取得
4. 配列を`forEach`で各要素をDynamoD
EC2インスタンスをAnsibleで操作するための事前準備
## 目的
本投稿では、AWSインスタンス(EC2)に対して、Ansibleでリモート操作するための事前準備について解説します。
## 構成
Ansible Client (Cloud9) -> Ansible Target(EC2 インスタンス)
– Ansibleインストール対象となるインスタンスとして、Cloud9を今回は利用しましたが、通常のEC2インスタンスでも構いません。
– Ansible ClientとAnsible Targetは、ネットワーク疎通が取れる状態にする必要があります。## 設定手順
### STEP1. Ansibleのインストール
以下コマンドでcloud9インスタンスに対して、ansibleのインストールを行います。
“`
sudo su –
yum install ansible -y
cd /etc/ansible/
“`最新バージョンである2.6.20がインストールされていることを確認します。
“`
ansible –version
ansible 2.6.20
config file = /etc/
Node.jsで常時フォルダを監視してS3へファイルをアップロードする
#概要
あるフォルダに不定期にCSVファイルが作成されるので、そのCSVファイルをS3にアップロードするプログラムをNode.jsで作成します。
処理に失敗するとAWS SESを使って、管理者へメールを配信します。
loggerも使って何が起こったかを追えるようにします。
[全コードはこちら](https://github.com/TKFM21/monitoring_template)#フロー
##起動時に監視フォルダとローカルの保存フォルダが存在するかチェック
“`javascript:initial_check.js
const fs = require(“fs”);
const fsPromises = fs.promises;const initialCheck = async (WATCHING_DIR, DEST_DIR) => {
try {
await fsPromises.access(
WATCHING_DIR,
fs.constants.R_OK | fs.constants.W_OK
);
await
【Nuxt.js】AWS ECR/FargateにデプロイするためのDockerイメージ作成方法
# TL;DR.
– AWS上でNext.js(SSR)アプリを動かすために、NuxtアプリをビルドするためのDockerイメージが必要
– ローカル環境で`docker build`した後、ECRにDockerイメージをpushして、それをFargateにデプロイする## 前提
– Node.jsのパッケージは管理は`yarn`を利用
– ローカル環境でNuxt.jsアプリが立ち上がる(yarn build / yarn startが実行できる)であること# ローカル環境での作業
#### 1. ルート直下に以下のファイルを作成
“`Dockerfile:Dockerfile
FROM node:12-alpineENV HOST 0.0.0.0
RUN mkdir -p /app
COPY . /app
WORKDIR /appARG ENV
ENV ENV $ENVRUN yarn && yarn build
EXPOSE 3000
CMD [“yarn”, “start”]
“`“`text:.dockerignore
node_modu
AWS Beanstalk環境における、Blue/Greenデプロイの実装によるデプロイ作業の簡略化
– Beanstalkで構築した環境で動くRailsアプリのデプロイを毎回手作業で行っていた
– コンソール上でデプロイする場合、いちいちアプリを圧縮し手作業でUPしないといけない
– デプロイだけなら上記手順で済むが、環境そのものの設定を変更したいときは一から作り直し。。。
– CodeCommitのリポジトリを参照してBeanstalkをビルドし、デプロイ処理を実行するパイプラインを作れば、デプロイ自動化できる!ということを教えていただきましたので備忘録として書き記します
– AWSに関してはかなり初心者(片手間で3ヵ月くらいしか触ってません)なので、おかしな部分があればご指摘いただければ幸いです“`
利用したAWSサービス:
– Elastic Beanstalk
– CodePipeline
– CodeCommit
– CodeBuild
– CloudFormation
“`## Blue/Greenデプロイとは
“`
In place: インスタンスはそのままに、新しいリビジョンのアプリのみをその場で反映させる
Blue/Green:
AWSソリューションアーキテクト アソシエイトに合格したので振り返り
#はじめに
2020/1/31にAWSソリューションアーキテクト アソシエイト(SAA)に合格したので振り返ります。
今年3月には試験が改定されること、勉強計画が良くなかったこともあり、あまり参考にはならないかもしれません…##事前情報として…
・AWSクラウドプラクティショナーに2019年12月に合格した
・SAAの勉強期間は約1か月##SAAの学習において重要と感じたこと
参考書は試験範囲全体を把握する程度にして、とにかく問題を多く解くのがいいと思いました。特に本試験は変わった問題や聞いたこともない用語が出てきたので、
1つのサイトやテキストの練習問題だけでは対策しきれないと感じました。Udemyなどの練習問題を色々と活用するのが最も良い学習法ではないかと思います。
(後述の失敗の通り、私はUdemyなどで勉強する時間が取れませんでした)##学習方法
以下のものをメインで使用しました。①[徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書](https://www.amazon.co.jp/%E5%BE%B9%E5%BA%95%E6%9
AWSでWordPressを始めてハマった話
# はじめに
突然「よーしパパAWSでWordPress頼んじゃうぞー」と思い立つ。まずは検索。
https://www.google.com/search?q=aws+wordpress情報いっぱいあるし、**余裕だな**。
# アカウントを作る
[AWS アカウント作成の流れ](https://aws.amazon.com/jp/register-flow/)
**簡単そうだな**。[スケーラブルなウェブサイトの構築方法:フェーズ 1
サーバー 1 台構成で WordPress 環境を構築](https://aws.amazon.com/jp/getting-started/projects/scalable-wordpress-website/01/)
スケーラブルにはしないのでサブネットの設定などは必要無いのだが、特に考えずにチュートリアルの通り進める。
見本の画面と実際の画面がところどころ違うが、大した問題ではない。
**簡単すぎる**。
# WordPressでハマる
無事にインスタンスが起動した。[フェーズ 1-5](https://aws.amazon.c
今日から始めるSAM CLI【API Gateway + Lambda + DynamoDB】
## SAM CLIでAPI Gateway + Lambda + DynamoDBを使う
AWSでのサーバレス構築を考えた時に最も無難でポピュラーな構成(悪く言えばあまり面白みのない)として挙げられる、
– API Gateway
– Lambda
– DynamoDBの構築を、SAM(Serverless Application Model) で行います。
## 書くこと
1. SAM CLIでプロジェクトの作成
2. SAMプロジェクトのデプロイ
3. SAMプロジェクトを修正してDynamoDBにテーブルを作成
4. SAMプロジェクトの更新## SAM CLIでプロジェクトの作成
まずSAM CLIをインストールします。
[Installing the AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)
“`
$ sam –version
SAM CLI,
【AWS SDK for Ruby】タグが大量にあるリソースの取得処理は非常に時間がかかることがある話
# はじめにまとめ
– AWS SDK for Rubyでタグが大量に付与されているリソースを大量に取得する処理は、タグが無いリソースに比べて大幅に時間がかかることがある(今回はEBSとEBSスナップショットで確認)
– 原因はSDK内で、AWSのAPIレスポンスのXMLをRubyのオブジェクトにパースするときの変換処理![graph.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/50690/e4d3a275-c9c5-f39f-4961-234f9df37af3.png)
# 背景
AWS SDK for Rubyである程度数の多いリソースの取得に非常に時間がかかったことがあり、原因を追求するとタグが大量に付与されたリソースの場合にそのような事象が発生する場合があることが分かったので、検証したメモ。# 前提(検証環境)
– クライアント
– 東京リージョンのLightStail
– Ubuntu 18.04
– Ruby 2.6.3
– AWS SDK fo
AWS CLIのqueryの使い方(基本)
# はじめに
前回、AWS CLIの–filtersの使い方を勉強したので、その流れで–queryの使い方を調べました。
新卒で入った現場がAIXの運用保守(たまに構築)だったということもあってCLIを使っているということもあるので、今後はCLIを使いこなせるようになろうと思っています。
※前回
https://qiita.com/kkino1985/items/6e92e87e01f40bc06d8b# 環境情報
OS : Windows10
CLI : aws-cli/1.17.9 Python/3.7.4 Windows/10 botocore/1.14.9# –filtersと–queryの違い(使い分け)
ざっくり言うと、指定した条件と一致する(またはしない)リソースを表示させるのが–filters、出力結果のうちどの項目を(何という名前で)出力させるかを制御するのが–queryです。
(こちらの記事にもっと良い表現がありました)
https://dev.classmethod.jp/cloud/aws/aws-cli-filter-and
AuroraServerlessのDataAPIの返値をいい感じに整形する
[以前の記事](https://qiita.com/Kept1994/items/157524e27e7742954f57)でAPI GatewayからAuroraServerlessにDataAPIを介してクエリを投げることは成功したが、戻り値がなんとも扱いにくい。。。
“`json:DataAPIでの戻り値
[
{
“stringValue”: “001”
},
{
“stringValue”: “fuga”
},
{
“longValue”: 123
}
]
“`そこで、DataAPIの返り値をいい感じに整形するlambdaサンプルコードを書いた。
カラム名は返り値のメタデータから取得する。“`python:サンプルコード
import jsondef lambda_handler(event, context):
key_list = []
value_list = []columns = event[“columnMetadata”]
records