id:a-oonoです。
今回の記事ではResource Managerを紹介したいと思います。
Resource ManagerはOracle Cloud Infrastructure (OCI) 向け Terraformの実行環境です。
OCIに限らず、エンタープライズ環境においてクラウド環境の
- 権限管理・運用
- インフラコードの管理
は煩雑になりやすいと思われますが、こちらのサービスを用いることでそういった課題を解決してくれそうな製品となります。
Resource Managerの特徴
Terraformのための実行権限はResource Managerが管理するため、コンソール上から操作する分には、TerraformのためのAPIキーの管理が各個人で不要となります。
Terraformの状態管理(State)ファイルはResource Manager上で管理されるため、複数人でインフラコードを管理するようなケースに有用と思われます。ただし、後述する制限があるので注意が必要です。
Resource Managerの用語
Stack(s)
- Terraform実行単位を一つのzipファイルに固めResource Manager上にアップします。そのリソースに対してResource Manger上で
terraform plan、terraform apply、terraform deleteが実施できます。 - このTerraform実行単位を1つのzipファイルに固めたものを当製品ではStackと称しています。
- Terraformの変数は、OCI/Resource Managerの画面から引数として渡すことが可能です。
- クレデンシャル情報はResource Managerが管理するため機密情報をTerraformのコードに記載する必要はありません。
- TerraformのリソースはStack単位 (≒ Terraform実行単位)で閉じているように見受けられ、Stack間でStateファイル参照ができません。Stack間を跨ぐような場合には Remote Sate を利用する必要があります。（2019/4/26時点でサポートへ確認済み）
Job(s)
- 上記で作成したStackに対する
terraform [plan, apply, destroy]といった1実行単位を指します。 - Jobを実行してみた結果、実行時スピードは手元のPC上で
terraformを実行するよりも若干遅いように感じられました。簡易的なリソース定義(VCN１つ)のplan / applyで3～4分程度です。Job実行の毎に実行環境となるインスタンスのプロビジョニングがスタートしているものと推測されます。
触ってみての所感
手元にterraformの実行環境を構築することなく、計画～実行～削除まで実施できかつ、成果物(stateファイル)がクラウド上に残るため比較的安全に インフラのコード管理／オペレーションができます。
記事を作成した時点ではリポジトリと連携する機能がないため、本機能上ではインフラコードのバージョン間差分比較が実施しにくいように感じられました。 コード管理には 別途ツール (GitHub) 等を利用するといった必要性が感じられました。
今後への期待
AWS CloudFormationという類似製品では、当製品と同様の概念でStackがあります。しかし、AWS側では別Stackのリソースを参照可能です。OCI Resource Managerでもそういった機能があると有用かもしれません。
また、Resource Manager単独で外部のコード管理と差分比較といった機能連携ができると有用性が上がるかと思われます。
おわりに
簡単にResource Managerの紹介をさせて頂きました。次回、実際の使い方など紹介できればと考えています。