Iruにおけるデバイス管理のConfig as Code：その仕組み

ほとんどのデバイス管理ワークフローは、未だに属人的な知識に依存しています。管理者が変更を加え、おそらく次の人がその理由を理解してくれることを願いつつ、どこかに記録を残します。小規模であれば対処可能ですが、エンタープライズ規模ではリスクとなります。

Configuration as Codeは、運用モデルを変革します。デバイス設定はバージョン管理された資産となり、変更はスクリーンショットではなくプルリクエストを通じて行われ、デプロイ履歴はそれを生成したコードとともに保存されます。そして、Iruを運用しているチームにとって、Config as Codeはデバイス管理の利用可能なオプションとなります。

Config as Codeとは？

Config as Code（CaC）とは、UIをクリックしていく代わりに、バージョン管理されたファイル内でシステム設定を定義および管理する手法です。この概念は、インフラストラクチャやアプリケーション配信において長年標準となっています。Terraform、Ansible、Kubernetesマニフェストなど、すべて同じ考え方であり、スタックのレイヤーが異なるだけです。

デバイス管理に適用すると、デバイス群の設定がGitリポジトリに保存されることを意味します。変更は完全な差分（diff）と作成者が記録されたコミットとなります。プルリクエストによって、デバイスに適用される内容が制御されます。新しいテナントの設定は、リポジトリをプッシュするだけで簡単に再構築できます。そして、現在または将来のどの管理者も、引き継がれた知識や文書化されていない設定に頼るのではなく、同じ信頼できる唯一の情報源（Source of Truth）から読み取ることになります。

これが解決する課題は、大規模なデバイス管理の経験がある人なら誰でも馴染みのあるものです。

• 変更の責任明確化: 誰が、何を、いつ、なぜ変更したのかが、事後に再構築されるのではなく、システムによって記録されます。
• 複数管理者間の調整: バージョン管理により競合が防止され、競合が発生した場合でも解決するための明確な経路が提供されます。
• コンプライアンスの追跡: 監査履歴は監査前に組み立てるものではなくなり、デフォルトでリポジトリ内に存在するため、より追跡が容易になります。
• 管理者の離職: 新しいチームメンバーはリポジトリをクローンするだけで、引き継ぎ期間を設けたり、スクリーンショットのフォルダや深く階層化されたConfluenceやNotionのドキュメントを確認したりすることなく、環境を理解できます。

最も変更管理が重要な部分から始める

現在、Iru Control (iructl) とIru Enterprise APIは、Mac向けのカスタムプロファイル、カスタムスクリプト、およびカスタムアプリに対応しています。これはプラットフォームの全領域を網羅しているわけではありませんが、変更管理が最も重要であり、最大の効果を発揮できるレイヤーです。

Blueprint、Assignment Maps、条件付きノードロジックなどのプラットフォームレベルの構造は、引き続きIruコンソールで管理されます。これは今後変更される予定です。IruのAPIファーストのロードマップにより、今年は対応領域が拡大され、UIにあるすべての機能をAPI経由で利用できるようにすることを目指しています。その拡大に伴い、リポジトリで管理できる範囲も広がります。

それまでの間も、このワークフローはコアとなる価値を提供し続けます。デプロイ可能な設定は、完全な変更管理と監査追跡を伴ってGit経由で反映されます。スコープ設定のロジックは、視覚的で把握しやすいコンソール内に留まります。プラットフォームのより多くの部分がAPIでアクセス可能になるにつれて、同じIru Controlワークフローがそれをカバーするように拡張されます。リポジトリはIruにデータを提供するものであり、Iruを置き換えるものではありません。そして本日より、iructlはConfig as Codeワークフローを通じて管理されるLibrary Itemを、Assignment Maps上の特定のノードに確実に割り当てることさえ可能になります。

現在のIruにおける仕組み

IruのEnterprise APIは、Mac向けのカスタムプロファイル、カスタムスクリプト、およびカスタムアプリに対する完全な作成（create）、読み取り（read）、更新（update）、削除（delete）操作をサポートしています。それが基盤となり、その上にワークフローを構築します。

GitHub Actionsを使用した、実際のワークフローの例は以下の通りです。

リポジトリ構造が定義となります。その中で、デプロイ可能なアイテムをプロファイル、スクリプト、アプリといったタイプ別に整理します。各アイテムには専用のフォルダが割り当てられます。プロファイルとスクリプトは、事前/事後インストールスクリプトや監査/修復スクリプトなどの補助ファイルとともに、ペイロード（.mobileconfigファイルやスクリプト）を直接保存します。アプリの仕組みは異なり、iructlがインストーラを自動的にアップロードし、マニフェストがアップロード前のメタデータを記録します。すべてのフォルダには、そのアイテムをどのようにデプロイすべきかを宣言するマニフェストファイルも含まれています。

マニフェストが宣言となります。アイテムの名前、アクティブかどうか、どのブループリントに属しているか（オプションで、そのブループリント内のどのノードに割り当てるべきか）、およびどのプラットフォームで実行するかを指定する、シンプルなJSON、YAML、またはPLISTファイルです。Mac、iPad、iPhoneなど、該当するものを指定します。

以下はマニフェストの例です。

{
 "id": "3bdb4111-cebe-4757-b97b-450b66fec878",
 "name": "Disable Improve Apple Search",
 "active": true,
 "mdm_identifier": "com.kandji.profile.custom.3bdb4111-cebe-4757-b97b-450b66fec878",
 "runs_on_mac": true,
 "ensure_blueprints": [
 {
   "blueprint": "Iru Level I"
 },
 {
   "blueprint": "341ec1b2-5e71-43f8-b27b-8805009a0342",
   "node": "da15159c-4d2a-42cc-9f4d-83f10369b4a2"
 }
 ]
}

それだけです。新しい管理者はコンソールを開くことなく、これが何を行うのか、どこに配置されるのか、そして何に影響を与えるのかを正確に把握できます。

同期ではハッシュを使用します。現在、Iruが提供するGitHubアクションを使用すると、すべてを盲目的にプッシュすることはありません。各マニフェストとプロファイルの構文を検証し、保存されたハッシュを現在の状態と照合して、実際に変更されたアイテムのみにパッチを適用します。新しいアイテムが作成されると、APIレスポンスがIDと同期ハッシュを書き戻すため、将来のプッシュで既存のレコードを対象にできるようになります。今年後半のAPIファーストのロードマップの一環として、IruはGitリポジトリへの書き戻しを完全に回避する宣言的なプロセスを提供する予定です。

パイプラインがガードレールとなります。検証。リント。ハッシュチェック。APIプッシュの前であれば、あらゆる処理が可能です。次のステップが実行される前に各ステップに合格する必要があるため、不正な形式のプロファイルがデバイスに到達した後ではなく、到達する前に検出することができます。

実際のデプロイはどのようになるか

以下は、iructl とGitHub Actionsを使用して新しいカスタムプロファイルを実行する手順です。

1. ローカルでリソースを作成します。iructl profile new を実行して、リポジトリ内に新しいカスタムプロファイルの雛形を作成します。これにより、メタデータファイルと.mobileconfigペイロード用のプレースホルダーを含むディレクトリ構造が作成されます。プロファイルを配置し、マニフェストを入力します。

2. 同期ステータスを確認します。iructl profile listは、何が新しく、何が変更され、何が同期されているかを示します。デバイスからデータが離れる前に、その状態を確認できます。

3. ブランチを作成し、コミットし、PR（プルリクエスト）を開きます。ここでバージョン管理が機能します。差分（diff）には、プロファイルのXMLとマニフェスト宣言など、何が追加されるのかが正確に表示されます。レビュー担当者は、設定とその設定がどこに割り当てられるかの両方を確認できます（オプション）。

4. PRが承認され、マージされます。ブランチ保護が機能し、本番環境（main）への変更が最初にレビューされることを保証します。mainへの承認されたマージにより、iructl-pushワークフロー（Iruが提供するGitHubアクション）がトリガーされます。

5. iructl-pushが変更をIruに同期します。新しいリソースが作成され、変更されたリソースが更新され、リポジトリから削除されたものはテナントからも削除されます。リポジトリの状態とIruの状態が一致します。

6. アイテムがIruに表示され、スコープが設定され、アクティブになり、デプロイされます。誰もコンソールに触れていません。プロファイルは、適切なプラットフォームを対象として、適切なブループリント内の適切なノードに配置されています。.mobileconfigの内容は、リポジトリ内のファイルとバイト単位で一致します。

ここからが、このワークフローを求めているエンタープライズチームにとって最も重要な部分です。

7. 何かが破損したり、誰かが誤ってコンソールからアイテムを削除してしまった場合。UIのみのワークフローでは、これは復旧プロジェクトになります。記憶やスクリーンショット、あるいは不完全なドキュメントから、そこにあったものを再構築することになります。

Config as Codeワークフローでは、iructl-pushワークフローが再実行され、リポジトリが宣言しているすべてを復元します。または、スケジュールに基づいて先に iructl-pullが実行された場合、削除を競合としてフラグを立て、Slack通知の送信などのワークフローをトリガーできるため、チームはどのように対処するかを決定できます。いずれにせよ、リポジトリが信頼できる唯一の情報源（Source of Truth）であり、宣言された状態に戻すことは再構築ではなく、再実行です。

2つのアプローチ：GitHub Actionsまたは管理者による実行、どちらもIru Controlが稼働

管理者として、Mac上で直接iructlを実行し、Iruテナントとインターフェースを操作することができます。現在の状態のプル、新しいリソースの作成、変更のプッシュ、同期ステータスの確認など、すべてをコマンドラインから行えます。ここで、本番環境に適用する前に、作成、テスト、および検証を行います。

チームとして完全なCI/CDワークフローを導入する準備が整ったとき、GitHub Actionsの統合が役立ちます。再利用可能なワークフローは、パイプライン内で同じiructlを使用します。同期ロジック、検証ステップ、そしてプッシュとプルの挙動は、すべてローカルで実行したものと同一です。自身のマシンでテストした内容がそのままCIで実行されます。翻訳レイヤーや、独自の挙動を持つ第2のツールは存在しません。

Iru ControlはHomebrew、uv、またはpipx経由でインストール可能であり、完全なドキュメントはGitHub上に公開されています。

デバイス群も、スタックの他の部分
と同じように機能すべき

デバイス群には、スタック内の他のすべてのものと同じように機能させたいはずです。宣言された信頼できる唯一の情報源（Source of Truth）からの一方向のプッシュ。ポリシーではなく、システムによって強制される変更管理。再構築ではなく、再実行による復旧。

それが、デバイス管理を実際に管理可能にするプラットフォームを諦めることを求めることなく、IruのConfig as Codeが提供するものです。

これらの仕組みがどのように動くか、また実際のテナントで動作している様子を確認したい場合、デモをご依頼ください。