Proxmox Offline Mirror とは？ 〜オフライン更新の仕組み〜

-

0. はじめに

Proxmoxを導入したお客様から、

Proxmox Offline Mirror（POM）を構築したいという案件相談がありました。

その際に調べた内容を、備忘も兼ねてまとめています。

少しニッチ?!な内容ではありますが、

POMに関する日本語情報がほとんど見当たらなかったため、

同じような構成を検討している方の参考になればと思います。

※今回は概要レベルの内容になります。

1. Proxmox Offline Mirror（POM）とは

Proxmox Offline Mirror（POM）は、

インターネットに直接接続できない環境において、

  • Proxmox VE

  • Proxmox Backup Server

  • それらに関連する Ceph パッケージ

の 更新およびサブスクリプション認証 を実施させるための仕組みです。


POMは、

Proxmox Server Solutions が公開しているツール群を用いて構成されており、

  • 公式リポジトリから取得したパッケージやメタデータを一度集約

  • オフライン環境向けに再配布可能な形へ変換・管理

する役割を担います。


単なるパッケージのコピーではなく、

以下のような仕組みを オフライン環境でも成立させる 点が特徴です。

  • 公式リポジトリからの取得

  • GPG署名を含むパッケージ整合性の維持

  • サブスクリプションの認証

  • snapshot を用いたパッケージの更新管理

2. どんな環境で POMが必要になるのか（ユースケース）

POMは、すべての Proxmox 環境で必要になるわけではありません。

一方で、以下のような環境では

ほぼ必須コンポーネントになります。

■ エアギャップ（隔離）環境

  • セキュリティポリシー上、外部インターネット接続が禁止されている環境

■ 拠点分散・閉域網環境

  • 本社 DC から各拠点へ閉域網で接続している構成

■ 更新タイミングを厳密に管理したい環境

  • 本番環境で

    • 「いつ更新したか」

    • 「どの状態で動いているか」を明確にしたい

  • トラブル発生時に即座に元へ戻したい

3. POMを導入するメリット

上記のような環境において、

POMを導入することで以下のメリットが得られます。 

※2.の内容と重複する部分もありますが

① オフライン環境でも公式更新を継続できる

POMを通じて取得・配信されたリポジトリを参照することで、

オフライン環境でも通常どおりが実行可能になります。

これは「独自リポジトリ」ではなく、

公式リポジトリを内部に持ち込んでいるという点が重要です。

② 更新状態をsnapshot単位で管理できる

POMでは、取得したリポジトリ状態を

snapshotとして保持できます。

  • 更新前の状態

  • 更新後の状態

  • 安定稼働が確認できた状態

これらを明確に分けて管理できるため、

問題発生時の切り戻しが現実的な運用になります。

③ 更新判断を中央集約できる

各Proxmoxノードが勝手に更新するのではなく、

  • どのsnapshotを配信するか

  • いつ配信を切り替えるか

を POM 側で制御できます。

4. POMを構成する主要コンポーネント

POMは、

単一の機能ではなく、役割が明確に分離された複数のコンポーネントで構成されています。

この構成を理解することが、

POMを「単なるミラー」ではなく

運用基盤として正しく扱うための第一歩になります。


4.1 POM Server（Mirror管理ノード）

POM Server は、POM 全体の中核となるノードです。

主な役割は以下の通りです。

  • Proxmox 公式リポジトリへのアクセス

  • パッケージおよびメタデータの取得

  • snapshot の作成と管理

  • サブスクリプションキーの登録・検証

ここで重要なのは、

POM Serverは「配信ノード」ではなく「管理ノード」

という点です。

4.2 Mirror領域（データ実体）

Mirror領域は、

公式リポジトリから取得した すべてのデータの実体を保持します。

特徴は以下の通りです。

  • 複数リポジトリ間で共通するファイルはハードリンクで集約

  • snapshot単位で状態を固定

Mirror は、

「取得した実体を保存する場所」です


4.3 Snapshot（世代管理単位）

Snapshot は、

Mirror領域の ある時点の状態を固定化した論理的な単位です。

  • 更新前後の状態を明確に分けられる

  • 問題発生時に即座に切り戻し可能

  • Mediumはsnapshotを参照するだけ


4.4 Medium領域（配信ビュー）

Medium 領域は、

Mirror上の snapshotを 外部に公開するための参照ビューです。

  • 実体データは持たない

  • medium syncによりsnapshotが反映される

  • HTTP/NFSなどで公開可能

4.5 クライアントノード（PVE / PBS）

クライアントノードは、

POMが提供するMediumをapt ポジトリとして利用する側です。

  • Proxmox VE

  • Proxmox Backup Server

  • （構成によっては Ceph 関連ノード）

クライアントは、

Mirrorやsnapshot を直接意識する必要はありません。

POMサーバーの利用イメージとMirro/Snapshot/Mediumの関係性
※ChatGPT5.2による図の生成


小話：技術用語としての「Medium」に戸惑った話

POM を触り始めた当初、

「Medium」という用語に少し戸惑いました。

日本語の感覚だと

Small / Medium / Large のサイズ区分を連想してしまい、

「なんでここで “中間” が出てくるんだ？」

と正直思いました（笑）

ですが、ここでの Medium は

Media（媒体）の単数形として使われていることを調べて知りました

  • Mirror: 取得したデータの保管庫

  • Medium: それを外部へ提供するための「媒体」

この意味を理解してから、整理された気がします。

5. 推奨システム要件（目安）

POM を安定して運用するための、

推奨システム要件の目安は以下の通りです。

■ CPU

  • 64bit x86（x86-64 / AMD64）

  • 2コア以上推奨

■ ストレージ

  • 必要容量は構成に依存

  • 実運用では

    • 100GB以上

    • 構成によっては 150GB以上 を想定

■ ファイルシステム

  • 以下の ハードリンク対応ファイルシステムが必須

    • ext4

    • xfs

    • zfs

  • FAT/NTFSなどの Windows系ファイルシステムは使用不可

6. Proxmox Offline Mirror 構築の全工程フロー

ここからは、

Proxmox Offline Mirror（POM）構築の全体フローを

ステップごとに整理します。

ステップ 1: システム要件の確認

ステップ 2：リポジトリのセットアップとインストール

POM をインストールするための準備を行います。

  1. 署名キーの取得

    • インストール先が既存の Proxmox環境でない場合

    • Proxmoxのリリースキーをダウンロードし、信頼設定を実施

  2. リポジトリの追加

    • pbs-clientリポジトリなどをAPTのソースリストに追加

  3. ツールのインストール

    • 指定されたコマンドを用いてPOM本体をインストール


ステップ 3：サブスクリプションの準備（重要）

Enterpriseリポジトリ（商用版）を

ミラーリングしたい場合は、この段階でキーの設定が必要です。

  1. POM自身の有効化

    • key add-mirror-key <キー> コマンドを使用

    • ミラーサーバー自身のサブスクリプションをアクティベート

  2. クライアントキーの登録

    • オフライン環境で使用する各ノードの

      • サーバー ID

      • サブスクリプションキー

        を登録し、認証情報を取得

ステップ 4：ストレージの準備（Mirror / Medium）

ここで、

データの保存先（Mirror）と配信先（Medium）の準備を行います。

  • ハードリンクのサポート

    • 使用するファイルシステムは

      ext4 / xfs / zfs など、ハードリンク対応が必須

    • FAT などの Windows 系ファイルシステムは使用不可

  • 分離とマウント

    • Mirror用とMedium用のディスク

      （またはパーティション）を分離

    • それぞれ適切なディレクトリにマウント

ステップ 5：リポジトリのミラーリング（取得）

  1. ミラー設定の作成

    • config mirror add を使用

    • どのリポジトリを、どのディレクトリ（base-dir）に保存するか定義

  2. スナップショットの作成

    • mirror snapshot create を実行

    • 公式サーバーからパッケージをダウンロード

ステップ 6：配信メディアへの同期（書き出し）

  1. メディア設定の作成

    • config media add を使用

    • どの snapshot を、どのマウントポイントに同期させるか定義

  2. 同期の実行

    • medium sync を実行

    • Mirror 領域から Medium 領域へデータを同期

    • （ハードリンクによる容量効率化を含む）

ステップ 7：オフライン環境での利用

  1. 媒体の搬送

    • 同期した外付け HDD やWebサーバーを立てオフライン環境のノードへ接続

  2. クライアント側の設定

    • オフライン側ノードで

      proxmox-offline-mirror-helper setup を実行

    • リポジトリの参照先やサブスクリプションキーを設定

さいごに

Proxmox Offline Mirror（POM）の概要は掴めたでしょうか？

POMはエアギャップ環境ではほぼ必須のサーバーとなりますので、

以下の特徴を把握していただけレバと思います。

  • Mirror / Snapshot / Medium の役割分離

  • snapshot を用いた世代管理

  • 更新判断の中央集約


今後、実際の運用を進める中で

また気づきがあれば追記していきたいと思います。

場所: マダガスカル

コメント

コメントを投稿

このブログの人気の投稿

ProxmoxでLet's Encryptを使用した証明書セットアップをやってみた

-
イメージ
■はじめに Proxmoxはデフォルトで自己証明書を使用しています。 このため、管理コンソールにアクセスすると「接続がプライベートではありません」といった画面が表示されます。 これの対処方法の一つとして、Let's Encryptを使用して簡単に証明書がセットアップできるとのことで、実際にやってみた内容を紹介したいと思います。 ■前提 ・自宅のProxmox環境（シングル構成）で実施 ・証明書取得時に使うのはDNS-01チャレンジ 　　HTTP-01チャレンジはWebサーバーを公開する必要があるためパス ・ハードル低めの（APIが使える）DNS Providerからドメインを取得して使用 　　下記の中からCloudflareをDNS Providerとして選択 　　　 How to use DNS API wiki ■手順概要 Cloudflareのアカウント作成～証明書反映まで、ということで実施内容としては下記となりました。 ＝＝＝＝＝ 1.Cloudflare アカウントの作成 2.Cloudflare ドメイン取得 3.Cloudflare アカウント APIトークンの作成 　　- ゾーン DNS を編集する権限を持つAPIトークンを作成 4.Cloudflare アカウント IDの取得 　　- ProxmoxのChallengeプラグインに投入するパラメータの取得 5.Proxmox ACME アカウントの追加 　　- 連絡先登録と利用規約への同意 6.Proxmox Challengeプラグインの追加 　　- Cloudflareのパラメータを投入 7.Proxmox ACME ドメインの追加 　　- 取得したいドメイン（FQDN）を設定 8.Proxmox 証明書の取得 　　- 証明書取得処理を手動開始 ＝＝＝＝＝ ■実施手順 1.Cloudflare アカウントの作成 Cloudflareのサイトにアクセスして画面右上の「ログイン」をクリックします。 　https://www.cloudflare.com/ja-jp/ ログイン画面に遷移するので、下部にある「サインインアップ」をクリックします。 登録するメールアドレスとパスワードを入力、ロボットでないこと確認にチェックを入れて「サインアップ」をクリックします。 アカウントが作成されます。 登録...
続きを読む

AIと共に「考える」エンジニアに！

-
イメージ
 ― ChatGPT時代に問われる「問いの力」と文章力 ― はじめに ChatGPTをはじめとする 生成AI が普及しはじめてから、もう2年近くが経ちました。   リリース当初は「すごい技術だな」と遠目から眺めている空気でしたが、今では多くの人がAIに触れる機会を持つようになりました。    我々 ITエンジニアとして 、アプローチはどうすべきか？何が必要か？について考えてみます。 AI利用の現状 まだAIを使い始めたばかりだったり、上手く使えてない人は、「このエラーを解決して」「この機能を実装して」と 指示を出すだけ になっているようです。   あるいは、「〇〇とは？」を丸ごとAIに聞いて解説してもらうケースも見られます。　便利ですが、それだと Google検索 と同じレベルに留まっていると感じます。 AIの本当の価値 私は、AIは 単なるコード生成ツールでも、Googleの上位互換でもない と考えています。   むしろ、使い方を間違えると取り残されていく可能性があります。  AIが本当に得意なのは、与えた問いに沿って 思考の幅を広げ、情報を整理すること です。   つまり、AIを活かすには、 問いを設計する力 が不可欠なのです。 問いを設計する力はAI以前からのビジネススキル 実は、問いを設計する力は、AIが登場する以前から、私たちエンジニアが日常的に使ってきたスキルです。   例えば、プロジェクトの課題を整理したり、仕様の確認事項を明確化したり、メールでの問い合わせの内容を意図通りに伝えたりなど...　いずれも、 相手や状況に応じて適切に問いを設計する力 がベースになっていました。   AIは文章やアイデアを生成してくれますが、 何を考えるべきかは教えてくれません 。だからこそ、この問いを設計する力がAI時代でも重要になるのです。 コンテキストエンジニアリング さらに最近は、単なるプロンプトの工夫（プロンプトエンジニアリング）だけでなく、文脈や前提を整理して問いを設計する「 コンテキストエンジニアリング 」が注目されています。   コンテキストエンジニアリングとは、単に「良いプロンプト...
続きを読む

ルーティングって何で必要で、何してるの？を React Routerで理解する

-
イメージ
はじめに フロントエンド開発が、正直苦手でした。 でも今回のプロジェクトでReactを触ることになり、「せっかくなら苦手意識を克服したい」と一念発起。 開発は終わりましたが、学習は継続しています。 Reactには多くの要素がありますが、今回はルーティングに絞ります。 バージョンの違いで書き方が変わり対応に戸惑ったこともあり、基本から振り返りつつ理解していった流れを記事にしたいと思います。 そもそもルーティングって何のために必要なの？ まず基礎の基礎になりますが、URL、ブラウザ、SPAの観点から振り返ります。 URLとは？ Uniform Resource Locator（統一資源位置指定子）の略語で、要するに「 インターネット上のモノの住所 」です。 https://example.com/products.html このようなURLの場合、ブラウザは、 URLを見る→( products.html というファイルが欲しいのだと解釈) サーバーにリクエストを送る HTMLファイル( products.html )をダウンロードして表示する つまり、URLは「どのファイルを取得するか」を指定する住所のようなものです。 ブラウザはURLで何をしているのか？ ブラウザにとってURLは「ページの識別子」です。 ブラウザは、URLをキーにして、いろんな機能を実現しています。      1. 履歴管理           URLが変わるたびに履歴に記録           「戻る」ボタンを押すと、履歴から1つ前のURLを取り出して、そのページに戻る           「進む」ボタンも同じ仕組み      2. ブックマーク           URLを保存することで、「このページ」を記憶           後でそのURLを開けば、同じページが表示される       3. URL共有...
続きを読む