OCI の Resource Manager を使って Terraform を実行する
Oracle Cloud Infrastructure (OCI) の中にある Oracle Resource Manager (ORM) というサービスを使うと、OCI 上で Terraform 定義ファイルを実行でき、状態管理ファイルを一元管理できる。
Terraform で OCI の操作をしたことがある人なら始めるのは簡単なので、紹介する。
目次
Resource Manager はどこにある？
リソースマネージャは、
- OCI コンソール → ハンバーガーメニュー → 「Solutions, Platform and Edge」セクション → 「Resource Manager」リンク
と進む。
Stack と Job
最初に表示されるのは「Stacks」というリソースで、その他に「Jobs」というリソースがあるのが分かる。
これらは何かというと、1つの Terraform ファイル群を Stack と呼んでおり、その Stack 定義を元に terraform コマンドが実行される1回の履歴を Job として管理するのだ。つまり、Stack : Job = 1 : n という関係。
Stack が Terraform 定義ファイルを置いているディレクトリで、Job がコマンドの実行履歴、といったところで良いだろう。
Terraform 定義ファイルの注意点
Resource Manager という名前だが、実態は単なる Terraform 実行基盤だ。使用する Terraform 定義ファイルは、ローカル開発マシンで terraform コマンドを使って実行した時のファイルがほぼそのまま使える。
ただ、Resource Manager 特有の特徴として、provider.oci には region プロパティ以外の指定が要らない、というところが特徴だ。region だけは、対象のリージョンを特定するために必要だが、Tenancy OCID だったり、Terraform を実行するユーザの情報、といったものは必要ない。Resource Manager 自身が manage all-resources in tenancy な特権を持っている状態だ。
この仕様による弊害は、OCI の場合は oci_containerengine_cluster_kube_config Data Source を使った KubeConfig ファイルの生成が出来なくなることぐらいだろうか。local_file を使ったファイル出力もできないので、KubeConfig ファイルの生成は Resource Manager を使わず別の手段をとろう。
Stack を作る
それでは、まずは Stack を作ってみよう。先程書いたとおり、Resource Manager はテナンシー内のどこにあるリソースでも作成・更新できるので、当該 Stack が所属するコンパートメントと、作れるリソースの範囲は関係ない。
Stack 作成画面で、Terraform 定義ファイル群をまとめた Zip ファイルをアップロードする。すると、ファイル内の variable 宣言と default 値を読み取って、変数のフォームをある程度自動入力してくれる。
公式ドキュメントを読むと、terraform.tfvars か *.auto.tfvars というファイルが Zip 内にあれば、その値を勝手に代入してくれるっぽいのだが、自分が試した限りでは変数値の代入はしてくれなかった。.tfvars ファイルから手作業で値をコピペしよう。
なお、配列の変数に関しては、テキストボックスに [ "hoge" ] といった形で書いていけば良い。
Job を実行する
Stack が作れたら、その Stack 定義を元に Terraform を実行する。選択できる Action は Plan、Apply、Destroy の3つで、terraform plan・terraform apply・terraform destroy コマンドと同じだ。
実際に Plan なり Apply なりを実行してみると、ステータスが「Accepted」になると思う。そこから数分待つと「In Progress」ステータスに移行し、実際に Terraform が実行されている様子が「Logs」画面で分かる。サラッと書いたが、1回のコマンド (Job) 実行に5〜10分くらいかかるので、動作速度は物凄く遅い。
こうして作業が終わると、実行結果は「Outputs」欄に表示される。「Logs」欄もそうだが、まさに terraform コマンドの実行結果がそのまま出力されている。
この Resource Manager の利点は、状態管理ファイル .tfstate の共有が不要になること。Terraform の機能にリモートステートといったモノがあるが、その設定すら不要になる。一度アップした Terraform ファイル群は Resource Manager からダウンロードできるし、複数の開発者で一つの Terraform ファイルを編集し、リソースを更新していきやすいのが特徴だろう。
削除について
Stack を削除する場合は、きちんと「Destroy」Job を実行してから Stack を Delete するようにしないと、リソースが残ったままになってしまうので注意。
また、Stack を削除した後、その Stack が所属していたコンパートメントを削除しようとすると、「Job」リソースが裏側でまだ残ったままとみなされてしまい、コンパートメントの削除に失敗してしまった。コレはどうやったら解決できるのか、まだ分かっていない。しばらく放置してみるか。
以上。実行速度が著しく遅いが、定義ファイルなどを共用しやすいので、例えば本番環境の構築などは、ローカルから Terraform を叩くのではなく、Resource Manager を使うようにしておくと良いかもしれない。