AWS関連のことを調べてみた2020年07月29日

ACMとELBを使いEC2サーバの証明書を一つにまとめる

# 概要

これまでEC2サーバ毎(コーポレートサイト、Redmine、GitLab等)にサーバ証明書を発行しており、証明書の更新作業が煩雑になっていました。
今回、EC2サーバにロードバランサーを挟むことでサーバ証明書を一つにまとめる作業を実施しました。

## 以前のサーバ構成

下記図のようにEC2サーバそれぞれが独立し、サーバ証明書を別々に使用している状態となっていました。

– https://○○○(ドメイン名).co.jp
– https://redmine.○○○(ドメイン名).co.jp
– https://gitLab.○○○(ドメイン名).co.jp etc…


## 今回の作業後のサーバ構成

下記図のようにELBを挟み、ACMから発行されるサーバ証明書一つに設定しました。
Gitlabについては、以

AWS: lambdaを使わないでEC2の定期起動・定期停止するCloudFormationを作る

## はじめに
EventBridgeを使ってEC2の定期起動・停止するCFnを作る時たくさん悩んだので、未来の私がCFn見直した時に思い出せるようにするためのメモ。

## CloudFormation

### 1. このCFnでつくられるもの。

##### ■ CloudWatch Event Rule
– 起動させるイベントルール
– 停止させるイベントルール

##### ■ IAM Role
– 自動化用のAutomationAssumeRole
– AWSマネージドポリシー
– 起動イベント用のロール
– カスタムポリシー
– 停止イベント用のロール
– カスタムポリシー

—

### 2. つくったテンプレート。

“`yaml
AWSTemplateFormatVersion: 2010-09-09
Description: EC2_Start_Stop

Parameters:
EC2InstanceID1:
Type: String
Description: EC2InstanceID1
Def

Boto3 に追加されたリトライ処理モードを利用する

## はじめに
AWS SDK は [Exponential Backoff](https://docs.aws.amazon.com/ja_jp/general/latest/gr/api-retries.html) による自動再試行ロジックが実装されていますが、
Boto3 では 3 つのリトライ処理モードを選択できます。

* legacy (デフォルト)
* standard
* adaptive

botocore の GitHub リポジトリを確認すると、2020年2月ごろに standard および adaptive が
追加され、それ以前の実装は legacy という名称になっています。

[Add support for new retry modes #1972](https://github.com/boto/botocore/pull/1972)

互換性のため、デフォルトが legacy となっており、standard/adaptive で追加された機能を
利用するにはリトライ処理モードを明示的に変更する必要があります。

## リトライ処理モードの変更方

ECS Fargate(Version 1.4.0)にてffmpegなpipe芸をしようとしたら見事に動かなかったので証跡を書いておく

# 概要

2020年7月29日現在、Fargateのver 1.4.0にてpipe周りにおかしな挙動があるっぽい。

おかげでffmpegのpipe芸に詰まってそれなりに時間を溶かしたのでメモっておく。

# 何をしたかったか？

ECSをTask RunするとRTMPを落としてMP4にパッケージングしつつS3に投げ込むっていう超絶シンプルな行いをしたかった。

原本では無いけど、Dockerfileとか起動時用コマンドはこんな感じ。

## Dockerfile

“`dockerfile
FROM ubuntu:18.04

ENV DEBIAN_FRONTEND=noninteractive

RUN set -x \
&& apt-get update \
&& apt-get install -y \
curl \
wget \
tar \
xz-utils \
liblzma-dev \
ca-certificates \
openssl \
musl-dev \
tzdata \

スタックの有無で待つ状態を切り替える

スタックの有無で wait するコマンドを切り替える。

“`bash
#!/bin/bash
set -eu

STACK_NAME=”foobar”
IS_UPDATE=0

set +e
aws cloudformation describe-stacks –stack-name ${STACK_NAME} > /dev/null 2>&1
if [ $? -eq 0 ]; then
IS_UPDATE=1
fi
set -e

aws cloudformation deploy –stack-name ${STACK_NAME} –template-file /path/to/template.yml

if [ $IS_UPDA

「WARNING: psql version 9.2, server version 11.0.　Some psql features might not work.」エラー対処(AWSLinux(EC2)からpsql11のインストール)

EC2でpostgresqlを使えるようにするぞー！とやっている最中で「WARNING: psql version 9.2, server version 11.0. Some psql features might not work.」が出てきてふぁ！？ってなっていろいろ調べたので記録します。

#Warningの内容
「サーバー側のバージョンは11.0だけどあなたが使っているpsqlバージョンは9.2よ！一部動かないかもしれないわ！」
と忠告してくれているようです。

#対処

バージョン11のpostgresqlをインストールします。

“`
sudo yum install postgresql
“`

でpostgresqlをインストールしようとすると、なにやらいろいろでてきた後に

“`
–> Finished Dependency Resolution

Dependencies Resolved

==================================================================

Nuxt × Go × AWS で比較コミュニケーション的な掲示板サービス作ってみた

比較コミュニケーションサイト Versus
https://versus-web.net



~~Twitter で技術マウント合戦している人たちが面白かったので~~
AWS と Go の勉強がてら、テーマを持ち寄ってコミュニケーションできる簡単な掲示板

AWS本番環境でよく使うコマンド一覧

自分のメモ用です。

#環境
Rails 5.2.4
ruby 2.5.1
capistrano 3.13.0
AWS(EC2)
Web Server Nginx
Application Server Unicorn

#Capistranoを導入後の自動デプロイの手順

###ターミナルからEC2userへログイン
“`
MacBook-Pro ~ % $ cd .ssh/

# ログイン
MacBook-Pro .ssh % ssh -i app名.pem ec2-user@18.000.000.00(IPアドレス)

# リポジトリに移動
[ec2-user@ip-111-11-11-111 ~]$ cd /var/www/app名　
“`
###Nginxの再起動
“`
ターミナル（EC2サーバ）[ec2-user@ip-111-11-11-111 ~]
$ sudo service nginx reload
$ sudo service nginx restart
“`
###MySQL起動
“`　
ターミナル（EC2サーバ）[ec2-user@ip-111-11-

ECR のイメージを使った ECS (Fargate) の構築を VPC の 中で完結させる

# 解決したいエラー

VPC 内で ECR のイメージを使って ECS Cluster を起動しようとすると、`CannotPullContainerError` のようなエラーが頻出する。

# 原因

ECR からイメージを取得するためには、ECR, S3 に接続する必要があるが、private subnet を使用している場合、これらのリソースにアクセスできず、取得に失敗している。

# 解決方法

– ECR のイメージ取得をインターネット接続を経由して行えるようにする
– VPC 内に各リソースを繋ぐトンネルを構築し、そこ経由で ECR のイメージ等が取得できるようにする

Ref: https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-api-error-ecr/?nc1=h_ls

2番目の方が綺麗だけれど、Cloud Formation を書くのがめんどくさい。
一度作成したので、使いまわせるようにここに置いておく。

# Cloud Formation

## VPC

`

逆引き Serverless Framework events for AWS

最近、既存の lambda を全て Serverless Framework を使って置き換えました。
Lambda は色んな event をトリガーにできるのですが記述方法を毎度ど忘れしてしまい、調べ直すことがあったのでメモを残します。もちろんこれで網羅しているわけではないので気づいたことあればご指摘ください。

# serverless.yml
ざっくりと基本構成について。

以下のように外部ファイルに値を定義している方法についてはこちらを参照
`${file(../variables-${self:provider.stage}.yml), file(../variables-dev.yml)}`
[Serverless Framework + Kotlin + Gradle で Lambda をデプロイする – Qiita](https://qiita.com/Nabesuke/items/40139ee441a33cb1dcf2#custom)

“`serverless.yml
service: my-service # サービス名

provider: # 各fun

[AWS] Serverless Application Model (SAM) でAPI Gateway + Lambda + DynamoDBなサンプルを作成してみる

# 前提
## 環境
今回は、Macの環境で行いますが、セットアップ方法以外の実行に際しては、Windows / Linuxでも大きな差異はないので、ご参考になるかと思います。

## 構成

– API Gateway
– Lambda (Python 3.7)
– DynamoDB

boto3によりDynamoDBにレコードを作成するサンプルを作成してみたいと思います。

## その他必要なもの

– AWSアカウント

# セットアップ
まずは、「[[AWS] Serverless Application Model (SAM) の基本まとめ](https://qiita.com/herohit-tool/items/420f4a7b294cfcf56ed7)」にあわせてセットアップをしていきたいと思います。

– Docker Desktopをインストールする
– Dockerを起動する

“`bash:Version確認
$ docker -v
Docker version 19.03.12, build 48a66213fe
“`
– Homebrewをインストールす

EC2 インスタンス名の一部からインスタンス情報を瞬時に出す

# 背景

あ、あの情報が必要なんだけど、なんだっけな。。
という時に、さくっと情報を取り出せたらスマートですよね。

業務上、EC2 インスタンスID 知りたくなることがあります。
[SSH over Session Manager](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html) で接続したいので、インスタンスID が必要だったり、 aws cli で AMI作りたいので、インスタンスID が必要だったり。

ブラウザからAWSコンソールにアクセスして調べたり aws cli で [describe-instances](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html) を使

東京大学計数工学科講義「AWSによるクラウド入門」をやってみた

東京大学計数工学科で開講されている講義資料「[AWSによるクラウド入門](https://tomomano.gitlab.io/intro-aws/)」が公開されており、AWSの基礎だけでなく、機械学習やサーバレスなどもHands-Onを通じて学べるということで、早速実施してみました。

クラウド入門者向けに簡潔かつ平易な言葉で書かれており、大変勉強になりました。飽き性の私でも最後まで楽しんでできました。

#かかった時間と費用

・一通り解説を流し読み、Hands-Onも全て実行して、約4時間
・費用は、0.49ドル


#学べること

大きく以下３点です。気になるキーワードがあれば、そこだけ掻い摘むのも良いのではないかと思います。

###クラウドの基礎
・クラウドの基礎となる概念・知識
・セキュリティやネットワークなど，クラウドを利

docker: AWSから完全にuninstall

###1 dockerが作成したnetworkを削除
`docker network prune`

###2 pre-definedのnetworkも削除
`service docker stop`
`vim /etc/docker/daemon.json`

“`.json:daemon.json
{
“bridge”: “none”
}
“`
`vim service start docker`

###3 uninstall
`sudo yum remove docker docker-common docker-selinux docker-engine`

###4 設定ファイルの削除
`rm -rf /etc/docker`

###5 imageの削除
`rm -rf /var/lib/docker`

git-remote-codecommit(GRC)を使ってAWS CodeCommitに繋いでみたら楽になった

こんにちは。AWS歴３年生の人です。最近、インフラもコードで管理するInfrastructure as Code(IaC)に関連して、Gitを使い始めたのですが、2020年春にAWSからgit-remote-codecommitという新しいGit認証ツールがリリースされたので勉強がてら試してみました。

[AWS CodeCommit が新しい Git 認証情報ヘルパーの git-remote-codecommit を導入](https://aws.amazon.com/jp/about-aws/whats-new/2020/03/aws-codecommit-introduces-open-source-remote-helper/)

**注意**

– 本記事は2020年7月17日時点でのバージョンで確認しました。

– 記載のコードにつきましては参考となりますので、利用時の不具合について一切の責任を負いません。

## 結論。こんな方におすすめです。

– AWSがきっかけでGitを使い始める人。
– AWSが提供しているGitリポジトリへ接続するための認証補助

ドメイン駆動設計の概念を古代哲学で整理する

今回の記事では、ドメイン駆動設計のドメイン層のアイディアを紀元前300年頃に発生した古代哲学の概念を利用して整理します。

古代の世界では、理論と実践が一致していたため、理論家は実践経験を踏まえた上で概念やアイディアを作成していました。
そのため、古代の世界では哲学者とは理論化であり実践者でした。
哲学者は実践経験において感じ取った概念をパターン化、抽象化し、人間の認識領域で共通した知識を共有するために哲学を作成しました。
古代の哲学は、現実の世界を捉えるためのテンプレートを提供し、人間の認識領域を拡大します。

今回の記事では、古代の哲学の概念を拝借し、ドメイン層の力の概念、形態、構造を明らかにし、ドメイン層をより深く理解するアイディアを提供します。

#ドメイン層の概念整理に利用する古代哲学
##アリストテレスの四原因説
四原因説とはアリストテレスが自著『自然学』の中で論じた、自然学の現象に関する4種類の原因。以下の4つの因子で構成されている。
**目的因・・・物事の終り、すなわち物事がそれのためにでもあるそれ（目的）をも原因と言う。**
**形相因・・・形相または原型。**
**

SSH通信について　まとめたこと

#SSH通信とは
SSH通信とは、Secure Shell の略で、言わばセキュリティの強固な通信方法のこと。
SSH通信を用いて送られている情報は全て暗号化されており、
仮に通信を覗き見をされていたとしても、キーを持っていなければ解読することが出来ないようになっている。

#SSHの仕組み

“`
[local]1.通信用の秘密鍵・公開鍵の作成
[local]2.サーバーに公開鍵を渡す

[server]A.サーバーにユーザーを登録する(sudo権限)
[server]B.サーバーに登録されているユーザーと、渡された公開鍵を紐づける
※この状態で初めて作成したユーザーによるサーバーへのログインが可能となります。

[local]3.作成したユーザーでログイン

[server]C.ログイン時に乱数を生成
[server]D.Cで生成した乱数から、ハッシュ値を生成
※このハッシュ値は認証で使うのでサーバー側で保持しておく。
[server]E.受け取った公開鍵 + Cで生成した乱数を用いて、暗号を生成
[server]F.Dで作成した暗号をローカルに送る

[local]4.1で作

【AWS】EC２ インスタンス SSH接続エラーを解消（ssh: connect to host xxx.xxx.xxx.xxx port 22: Operation timed out）

# はじめに
Rails アプリをAWSにてデプロイしようと試みていた過程でEC2サーバにローカル環境からアクセス（SSH接続）しようとした際に、突然アクセスできなくなる、というトラブルに遭遇したので解決方法とともに残します。
（かなり初歩的な部分かと思います。）

原因は場所を移動して作業したこと（接続場所によりIPアドレスが相違していたこと）にありました。
以下で詳細について書きます。

※筆者はMacを使っており、接続方法はMacの仕様で行なっております。

# どのようなエラーが起きたのか？
ローカル環境（MacBookAir)から、該当のECSインスタンスにSSHキーを使って、SSH接続を試みる。

“`
# ターミナルにて

$ ssh -i .ssh/ファイル名.pem ec2-user@xxx.xxx.xxx.xxx（該当EC2インスタンスのパブリックIP）

ssh: connect to host xxx.xxx.xxx.xxx port 22: Operation timed out
“`

すると、「接続操作がタイムアウトした」という内容のエラーメッセージ

AWSを利用した会員サイトをサーバーレスで実装しました

AWSを利用した会員サイトをサーバーレスで実装しました。
始めはCognitoとS3でなんとかなるだろうと思っていましたが、
いざやってみるとどうにも思い通りにならず、四苦八苦しました。

調べてみると、どうやらCognitoとS3だけでは、S3に対して**ユーザー単位のコンテンツ**にしかアクセスできず、**ユーザー共有のコンテンツ**にはアクセスできないみたいです。(私の調査不足/理解不足かもしれませんが…)

というわけで、以下のAWSの機能を利用して実装してみました。

* S3
* CloudFront
* Cognito
* API Gateway
* Lambda

## 処理手順
1. S3に公開フォルダと会員限定フォルダを作成する。
1. S3に対してはCloudFrontを通してアクセスする。
1. S3の会員限定フォルダへは、**CloudFrontの閲覧者のアクセスを制限する機能**のCookieを使用する。
1. Cognitoで認証が成功した場合、認証情報のJWTトークンをAPI Gatewayのオーソライザーで検証する。
1. API Gatewayの

AWS 認定クラウドプラクティショナー(CLF)を、これまでの振り返りを兼ねて取得したやったことまとめ

# はじめに
AWS 認定クラウドプラクティショナー(CLF)について、これまでの振り返りを兼ねて受験してみました。

クラウドプラクティショナー認定については、Qiita記事が多く投稿されていますので、少し視点を変えて、クラウドプラクティショナー認定に特化した内容は何だったのか感じた内容をお伝えできればと思います。
変則的とはなりますが、クラウドプラクティショナーに関わるAWS関連サービスのイメージを掴んでいただければ幸いです。

# 本記事の主な対象者
– クラウドプラクティショナーの受験を検討している方
– 取得に向けて有効な学習方法などの情報収集したい方

# 筆者のAWS認定履歴

|AWS認定 |取得日 |
|—|—|—|
|ソリューションアーキテクト – アソシエイト |2018-05-13|
|デベロッパー – アソシエイト |2018-06-03|
|SysOpsアドミニストレーター – アソシエイト | 2018-06-10|
|ソリューションアーキテクト – プロフェッショナル |2018-07-29|
|DevOpsエンジニア – プロフ