Приложение использует sourcing secrets.sh для переменных env.Как сделать это в моем Dockerfile? - PullRequest
Новая
       11

Приложение использует sourcing secrets.sh для переменных env.Как сделать это в моем Dockerfile?

0 голосов
/ 29 марта 2019

Я работаю над созданием контейнера для моего запущенного приложения Django. Во время разработки и ручного развертывания я устанавливал переменные среды, используя в своем репозитории файл secretts.sh. До сих пор это работало нормально, когда я пытаюсь автоматизировать среду конфигурации моего сервера в Dockerfile.

Пока это выглядит так: 

FROM python:3.7-alpine

RUN pip install --upgrade pip
RUN pip install pipenv

RUN addgroup -S appgroup && adduser -S appuser -G appgroup

USER appuser

WORKDIR /home/appuser/site

COPY . /home/appuser/site

RUN /bin/sh -c "source secrets.sh"
RUN env

Я ожидаю, что это правильно установит переменные окружения, но это не так. Я также попытался добавить переменные в bashrc моего приложения, но это тоже не работает.

Я что-то здесь упускаю? Есть ли другой лучший способ установить переменные env, чтобы они были доступны для django, без необходимости регистрировать их в Dockerfile в моем репо?

1 Ответ

3 голосов
/ 29 марта 2019

Каждый шаг RUN запускает совершенно новый контейнер с совершенно новой оболочкой;только его файловая система сохраняется впоследствии.RUN Команды, которые пытаются запустить процессы или установить переменные среды, не имеют значения.(RUN export или RUN service start абсолютно ничего не делают.)

В вашей настройке необходимо, чтобы переменные среды устанавливались во время запуска контейнера на основе информации, которая недоступна во время сборки.(Вы не хотите сохранять секреты в изображении: они могут быть легко прочитаны любым, кто получит изображение позже.) Обычный способ сделать это с помощью сценария точки входа;это может выглядеть как 

#!/bin/sh
# If the secrets file exists, read it in.
if [ -f /secrets.sh ]; then
  # (Prefer POSIX "." to bash-specific "source".)
  . /secrets.sh
fi
# Now run the main container CMD, replacing this script.
exec "$@"

Типичный Docker-файл, построенный вокруг этого, будет выглядеть так: 

FROM python:3.7-alpine
RUN pip install --upgrade pip
WORKDIR /app

# Install Python dependencies, as an early step to support
# Docker layer caching.
COPY requirements.txt ./
RUN pip install -r requirements.txt

# Install the main application.
COPY . ./

# Create a non-root user.  It doesn't own the source files,
# and so can't modify the application.
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

# Startup-time metadata.
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["/app/app.py"]

А затем, когда вы запускаете контейнер, вы вводите файл секретов 

docker run -p 8080:8080 -v $PWD/secrets-prod.sh:/secrets.sh myimage

(Для стиля я резервирую ENTRYPOINT для этого шаблона и для однобинарных контейнеров FROM scratch и всегда использую CMD для любого основного процесса контейнера.)

...