Файловая система Docker – совместимость с символическими ссылками

Вопрос выделен жирным шрифтом, если вы хотите пропустить объяснение нашей ситуации.

Я работаю разработчиком для серверной сети. Мы развертываем несколько экземпляров наших серверов. мы имеем 5 типов типов серверов и 3-5 экземпляров каждого из них. Мы используем автономный сервер с API для разработки надстроек. Каждый тип сервера имеет другой набор дополнений, которые требуются.

В настоящее время мы используем структуру папок и запускаем экземпляры вручную:

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

и т.д…

Каждый из этих экземпляров имеет папку с именем module \ и внутри этой папки у нас есть файлы jar (система работает на Java)

Каждый раз, когда мы добавляем обновления, мы должны копировать их во все экземпляры серверов, на которых требуется дополнительное дополнение. Мы хотим использовать символические ссылки (ln -s) и хранить только один экземпляр каждого дополнения. Это было бы идеально, за исключением того, что мы хотим перейти к управлению виртуальными экземплярами. Мы отсортировали несколько вариантов, и Docker, похоже, подходит для наших потребностей лучше всего, поскольку он встроен в систему балансировки нагрузки.

Большинство виртуальных платформ также виртуализируют файловую систему, например, большинство виртуальных машин создадут файл, содержащий всю информацию о файле.

Вопрос в том, делает ли Docker виртуализацию файловой системы или монтирует экземпляр из исходной файловой системы Ubuntu? Я знаю, что Docker использует LXC, когда он доступен, однако я не очень знаком с тем, как работает LXC, и если символические ссылки могут работать между экземплярами. Если он делает виртуализацию, то это означает, что sym-ссылки не будут вариантом. Если это так, мы не будем использовать Docker, потому что для эффективности системы, которые сохраняют файловую систему в один файл или набор файлов, также увеличивают количество записей на жесткий диск, так как файл необходимо переписать для любых изменений, а экземпляры сервера могут быть довольно большими (несколько GB).

Я не уверен, правильно ли я понял вашу проблему, но с Docker вы можете смонтировать каталог из хост-системы внутри файловой системы гостевой / виртуальной системы. Вы можете установить один и тот же каталог с хоста на несколько гостевых систем. Вы можете найти более подробную информацию здесь: https://docs.docker.com/userguide/dockervolumes/

Он должен работать следующим образом:

 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 ... 

Здесь /home/shared/addon/ является общим для экземпляров, внутри каждого экземпляра его можно получить в /usr/local/addon/ , и экземпляры могут читать только его ( ro ). Вам даже не нужно ln -s .

Это единственный возможный способ сделать это, в документах есть более сложные параметры.

Позвольте мне поделиться своим опытом здесь. Докер, похоже, не справляется с символическими ссылками. Я смонтировал мой реальный каталог директору контейнера обычным способом (EXTERNAL_DATA – это переменная среды для ясности: say / data / projectA):

 -v $EXTERNAL_DATA:/docker/data 

У меня есть символический связанный файл, если вы смотрите из внешнего вида

 symlink_file -> /data/projA/somereal_file.txt 

Когда вы войдете в контейнер, команда ls покажет его точно, если вы набрали команду за пределами контейнера. Файл somereal_file.txt находится в том же каталоге, что и файл symlink_file

Вы можете получить доступ к реальному файлу, но вы получите сообщение об ошибке, если попытаетесь использовать символическую ссылку.

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

Я обнаружил это при переносе одного из моих приложений в контейнер докеров. Не уверен, что это дефект дизайна докера, или есть способы обойти это без перезаписи оригинального приложения, чтобы справиться с этой особой ситуацией. Даже вы можете изменить приложение, это не лучший способ справиться с этой проблемой.

Должны ли мы называть это фундаментальным недостатком символической ссылки докера?