Как я могу скопировать псевдонимы моего домашнего каталога в Docker, поскольку ~ не работает?

Question

В моем Dockerfile ...

Я могу скопировать файлы, которые я переместил в мой каталог, в котором я нахожусь, например,

COPY docker_files/.bash_aliases /root/

, но как мне обратиться к моему дому?каталог, то есть "~"

COPY ~/.bash_aliases /root/

, как при использовании "~", я получаю:

Step 5/6 : COPY ~/.bash_aliases /root/
COPY failed: stat /var/snap/docker/common/var-lib-docker/tmp/docker-builder645558599/~/.bash_aliases: no such file or directory

Я хочу избежать жесткого кодирования моего имени пользователя.
Может быть, я должен использовать $ USER или $ USERNAME не уверен

Answer 1

Как упоминалось в другом ответе, ваш домашний каталог, скорее всего, не включен в контекст сборки.Кроме того, команда Docker COPY поддерживает только подстановочные знаки, поддерживаемые Golangs filepath.Match, см. здесь

В качестве альтернативы COPY использованию bash_aliases в вашем Dockerfile, я бы сказал, чтоесли возможно, вы просто монтируете их как том при запуске контейнера.

т.е.:

$ docker run -v ~/bash_aliases:/root <image>

Если вы непланируя распространить этот образ Docker среди других членов группы, вы можете включить монтирование тома в файл docker-compose.

Answer 2

Единственные файлы, доступные Docker при создании образа, - это файлы в контексте сборки . Как правило, это каталог, содержащий Dockerfile и все его подкаталоги. Кроме того, обычно это не будет включать ваш домашний каталог ~, поэтому копировать файлы оттуда не имеет смысла.

Возможно, самое простое решение - сначала скопировать файлы в каталог, содержащий Dockerfile (вне процесса сборки Docker), а затем использовать относительный путь в вашем Dockerfile.

---

Как более конкретный ответ на ваш конкретный вопрос, Докер не понимает ~, и вы можете заменить его на /home/mdurrant. Но это не решает проблему сохранения независимости от пользователей. Если вы сделали «сценарий bash перед сборкой» или что-то подобное, вы можете скопировать с ~/.bash_aliases на ./bash_aliases (или что-то подобное). Но в этом случае я бы сказал, что это плохая практика, так как это изменит встроенный образ в зависимости от того, кто его создает и какие у них файлы.