#github #docker #dockerfile
#github #docker #dockerfile
Вопрос:
У меня есть файл на сервере, который содержит мой токен доступа для github. Я хотел бы сохранить токен доступа в текстовом файле, который вызывается при создании Dockerfile
Вот некоторый псевдокод, о котором я думал:
creds.sh
export GITHUB_CREDS mylongcred
Dockerfile
FROM some/image
RUN ../path/to/creds.sh
RUN install_github("my/repo", "$GITHUB_CREDS")
Очевидно, что это не работает. Теоретически, есть ли что-то неправильное в том, что вы видите здесь?
Выполняется ли она или, возможно, какая-то другая командная директива, которую я должен использовать для выполнения этого?
Обновления:
- Файл учетных данных находится за пределами области сборки (на один каталог позади)
- Dockerfile запускается с вызовом, который я не могу изменить напрямую, потому что он вызывается плагином jenkins
Комментарии:
1. Каждая команда RUN выполняется на разных уровнях, вы могли бы выполнить их одной командой RUN с помощью RUN /path/to/creds.sh amp;amp; install_github(… или вы могли бы использовать директиву ARGS в файле dockerfile
2. Вы пробовали
ENV
использовать директиву в вашем Dockerfile?
Ответ №1:
Для этого есть несколько возможных решений (однако ни одно из них не идеально).
1. Экспортируйте и запустите за один шаг
Как отмечено в комментариях @STLMikey, экспортированные переменные окружения не будут сохраняться от одного RUN
шага к следующему, поскольку они будут выполняться в двух разных промежуточных контейнерах. Вы можете обойти это, используя один шаг сборки:
RUN path/to/creds.sh amp;amp; install_github("my/repo", "$GITHUB_CREDENTIALS")
Помните, что она path/to/creds.sh
должна содержать что-то вроде export GITHUB_CREDENTIALS=<insert credentials here>
(имейте в виду =
, чего не было в исходном файле в вашем вопросе).
Предостережение: обратите внимание, что path/to/creds.sh
она будет включена в ваше изображение и видна всем, кто ее использует. Скорее всего, это не то, что вы хотите. Также помните, что rm
редактирование файла на этом шаге или более позднем шаге не поможет, поскольку файл учетных данных все еще будет присутствовать на родительском уровне. Это приводит нас к…
2. Шаг 1 Сжатие изображения
Используйте такой инструмент, как docker-squash, чтобы объединить все слои вашего изображения в один. Это позволяет удалять секретные файлы, которые были добавлены в процессе сборки, не оставляя их следов на одном из родительских слоев:
$ docker save <image-id> | docker-squash -t squash -verbose | docker load
Однако при выполнении этого вы потеряете все уровни вашей файловой системы, что затруднит эффективное использование результирующего изображения. Даже малейшее изменение приведет к совершенно новому изображению с одним большим слоем. Это также может быть не идеально. Что снова приводит нас к…
3. Переменные времени сборки
В официальной документации это решение не рекомендуется, а также продолжается обсуждение этого в Docker issue Tracker. Используйте это по своему усмотрению.
Предупреждение: не рекомендуется использовать переменные времени сборки для передачи секретных данных, таких как ключи github, учетные данные пользователя и т.д. Значения переменных во время сборки видны любому пользователю изображения с помощью
docker history
команды.
Для этого вы можете использовать переменные времени сборки, используя --build-arg
флаг. Для этого начните с определения аргумента в вашем Dockerfile с помощью ARG
инструкции:
FROM some/image
ARG GITHUB_CREDENTIALS
RUN install_github("my/repo", ${GITHUB_CREDENTIALS})
Затем передайте аргумент в docker build
:
docker build --build-arg GITHUB_CREDENTIALS=<insert credentials here>
Комментарии:
1. Это отличный ответ, но мой вопрос совершенно неправильный. В моем случае учетные данные находятся за пределами области сборки, и я не могу напрямую передать аргументы
docker build
, потому что это делается плагином jenkins.