こんにちは。
dotDでインフラエンジニアをやっている棟方です。
今回PJでOracle Cloud Infrastructure （OCI）でいろいろと作ってみた上で、こんなところが困ったな、難しかったな、といったような話を書いていきたいと思いいます。
今回はOCI DevOpsというデプロイサービスについて書いていきます。

▼目次

• OCI DevOpsとは？
• 構築の前提条件
• 構築順序
• 所感

OCI DevOpsとは？

参考文献：

OCI上でコードのバージョン管理からデプロイまでを一気通貫で全部管理できますよ、という一見大変便利そうなツール。
しかもGitHubとの同期機能もあるので使いこなせれば便利。

構築の前提条件

DevOpsを構築するにあたって、DevOpsのセットアップ以外で必要だったあれこれについて、いろいろ試してみた結果下記が判明。
まず、前提の前提として、OCIはゼロ トラストです。
一切合切使わせないという方針のもとサービス展開がされているので、筆者も「フーン」くらいでしたが、実際やってみていろいろと詰まりました。

• IAMポリシー
• • どんなクラウドサービスでも当然と言えば当然だけど、人が操作するユーザ＋各サービスが実行するための細かいポリシー設定が必要だと途中で判明。
    また、IAMポリシーとグループ、動的グループの３種類が必要で、どれが何に紐づいて権限が継承されるのか、コツが必要です。
    途中から設定したので、いったい何が何やらわからず混乱しました。
    ※実行する際のユーザはあくまでDevOpsをぽちっと実行する権限だけでOKで、他の実行権限についてはその他サービスが振られた権限で動作を担保します。文章的にはAWSと変わらない感じがしますが、同じ感覚で行おうとするとかなり詰まる
• Vault
• • GitHubと連携する際に必要。これもかなり権限回りで苦労しました。
    あと、すぐには消えないため、削除等の対応も考える必要があります。
• リポジトリ
• • DevOpsのパイプライン定義（yaml）の保存先と、ビルドのアーティファクト格納先として利用。利用の際、同じリポジトリサービス内の種類が違うリポジトリサービスを構築する必要があることが後々判明。
    ドキュメントにはふんわり「リポジトリ用意してね」くらいのノリで記載があったので、構築しながら利用できるリポジトリを探しました。
• 定義ファイル（yaml）
• • DevOpsなので当然必要。けれど何をどうかけばどう動くのか？仕組み・仕掛けが難解でかなり苦戦しました。
• インスタンス
• • 今回はコンピュートインスタンスにデプロイを想定していたので、こちらも用意しました。
    ですが、デプロイ時にデフォルトでインストールされているOCIのエージェントユーザの設定をする必要がある、それに対してIAMポリシーを割り当てる必要があるなどこちらも難解でした。
    ※動的グループでインスタンスIDべた書きで付与しないといけないため、大量インスタンスで構成されているシステムにはあまり向いていないかもしれないです

構築順序

参考文献：
インスタンス・グループへのデプロイ (oracle.com)
https://oracle-japan.github.io/ocitutorials/cloud-native/devops-for-commons/

上記２つのドキュメントに従って…と言いたいところですが、そのままやると前項のようにいろんなところで躓きます。
きっと、恐らく下記のような順序で構築を進めていくのがベストではないかというのがありますので、ご紹介します。

1. デプロイ先環境準備
2. 1. コンピュートインスタンスの構築
   2. IAMポリシーの作成
   3. コンピュートインスタンスにあれこれ実行できる権限を付与
      例）
      Allow dynamic-group test_deploypipline to manage all-resources in tenancy
      Allow dynamic-group test_deploypipline to manage devops-family in compartment id <コンパートメントID>
      Allow dynamic-group test_deploypipline to manage instance-agent-command-execution-family in tenancy
      Allow dynamic-group test_deploypipline to manage all-artifacts in compartment id <コンパートメントID>
      Allow group DevOps to manage instance-agent-command-family in compartment id <コンパートメントID>
      Allow group DevOps to manage devops-family in compartment id <コンパートメントID>
      Allow group DevOps to manage all-artifacts in compartment id <コンパートメントID>
   4. 動的グループの準備
   5. 上記で作ったIAMポリシーを動的グループに割り当てる
      例）
      All {instance.id = 'インスタンスID'}
      All {resource.type = 'devopsdeploypipeline', resource.compartment.id = 'インスタンスID'}
      All {instance.compartment.id = 'インスタンスID'}
   6. DevOpsのデプロイメントパイプラインはデプロイ時にインスタンス内部にプリインストールされている"ocarun"というユーザを使用
   7. デプロイ対象ユーザのホームディレクトリを755に変更
   8. デプロイ先のディレクトリがホームディレクトリ内にある場合は777に変更
   9. ocarunユーザをwheelグループに追加
2. DevOpsサービスの準備
3. 1. IAMポリシーの準備
   2. DevOpsが各リソースを実行・管理するためのポリシーが必要
      詳細についてはドキュメントに記載があるので割愛
   3. 動的グループの準備
      大体 in tenancy（テナンシー全体）に適用したら動きますが、権限が広範囲すぎるので絞った方がいいのですが、変に絞ると動作しなくなります。
   4. DevOpsプロジェクトの作成
   5. こちらは公式ドキュメント通りでOK
   6. リポジトリの作成
   7. パイプラインの定義（yamlファイル）を格納するアーティファクト・レジストリ・リポジトリを「インスタンス・グループ・デプロイメント構成」で作成
   8. ビルドしたアーティファクトを格納しておくアーティファクト・レジストリ・リポジトリを「汎用アーティファクト」で作成
   9. ビルド・パイプラインの作成
   10. 好きなようにyamlを書いてOK（たぶん…）
   11. デプロイメント・パイプラインの作成
   12. 好きなようにyamlを書いてOK。ただし、実行先がインスタンス上のocarunユーザかつ、作業がocarunユーザが作成するディレクトリ上で行われるので、要注意
   13. デプロイ実行

所感

あちらこちらのドキュメントを参考にしていましたが、成功たどり着くまでにかなり迷いました。
ドキュメントもあちらこちらのリンクに飛ばされるので難解です。。。
上記の方法も本当に正解かはわからないのですが、結果としてはうまくいった方法です。

少しでも参考になればと思います。