久しぶりにちゃんと勉強会の感想ブログ書きます。
① State の分割戦略 〜ModulesとWorkspacesを利用して〜
StateはTerraform上での管理を分ける意味では非常に重要な要素であり、適切に分けることで不慮の事故や予期せぬ変更からクラウドリソースを守ることができます。このセッションでは演者が実際にTerraformを利用して感じたことを交えながら、適切なStateの分割戦略とは?について話します。
Stateの分割についてModuleによるアプローチとWorkspacesによるアプローチ、そしてそのあわせ技についての説明がありました。 Workspacesは使ったことないのであまり知見がなかったので、いろいろ参考になる部分がありました。
今のterraform運用だと環境ごとにディレクトリを切ってstateを分割してます。で、環境ごとの差異としてパラメータだけでなく、作るリソース作らないリソースが若干まちまちなので、そのままだとWorkspacesは向かないなと感じました。
絶対に作るリソース、RDSやVPCなどは分割した上でWorkspacesで管理するのはありなのかなとは思いました。ただ、同じシステムで、環境毎のディレクトリとリソース毎のディレクトリが混在するのはわかりにくくならないかなという懸念はあります。悩ましいですね
あと、ブランチ戦略も難しいですね。現状はmasterでprdをapplyするように、stagingでそれ以外の環境をapplyするようになってますが、全部masterでやるようにしても良いのではと思ったりもしてる今日このごろです。
② クラウドリソース自体をdestroy/createdせずに、Terraformリソース定義の記述場所を変更する方法
クラウドサービス上で稼働するリソースには一切手を付けずに、Terraformの定義記載場所だけを変更する方法を話します。
Terraformを利用していると「このディレクトリ配置じゃダメだ。配置変えしたいのだけれど、リソースの再作成はできない。次にインフラ設計するときは、〇〇に注意しよう」という運用ナレッジが貯まると思います。スタート時点で完璧なTerraformディレクトリ設計ができれば御の字ですが、それが不可能なことは、この分野でベストプラクティスが確立されていないことにより証明されています。
本パートでは「Terraformのディレクトリ配置には定石がないのだから、運用状況に合わせて柔軟に配置換えすべき」という観点から、「動作中リソースに影響なく、Terraform定義箇所を移植する方法」について話します。
こんなふうに別のtfstateファイルにリソースをmvすることによって、Stateにリソースを移動できる手法を説明してました。
terraform state mv -state-out=${moved_resource.tfstate} ${moved_resource}
terraform state pull > ${to.tfstate}
terraofm state mv -state=${moved_resource.tfstate} -state-out=${to.tfstate}
terraform state push ${to.tfstate}
State間でのリソース移動に関しては、terraform state rm
とterraform import
のあわせ技しか知らなかったので、新しい知見を得ました。まだ試せてないないんですが、State内での移動であれば、moved block使うのもありなのかなと思いました。ちなみリソースが消えた場合にもmove blockって使えるんですかね?
なかなか他の会社のterraform運用の話を聞く機会があまりなかったので、楽しかったですね。
最近勉強会出てもメモすら残さないことが多くて、せっかく参加したのにあまり有意義に時間を使えていなかったので、薄くてもいいので今後ちゃんと感想、意見を書き残していきたいと思いました。