ヘッドレスMacビルドフリートの運用プラットフォーム

• Namespaceは、ヘッドレスMacで深刻な障害に直面しました。KVM画面からFileVaultのパスワード入力画面が5分後に消える、USB NICがネットワークサービスをGUIで再作成するまで落ちたままになる、復旧のためだけにHDMI/KVMの配線を工夫する必要がある、などです。 記事から ↗
• 記事の大半はAppleのバグへの対処であり、Macのデータセンター運用を理解するのは非常にコストがかかるため、人々はその手間を避けるためにプレミアムを払うだろう、と主張しています。 コメントを読む ↗
• ヘッドレスのMac miniサーバーを運用する人が、起動時のディスク暗号化パスワード入力を大きな関門と感じています。誰かが物理的にロックを解除するまでサーバーが止まってしまうのです。 コメントを読む ↗
• AWSのMacサービスの問題点として、唯一の対策がFileVaultの無効化であること、利用のたびに1時間ほどかかる初期化、5〜10分の起動時間、ホストの頻繁な不足が挙げられています。 コメントを読む ↗
• TestingBotはVirtualization.frameworkを使って自社のMac miniフリートを構築し、バッテリーの膨張のようなハードウェアの危険にも対処しており、多くの小規模運用者が同じ運用作業を繰り返していることを示しています。 コメントを読む ↗

議論の内容を要約したものです。元のコメントはリンクからどうぞ。

Jamf and Kandji (MDM built for employee endpoints, not CI build nodes)MacStadium Orka (orchestration locked to MacStadium hardware)Tart / Cirrus CLI (VM runner, no host-level recovery or hardware ops)Ansible + custom scripts (the current DIY default)

既存のMDMツールはログイン中のユーザーがいるノートPCを管理し、VMツールはゲストOSの手前で止まります。ヘッドレスMacフリートのホスト単位の運用を提供する製品はありません。無人のFileVault/authrestartによる復旧ワークフロー、GUIのみの状態に対するIP KVMの制御、ネットワークサービスの自己修復、バージョン管理されたVMイメージのパイプラインを一つの製品で扱えるものがないのです。

1. Macホスト向けのエージェントを出荷し、既知の障害状態を検出して自動復旧させる：fdesetup authrestartポリシーによるFileVaultの起動時プロンプトへの対応、故障したUSB NICのネットワークサービス再構築、IP KVM APIによる再起動の制御。
2. バージョン管理されたmacOS VMイメージのパイプライン（Tart互換）を構築し、Appleのリリース後数時間以内に新しいXcode/iOSランタイムのイメージを作成して、フリート全体に展開する。
3. ノードごとの状態、復旧の監査ログ、ワンクリックの再プロビジョニングを備えたフリートダッシュボードを追加し、Mac miniを20台以上運用する5社のパイロット顧客に販売する。