t_hazawaの日記

株式投資とWebエンジニアリングのブログです。株式投資の目次は→です。 https://t-hazawa.hatenablog.com/entry/2021/02/12/220933

業務のEC2をCloudFormationにするぞ1:勉強編

Webエンジニアリング CloudFormation

経緯

  • 業務のEC2 が IaCになってないのでしたい

選定

  • そのシステムはAWSべったりなどの理由でCloudFormationでもよいとなった(ざっくり)
    • GUIがあって初めて見る人もわかりやすそうというのもよい

時間的目論見

  • 結構大きいので15時間 (= 15日)で終わるといいなと思う
  • 2021/07/04 20:38(1日目) 開始

やること

  • まず、 AMI になってなかったらとっとく
  • CFについて知る
  • まずは私物AWSで
    • GUIポチポチでさわってみる
    • IaCでやってみる
  • 本物をCF (IaC)にする

AMI編

  • 2021/07/04 20:43

  • EC2にいって、AMIのところを押しても何もなかったので、無い

    とり方

  • インスタンス一覧でチェック、右クリック、「イメージを作成」

    • No reboot を選んでおく(取得時に再起動しない)

CF知る編

自分のAWSで試してみる編

  • 【CloudFormation入門】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築 | DevelopersIO
    • 入門1のVPCつくるところまでやった (この部分のまとめ書くのに3.5分かかった)
  • その後20分で、その入門3まで、つまり全部やった　2021/07/04 22:39
    • ☆そこで、 下のまだできないポイントがうまれた
      • これで作ったVPC消してみたんだけど、復活はどうするんだろ
      • 生成に失敗したときの再挑戦方法まだわかってない
  • EC2を作りたいので、次の御手本を探した
  • その後、14分でこれを読み切り、このテンプレをコピペさせていただき、EC2をcreate_in_progressまでやった

2021/07/05 (2日め): EC2立てた。ドリフトわかった

  • まず32分で、下のことをした
    • MyIP に XXX.XXX.XXX.XXX ではなく XXX.XXX.XXX.XXX/24 を指定して、EC2を作り直した
    • ssh -i .ssh/2021-07-05_aws.pem ec2-user@52.XXX.XXX.XXX でログインした
      • AWSのキーペアには _awsって名前につけるとどこの鍵かわかりやすくてよい
    • このEC2スタックの作成は1分20秒、削除は1分30秒 かかるとわかった
    • スタックの初回生成に失敗した場合、「削除して最初からやりなおすしかなさそう」とわかった
    • スタックセットは「スタックを複数アカウントや複数地域で立ち上げるもの」だとわかった
    • (↑の記述を4分で書いた)
  • その後、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 を理解した
  • EC2 にそのままだと、割り当てられるGlobal IP Address は非固定、Elastic IPで確保すると、固定のを割り当てられる…ことを思い出した
  • (↑を5分で書いた)
  • (その後、 18分で↓を理解した)
  • Subnet とは
    • サブネットとインターネット通信 | DevelopersIO
    • まぁ、普通のサブネット、 /18　とかで区切るやつです
    • パブリックは IGW があってインターネットと通信できる
    • プロテクトは、 NAT GW を通じて、 パブリックサブネットのIGW経由でインターネット通信ができる
      • インターネット側から始まる通信はできない
    • 踏み台サーバは英語で Bastion (砦の意)
    • プロテクトサブネットとは、 NATサーバや踏み台サーバ経由で、インターネットと通信できるサブネット
      • (Privateサブネットの一種と捉えられることが多そう。インターネットと通信できない真の Private Subnetより弱い版)
  • ルートテーブル
    • (ここまでで大体わかったので、AWS Console みて理解した)
    • VPCの設定項目
    • 送信先(ターゲットに振り分ける対象)とターゲット(流し込む相手)をきめる
    • ↑の EC2の御手本cFnテンプレでは、、PublicSubnet用のルートテーブルを作って、実際のルーティング(Route)を設定して、ルートテーブルをサブネットにassociateしてる
      • ルーティングで、全部の通信のTargetをIGWにすることで、インターネットへの/からの 通信を仕放題にしている (SecurityGroupで守る)

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とは

  • データベースが絡む場合です。テンプレートを更新すると、インスタンスを再作成してしまいます - > 実施したシナリオ。。aurora mysqlのクラスターをcdkで作成していた状態で、auroraの自動マイナーバージョンアップグレードが走ったために、スタックドリフトが発生した、というシナリオでスタックドリフトの解消を行ってみたいと思います。 - うーん、データベースに使うのは難しそうだ - retainにしてからコメントアウトして一度スタック管理外にしようね。すると、バージョンを実体に合わせられるよ - > これらのリソースはスタックから切り離したまま運用するという選択肢もあるかもしれません。

  • つまり、「全てをcFnで変更できるわけではない」
    • (/16と/17を切り替えるのは、IPセグメントがかぶっていて、一度切り離さないと無理、ということのようだ)
    • 一度スタックから外して、再度インポートすればよい
  • データベースの件で、cFn本当に大丈夫か気になったが、
    • 「cloudformation」でツイッター検索しても「CloudFormationはダメだ」みたいなのは見えない
    • というか、普通に運用に使われてそうだった
  • (↑を5分で書いた)
  • (↓その後、34分で↓をした)
  • AWS CodeCommit がgit だと理解した
  • cFnにすべく、業務のAWSのNW周りをみていってる
    • VPC, Internet Gateway, Subnet (EC2とRDSがどこにあるかも見た)
    • RouteTable 理解中
      • メインと private用がある
        • メインは、VPCのcidrだったらlocalに送るし
        • 他は igw
      • privateは VPCのcidrだったらlocalに送るし
        • ほかは nat gw
      • ここで、新キャラ: マネージドプレフィックスリスト が登場したので、明日はそれを知るところから。
  • ☆cFnのスタックにインポートするだけなら、実体に変更は入らないから安全！
  • (↑ を3分で書いた)

2021/07/11 14:39(8日目) : Managed Prefix List, AWSのネットワークインターフェイスを理解

2021/07/13 20:55(9日目): 業務AWSのNetwork ACLを理解

  • NAT Gateway
    • 業務のNAT GW には、Private IPアドレスが割り当ててある
    • 最初からcFnで構築するなら、無指定で任意のを割り当ててもらっていいけど、今回はcFnのテンプレにこのPrivate アドレスを書いた方が無難そう
  • Elastic IP
    • NAT Gateway用 と SSHサーバ用 で 2つあるから、これもcFnにしよう
  • 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つしかないので、大して面倒ではない

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個だけあった
  • (↑を5分で書いた)

時間まとめ

  • 2021/07/04 1日め 80分
    • AMIがまだとってないことはわかった
    • どう取るか調べた (簡単)
    • CFの概要を掴んだ
    • EC2を作成中のところまですすんだ
    • 業務のSSHサーバ移植まで、15時間もかからなさそう。
    • 明日は、EC2立てるのが、うまくいったか確認から。
  • 2021/07/05 2日め 62分
    • EC2を建てれた
    • EC2にsshできた
    • ドリフトとその検出方法、違いがある時の動作がわかった
    • sshサーバの機能を書き出した(要件)
    • 既存リソースをcFnにする方法勉強し始めた
    • 70分中、52分勉強し、18分 ブログ記述などをした 。 25%が記述の時間
  • 2021/07/06 3日め 50分
    • 既存リソースインポート方法学んだ
    • やってみた。コピーになるのはしかたないのかな…？(次回調べたい)
      • 既存スタックに取り込む、でも変わらないだろうけど…、コピーでも問題ないのかな…？
  • 2021/07/08 4日め 29分
  • 2021/7/8 5日め 58分
    • Internet Gateway, Subnet, RouteTable がわかった
    • あとは、 Security Group だけ
    • その後は、業務の踏み台周りのネットワーク部分をcFnにするにはどうするか、ということになりそう。
    • 多分、12時間ほどで ネットワーク周りは cFnになるんじゃないかな。 (ここまでを1つのものとしたい)
      • その先(sshサーバのcFn化)はさらに10時間かかりそう。(これを別の1つの実践としたい)
  • 2021/07/09 6日目 60分
    • Security Group, Network Access Control List を知った
    • 私物AWSで既存VPCをcFnのスタックに取り込み練習中
  • 2021/07/10 7日目 56分
    • 全てをcFnで変更できるわけではないと知った
    • 業務のNW周り理解中
  • 2021/07/12 2:23 8日目 53分
  • (2021/07/12 70分、 2021/07/13 25分)
    • 月イチの1on1ミーティングを受けるべく、準備をした
    • 勉強進捗、案件にかかった時間まとめ、期末の評価資料を少しずつ作っていく
  • 2021/07/13 20:32 32分 9日目
    • 業務のAWSのNetwork ACLをみて、どうcFnにするか考えた
  • 2021/07/14 20:13 56分 10日目
    • 業務AWSのSecurity Group 理解した。
    • 見落としてる業務AWSのNW要素ないかチェック中
      • S3用エンドポイントを見つけた。
  • 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に行こうと思った
  • 2021/07/19 21:51 15日め 60分
    • cFnのベストプラクティスを学びきった
    • いまは、「ネストすると(テンプレ分割すると)、子の詳細な変更セットが見れなくなるよ」というやや古い情報が見つかったので、それを実験して確かめ中
      • ネストできないと、テンプレがとても長くなってかなりよくない
  • 2021/07/20 21:18 16日目 57分
    • 変更セットの見方を知った
    • 2020/11に変更が入り、ネストされたスタックの変更箇所も、変更セットで表示されるようになった事が確認できた
  • 2021/07/22 2:40 17日目 58分
    • ベストプラクティスに則って業務AWS NW周りをテンプレにし始めた
  • 2021/07/22 17:31 18日目 54分
    • VSCodeでcFnのLintできるようになった
  • 2021/07/25 3:48 19日目 80分
    • VPCとIGWをベストプラクティスで作れた(私物AWSで)
    • サブネットをベストプラクティスに則ったcFnにしてる
  • 2021/07/25 22:02 20日目 63分
    • サブネットをテンプレにした
    • あとはセキュリティグループだけになった

次