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しても、なにも更新されない（そもそも更新対象として検出されない）