t_hazawaの日記

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

業務のEC2をCloudFormationにするぞ2:ベストプラクティス勉強編

Webエンジニアリング CloudFormation

2021/07/15 21:41(11日め): 業務AWSのNW要素見落としないかチェック, 業務AWSのNWをテンプレ化開始

  • VPCのメニューをチェック中 (あとでEC2をやる)
  • AWSマネージドドメインリスト
  • Wavelength
    • VPCのSettingsにあった
    • 5G向けらしい
    • wavelengthについては、オプトアウトしているので、使わないようにしているのだろう
    • azは普通 a,c,d apnortheast-1の
  • (VPCは全部確認おわり)
  • EC2のメニューを見ていく
    • NW周りでは特に見てないものはなかった
  • (↑を20分でやった)
  • じゃあ、Elastic BeanstalkでNW周りが変更されないか一応みておこう
    • 初回以外は、NW周りについては、既に作ってあるものを再利用するようだ (EBの環境の設定をみた)
  • ◎いよいよテンプレ化開始した。
  • (35分で↓をした)
  • ☆10種類のものをcFnのテンプレにする対象として洗い出した
    • VPC, IGW, Subnet, Route Table, Managed Prefix List, NAT Gateway, Elastic IP, Network ACL, Security Group, S3用エンドポイント
  • VPCとIGWをテンプレにしてみた
  • サブネットを1つテンプレにした PubSubAPne1dForSSH

2021/07/18 5:00 (12日め): マクロを学ぶ必要があると分かった

  • (G検定の準備をしていたので2日ぶり)
  • 業務のAWSをcFnにしていってる
  • でも、そのままでは、同じことを何度も書くことになりそう
  • マクロを学ぼうと考えた

2021/07/18 14:38(13日め、14日め): cFnで使えるマクロ(というか同じ内容の繰り返し方法)を学ぶぞ, ベストプラクティスというか、使ってる人の記事を読むぞ

パラメータストア自体を知る

  • まずパラメータストアのことを知る必要があったので読む (21分)
    • Amazon EC2 Systems Managerでパラメーターストアを試してみた #reinvent | DevelopersIO
    • 2016年発表
    • 私物でやってみた(簡単)
    • Run Command で取れるということなので、やろうとした
      • デフォルトのコマンドがたくさんある　Ansibleを流すとか configDockerとか
      • シェルスクリプトも実行できる(これがメインになりそう)
      • でも、起動してるEC2がないとダメだったのでやらなかった
        • 私物AWSで、自動で起動しているEC2を止めて回る定期ジョブをなんとかして搭載したい
        • AWSに、いかにも、そういう定期ジョブ登録機能がある気がしている。
    • (↑を5分で書いた)

パラメータストアを使って、cFnのテンプレの重複をなくす手法を学ぶ

その前に、まずはパラメータストアの普通の利用法を一応みておく

  • 次に、パラメータストアを使って、cFnの重複設定をDRYにする方法を知った (22分)

いよいよ、「cFnの重複をなくす方法」

  • 本題
    • [Tips]CloudFormationで文字列の繰り返しやめたいと思ったのでAWS Systems Manager パラメータストアに保存することを思いついた話 | DevelopersIO
      • これが、本来知りたかった、「cFnの重複部分をなくす方法」

        • もっと繰り返したいとか条件分岐をする必要があれば、AWS CDK等での対応も検討ください - AWS Cloud Development kit。 Pythonとかでかけるサービス。cFnより複雑

      • IAMRole2: Type: AWS::IAM::Role ManagedPolicyArns:

      • !Ref "IAMManagedPolicy2"
        • この部分は、 Role に この名前のpolicyをつけるよってこと
      • ssmに登録する体をとることで、何回も出てくる文字列を変数的に扱えるのだ

      • 気になる方はpoliciesを設定して有効期限を短くして削除してしまうことも可能かと思います

      • TagsのName に_for_cfn_template みたいな わかりやすい名前をつけてもいいかも。
      • 元のcFnテンプレよりだいぶよくなってる
    • (↑を8分で書いた)

cFnを実際に使われてる方のノウハウ記事を読む

  • 実際にcFnを使われてる方の記事を読んだ (23分)
    • というのも、ベストプラクティスというか、テンプレの良い書き方とかを知りたかったのだった
  • CloudFormation入門 - ハマリポイント・注意点 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
    • ☆かなりイケてる資料
    • ◎実はcFnもファイル分割できる(スタック1個に複数ファイルのテンプレ)とのことなので、やり方を調べたい
    • IAM, DBをスタック別にするのは確かに良さそう。でも、デメリットもあるので、最初は分割なしでいいかな。
    • ◎ なるほど、構文チェックツール
    • Subnet には EnableDnsHostnames: true EnableDnsSupport: true みたいなのが要るらしい
      • まぁ、実際に作ってみて、「むむ、ここが違うぞとなったら気付けるかな」
    • ☆Condition も Mappingsも初めて聞いた (使えそう)
    • ◎リソースの名前、英数字だけ(記号不可)と書かれててしっかりしてる。
    • Outputs もようやく意義がわかった　(他のスタックにわたすものをOutputsとして出力する)
      • 　必要最低限にしないとだめよ　ロックされるから　とのこと

      • 弊社のサービスではスタックに番号が振ってあり、小さい方から大きい方へのみ参照するようにしています。

      • ↑大変そう
    • ◎変更セットは「JSONの変更」 が一番くわしいらしい
    • ☆ > "replacement": "False", # これがtrueだとリソースが一度削除されて作り直されるのでサービスが停止する可能性あり

    • 弊社のAWS環境は小規模な方だと思いますが、それでもCFNのテンプレートは数千行に及んでいました。 今となっては、だからといって手動でひとつひとつ設定していくわけにも行きません。 - つよい - でもterraformでもそのくらいあった感じがする

    • (感想) やはり、CDKでは？　cFnをマスターしたら素早くCDKに行こう！
  • (おさらい)CDKとは

テンプレを分割する手法を学んだ

  • 2種類の方針がある
    • 1つのスタックを複数のテンプレで記述(少数派)
      • だいたいCDKにしよう！という感じ
    • 役割でスタックを3,4つにわける (多数派)

1つのスタックを複数のテンプレで記述

複数のスタックを連携させる (クロススタック)

15日め 2021/07/19 21:07 : cFnのベストプラクティス調べ

  • 前日に引き続き、ベストプラクティスを学んでいる
  • CloudFormationの実践ベストプラクティス - Qiita (21分)
    • ☆めちゃいい資料
      • (これを読むまで、テンプレをきれいに分割する方法が分からなかった…というか、「1スタックは1テンプレファイル」ということが繰り返し出てきたのだが…？)
    • この方も、現時点では CDK (Cloud Development Kit) 推し
      • 自分もcFnマスターしたら早急にCDKにいくぞ。
    • 「ライフサイクル」で分けよう の話
      • まぁ、今までに考えてきた、 NW　→ Security → DataDtore → App でも、後ろの方ほどライフサイクルが短くなってて、ちょうどよさそう 　- 前のやつほど、全然更新されないので、依存関係的にもよさそう
        • そうかな？なんか、接続元IPが変わるので、 VPNを変えたい、とかなりそう
    • teamAとBのテンプレを分けておくと、変更しやすくてよいという話
    • 「タグのnameは気軽に変えられるもののままにしておこうね、クロスすタック参照にしたりしないようにしようね」
    • ☆「ネストされたスタック」
      • ☆普通に、他のテンプレをインポート的なことができる
      • ☆しかも、Parameter を何にするかを親(呼び元)で指定できる
    • ☆ファイル構成もぜひこれを真似しよう
      • Layerがさっきまでカンガえてた nw, security, datastore, app かな？
      • (2021/08/26 19:31 追記) ただ、次回のブログで、「子スタックを持つスタックはインポートできない」(=インポートでは二段構成までしか作れない) ことが判明した
    • (↑を9分で書いた)
  • 私的CloudFormationベストプラクティス - Qiita (11分)
    • cFnテンプレのかなり詳細な例がある
    • 差分テンプレいい感じ(多分 web-office.yml のこと)
    • 依存しているスタックを書くのは行数(みやすさ)が見合ってないかも。
      • 書くならコメントでいいかも
    • ☆ネストには2019/9/30当時には、「子の詳細な変更セットが見れない」という弱点があったとのことなので、いまでもそうか実験してみたい
    • 命名法も参考になった
    • (↑を5分で書いた)
    • これでベストプラクティスは一旦いいだろう！

今後の方針を考えた (cFnをマスターしたらCDKにいきたい)

  • どう考えても、将来的には、ちゃんと書けるCDKを使うのがよい
  • ただ、 CDK は cFn のラッパーなので、まずはcFnをマスターしたい

16日目 2021/07/20 20:48 : 今でもネストすると詳細な変更セットが見れないのか調査(2020/11に見れるようになったことを確認した), 変更セットの公式ドキュメント読んだ

変更セットの公式ドキュメント

  • 変更セットのサンプル - AWS CloudFormation (21分)
    • cFnが認識する変更には「テンプレの直接変更」と「パラメータ値の更新による変更」があるらしい (ChangeSource フィールド)
    • RequiresRecreation: インスタンスの置き換えが必要ないかを示す
    • replacement: AWS CloudFormationが新しいリソースを作成して古いものを削除する必要はないということを示す。falseなら 安心して実行できる。
      • ☆true だと危険！
    • (↑を4分で書いた)

ネストした子の詳細な変更セットが見れるようになった調査

  • その後、20分で、下の調査をした
  • ネストされたスタックの変更セット - AWS CloudFormation (10分)
    • 自信満々な「ネストされたスタックも変更セット見れる」というドキュメント
    • ただ、日付が書いてないので、2019/9時点での問題を解決したものか分からなかった(フィードバックを送った)
  • 変更セットの差分は、このリソースが変わるよ、ということしか分からないものだと理解した
    • (Drift (テンプレと実体の差分)では どの部分が違うかの差分が出る)
  • AWS CloudFormation 変更セットがネストされたスタックのサポートを開始
    • この資料により、上記のドキュメントは、2019/9時点の問題に対応したものだとわかった
    • つまり、現時点(2021/7)では、「ネスト機能」は有効に使えそうだと分かった
  • (上を3分で書いた)

17日目 2021/07/22 2:36: 学んだベストプラクティスを使って業務AWSのNWをcFnテンプレにし始めた

  • 52分で↓をした
  • テンプレの構成考えた
  • VPCと IGWをその構成でテンプレにした
  • 私物AWSでテストしようとしている
    • この時に、業務AWSで使おうとおもってたS3バケット名を使ってしまった
      • (世界でユニーク、一度も使われてない必要があるので、業務AWSで使えなくなった)
  • cFnでテンプレを読み込んで、デザイナーにきれいに表示された
    • 実際の実行はまた明日
  • (↑を4分で書いた)

18日目 2021/07/22 17:26: VSCodeでLintできるようになった

19日目 ベストプラクティスで作ったcFnテンプレでVPCとIGWを作った, SubnetをcFnテンプレにしてる

VPCとIGWを作れるか試す

  • ↓を32分でやった
  • VSCodeでcfn-lint できるようになったので、ベストプラクティスに則った形で VPCとIGWを作った
  • つまりポイント
    • Terapadで yaml のコメントを日本語で書いた後に VSCodeにそれをもっていったら、 文字化けして、 cfn-lintは ファイルを読み込めません的なエラーを出した
      • そのコメントを消したら解消した
    • cfn-lint 的には UpdateReplacePolicy をつけるのが必須みたいなので、Retainでつけた
      • 更新のためにリソースを置き換えるときに、元のを残すかの設定
      • retainにしておくのが、料金かかるリスクはあるが安全 (最初は安全に倒すべし)
    • template url は、 s3:// ではダメで https:// じゃないと通らなかった
  • スタック作る時に 予想コストもでていいね (vpcとigwだけなら0円)
  • 作成できた
    • VPCとIGWだけでも1分半かかった
    • (↑までを6分で書いた)

Subnetをテンプレにする

      Tags:
        - Key: Name
          Value: !Join 
            ["-", [!Ref InternetAccessibility, "Subnet", !Ref AvailabilityZone, "routetable", "cfn"]]
  • のように、配列の一行記法を使って、見やすく書いた
    • ↑のブログを4分で書いた

20日目 2021/07/25 16:37: SubnetをcFnにした, 残すはSGだけになった

Subnet編

  • 18分で下をした
  • cFnテンプレを完成させて、私物AWSで流してみた
    • うまくできた
  • テンプレのS3パスが前回と同じでも、「既存テンプレを置き換える」を選択せねば、前回実行時のテンプレが使われてしまう (変更セットの作成)
  • ドリフト検出も、変更セット作成も、今回の「サブネット追加」くらいなら1分間くらいかかる
  • localへのrouteは書かなくても勝手に追加されてた
  • (↑を4分で書いた)

他のNW要素編

  • その後、下のことを30分でやった
  • よくみたら、1つのRouteTableを複数のSubnetで使ってたので、Subnetのテンプレから切り出した
  • managed prefix list は S3が勝手に作るものだからテンプレにしなくてよいと考えた
  • NAT Gateway は 今回 Private Subnet がないのでテンプレにしなくてよいと考えた
  • Elastic IP も、NAT Gateway や SSHサーバをテンプレにする時にテンプレにすればいいと考えた
  • NACLも、私物AWSで試しに作ったスタックでは、勝手に全通しのNACLができていたので、別にテンプレに書く必要はないと確認した
  • S3エンドポイントも今回S3は対象外なのでいいや (多分S3を作る時にも勝手にできそう)
  • あとは VPC用、default のセキュリティグループだけになった

21日め 2021/07/26 20:58 : Security Group も今回はcFnに書かなくていいと確認した、チームに説明する資料を書いている

  • 49分で↓をした

Security Group 編

  • 事前の調査によると、今回は VPC用SGと default SG をcFnにすればよさそうだった
  • しかし、 VPC用SG は説明に VPC用と書かれているだけで、実際は EC2用SGだった
    • 今回は EC2 を作らないのでパス
  • default SG (default SGからのinを全通し、 outは全通し)は、私物AWSでcFn練習した時に、勝手に作られていた
  • このため、今回はSGをcFnに書かなくて良い、と判断した。

チームに説明する

  • 説明するため、社内ドキュメントに説明書きを書いていっている。

22日め　2021/07/27 22:03 : チームへの説明を書ききった, テンプレを仕上げ中

  • 58分
  • チームへの説明をかききった
  • テンプレを仕上げてる

23日目 2021/07/28 20:50: gitbucket にprを出して、説明の準備が完了した

  • 56分
  • 私物AWSで実行したらエラーが出たので直した
    • 「Parameters: [IgwId] do not exist in the template」というエラーがでていた
    • テンプレで使ってないパラメータを含めてるよ、というエラーだった(消して解決)
  • gitbucket にリポジトリを作ってprを出した
  • 説明ドキュメントを読み返して修正した

24日め 2021/08/05 21:37: Beanstalk は マルチAZ

Beanstalk は マルチAZ

時間まとめ2

  • 21日め 2021/07/26 20:58 63分
    • Security Group を今回はcFnにしなくて良いと確認した
    • チームに説明するドキュメントを書いてる
  • 22日め 2021/07/27 22:04 59分
    • チームへの説明をかききった
    • テンプレを仕上げてる
  • 23日め 59分 2021/07/28 20:52
    • prを出して、説明準備完了