- 経緯
- 選定
- 時間的目論見
- やること
- AMI編
- CF知る編
- 自分のAWSで試してみる編
- 2021/07/05 (2日め): EC2立てた。ドリフトわかった
- 2021/07/06 21:06 (3日め): 既存リソースをcFnにするぞ
- 2021/07/08 0:33(4日め): VPCを理解するぞ
- 2021/07/08 21:20(5日め): Internet Gateway, NAT Gateway, Subnet, RouteTable を理解するぞ
- 2021/07/09 20:16(6日目): Security Groupと Network ACLを理解するぞ、既存VPCをcFnに取り込むぞ
- 2021/07/10 12:43(7日目): ドリフト解消方法の理解を深めた, 業務のAWSのNW周りを理解中
- 2021/07/11 14:39(8日目) : Managed Prefix List, AWSのネットワークインターフェイスを理解
- 2021/07/13 20:55(9日目): 業務AWSのNetwork ACLを理解
- 2021/07/14 19:40(10日目): 業務のAWSのSecurity Group を理解, 見落としてるNW要素ないかチェック中(S3用エンドポイントがあった)
- 時間まとめ
- リンクが多すぎると、リンクされなくなるようなので、 11日め以降は別記事に分けた
経緯
- 業務のEC2 が IaCになってないのでしたい
選定
時間的目論見
- 結構大きいので15時間 (= 15日)で終わるといいなと思う
- 2021/07/04 20:38(1日目) 開始
やること
AMI編
- 2021/07/04 20:43
EC2にいって、AMIのところを押しても何もなかったので、無い
とり方
インスタンス一覧でチェック、右クリック、「イメージを作成」
- No reboot を選んでおく(取得時に再起動しない)
CF知る編
- 2021/07/04 21:56。そのご、30分かけて、読んで、VPCつくるところまでやった
- AWS CloudFormation（テンプレートを使ったリソースのモデル化と管理）| AWS 概要を掴んだ
- よくある質問 - AWS CloudFormation | AWS なんとなくわかった感じ
☆ elastic beanstalkの内部では、cloudformationを使用してリソースの作成とメンテナンスが行われています
自分のAWSで試してみる編
- 【CloudFormation入門】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築 | DevelopersIO
- 入門1のVPCつくるところまでやった (この部分のまとめ書くのに3.5分かかった)
- その後20分で、その入門3まで、つまり全部やった 2021/07/04 22:39
- ☆そこで、 下のまだできないポイントがうまれた
- これで作ったVPC消してみたんだけど、復活はどうするんだろ
- 生成に失敗したときの再挑戦方法まだわかってない
- ☆そこで、 下のまだできないポイントがうまれた
- EC2を作りたいので、次の御手本を探した
- AWS CloudFormationでEC2を構築 - Qiita
- とてもわかり易い
☆userdataに記述した内容はインスタンスの作成時に実行されるので、プログラムのインストールなど初期設定を行うことができます。
- その後、14分でこれを読み切り、このテンプレをコピペさせていただき、EC2をcreate_in_progressまでやった
2021/07/05 (2日め): EC2立てた。ドリフトわかった
- まず32分で、下のことをした
- その後、20分で下のことをした
- 「ドリフト」について調べた
- (テンプレと実体との違い、ギャップのこと)
- CloudFormation Drift Detectionを試してみた - Qiita
- わかりやすかった
- CloudFormation Drift Detection を使うことで、テンプレ更新前に、実体とテンプレの違いがわかると知れた
- 手で消したVPCが、Drift Detectionで Deletedになるのを確認した
- deleted の場合は、「テンプレとここが違うよ」差分は出ないようだ
- スタックをupdateするには、やはり、テンプレートのどこかに変更がないといけなさそう
- その際に、実体はテンプレの方に合わさせられる
- (ので、実体の方を残したいなら、先にテンプレに反映させる)
- テンプレート反映(update)前にはかならずこのDrift Detectionをチェックして、意図した変更だけになるか見よう
- その際に、実体はテンプレの方に合わさせられる
- CloudFormationには結構知れてきたので、業務のSSHサーバに何があるかを書き出してみた(要件)
- 確かに、EC2は中身がかなりでかいので、ファーストステップとしてはVPCとか周辺のものだけで、その後EC2に進むのがよさそう。
- でも、「既存のリソースをCloudFormationにする方法」とかを知らないので勉強中
- 「ドリフト」について調べた
2021/07/06 21:06 (3日め): 既存リソースをcFnにするぞ
- まず5分で AMIとった
- つぎの17ふん(累計22分)で、上の「既存リソース組み込み公式」読んだ
- 結局は、「手作業でテンプレに既存リソースを書けば、組み込める」ということ
- このあと、私物AWSで、手創りVPCを組み込んで見ようと思う (3分でブログ書いた)
- その後20分で、既存のVPCを取り込んでみた
AWSTemplateFormatVersion: "2010-09-09" Description: VPC Import test Resources: ImportedVpc: Type: AWS::EC2::VPC DeletionPolicy: Retain Properties: CidrBlock: 10.0.0.0/17
- インデントこわれた
- 確かにコピーできた。
- 上の書き方だと、 インポート時に VPC ID指定しないとだけど、 https://dev.classmethod.jp/articles/chonyumon-cloudformation/ "RouteTableId" : { "Ref" : "MyRouteTable" }, みたいに、テンプレートで指定も可能そう
- 「変更セット」: cFn に変更したテンプレートを上げて、どれが変わるかみる機能。どのリソースかまでしかでないので、違いは テンプレートを読むしかなさそう。
- なんか、元のvpcを取り込むじゃなくて、コピーしてる感じ
- 10分たっても UPDATE_COMPLETE_CLEANUP_IN_PROGRESS]
2021/07/08 0:33(4日め): VPCを理解するぞ
- (↓23分で以下のことをした)
- VPCはcFnでインポートしても、コピーになるようだった
- そもそも、VPCとかSecurityGroupを完全に理解してないので、はっきりと理解していくことにした
- VPC
- AWSのVPCって何？メリットや使えるシーンなど徹底解説！｜TECH PLAY Magazine ［テックプレイマガジン］
- CidrBlock: 10.0.0.0/16 という中に世界を作る感じ
- 複数のVPCを作れば、複数 10.0.0.0/16 の世界を作れる (行き来できない世界になりそう)
- SecurityGroupを VPCに所属させて、EC2をSecurityGroupに所属させる感じ
- EC2を複数のSecurityGroupに所属させられるので、1台のEC2を複数のVPCに所属させられる
可能な限りプライベートサブネットにしよう - > プライベートサブネットをパブリックにするには、後述するインターネットゲートウェイに接続する必要がある
- ルーティングもあるよ(要るよ)
- テナンシー: 他のリソースと物理リソースを共有するかしないか。デフォルトはdefault(普通に共有する)
- …ということで、VPCの説明記事は一つ読んだので、実際の私物AWSのVPCをみて、わからないところがないかチェック中
- (↑を5分で書いた)
2021/07/08 21:20(5日め): Internet Gateway, NAT Gateway, Subnet, RouteTable を理解するぞ
- (↓のことを27分でした)
- 引き続き、 AWS CloudFormationでEC2を構築 - Qiita を完全に理解しようとしています
- InternetGateway を理解した
- 【図解/AWS】インターネットGWとNAT-GWの違い〜各メリット、パブリックサブネットとは〜 | SEの道標
- IGW: VPCの中のprivate addressを 外のglobal IP Address と変換して、通信できるようになるぞ
- NAT Gateway: Private Subnet (や Public Subnet ) の 複数の Private IP Address を外のPublic IP Address に変換するぞ。どれとの通信か分かるようにポートも変えるぞ
- EC2 にそのままだと、割り当てられるGlobal IP Address は非固定、Elastic IPで確保すると、固定のを割り当てられる…ことを思い出した
- (↑を5分で書いた)
- (その後、 18分で↓を理解した)
- Subnet とは
- サブネットとインターネット通信 | DevelopersIO
- まぁ、普通のサブネット、 /18 とかで区切るやつです
- パブリックは IGW があってインターネットと通信できる
- プロテクトは、 NAT GW を通じて、 パブリックサブネットのIGW経由でインターネット通信ができる
- インターネット側から始まる通信はできない
- 踏み台サーバは英語で Bastion (砦の意)
- プロテクトサブネットとは、 NATサーバや踏み台サーバ経由で、インターネットと通信できるサブネット
- (Privateサブネットの一種と捉えられることが多そう。インターネットと通信できない真の Private Subnetより弱い版)
- ルートテーブル
2021/07/09 20:16(6日目): Security Groupと Network ACLを理解するぞ、既存VPCをcFnに取り込むぞ
- (↓まず、29分で下のことをした)
- 引き継ぎ、https://qiita.com/tyoshitake/items/c5176c0ef4de8d7cf5d8 を完全に理解しようとしています(最後)
- なぜネットワークACLでなくセキュリティグループで細かいトラフィック制御を行なうのか | DevelopersIO
- 基本セキュリティグループとわかった
- IPセグメントまるごと規制したいときくらいにしかNACLの出番はない(基本全通し)
- セキュリティグループは基本通さない (必要なものについて穴を開ける)
- inbound の 80, 22 だけでなく、 outboundの全通しも設定しましょうね
- セキュリテぃグループIDとは
- あるセキュリティグループがアタッチされているインスタンスをまとめて設定できる
- 基本セキュリティグループとわかった
- (↑を5分で書いた)
- (↓その後20分で↓のことをした)
- 問題:「前、既存VPCを私物AWSのcFnに取り込めなかった」
- 再度やってみたら取り込めた
- 前回は VPCIDの指定を間違えたのかな？
- CloudFormationで既存のVPCと既存のサブネットの中にEC2インスタンスを立ち上げてみる - Qiita を読んだ
どこをどう変更したのかといった変更履歴も保持しているので追跡性もあります。
◎＊cloudformerというのを使って既存のデータをコード化します - 変換機能(ただし、テンプレが手でメンテできなくなる)があるらしい (多分使わない)
- Design Template というGUIがある
- 私物VPCをcFnのスタックに取り込めたし、Tags の Name を着けることもできた (元々あったNameを上書いた)
- ドリフトの差分もみれた (実物は/16 だけど テンプレは /17 みたいな)
- でも、変更セットを作ってもドリフトの解決をできなかったので、明日はここから (ドリフト解決したい) (私物AWSの話)
- その後、 業務SSHサーバ周りのNWを知って、cFn化を目論む
- (↑を5分で書いた)
2021/07/10 12:43(7日目): ドリフト解消方法の理解を深めた, 業務のAWSのNW周りを理解中
- (↓13分で↓をした)
- VPCの /16と/17をcFnで変えられないなぁ
- ドリフト解消方法を知るぞ！
- AWS CDK/CloudFormation、リソースを変更せずにスタックドリフトを解消する | DevelopersIO を読む
- cdkとは
- AWS クラウド開発キット – アマゾン ウェブ サービス
- プログラミング言語→cFn
- terraformやk8sにも対応！
- TypeScript、Python、Java、.NET、および Go
データベースが絡む場合です。テンプレートを更新すると、インスタンスを再作成してしまいます - > 実施したシナリオ。。aurora mysqlのクラスターをcdkで作成していた状態で、auroraの自動マイナーバージョンアップグレードが走ったために、スタックドリフトが発生した、というシナリオでスタックドリフトの解消を行ってみたいと思います。 - うーん、データベースに使うのは難しそうだ - retainにしてからコメントアウトして一度スタック管理外にしようね。すると、バージョンを実体に合わせられるよ - > これらのリソースはスタックから切り離したまま運用するという選択肢もあるかもしれません。
- つまり、「全てをcFnで変更できるわけではない」
- (/16と/17を切り替えるのは、IPセグメントがかぶっていて、一度切り離さないと無理、ということのようだ)
- 一度スタックから外して、再度インポートすればよい
- データベースの件で、cFn本当に大丈夫か気になったが、
- 「cloudformation」でツイッター検索しても「CloudFormationはダメだ」みたいなのは見えない
- というか、普通に運用に使われてそうだった
- (↑を5分で書いた)
- (↓その後、34分で↓をした)
- AWS CodeCommit がgit だと理解した
- cFnにすべく、業務のAWSのNW周りをみていってる
- ☆cFnのスタックにインポートするだけなら、実体に変更は入らないから安全！
- (↑ を3分で書いた)
2021/07/11 14:39(8日目) : Managed Prefix List, AWSのネットワークインターフェイスを理解
- Managed Prefix List
- [アップデート] 複数のCIDRをまとめて管理！Amazon VPC で プレフィックスリストが利用可能になりました | DevelopersIO
- CIDRとプレフィックス - ネットワークエンジニアを目指して
- MPL は、「複数のプレフィックス(Cidr)を1つにまとめて、Route Tableの転送するCidrなどに指定できる」機能
- AWS が(S3とDynamoDBで) 勝手に登録する AWSマネージドプレフィックスリスト がある
- 業務のAWSをcFnにする文脈だと、RouteTableでこのMPLを参照してるからには、MPLもcFn管理にせざるを得なさそう。
- 業務AWSには、S3用と dynamoDB用の MPLがあるが、dynamoDBはシステムで使ってないので、S3の方だけcFnに含めれば良さそう。
- CodeCommmt にReview機能はあるの？
- 業務のAWSのユーザー、どのように発行してるか理解した
- この次: MPLは理解したので、昨日の続き(業務のAWSのNW周りを理解する) をしていはう
- (↑を29分でやった)
- 業務のAWSのNat Gatewayを理解した
2021/07/13 20:55(9日目): 業務AWSのNetwork ACLを理解
- NAT Gateway
- 業務のNAT GW には、Private IPアドレスが割り当ててある
- 最初からcFnで構築するなら、無指定で任意のを割り当ててもらっていいけど、今回はcFnのテンプレにこのPrivate アドレスを書いた方が無難そう
- Elastic IP
- Network Access Control List
- 業務AWSに1つだけある 4つ全てのサブネットと関連付け
- インもアウトも全通しなよくある形
- (subnetには、必ずNACLが割り当てられる)
- 私物AWSをみると、cFnでは、特にNACLの作成を指定しなくても、(VPCやsubnetを作ると) 勝手に全通しで作られるようだ
- それどころか、 VPCを作るだけの簡単なcFnテンプレでも、勝手にサブネットが4つ作られてるような…
- /24で public a, private a, public c, private c で
- 業務ACLの話に戻ると、NACLは、やはり、最初からcFnだったら、「NACLを無指定にしたら、勝手に全通しのができてた」で良いと思う
- しかし、今回は既存のNACLがあるので、NACLもcFnのテンプレに含めた方が無難だと思う
- その際には AWS CloudFormationでNACL設定を入れてみる | DevelopersIO を参考にするとよさそう。
- subnetは4つしかないので、大して面倒ではない
- 業務AWSに1つだけある 4つ全てのサブネットと関連付け
2021/07/14 19:40(10日目): 業務のAWSのSecurity Group を理解, 見落としてるNW要素ないかチェック中(S3用エンドポイントがあった)
- (↓25分で↓をやった)
- 業務AWSのSGを理解
- Security Group は、 SGの方の一覧からは、どのSGをどのインスタンスで使ってるかわからないので、「production RDS Security Group」みたいに、どこ用か、Nameか説明で示すのが大事
- 業務AWSには、4環境ある
- 業務AWSには、 VPC用 4、 LB用 4、RDS用 3 (stagingが productionと同じ)、SSHサーバ用 2 (gitbucket, office)、 default 1 の計14個のSGがあった
- 全てのSGが、outbound は全通し
- SSHサーバには、office IPサブネットから全ポート inbound OKとするSGがあった
- defaultでは、defaultからのインバウンドは全部通すようになってた (内部通信はAll OK)
- そのSGを使うインスタンスをcFnにする時に、一緒にSGもcFn管理にするのが良いと思った
- つまり、 最初は SSHサーバ用2 と default を管理下にするのが良いと思った
- (豆知識) EC2の一覧の実行中、停止中の横の +, - 虫眼鏡は、「同じstatusのインスタンスだけに絞り込む/同じstatusのインスタンスを一覧から抜く」ボタン
- (↑ を 8分で書いた)
- (↓を 17分でやった)
- ↑までに書いたもので、cFnにする時どうするのか観点が抜けてるところがあったので書いた (MPLとか)
- 他に見逃してるNW構成要素がないか、業務VPCの左メニューをチェック中
- すると、エンドポイントというものが1個だけあった
- ゲートウェイエンドポイント
- VPC エンドポイント - Amazon Virtual Private Cloud
- S3とVPCの通信をPrivate(AWS NW内だけ)にするためのエンドポイント
- ルートテーブルのターゲットなどにできる
- 明示的に、これを作ると指定しないと作られないようだ(勝手にS3についてくるものではない)
- ルートテーブルのTargetになっていたら、cFn化せざるを得ないだろう。
- (↑を5分で書いた)
時間まとめ
- 2021/07/04 1日め 80分
- AMIがまだとってないことはわかった
- どう取るか調べた (簡単)
- CFの概要を掴んだ
- EC2を作成中のところまですすんだ
- 業務のSSHサーバ移植まで、15時間もかからなさそう。
- 明日は、EC2立てるのが、うまくいったか確認から。
- 2021/07/05 2日め 62分
- 2021/07/06 3日め 50分
- 既存リソースインポート方法学んだ
- やってみた。コピーになるのはしかたないのかな…？(次回調べたい)
- 既存スタックに取り込む、でも変わらないだろうけど…、コピーでも問題ないのかな…？
- 2021/07/08 4日め 29分
- VPC学習中
- 2021/7/8 5日め 58分
- 2021/07/09 6日目 60分
- 2021/07/10 7日目 56分
- 全てをcFnで変更できるわけではないと知った
- 業務のNW周り理解中
- 2021/07/12 2:23 8日目 53分
- マネージドプレフィックスリスト理解
- 業務のNW 理解中
- (2021/07/12 70分、 2021/07/13 25分)
- 月イチの1on1ミーティングを受けるべく、準備をした
- 勉強進捗、案件にかかった時間まとめ、期末の評価資料を少しずつ作っていく
- 2021/07/13 20:32 32分 9日目
- 2021/07/14 20:13 56分 10日目
- 2021/07/15 23:07 64分 11日め
- 他にはNW周りで見落としてるものがないことを確認した
- VPC, IGW, Subnet 1つを cFnのテンプレにした
- 2021/07/18 5:00 31分 12日め
- マクロなど、繰り返しを避ける方法が必要そうだった
- 2021/07/18 13,14日め 142分
- cFnのテンプレを書くベストプラクティスを調べた
- というかまだ調べ中
- CDK (Cloud Development Kit) を推してる人が多かった
- 自分も、cFnをある程度マスターしたら、すぐにCDKに行こうと思った
- cFnのテンプレを書くベストプラクティスを調べた
- 2021/07/19 21:51 15日め 60分
- cFnのベストプラクティスを学びきった
- いまは、「ネストすると(テンプレ分割すると)、子の詳細な変更セットが見れなくなるよ」というやや古い情報が見つかったので、それを実験して確かめ中
- ネストできないと、テンプレがとても長くなってかなりよくない
- 2021/07/20 21:18 16日目 57分
- 変更セットの見方を知った
- 2020/11に変更が入り、ネストされたスタックの変更箇所も、変更セットで表示されるようになった事が確認できた
- 2021/07/22 2:40 17日目 58分
- 2021/07/22 17:31 18日目 54分
- VSCodeでcFnのLintできるようになった
- 2021/07/25 3:48 19日目 80分
- 2021/07/25 22:02 20日目 63分
- サブネットをテンプレにした
- あとはセキュリティグループだけになった