Как разделять энв для дева, стейджа, etc?

Допустим вот в одном окружении Линк на одну базу, а в другом Линк в другую базу

У меня маунт файлов (на каждом серваке /opt/project/.env)

Т.е. у тебя нет автоскейлинг группы, где сервера автоматом добавляются?

Вот если каждую переменную, то тут уже не выходит IaC

Т.е. у тебя нет автоскейлинг группы, где сервера автоматом добавляются?

да перестань, чего это нет?

Ну если только через энв файлы

Копипаста и дублирование

Только хоста

Допустим вот в одном окружении Линк на одну базу, а в другом Линк в другую базу

Передаете линк на базу в env и потом подставляете в конфиг. Все параметры зависимые от среды передаются (внезапно) как переменные среды.

То есть, если у меня 5 сред, то и ямлов для деплоймента тоже 5? Не кажется слабо масштабируемым решением?

Нет, у тебя 5 конфигмапов в кубере и переменные среды берутся оттуда

О! Конфигмапы - это о чем?

google://kubernetes+configmap

:)

Я ничего не понял о задаче, но конфиги можно хранить не nfs, а в том же glusterfs и единой точки отказа не будет и маунтить можно на хост прям или в поду. Если URL нужно внутрь контейнера при сборке Dockerfile прокинуть, то лучше передавать переменную с урлом через —build-arg при сборке конетенйра через docker build и иметь единый Dockerfile для разных сред . При этом внутри файла переменная активируется через директиву ARG. Если у тебя внутри приложения есть конфиг файл, а само приложения не умеет из переменных окружения подхватывать настройки, а только из файла, то если конфиг у тебя в формате yaml, то прокатит такая конструкция back_host: "<%= ENV.fetch('BACK_HOST', 'http://localhost:3000') %>" в конфиг файле Для puba.rb например такой формат environment ENV.fetch('RAILS_ENV') { "development" } Такая конструкция позволяет в файл прокидывать переменные из окружения.

Gluster редкое г... Наелся я его уже.

То есть, если у меня 5 сред, то и ямлов для деплоймента тоже 5? Не кажется слабо масштабируемым решением?

Гластер, нфс?

И контейнеры оркестрировать через systemd)

Пока писал не заметил что у тебя там yaml файл так что такая конструкция должна работать database: <%= ENV.fetch('MONGOID_DATABASE') %>

Есть конфигмапы, есть секреты, есть хелм, есть init контейнера, но нет, будем жевать кактус...

будет один файл, а его содержание будет меняться в зависимости от того какие переменные ты туда передашь во время запуска контейнера

Как это сделать со стороны кода я уж как-то знаю... Лучше бы контекст почитал. ЛЕГАСИ!

И вот тоже полезно: https://12factor.net/

12фактор знаю, да. Но не всегда применимо, к сожалению.

Свое легаси или чужое?

Так, мы сейчас конкретную проблему решаем или сферически в вакууме делаем всех счастивыми?

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

OTRS, как пример. Древний как говно мамонта. Лезть туда руками я совсем не хочу.

И где не применимо?

И его несколько энвов держать надо и еще эти энвы плодить часто?

А задача какая?

Да, на него завязаны наши сервисы. QA'м хочется поднимать полное окружение для тестов.