Compartilhamento de volumes de disco em todos os convidados do OpenVZ para reduzir a sobrecarga de gerenciamento de pacotes

Question

É possível criar um único convidado "mestre" do OpenVZ que seria usado apenas para o gerenciamento de pacotes, e usar algo como mount --bind em vários outros convidados do OpenVZ para transformá-los em um ambiente instalado pelo guest principal?

O objetivo disso é que os usuários possam manter seus próprios contêineres e, ao mesmo tempo, permanecer sincronizados com o ambiente mestre de desenvolvimento. Assim, eles sempre terão os mais recentes & maiores exigências sem se preocupar muito com a administração do sistema. Se eles precisarem instalar seus próprios pacotes, poderiam colocá-los em / opt ou / usr / local (ou definir um caminho para seu diretório pessoal)?

Para reformular, eu gostaria de vários convidados do desenvolvedor (por exemplo) OpenVZ cujos / bin, / usr (e assim por diante ...) realmente se referissem ao mesmo local de disco de um convidado master OpenVZ que pode ser iniciado até instalar e atualizar pacotes comuns para o ambiente a ser compartilhado por todo este grupo de convidados do OpenVZ.

Por que vale a pena, estamos usando o Debian 6.

Editar:

Eu tentei montar (bind e readonly) / bin, / lib, / sbin, / usr desta forma e ele se recusa a iniciar os containers informando que os arquivos já estão montados ou em uso:

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]

Se eu desmontar esses quatro volumes e iniciar o convidado e montá-los depois que o convidado tiver iniciado, o convidado nunca os verá montados.

    

Answer 1

Com base nos comentários, a questão é um pouco diferente do que eu (e talvez outros) esperavam: o uso de "manter" não se relaciona com os pacotes dentro dos contêineres, mas com sua configuração individual.

Isso torna o processo mais difícil, mas ainda é possível. Por exemplo:

Montando os diretórios

Como você disse, você precisará compartilhar uma montagem para os binários (como /usr/bin ), que seria o primeiro passo para garantir que eles possam compartilhar todos os pacotes - isso permitirá que os binários instalados sejam prontamente disponível para todos os outros recipientes.

Você precisa garantir que quando você mount --bind fizer isso no diretório ROOT no arquivo /etc/vz/<veid>.conf apropriado.

Por exemplo, mount --bind /some/mount/point/bin /vz/root/1/bin

Também é essencial que essas montagens estejam limpas (como garantir que elas estejam lá depois que a máquina for inicializada pela primeira vez?). Para fazer isso, o OpenVZ oferece ganchos de início e parada na forma de scripts. Supondo que você esteja trabalhando em /etc/vz/conf , você pode ter:

• /etc/vz/conf/<veid>.mount - este é o gancho inicial: chamado assim que o contêiner estiver sendo executado
• /etc/vz/conf/<veid>.umount - este é o gancho de parada: chamado assim que o contêiner tiver desligado

Seus nomes são derivados de suas definições técnicas: o OpenVZ monta /vz/private/<veid> em /vz/root/<veid> , então é isso que ele está enganchando (assumindo os diretórios padrão).

Configuração

Nos comentários, você perguntou que uma vantagem seria configurar o servidor deles de acordo com o gosto deles (por exemplo, mysql.cnf ou httpd.conf / apache2.conf ). O único problema que pude ver com isso é que você precisa garantir que, ao instalar os pacotes, esses arquivos de configuração estejam configurados dentro de cada um dos contêineres. Você pode tentar compartilhar um compartilhamento de cópia na gravação .

O problema com isso é exatamente quais diretórios para compartilhar. Apache em /etc/httpd e MySQL em /etc/mysql - então você precisa ter certeza de que copiou esses arquivos de estoque ou essa idéia não funcionará. Pessoalmente, eu inspecionaria os arquivos .deb que são instalados pelo administrador do pacote 'global' e extraia os diretórios que não são compartilhados em contêineres individuais. Mas, esta é apenas uma maneira única de fazê-lo - tenho certeza de que existem mais alguns.

Pegadinhas

Uma coisa que eu descobri é que você pode simplesmente substituir os binários e bibliotecas que vêm com um pacote, mas você precisa observar se o gerenciador de pacotes reinicia ou não os serviços depois de instalá-lo

Erro no seu post

Você está montando em private , você precisa montar no diretório /var/lib/vz/root/1102/bin (supondo que é para onde a raiz aponta no arquivo .conf do seu vz).

    

Answer 2

Jay tem a resposta correta para implementá-lo, como você pergunta, mas não tenho certeza se deseja atualizar os contêineres das pessoas enquanto o material está em execução.

Eu acho que você ainda quer montar diretórios do sistema como somente leitura em seus contêineres, mas você quer versionar esses diretórios do sistema e deseja que eles instalem seu próprio software em seu diretório home ou em algum lugar que esteja ligado a ele fora de seus recipiente.

Quando o usuário deseja a versão mais recente, você deve recriar a CT usando o modelo atualizado. Cada vez que você atualiza, você pode salvá-lo como um modelo de CT. Isso mantém seus sistemas estáveis, mas eles podem solicitar uma atualização a qualquer momento.