2015-10-15 13 views
1

Мой вопрос в том, что происходит, когда вы создаете символическую ссылку из контейнера в каталоге, установленном узлом. Это проще всего, если я просто попрошу пример.Как символические ссылки в томе хоста работают в контейнерах Docker?

Предположим, что мы запускаем такой контейнер. Большая часть команды не имеет значения, что важно здесь для монтирования тома хоста.

docker run --rm -ti -h thecontainer -v /home/userguy:/container-home alpine /bin/sh 

В то время как в контейнере создать символьную ссылку в каталоге тома хоста

thecontainer$ ln -s /tmp /container-home/tmp-link 

В то время как в контейнере я могу ls /container-home/tmp-link и я вижу содержимое контейнера /tmp, как и ожидалось.

Теперь, если я вернусь к своей главной машине, я вижу ссылку /home/userguy/tmp-link -> /tmp. Если я ls, то в этом каталоге я вижу содержимое хоста/tmp. т. е. разные результаты.

Вопрос, как работают тома хостов под обложками, которые позволяют этой ситуации работать? Является ли это продуктом самого Docker или lxc? Я был удивлен, увидев эту работу, потому что мыслительные ссылки, указывающие на inodes и предполагаемые/tmp в контейнере, будут отличаться от/tmp на хосте.

ответ

1

Это часть уровня виртуальной файловой системы ОС. Символьная ссылка содержит имя, и VFS разрешает это имя динамически при обращении к символической ссылке.

Указатели на иноды называются ссылками, которые обычно называются «жесткими ссылками», чтобы отличать их от символических ссылок.

+0

Хорошо, я не был уверен, ссылается ли мягкая ссылка на индексный дескриптор. Таким образом, символические ссылки содержат только путь и этот путь разрешается во время чтения. Таким образом, поведение, которое я вижу, - это просто функция работы символических ссылок? –

+0

Это правильно. –

Смежные вопросы