Docker не поддерживает символические ссылки в каталоге сборки

Вопрос: Я Dockerizing приложение, которое предполагает связывание двоичных файлов с другими C файлами через Clang. Мы поддерживаем символическую версию двоичных файлов, поскольку они используются во всей кодовой базе. Мой Docker построить каталог содержит все это кодовый (включая исходные файлы, а также символические ссылки на эти исходные файлы), и Докер распознает эти файлы, когда я делаю

Вопрос:

Я Dockerizing приложение, которое предполагает связывание двоичных файлов с другими C файлами через Clang. Мы поддерживаем символическую версию двоичных файлов, поскольку они используются во всей кодовой базе. Мой Docker построить каталог содержит все это кодовый (включая исходные файлы, а также символические ссылки на эти исходные файлы), и Докер распознает эти файлы, когда я делаю такие вещи, как cat [symlinked_file] (то есть файл cat – й изд правильно). Тем не менее, он не связывает файлы с символикой, когда я запускаю свои команды Clang в моем Makefile (они отлично работают в Docker). Затем я скопировал оригиналы в каталог, где символические ссылки, заменяя символические ссылки, а Docker не выдавал никаких ошибок при сборке.

Кто-нибудь знает, как обойти это? Есть ли какие-то специальные команды, которые мне нужно дать Докеру или Клану здесь? Я не уверен, почему Clang ведет себя по-другому в контейнере Docker, чем за его пределами. Я использую базовое изображение Ubuntu 16.04 для справки.

Ответ №1

Docker будет работать с символическими ссылками (по крайней мере, при создании на моем Linux-хосте), но цель symlink должна быть в контексте сборки. Этот контекст передается движку докера, и сборка происходит на этом сервере внутри контейнеров, поэтому любая ссылка на файлы вне этого контекста не будет разрешаться:

$ ls -al total 8 drwxr-xr-x 2 bmitch bmitch 4096 Mar 2 21:08 . drwxr-xr-x 13 bmitch bmitch 4096 Mar 2 21:07 .. lrwxrwxrwx 1 bmitch bmitch 11 Mar 2 21:08 outside.txt -> ../test.out lrwxrwxrwx 1 bmitch bmitch 10 Mar 2 21:08 source.txt -> target.txt -rw-r—r— 1 bmitch bmitch 0 Mar 2 21:08 target.txt $ cat Dockerfile FROM busybox COPY . /build-context WORKDIR /build-context CMD find . $ docker build -t test-symlink . Sending build context to Docker daemon 3.584 kB Step 1/4 : FROM busybox —> 7968321274dc Step 2/4 : COPY . /build-context —> 8238dac16669 Removing intermediate container dd653dfdf7a4 Step 3/4 : WORKDIR /build-context —> c1850cb52f0e Removing intermediate container 7ee87e20d525 Step 4/4 : CMD find . —> Running in e710e965d98c —> fd57eb8f426b Removing intermediate container e710e965d98c Successfully built fd57eb8f426b $ docker run test-symlink . ./outside.txt ./Dockerfile ./source.txt ./target.txt $ docker run -it —rm test-symlink /bin/sh /build-context # ls -al total 12 drwxr-xr-x 2 root root 4096 Mar 3 02:09 . drwxr-xr-x 20 root root 4096 Mar 3 02:09 .. -rw-r—r— 1 root root 69 Mar 3 02:08 Dockerfile lrwxrwxrwx 1 root root 11 Mar 3 02:08 outside.txt -> ../test.out lrwxrwxrwx 1 root root 10 Mar 3 02:08 source.txt -> target.txt -rw-r—r— 1 root root 0 Mar 3 02:08 target.txt /build-context # cat outside.txt cat: can’t open ‘outside.txt’: No such file or directory /build-context # cat target.txt /build-context # exit Ответ №2

Недавно я столкнулся с той же проблемой. После много исследований и испытаний, вот что я нашел из команды Docker…

Да, мы решили не следовать символическим ссылкам на сборку докеров из-за несогласованных результатов, которые могут возникнуть в разных системах.

В принципе, это не особенность, которая наступает.

Здесь у меня была структура папок. Два репозитория, которые находятся на одном уровне каталогов.

/cms-code /cms-themes

Я хотел, чтобы symlink /public folder внутри /cms-code в папку /cms-themes. И при создании Dockerfile внутри /cms-code на COPY или ADD Dockerfile папку в изображение. К сожалению, все, что я получил, это символическая ссылка, скопированная в образ/контейнер, но не содержание.

Параметры, как я их вижу:

  1. Создайте сценарий bash/sh, чтобы скопировать файлы в публикацию после установки обоих репозиториев. [Не способствует активной разработке или обновлению при изменении файла]
  2. Используйте систему подмодулей Git для перемещения моего репозитория cms-themes в /public папку репозитория /cms-code. [Не подходит для моей конкретной ситуации]
  3. Используйте docker-compose для установки /public папки в /cms-code для синхронизации с моим каталогом хостов /cms-themes. [Это, в конечном счете, то, что я выбрал. Он все еще не идеален, но он работает. Контейнер CMS (после запуска) видит все содержимое /public которые на самом деле являются файлами в /cms-themes.

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

UPDATE – добавление ссылки на файл для компоновки как Gist: https://gist.github.com/sgelliott/191c681ebb261c6a36ecd5fb70eb0176

Оцените статью
Добавить комментарий