パッケージ管理にのみ使用される単一の「マスター」OpenVZゲストを作成し、他のいくつかのOpenVZゲストでmount --bind
のようなものを使用して、マスターゲストによってインストールされた環境を使用するように仕向けることは可能ですか?
これのポイントは、ユーザーが独自のコンテナーを維持しながら、マスター開発環境との同期を維持できるようにすることです。これにより、システム管理についてあまり心配することなく、常に最新かつ最大の要件を満たせるようになります。独自のパッケージをインストールする必要がある場合は、それらを/ optまたは/ usr/localに配置できますか(またはホームディレクトリへのパスを設定できますか)?
言い換えると、/ bin、/ usr(など)が実際にインストールを開始できるマスターOpenVZゲストと同じディスクの場所を参照するいくつかの(開発者などの)OpenVZゲストが欲しいです。そして、OpenVZゲストのこのグループすべてによって共有される環境の共通パッケージを更新します。
その価値のために、Debian6を実行しています。
編集:
この方法で/ bin、/ lib、/ sbin、/ usrをマウント(バインドおよび読み取り専用)しようとしましたが、ファイルがすでにマウントされているか、使用中であることを示すコンテナーの開始を拒否します。
Starting container ...
vzquota : (error) Quota on syscall for id 1102: Device or resource busy
vzquota : (error) Possible reasons:
vzquota : (error) - Container's root is already mounted
vzquota : (error) - there are opened files inside Container's private area
vzquota : (error) - your current working directory is inside Container's
vzquota : (error) private area
vzquota : (error) Currently used file(s):
/var/lib/vz/private/1102/sbin
/var/lib/vz/private/1102/usr
/var/lib/vz/private/1102/lib
/var/lib/vz/private/1102/bin
vzquota on failed [3]
これらの4つのボリュームをアンマウントし、ゲストを起動し、ゲストの起動後にマウントすると、ゲストにはマウントが表示されません。
コメントに基づくと、質問は私(そしておそらく他の人)が期待したものとは少し異なります。「maintain」の使用は、コンテナー内のパッケージではなく、個々の構成に関係します。
これにより、プロセスがより困難になりますが、それでも可能です。例えば:
あなたが言ったように、バイナリのマウント(/usr/bin
など)を共有する必要があります。これは、すべてのパッケージを共有できるようにするための最初のステップです。これにより、インストールされたバイナリを簡単に共有できるようになります。他のすべてのコンテナで利用できます。
mount --bind
の場合、適切な/etc/vz/<veid>.conf
ファイルのROOT
ディレクトリでこれを行うようにする必要があります。
たとえば、mount --bind /some/mount/point/bin /vz/root/1/bin
これらのマウントがきれいであることも重要です(マシンが最初に起動した後にマウントが確実に存在するようにするにはどうすればよいですか?)。これを行うために、OpenVZはスクリプトの形式で開始フックと停止フックを提供します。 /etc/vz/conf
内で作業しているとすると、次のことができます。
/etc/vz/conf/<veid>.mount
-これは開始フックです:コンテナが実行されると呼び出されます/etc/vz/conf/<veid>.umount
-これはストップフックです:コンテナがシャットダウンすると呼び出されますそれらの名前は、技術的な定義に由来しています。OpenVZは/vz/private/<veid>
を/vz/root/<veid>
にマウントするため、これがフックされます(デフォルトのディレクトリを想定)。
コメントで、1つの利点は、サーバーを好きなように構成できることだと質問しました(例:mysql.cnf
またはhttpd.conf
/Apache2.conf
)。これで私が見ることができた唯一の問題は、パッケージをインストールするときに、これらの構成ファイルが各コンテナー内にセットアップされていることを確認する必要があることです。マウントを共有してみてください コピーオンライト 共有。
これに関する問題は、正確にwhichディレクトリを共有することです。 /etc/httpd
でApacheを実行し、/etc/mysql
でMySQLを実行します。したがって、これらのストックファイルをコピーする必要があります。そうしないと、このアイデアは機能しません。個人的には、「グローバル」パッケージ管理者によってインストールされた.deb
ファイルを調べて、個々のコンテナーに共有されていないディレクトリを抽出します。しかし、これはそれを行うための1つの方法にすぎません。他にもかなりの数があると確信しています。
私が思いついたのは、パッケージに付属しているバイナリとライブラリを直接置き換えることができるということですが、パッケージマネージャーがインストール後にサービスを再起動するかどうかを観察する必要があります
private
にマウントする場合は、/var/lib/vz/root/1102/bin
ディレクトリにマウントする必要があります(vzの.conf
ファイルでルートが指す場所であると想定しています)。
ジェイはあなたが尋ねるようにそれを実装するための正しい答えを持っています、しかしあなたがものが実行されている間に人々のコンテナをアップグレードしたいかどうかはわかりません。
システムディレクトリを読み取り専用としてコンテナにマウントしたいと思いますが、それらのシステムディレクトリをバージョン管理し、独自のソフトウェアをホームディレクトリまたはコンテナの外部からバインドマウントされた場所にインストールする必要があります。
ユーザーが最新バージョンを必要とする場合は、更新されたテンプレートを使用してCTを再作成する必要があります。アップグレードするたびに、CTテンプレートとして保存できます。これにより、システムは安定した状態に保たれますが、いつでもアップグレードを要求できます。