月: 2021年9月
AmazonLinux2 で lego を使い Route53 認証でサーバ証明書を取得する
lego --accept-tos \ --path=/etc/letsencrypt \ --email="email@example.com" \ --dns="route53" \ --domains="www.example.com" \ run
lego --accept-tos \
--path=/etc/letsencrypt \
--email="email@example.com" \
--dns="route53" \
--domains="www.example.com" \
renew \
--days 30
AWS CDKに感動した話
CDKとは
AWS クラウド開発キット (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。 出展：https://aws.amazon.com/jp/cdk/AWS CDK（以降CDKに省略）はソースコードでインフラ構築・管理を行うフレームワークです ソースコードによるインフラ構築であればCloudFormationも候補に上がりますが、 CloudFormationの場合、ソースコードとしてjsonファイルもしくはyamlファイルに論理名の紐付けなど細かく記載する必要があります。 しかし、CDKの場合はTypeScritp、Python、Javaなど普段使い慣れたプログラム言語を使用することができ、細かい設定はCDKが吸収してくれるため、実装負荷が大変少ないです。
CDKで変わったインフラ構築
これまではAWSのコンソール上からインフラを構築していました。 しかし、コンソール上から手作業でインフラを用意するのは下記のこともあり”とても”大変です。- 構築に時間がかかる インフラ構築にはVPC、EC2、RDSなどさまざまなものを構築する必要がある それぞれ人の手で行うと一つの環境を作るのに数時間掛かってしまう
- 構築ミスが発生 人の手による作業なので当然構築ミスも発生する 当然、ミスが出た際の問題解決に時間が割かれてしまう
- 殆ど同じ環境を作らなければいけない苦行 web開発では通常、 PROD,STG,DEV+α環境と多くの環境を作ることが求められる。 そのため、同じ作業を複数回行わなければならず、マラソンをやっているような気持ちになる ※こちらとても私的な意見です
CDKのソースコードがあれば短時間でインフラ構築が完了する
CDKではソースコードさえあればターミナル上で片手で数えられるコード入力のみでインフラの構築が済んでしまう 例えば、下記のコマンド一発でソースコード記載のインフラ構築ができてしまいます。cdk deploy --allミスが少なくて済む
ソースコードを読み込んでインフラ構築を行うため、いつでも同じ環境を作成することができる 属人化を防ぐ意味でも良いですね また、CDKはライブラリを使用するため、エディタの補完機能を使用することができ、ソースコード作成時のミスも少なくて済みます。バージョン管理ができる
CDKはソースコードでインフラ構築ができるため、gitなどでバージョン管理ができます 下記のコマンド一発でソースコード記載のインフラ環境と実際にインフラ環境の差分が表示されますcdk diffCDKはいいぞ
CDKは便利の一言です 一度ソースコードを組んでしまえば同じ環境をいくらでも量産できるので、ちょっと新しい環境を作って試してみたいことがあった際に簡単にスクラップ&ビルドを行えてしまいます。 開発速度の向上が期待できますね。 また、インフラ構築自体はコマンド一発で出来上がってしまうので、属人化しないのが非常に良いですね。極論を言ってしまえば、ソースコードさえあればサルでもインフラ構築ができてしまいます。 問題のソースコードの実装自体は慣れさえすれば簡単です。特にAWSを使用したことがある方であれば構築時の設定と同じ内容を記載すれば良いので、すぐに感覚が掴めると思います。 一度触ってしまったらコンソール上でのインフラ構築には戻れません CDKにはそれほどの魅了が詰まっています 初心者用にAWSがワークショップを作ってくれているのも敷居が低くて大変良いです 皆さんも是非機会がありまたら触ってみてください！
Autoscaling起動時にEIPをアタッチさせる
外部APIとの接続があるときautoscalingで起動されたec2にも固定IPをつけたくなることがあると思います。その場合はNATゲートウェイを使うのがベストプラクティスだそうです。しかし、NATゲートウェイは意外と料金が高くつくので今回はEIPをAutoscaling時に自動でアタッチさせる方法を試してみます。
■まとめ
今回はAutoscaling起動時のec2のIPを固定化するためにEIPをアタッチさせました。EIPは月に300円程度なのでNatゲートウェイを使うよりも安く収まります。しかし、Natゲートウェイを利用したほうがec2をプライベートサブネットに置くことができるなどのメリットがあるのでNatゲートウェイの利用をおすすめします。
■参考
https://aws.amazon.com/jp/blogs/security/demystifying-ec2-resource-level-permissions/?nc1=h_ls
https://dev.classmethod.jp/articles/choose-eip-from-addresspool/
実装手順
- 1. アタッチさせるEIPを事前にプールしておく
- 2. IAMポリシーの作成
- 3. シェルスクリプトの設定
- 1. アタッチさせるEIPを事前にプールしておく
- 2. IAMポリシーの作成
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ec2eip",
"Effect": "Allow",
"Action": [
"ec2:CreateImage",
"ec2:CreateSnapshot",
"ec2:Describe*",
"ec2:DescribeInstances",
"ec2:DescribeAddresses",
"ec2:AssociateAddress"
],
"Resource": [
"*"
]
},
{
"Sid": "ec2",
"Effect": "Allow",
"Action": [
"ec2:RebootInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1::instance/"
]
}
]
}- 3. シェルスクリプトの設定
#!/bin/bash
yum install jq -y
# EIPの割り当てID
eip_alloc_ids="eipalloc-07fad2290f8915762"
export AWS_DEFAULT_REGION=ap-northeast-1 instance_id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
available_alloc_id=$(aws ec2 describe-addresses --allocation-ids ${eip_alloc_ids} | jq -r '[.Addresses[] | select(.InstanceId == null)][0] | .AllocationId')
echo $available_alloc_id
aws ec2 associate-address --instance-id ${instance_id} --allocation-id ${available_alloc_id}