Sistema de arquivos 'Docker' - Compatibilidade com links simbólicos

Question

A pergunta é marcada em negrito se você deseja ignorar a explicação da nossa situação.

Eu trabalho como desenvolvedor para uma rede de servidores. Nós implantamos várias instâncias de nossos servidores. temos 5 tipos de tipos de servidores e entre 3 e 5 instâncias de cada um. Usamos um servidor autônomo com uma API para desenvolver complementos. Cada tipo de servidor tem um conjunto diferente de complementos necessários.

Atualmente, estamos usando uma estrutura de pastas e executando as instâncias manualmente, assim:

/servers
    /server1
        /instance1/.
        /instance2/.
    /server2
        /instance1/.

etc ...

Cada uma dessas instâncias tem uma pasta chamada module \ e dentro dessa pasta nós temos nossos arquivos jar (o sistema roda em Java)

Toda vez que nossas atualizações de complemento, precisamos copiá-lo em todas as instâncias dos servidores que o complemento é necessário. Queremos usar links simbólicos (ln -s) e armazenar apenas uma instância de cada complemento. Isso seria ideal, exceto pelo fato de que queremos passar para o gerenciamento de instâncias virtuais. Nós classificamos várias opções e o Docker parece ser o que melhor atende às nossas necessidades, com o sistema de balanceamento de carga integrado.

A maioria das plataformas virtuais também virtualiza o sistema de arquivos, por exemplo, a maioria das máquinas virtuais cria um arquivo que contém todas as informações sobre o arquivo.

A questão é, o Docker virtualiza o sistema de arquivos, ou monta a instância do sistema de arquivos nativo do Ubuntu? Estou ciente de que o Docker usa o LXC quando disponível, no entanto, não sou muito familiarizado com o funcionamento do LXC e se links simbólicos podem funcionar entre instâncias Se virtualizar, significa que sym-links não será uma opção . Se esse for o caso, não acabaremos usando o Docker, porque, para eficiência, os sistemas que salvam o sistema de arquivos em um único arquivo ou em um conjunto de arquivos também aumentam a quantidade de gravações no disco rígido, como o arquivo. precisa ser reescrito para qualquer alteração, e as instâncias do servidor podem ser bem grandes (vários GB).

    

Answer 1

Não tenho certeza se entendi corretamente o seu problema, mas com o Docker você pode montar um diretório do sistema host dentro do sistema de arquivos do sistema guest / virtual. Você pode montar o mesmo diretório do host para vários sistemas convidados. Você pode encontrar informações mais detalhadas aqui: link

Deve funcionar assim:

docker create --name=instance1 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance2 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance3 -v /home/shared/addon/:/usr/local/addon/:ro ...

Aqui /home/shared/addon/ é compartilhado entre as instâncias. Dentro de cada instância, ele pode ser acessado em /usr/local/addon/ e as instâncias só podem lê-lo ( ro ). Você nem precisa de ln -s .

Esta é apenas uma maneira possível de fazê-lo. Nos documentos, há opções mais avançadas.

    

Answer 2

Deixe-me compartilhar minhas experiências aqui. O Docker não parece manipular bem os links simbólicos. Eu montei meu diretório real para meu diretor de contêineres da maneira usual (EXTERNAL_DATA é uma variável de ambiente para maior clareza: digamos / data / projectA):

-v $EXTERNAL_DATA:/docker/data

Eu tenho um arquivo vinculado simbólico se você olhar de uma visão externa é

symlink_file -> /data/projA/somereal_file.txt

Quando você entra no container, o comando ls mostrará exatamente se você digitou o comando fora do contêiner. O somereal_file.txt está no mesmo diretório que o symlink_file

Você pode acessar o arquivo real, mas receberá um erro se tentar usar o link simbólico.

head symlink_file
head: cannot open 'simlink_file' for reading: No such file or directory

Descubro isso ao migrar um dos meus aplicativos para o contêiner docker. Não tenho certeza se essa é uma falha de projeto do docker ou se há maneiras de contornar isso sem reescrever o aplicativo original para lidar com essa situação especial. Mesmo você pode alterar o aplicativo, esta não é a melhor maneira de lidar com esse problema.

Devemos chamar isso de falha fundamental do link simbólico do docker?