OCI OS Management Hub

解決する課題

数十〜数千台の OS を個別に SSH してパッチを当てる運用は、適用漏れ・バージョン乖離・脆弱性の放置を招きます。OS Management Hub は、Linux と Windows のパッチ／更新／構成をクラウド側から一元的に統制し、フリート全体の状態を可視化します。

• どのインスタンスに未適用の更新やセキュリティパッチがあるかを横断的に把握したい
• パッチ適用をスケジュール化・自動化し、メンテナンスウィンドウ内で安全に回したい
• 環境（開発・本番）ごとに適用するパッケージのバージョンを固定し、構成のドリフトを防ぎたい
• インターネット非接続のプライベートサブネットやオンプレミスのホストにも更新を届けたい
• 監査向けに「いつ・どのホストに・何を適用したか」の履歴とコンプライアンス状況を残したい

主要概念と用語

• マネージドインスタンス（Managed Instance）: OS Management Hub の管理対象となる個々のホスト。OCI 上の Compute だけでなく、エージェントを入れたオンプレや他クラウドのホストも対象にできる
• エージェント: OCI Compute は Oracle Cloud Agent の OS Management Hub プラグイン（最低 1.40）を使う。オンプレミスと対応する第三者クラウドは Management Agent にプラグインを有効化して登録する
• グループ／フリート（Managed Instance Group）: 複数のマネージドインスタンスをまとめて一括操作する単位。グループ単位でパッチ適用や更新の実行ができる
• ライフサイクル環境（Lifecycle Environment）: 開発・テスト・本番のように更新を段階的に昇格させるための環境ステージ。各ステージへ順に適用し、検証済みの更新だけを本番へ進められる
• ソフトウェアソース（Software Source）: パッケージの配信元（リポジトリ）。ベンダー提供のものに加え、必要なパッケージだけを束ねたカスタムソフトウェアソースを作って配布内容を統制できる
• 管理ステーション（Management Station）: プライベート環境向けの中継・プロキシ兼ミラー。インターネット非接続のインスタンスへ更新を配信する経路となり、コンテンツのミラーリングも担う
• スケジュールジョブ（Scheduled Job）: パッチ適用やパッケージ操作などを指定時刻・繰り返しで実行する定義。メンテナンスウィンドウの実装に使う
• コンプライアンス（Compliance）: 各インスタンスが期待する更新状態を満たしているかの評価。未適用の更新の有無で準拠／非準拠が示される

仕様・制限・クォータ

• 対応 OS: OCI Compute では Oracle Linux 7〜10、Ubuntu 20.04／22.04／24.04、対応する Windows Server／Windows 11 を管理できる。オンプレミス・AWS・Azureでは Oracle Linux 7〜10（x86-64）のみが対象
• エージェント前提: OCI は Oracle Cloud Agent 1.40 以上、外部環境は Management Agent が必要。プラグインが無効・未到達だと検出も適用も行われない
• ネットワーク到達性: エージェントは管理サービスのエンドポイントへ到達できる必要がある。プライベートサブネットでは Service Gateway や管理ステーション経由など、経路の設計が前提になる
• リージョン単位のサービス: 管理対象やソフトウェアソースはリージョンに紐づく。クロスリージョンの一括操作は標準では行わず、リージョンごとに構成する
• クォータ: 管理ステーションやグループ、ソフトウェアソースなどの作成数にはテナンシ／リージョン単位の上限があり、上限引き上げはサービスリクエストで申請する。変動し得るため、最新の上限はコンソールのリミット表示で確認する
• 保持期間: 90日間通信のない管理対象、90日を超えたイベントや完了済み作業要求などはサービスから削除される。長期監査が必要なら外部へ保存する
• OCI Compute の利用には追加料金がかからないが、オンプレミス・第三者クラウドでは有効な Oracle Linux Basic または Premier Support 契約が必要。Free Tier インスタンスでは利用できない

内部の仕組み

横にスクロール

各ホストのエージェントが、インストール済みパッケージと利用可能な更新を定期的に検出し、結果を OS Management Hub サービスへ報告します。サービス側はこれを集約してコンプライアンス状態を算出し、コンソール／API でフリート横断のビューを提供します。パッチ適用や更新の実行は、サービスからエージェントへ指示が降り、エージェントが対象ホスト上でパッケージマネージャー（Linux なら RPM 系のパッケージ管理）を呼び出して行います。

• 配信経路の二系統が要点です。
  • パブリックに到達できるインスタンスは、ソフトウェアソース（リポジトリ）から直接更新を取得できる
  • インターネット非接続のインスタンスは、管理ステーションをプロキシ兼ミラーとして経由し、内部ネットワーク内で更新を受け取る
• ソフトウェアソースで配布内容を固定できます。カスタムソフトウェアソースに許可するパッケージとバージョンを定義し、ライフサイクル環境のステージへ割り当てることで、環境ごとに何が入るかを統制します。
• ライフサイクル環境を使うと、同じ更新セットを開発から本番へ段階的に昇格でき、検証していない更新が本番へ流れ込むのを防げます。

設計パターン / ベストプラクティス

• グループ＋スケジュールジョブでメンテナンスウィンドウを実装: フリートをグループ化し、深夜帯のスケジュールジョブで一括適用する。再起動を伴う更新は対象を分割し、可用性を保ちながらローリングで回す
• ライフサイクル環境で段階適用: 開発→テスト→本番の順に同じ更新を昇格させ、問題があれば本番到達前に止める
• カスタムソフトウェアソースでバージョン固定: 本番に入れてよいパッケージ・バージョンを明示し、構成ドリフトと想定外のメジャー更新を防ぐ
• 外部環境は配信経路を明示: オンプレミスや第三者クラウドで通信の集約やローカルミラーが必要なら管理ステーションを置き、内部経由で更新を配信する。可用性が要るなら冗長性も検討する
• コンプライアンスを定期レビュー: 非準拠インスタンスの一覧を定期的に確認し、未適用のセキュリティ更新を運用 KPI として追う
• 段階ロールアウトで影響を局所化: まず少数のホストへ適用して安定を確認し、問題なければ残りへ展開する

運用・監視

• インスタンスが管理対象に出てこない: エージェント（OS Management Hub プラグイン）が有効か、サービスエンドポイントへ到達できるネットワーク経路と IAM ポリシーがあるかを確認する
• 更新が検出・適用されない: ソフトウェアソースが正しく割り当てられているか、プライベート環境なら管理ステーション経由の経路が機能しているかを点検する
• 適用後の不具合: ライフサイクル環境の前段ステージで再現するか確認し、カスタムソフトウェアソースで問題バージョンを除外してから再展開する
• 可観測性の連携: ジョブ結果・イベントはサービス画面やAPIで確認し、構成変更の監査証跡は OCI Audit で追う。長期監査が必要な履歴は90日より前に外部へ保存する
• 管理ステーションの健全性: ミラーの同期状況・ディスク使用量・到達性を監視し、配信が滞らないようにする

コスト

OS Management Hub サービス自体は無料です。OCI Compute では追加料金なしで利用でき、管理ステーション用 Compute、ミラー用ストレージ、通信などの周辺資源には通常どおり料金が発生します。オンプレミス・第三者クラウドの Oracle Linux を管理する場合は、別途有効な Oracle Linux Basic または Premier Support 契約が必要です。

セキュリティ

• IAM ポリシーで最小権限: パッチ適用やソフトウェアソース管理など、操作種別ごとに必要なグループ／動的グループへ限定して権限を付与する
• 動的グループ＋インスタンスプリンシパル: エージェントの認証に長期キーを埋め込まず、インスタンスプリンシパルで認証させる（AWS の IAM ロール相当）
• 配布内容の統制でサプライチェーンを守る: カスタムソフトウェアソースで許可パッケージを明示し、想定外のリポジトリや未検証バージョンの混入を防ぐ
• セキュリティ更新の優先適用: コンプライアンス評価を使い、脆弱性に対応する更新を優先してフリートへ展開する。重大度の高い未適用更新を放置しない
• 役割分担: 「何を適用したか」の操作監査は OCI Audit、実行ログは OCI Logging が担う。OS Management Hub 自体は適用と状態管理にフォーカスする

Well-Architected の観点

• 運用上の優秀性（operational）: パッチ適用をスケジュール化・標準化し、フリート横断でコンプライアンスを定量把握できる。手作業の SSH 運用から、繰り返し可能で監査可能なプロセスへ移行できる
• セキュリティ（security）: セキュリティ更新を漏れなく追跡・適用し、配布内容をカスタムソフトウェアソースで統制することで、脆弱性の放置と未検証パッケージの混入リスクを下げられる
• ライフサイクル環境による段階適用は、変更を本番に入れる前に検証する運用と相性がよく、可用性への影響を抑える助けになる

試験で問われるポイント

関連サービス・比較

OS Management Hub は OS レイヤーの運用を担い、メトリクス監視・通知・監査・ログ収集はそれぞれ別サービスが分担します。AWS では Systems Manager がパッチに加え多機能を内包しますが、OCI では OS 運用に焦点を当てたサービスとして整理されています。

ハンズオン / CLI例

# 1) 管理対象インスタンスのグループ（フリート単位）を作成
oci os-management-hub managed-instance-group create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "prod-linux-fleet" \
  --os-family "ORACLE_LINUX_9" \
  --vendor-name "ORACLE" \
  --arch-type "X86_64"

# 2) グループ内のインスタンス一覧を確認（管理対象として認識されているか）
oci os-management-hub managed-instance-group list-managed-instances \
  --group-id "$GROUP_OCID"

# 3) グループ全体へ利用可能な更新を一括適用（ジョブとして実行）
#    再起動を伴う更新は対象や時間帯を絞り、ローリングで回すのが安全
oci os-management-hub managed-instance-group update-all-packages \
  --group-id "$GROUP_OCID"

# 4) フリートのコンプライアンス状況を取得（未適用更新の有無を把握）
oci os-management-hub managed-instance list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query "data.items[].{name:\"display-name\",status:\"status\"}"