Я знаю о доступных заменах переменных, где я мог бы использовать .env в корне проекта, и это было бы сделано, но в этом случае я адаптирую существующий проект, где существующий .envрасположение файлов ожидается, и я хотел бы избежать необходимости иметь записи var для нескольких файлов!
См. документацию для получения дополнительной информации, и весь код доступен как WIP на docker-supportфилиал репо, но я кратко опишу проект и проблему ниже:
Структура проекта
|- root
| |- .env # mongo and mongo-express vars (not on git!)
| |- docker-compose.yaml # build and ups a staging env
| |- docker-compose.prod.yaml # future wip
| |- api # the saas-api service
| |- Dockerfile # if 'docked' directly should build production
| |- .env # api relative vars (not on git!)
| |- app # the saas-app service
| |- Dockerfile # if 'docked' directly should build production
| |- .env # api relative vars (not on git!)
Или посмотреть все это здесь , он прекрасно работаеткстати на данный момент, но есть одна проблема с saas-app при создании образа для постановки / производства, которую я до сих пор мог идентифицировать.
выпуск
во время сборки Next.js buildsстатическая версия страниц, использующая веб-пакет для выполнения подстановки process.env, поэтому требуется, чтобы фактические возможные запущенные переменные были включены на этапе сборки докера, поэтому next.js не нужно повторностроить снова во время выполнения, а также, чтобы я мог безопасно создавать несколько экземпляров, когда требуется трафик!
Я знаю, что если во время выполнения не будут отправлены те же самые переменные, ему придется заново строить, игнорируя смысл этого упражнения, но это именно то, что я пытаюсь здесь предотвратить, если это неправильнозначения отправляются нам, а не проекту!
И мне также нужно рассмотреть управление BUILD ID в Next.js, но это в другой раз / вопрос.
Попытки
Я тестировал с включением деклараций ARG и ENV для каждой из переменных, ожидаемых приложением в Dockerfile , например:
ARG GA_TRACKING_ID=
ENV GA_TRACKING_ID ${GA_TRACKING_ID}
Это работает, как и ожидалось, однаковынуждает меня вручную объявить их в файле docker-compose.yml , что не идеально:
saas-app:
build:
context: app
args:
GA_TRACKING_ID: UA-xXxXXXX-X
Я не могу использовать подстановку переменных здесь, потому что мой корень .env не включаетэта переменная находится на ./app/.env, и я также проверил, оставив значение пустым, но оно не берется из определений env_file или enviroment, что, как я полагаю, соответствует ожиданиям.
I 'VE Pastbinned полный вывод docker-compose config с существующей версией в хранилище:
В идеале я бы хотел:
saas-app:
build:
args:
LOG_LEVEL: notice
NODE_ENV: development
PORT: '3000'
context: /home/pedro/src/opensource/saas-boilerplate/app
command: yarn start
container_name: saas-app
depends_on:
- saas-api
environment:
...
Стать:
saas-app:
build:
args:
LOG_LEVEL: notice
NODE_ENV: development
PORT: '3000'
BUCKET_FOR_POSTS: xxxxxx
BUCKET_FOR_TEAM_AVATARS: xxxxxx
GA_TRACKING_ID: ''
LAMBDA_API_ENDPOINT: xxxxxxapi
NODE_ENV: development
STRIPEPUBLISHABLEKEY: pk_test_xxxxxxxxxxxxxxx
URL_API: http://api.saas.localhost:8000
URL_APP: http://app.saas.localhost:3000
context: /home/pedro/src/opensource/saas-boilerplate/app
command: yarn start
container_name: saas-app
depends_on:
- saas-api
environment:
...
Вопросы
Как бы я мог добиться этого, если это возможно, но:
- Без объединения существующих файлов
.env в один корень или необходимости дублировать переменные на несколькихфайлы. - Без ручного объявления значений в файле compose или необходимости выводить их по команде, например
docker-compose build --build-arg GA_TRACKING_ID=UA-xXxXXXX-X? - Без необходимости
COPY каждого .env файла во время этап сборки , потому что он не выглядит правильным и / или безопасным? - Возможно, запрос
args_file на опцию compose build опций для команды compose мне кажетсяДопустим, вы бы тоже так сказали? - Или, возможно, у вас есть корневая опция в файле compose, где вы можете установить более одного
.env файла для замены переменных? - Или, возможно, другое решениея не вижу?Любые идеи?
- Я не против отправить каждый
.env файл в виде config или secret , это более чистое решение, чем разделение составных файлов, кто-нибудьзапустить такой пример для производства?