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

docker-compose + capistrano

## 前置き
一応、AWSにデプロイすることを想定しています
すでに手動デプロイが成功している前提で行います

## 構成
本番環境用にふたつ用意する
– docker-compose.production.yml
– Dockerfile.production

## コンテナ内にキーを保存
ローカルで下記コマンドを実行し、キーをコピー。
ローカルで起動するコンテナにコピーすること
“`
$ docker container cp ~/.ssh/<秘密鍵名> <コンテナ名>:/root/.ssh/<秘密鍵名>
“`
コンテナ内で下記コマンドを実行し、EC2にログインできるか試す
“`
$ ssh -i ~/.ssh/<秘密鍵> ec2-user@EC2IPアドレス
“`
できたらおk
ローカル環境用のdocker-compose.dev.ymlに、キーを保存するよう記述
“`
web:
# 省略
volumes:
– ~/.ssh:/root/.ssh
# 省略
“`

## Gem追加
“`Gemfile
group :deve

AWS-SAA（C03）試験の対策

2022 年 8 月 30 日からAWS SAAの新試験が開始されます。

https://aws.amazon.com/jp/certification/coming-soon/

8月からちょこちょことSAAの勉強をしていたのですが、新試験に変わることを知らず旧形式の教材を使っていました。。。
無理をして旧形式の試験受験にも滑り込めたのですが、どうせなら新しいサービスも合わせて知っておきたいと思い、新試験で受験することに決めました。
何が変わったのか、追加されたサービスが何なのかまとめていきます。

## 試験ガイドの比較
AWSの新試験についての案内を読んでみると試験ガイドをよく読んでねって書いてありましたので詳しく比較してみました。
試験ガイドは以下から確認できます。
##### SAA-C02の試験ガイド
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-assoc/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf
###

AWS lambda nodeをローカルでdocker開発して、イメージデプロイする

https://aws.amazon.com/jp/builders-flash/202103/new-lambda-container-development/?awsf.filter-name=*all

AWS lambdaの開発にSAMを使用していましたが、ローカルでdocker開発して、そのままデプロイできるようになったらしいので手順の確認。

dockerのイメージ生成→AWSのECRリポジトリにPUSH→AWS Lambda にECRからデプロイ。

https://qiita.com/rei-ta/items/e86546130d157561ba8e

Dockerfile
docker-compose.yml
package.json
app.js

Dockerfile

“`
FROM public.ecr.aws/lambda/nodejs:16
COPY app.js package*.json ./
RUN npm install
CMD [ “app.lambdaHandler” ]
“`

ecrイメージでのdockerを作成。public.ec

AWS Organizationsの使用事始め

# はじめに
組織内で複数のAWSアカウントを所有している場合、[AWS Organizations](https://aws.amazon.com/jp/organizations/)を使用することで、AWS環境の一元管理やガバナンスを効かせることが可能になりますが、業務でAWS環境の管理者経験のある方でなければ、AWSを触ってる方でもおそらくは数多くのAWSサービスの中でも使用する機会のないサービスかと思います。とはいえ、AWS Organizationsは無料で使用できますし、いつ何時業務でAWS環境管理を任されないとも限りません。(そもそも業務でAWSを使う機会があるのかというのもありますが、とりあえずそれは置いておきます。)

そこで、今回は個人で利用しているAWSアカウントを使用して、AWS Organizationsサービスを使って、アカウントの招待や組織単位(Organizational Unit)の作成などをしてみました。以下にそのときの手順を備忘録的にまとめておきます。

# 事前準備
* 複数のAWSアカウントの準備
* AWS Organizations

デフォルトVPCとは

# デフォルトVPCとは
AWSではネットワークが詳しくない人でも利用できようにリージョンごとに**デフォルトVPC**が用意されている。
デフォルトVPCは選択したら、使用できる城田になっているので、個別に設定をする必要がない。基本的な要件の場合デフォルトVPCを使うと便利。
# デフォルトVPCの構成
デフォルトVPCとは**サブネットやインターネットゲートウェイが予め設定されているVPC**。EC2およびRDS作成画面で確認できる。
ネットワークの範囲は、プライベートIPアドレスの172.31.0.0/16が振られている。デフォルトのVPCでは「デフォルトのサブネット」と呼ばれるサブネットが、それぞれのAZに1つずつ作成される。東京リージョンだと、全てで4つ用意される。

**デフォルトVPCのネットワーク構成**
|ネットワーク|CIDR|ネットワークの範囲|
|-|-|-|
|VPC全体のネットワークの範囲|172.31.0.0/16|172.31.0.0~172.31.255.255|
|サブネット1|172.31.0.0/20|172.31.0.0~172.31.15.2

EC2上にrailsアプリをデプロイするまで～puma起動で躓いた所を整理

アプリケーションのpumaの起動で起きたエラーとその解決策を記録。

もろもろの設定を終えた後に

bundle exec pumactl start

で起動しようとすると、

! Unable to load application: Aws::Sigv4::Errors::MissingCredentialsError: missing credentials, provide credentials with one of the following options:
– :access_key_id and :secret_access_key
– :credentials
– :credentials_provider
missing credentials, provide credentials with one of the following options:
– :access_key_id and :secret_access_key
– :credentials
– :credentials_provider

という謎エラー。数日前に

Amazon S3からのスクリプトの実行をやってみた。

# はじめに
`AWS Systems Manager`のユーザーガイドを眺めていたところ、「**Amazon S3からのスクリプトの実行**」という内容が目に留まったので実際にやってみました。

– [Amazon S3 からのスクリプトの実行](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/integration-s3.html)

# AWS Systems Managerとは
`SSM Agent`と呼ばれるエージェントソフトがインストールされているノードに対して、パッケージ・パッチの適用管理を行ったり、対象ノードにリモートログインしたり、今回のように対象ノードに対してスクリプトを実行したりするサービスです。

別々のサービスに分けてもいいんじゃないかと思われるほど`Systems Manager`は様々な機能を提供しているサービスですが、特にリモートログイン機能は、セキュリティグループで`SSH`を許可しなくてもアクセスでき、`Systems Manager`側で操作ログや権限制御を行うこ

AWSアソシエイト勉強でつまづいた点 part6

DAX（DynamoDB Accelerator)

DynamoDBのインメモリのキャッシュクラスタ
DAXを利用することにより、ミリ秒（千分の一秒）だったレスポンスをマイクロ秒（百万分の一秒）レベルのパフォーマンスまで向上させることができる

Redshift クロスリージョンスナップショット

Amazon Redshiftでは、スナップショットを採取することでバックアップをとる。スナップショットは、 RedshiftのディスクイメージをAmazonS3へ保存する。

スナップショットは異なるリージョンへ保存することもできる。これを「クロスリージョンスナップショット」と呼ぶ
異なるリージョンへ取ったスナップショットから Redshiftクラスタを再構築できるので、大規模な災害への対策（Disaster Recovery：ディザスタリカバリ）や異なるリージョンで Redshiftクラスタを構築する場合に有効

リザーブドキャパシティユニット

Amazon DynamoDBにおけるプロビジョニングモードの書き込み・読み込みの単位

仮想ネットワークを使うまでの流れ

# VPCで設定すべきこと
**VPCとはネットワークのこと**。すなわち、**どんな環境にサーバー(インスタンス)を置くのか、そのサーバーはインターネットに接続するのか**を設計する必要がある。
**インターネットへの接続をするのであれば、インターネットゲートウェイの設定が必要。**
**オートスケーリングを行うのであれば、サーバーが自動的に増えるので、IPアドレスを多めに用意しておく必要がある**。
セキュリティグループやネットワークACL(どちらも仮想ファイアーウォール)の設定のため、インスタンス用途に応じたポートの設定も考える必要がある。デフォルトではポート（機器やソフトウェアが外部の別の主体と接続・通信するための末端部分のこと）が開いていないので、サーバーとして使用するには、設定を変える必要がある。
VPCには予め、デフォルトVPCを初め、デフォルトのサブネットや、デフォルトのセキュリティグループが用意されている。
# VPCを使用する流れ（マネジメントコンソールにて）
1. AWSにログインする
* リージョンを選択し、マネジメントコンソールを開く
* VPCダッシュボード

AWS上に作成する仮想ネットワーク

# Amazon VPCとは
**Webサーバーやデータベースサーバーなど、各種サーバーは、ネットワークにつながってなければ、意味を成さない。**
そこで、**AWSで提供されているリソースを仮想ネットワークに置くのが、AmazonVPC**。
**Amazon VPC（Virtual Private Cloud）はAWSアカウント専用の仮想ネットワークでAWSで提供されているリソースのみを置くことができる**。
EC2やRDSの場合、作成時にVPCを選択しなければならない。
# VPCの構成
VPCの中にサーバーを置くことでネットワークに所属することになる。
しかし、VPCはそのままでは閉じたネットワークなので、VPC自体をさたにインターネットや社内LANに繋げる必要がある。
# VPCの機能
VPCでは**ネットワークやサブネットの範囲、ルートテーブルやネットワークゲートウェイの設定など、仮想ネットワーキング環境**を設定できる。
**VPCの主な機能**
|項目|内容|
|-|-|
|CIDRブロック|サブネットのこと。ネットワークを分ける範囲。VPC作成時にネットワークの範囲を

コンテナイメージから作るLambdaをSAMでデプロイ

# はじめに

以前、Microsoft365の監査ログを取得するLambdaをコンテナで作りました。

https://qiita.com/a_b_/items/84d6ae3cf8a21b8b332c

これを以下のページを参考に、Cloud9上でAWS SAM CLIでのデプロイにチャレンジしてみました。

https://aws.amazon.com/jp/builders-flash/202107/new-lambda-container-development-4/?awsf.filter-name=*all

# 所感

– AWS SAM CLIを用いると、デプロイまでの手間が減る
– 特に、ECRの作成や管理を考えなくてよいのが大変助かる
– 上記ページでは作っていますが、現時点では不要のようです
– (Cloud9上の)AWS Toolkitのウィザードでも試しましたが、launch.json を使ったデバッグ実行がうまくいかなかった
– AWS SAM CLIのナビゲーションで十分便利なので、GUIのウィザードを使わなくてもよいかも

EC2→ECS移行の際に、本番環境へのデプロイにecspressoを用いた話

# はじめに

本日のテーマはWebアプリケーションのEC2 → ECS Fargate移行の際に、
ECSデプロイツールであるecspressoを利用した話です。

#### 移行対象のアプリケーションについて

– JavaのWebアプリケーション
– テスト・デプロイ作業は手動な部分が多い

元々のアプリケーションは複数機能が同一EC2上に同居しており、
今回、その一部アプリケーションをリプレースすると共に、コンテナ化する形を取りました。

## プロジェクトの全体像

– コンテナ移行（EC2→ECS Fargate）
– CICDパイプライン用意（開発→テスト環境）
– **リリースシェル用意（テスト→本番環境）** ?今回のテーマ

開発環境と本番環境のAWSアカウントが分かれており、
既存Webサーバーと同様に夜間リリースの運用にしたいという事情がありました。

そこで今回はCICDパイプラインと別に
**テスト環境でテスト済のコンテナイメージを基に、本番環境にデプロイする為のリリースシェル**
を用意しました。

## リリースシェルについて

CICDパイプライ

CloudFormation で変更なしの変更セットを流したい時

## 概要

CloudFormationのコードを書いているとリソースに変更は加えたくないけどコードの中身を整理したいときがたまにある。
そのまま変更セットを流そうとすると以下エラーで怒られてしまう。

“`
The submitted information didn’t contain changes. Submit different information to create a change set.
“`

そのため、影響の少なそうな変更箇所が無いか探してみた。

## 変更箇所

### Parameters を追加してみる → ダメでした

“`yaml
Parameters:
Dummy:
Type: string
Default: dummy
“`

### Outputs を追加してみる → いけた！

“`yaml
Outputs:
Dummy:
Value: “dummy”
“`

スタックの出力に変なの追加されちゃうので消し忘れの無いように、、、
(せっかく整理したのに・・・まあ影響ないけど。)

IT業界から離れたOLがSAA受かった話

お久しぶりです！

実は昨年の頭に退職しまして、エンジニアから離れた生活をしておりました。

そんな私がSAA合格した話をまとめました(✌?️’꒳’✌?️)
試験内容が変わるので、需要ありませんがｗｗ

■まず、IT業界とわたし

新卒で、サーバーサイドエンジニアとして、3年と少し勤めました！

今は違う業種で仕事してます。
前職は.NET/PHPを主にしてました。
現在は派遣OLです〜‪·͜·

■AWSの経験

実務としては未経験です。

前職の時にインフラ勉強したいな〜とりあえずSAA受けよう！となったのが、AWSとの出会いです???
テストセンターの経験として、CLFを2年ほど前に取得しています。
その後に、JAWS-UGうどん県に入りました。（関係ない）
が、仕事を休職し、退職してしまうというハードモード人生のため、SAAは受けずにずっと放置していました・・・orz

■SAAを受けようと思った理由

現職に転職して、業務を進めていくうちに、やっぱりIT業界に戻って、勉強しながら成長したいな〜〜という気持ちが強くな

EC2 に Auto Scaling の設定 と Cl/CD (CodePipeline + CodeDeploy + LambdaによるAMIの自動更新) を導入 ②

# はじめに
こちらの続きです。

https://qiita.com/hirai-11/items/127e812dc7bc570c4398

# CodePipelineを作成
CodePipelineを作成しましょう。

– パイプライン名を記入し次へ
– GitHub(バージョン2)を選択し、`GitHubに接続する`をクリックします。
– 接続名は、適当に入力します。
!

rootユーザー以外でCost Explorerを見たい

# 設定方法

・rootユーザーでログインしアカウントの設定画面に移動。
・IAMアクセスのアクティブ化にチェックボックスを入れ、更新実施
・IAMユーザーに対して必要なポリシーをアタッチする事でrootユーザー以外でも請求情報を参照可能になる。


https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/control-access-billing.html#grantaccess

自動で平日にEC2を開始させて休日・祝日に開始させない方法

この業界に来て4ヶ月目、
まともにタスクをこなすことができずあっぷあっぷしている中、ある検証タスクを任されました。

「マジかよ・・」
ただでさえタスクが溜まっているのに、気が滅入っているのを知っているのに！と思いましたが

自分にはできることはこれくらいしかない！
仕事が終わった後も自宅PCで試してみて顔に脂汗をかきながら試していました。

今回のタスクで行ったことを自宅PCで試したものをスクショして、ハマったこと、わかりにくかったことをシェアしたいと思います。

そもそもこの仕組みの目的はというと、、

## 毎日のバッチ処理を休日・祝日はさせたくない
企業ってだいたい土日・祝日って休みじゃないですか。
休業日にサーバーが起動していたらもったいない、不要な処理は止めておきたい、、、そんなニーズってあると思うんですよね。

平日は普段通りインスタンスを開始させたい、
でも休日、祝日には停止させておきたい、そんな仕組み。

なので今回の記事は、、、

・サーバーの自動管理ができるようにしたい、
・コスト削減、労力の削減がしたい、
・エンジニアが他の業務に集中したい、

こんな方が対象で

Amazon Cloudsearch をlocalのDocker Lamda node.jsから叩く

資料がなかったので、備忘録代わりに。
client-cloudsearch-domain、ローカルなので認証のためにcredentialが必要。endpointだけじゃなくて、regionも必要でした。cloudに持っていくと、認証は別方式のほうが良いと思われるので、消してください。

参考（AWS公式、node用のサンプルがあります）
https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-cloudsearch-domain/index.html

docker-compose.yml
Dockerfile
package.json
app.js (実行ファイルなので、任意にindex.jsなどに)

docker-compose.yml

“`
version: ‘3’
services:
cloudsearch-api:
image: cloudsearch-api
build: .
ports:
– 9199:8080
tty: true

jenkins で aws コマンド実行

## 大枠
“`
node {
stage(‘check instance’) {
def resultArray = getInstanceInfoList()
for (instance in resultArray) {
if (instance.Status == “running”) {
// なにかする
}
}
}
}
“`

## インスタンス情報取得
指定環境のフィルターとインスタンスID、稼働状況、OS情報、ip、タグ名を取得するクエリ設定
“`
def getInstanceInfoList(String env = “”)
{
String filter = “”
if (env.isEmpty()) {
filter = “Name=tag-key,Values=envName”
} else {
filter = “Name=tag:envName,Valu

AWS Systems Managerを使って外部から自宅のRaspberry Piにアクセスしてみる

# はじめに
以前、以下の記事でラズパイを使ってKubernetesクラスタを構築してみました。
[Raspberry Pi 4を使ってKubernetesクラスタを構築する](https://qiita.com/hato52/items/2d22a9a24299b2d0c904)

どうせなら外部からアクセスして管理できるようにしたいと思っていたのですが、自宅の環境的にポート開放することが難しい…。

どうにかポート開放すること無く外部からアクセスする方法が無いかと調べていたところ、AWSのSystems Managerで実現出来そうだったので、ラズパイに導入してみました。

# ハイブリッドアクティベーションの作成
AWS Systems Managerのページを開き、左側メニューからハイブリッドアクティベーションのページを開きます。
「アクティベーションを作成する」ボタンがあるので選択します。
![スクリーンショット 2022-08-17 0.36.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.co