概要
Elasticache を使うほどではないが、Redisを疎にして用意しておきたい、、ということで、Lightsail + Docker で構築。
正直、Elasticache 使った方が色々楽なのだが、最小インスタンスでも月に2500円持ってかれるのは同人でつけっぱにするにはちと微妙でな。。
費用が、2500円/月 => 500円/月 になるので、これならつけっぱでもまぁ。
というわけで、下記の構成のElasticacheをLightsailにもそっと置き換えました。
ちなみに、上記の構成（Terraform + Serverless Framework）はGithubにまとめてある。
karinharp/AmRedis
手順
ただし、LightsailはAmazonLinux 1系しかサポートされないので、自動起動スクリプトは、
sudo chkconfig ${Service} on
を使うことになる。
Port Mapping は適当に
docker run -p 6379:6379 --name my-redis -d redis
Peering 設定
-
LightsailのVPC Peering を有効にする
- 通常、VPC Peering を行う際、承認処理やルーティングテーブルの設定を別途する必要があるが、Lightsailの場合は、その辺、自動で設定してくれるっぽい（VPCの設定見にいったら設定増えてた）
-
API 構成
- VPC/SecurityGateway/Endpointの設定をElasticacheからLightsail側に変更
動作確認方法
- Elasticacheの時と同じテストコード（EndpointでSet/Get）が通ればそれでいい
- Redis単体での動作チェックをするなら、一時的に、Lightsail側のFirewallに穴をあけて、適当なところから、redis-cli を直だだきすればいいと思う。
柔軟な構成のために
- Route53で内部DNSの空間を切っておいて、Aレコードを発行しておくこと。
- こうしておけば、Elasticacheを再構築して、むき先変えて対応とかも簡単に。
まぁ、どうせ Serverless Framework で構築してるし、設定ファイル書き換えて再構築でいいじゃんという話もあるがねw
この構成のメリット
Reids に対して何らかのバッチ処理を行いたい場合に、Lightsailのインスタンスにやらせることが出来る、、というのはよい。
定期的にリセットとか、バックアップとか、cronで済む場合はそれでよいしな。
VPC Peering を 一部Terraformに持ってくる場合に必要なリソース
依存関係が芋づる式に膨れあがるので、どこまで持ってくるかは悩ましい。
あとは承認処理で結局手動だからなぁ。
## routetable
resource "aws_route_table" "RouteTable" {
vpc_id = "${aws_vpc.VPC.id}"
route {
cidr_block = "0.0.0.0/0"
gateway_id = "${aws_internet_gateway.IGW.id}"
}
route {
ipv6_cidr_block = "::/0"
gateway_id = "${aws_internet_gateway.IGW.id}"
}
route {
cidr_block = "172.31.0.0/16"
gateway_id = "pcx-xxxxxxxxxxxxxxxxxxx"
}
tags {
Name = "${var.title}-${var.env}"
}
}
## routable default association
resource "aws_main_route_table_association" "RouteTableAssoc" {
vpc_id = "${aws_vpc.VPC.id}"
route_table_id = "${aws_route_table.RouteTable.id}"
}