Deployment Managerを触って気になったところ - GCPを使い始めて気づいたAWSとの違いをメモしていく その2

https://qiita.com/watarin/items/d867dcfac9cfd62abbc0
に続いて、今日はDeployment Managerを色々触ってみたのでそのメモ

基本的な概念

• AWSのCloudFormationみたいなやつ
• 名前の通り、Deploymentする仕組みで、Convergeする仕組みではない（CloudFormationと同じ）
  • Terraformのstateのrefreshや、stateの直接編集みたいなこともできないので、他でいじると破綻する

個人的にはこの手のツールはConvergeして欲しいので、GCPでもTerraformメインになるかな？という気がしている（GCPでTerraformまだ試していないので、結果どうなるかはわからないけど）

テンプレート

CloudFormationより明らかに便利なところ。大量にコピペしなくてよい！

• Python or Janja2 on YAMLでテンプレートが作れる
• PythonはYAML構造を出力する関数を定義する
• create/update時に、Pythonのコンパイルエラーは当該のPythonファイルに対して検出されるけど、構成ファイルとしてのエラーはテンプレート処理後のYAMLに対してエラーがでるので、Pythonファイルでどこを間違えたかは、自分で探す必要がある（まぁ仕組み的に当然といえば当然）
• 手元で、構成YAMLを動的に作るのと、ぶっちゃけ大差ない仕組みな気がする。とはいえやっぱり仕組みとして提供されているのは便利

変更の確認

CloudFormationとは一長一短かなぁ、、、、個人的にはTerraformのplanみたいなのが一番わかりやすいと思っている

• updateの際に --preview でプレビュー状態になる
• Deployment Manger内で仮想のresourceが作成されるので、それでどうなるかが確認できる。
• CloudFormationの変更セットみたいに、変更の一覧がざっとでてくる、というのはない。
• 各リソースの内容をそれぞれ見る必要がある。resources list して、UPDATE になっているリソースを一つづつ resources describe する必要ある
  • WEBコンソールだと、、、プレビュー状態になっていることと、変更実行はできるけど、、、リソース情報はプレビュー状態のもの（変更予定のもの）は見れず、現状あるものしか見れない。
• 各リソースをdescribeすると、before/afterはでてくるけど、差分箇所の明示はされない。

適用

• 適用が失敗したら、そこで止まる。(CloudFormationみたいにロールバックしようとしない）
• previewで成功したからと言って、更新が成功するとは限らない（この手のはみんなそうだよね）
  • ex: comupteインスタンスのタイプ変更
• 実行にあたっては、Deployment Managerの権限を持っていれば各リソースに対する権限は不要
  • Deployment Managerのサービスアカウントがリソース操作する
• CloudFormationとは違って、リソースの変更を伴わない変更もできる

他でリソースいじると？

冒頭の通り、検知しない。Convergeもしない。なので絶対触っちゃだめ

• Deployment Manager外でリソースを編集しても一切関知しない（CloudFormationと同じ）
• 例えば、compute インスタンスをDeployment Mangerで作って、コンソールからインスタンスタイプ変えた後、Deplyment Managerでupdateしても、なにも更新されない（そもそも更新対象として検出されない）