И какую проблему решит это действие? :)

Я вообще не понял какая изначально проблема

Ну занеси сразу всё в куб

Не все сразу, а так да, зоопарк - у stolon consul бакенд

По ходу сумбурно обясняю 1. Клиент в единый момент времени может работать только с 1 сервисом, но может содержать ip других сервисов и если ответ текущего сервиса превышает таймаут - переключается на следующий 2. Сервис может работать только с одним линком к дб

Ну так столон в кубе тебе решит эти проблемы

Кажется перенос столона в куб - сильно больше задача

Кажется перенос столона в куб - сильно больше задача

Зависит от размера баз

Кажется перенос столона в куб - сильно больше задача

Ну просто бд большая

Ну просто бд большая

Ты можешь по нормальному объяснить твою проблему?

Ну так столон в кубе тебе решит эти проблемы

А какие плюсы, etcd + kube-dns его не заменят? Если не считать шаблоны

Гайз, а кто как конфиги в контейнер подсовывает?

Ты можешь по нормальному объяснить твою проблему?

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

Гайз, а кто как конфиги в контейнер подсовывает?

Я юзаю секреты

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

Ну так затащить в куб. И как раз через кубовый сервис его выставить

Гайз, а кто как конфиги в контейнер подсовывает?

Переменные окружения?

Переменные окружения?

Да, это хорошо. Ну, а если Легаси? Энв переменные + шаблонизация? Или как?

Ну тогда в файл его и на вход легаси

Ну или враппер который готовит конфиг на основе окружения

а есть что нибудь готовое как в ансибле шаблонизатор j2 kube template какой нибудь?

На этапе сборки контейнера

Если есть возможность подпни разрабов

Вот. Файлы у меня и есть. Все завернуто в контейнер с нжинкс, который их раздает. Но это как-то... Странно и несекурно что-ли.

Вот и советуюсь, как бы это улучшить

а есть что нибудь готовое как в ансибле шаблонизатор j2 kube template какой нибудь?

Если правильно понимаю, то возможно для этого helm подойдет

Мы юзаем ансибль для этого, что бы на этапе сборки контейнера прокидывать в него конфиги, а их можно из ansible-secret подтягивать.

Вот. Файлы у меня и есть. Все завернуто в контейнер с нжинкс, который их раздает. Но это как-то... Странно и несекурно что-ли.

Мы юзаем ансибль для этого, что бы на этапе сборки контейнера прокидывать в него конфиги, а их можно из ansible-secret подтягивать.

Я считаю, что хранить готовые конфиги в самом образе - это как-то не правильно.

Его ж надо и на деве и на стейджа ещё запускать. И как его в девовую базу тогда отправлять?

Его ж надо и на деве и на стейджа ещё запускать. И как его в девовую базу тогда отправлять?

Env же есть

Env же есть

Перечитай выше плз.

Перечитай выше плз.

Ответ тот же

Т.е. таки энв + шаблонизатор?

Динамические конфиги, работает на ура

Можно подробнее? Ссылку там какую... Спасибо.

Можно подробнее? Ссылку там какую... Спасибо.

Да любой докерфайл на гитхабе глянь, entrypoint скрипт кушает env и генерит. Логика одна. Кто-то на баше, кто-то на го

А, ну т.е. как я и говорил. Энв + шаблон

Ок. Это понятно и логично

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

Шаблон (tpl) или просто строку запуска генерит

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

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

так уже от задачи к задаче. либо меняется профиль приложения, сохраненный в образе, типа spring-profile либо каждую переменную передаёшь

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

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

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

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

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

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

Попадают туды ансиблом, креды валяются на серваке в офисе под луксом

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

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

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

Автоскейла нет, только вручную запуск плэйбуков. Но к заббиксу прибить не сложно

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

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

Но и это не решает проблемы автоскейлинга и добавления серверов

Нфс как выход, но это точка отказа

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

https://github.com/sameersbn/docker-gitlab/blob/master/kubernetes/gitlab-rc.yml

рандом конфиг с гитхаба

Это я понимаю. Ты предлагаешь как раз вариант только для разных энвов разные файлы

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

Это ж плохой подход. Или я не верно понимаю?

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

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

Я их руками пишу и стараюсь не допускать дублирования

Ну и инвентори максимально использую с переменными

запуск то всё равно идёт через указание хостов\переменных

чем тут не так

Только хоста

Все остальное автоматом

Хост файла

Только хоста

у тебя для каждого хоста отдельная роль\конфиги?

Нет, я имел ввиду хостс файл

Инвентори

Можем перейти в личку, ибо оффтопик уже

Ладно, забей, а то хотел по аналогии с ансиблом показать, а в итоге про ансибл говорим))

:)

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

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

Не нравится точка входа которая генерирует конфиг -- впиливайте в приложение поддержку переменных среды.

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

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

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

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

Ты про клонирование говоришь, при масштабировании конфиг не меняется

Мало того, если вспомнить про сервис дискавери то будет еще меньше

Масштабирование - это понятие относительное. Масштабировать можно и энвы. Контекст разный может быть

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

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

Не пинайте ногами. Пытаюсь сложить в голове логичную структуру.

Я хз какие ещё контексты у масштабирования, кроме как изменения размера

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

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

google://kubernetes+configmap

google://kubernetes+configmap

пошел читать. Спасибо

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

:)

Я ничего не понял о задаче, но конфиги можно хранить не 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" } Такая конструкция позволяет в файл прокидывать переменные из окружения.

Я ничего не понял о задаче, но конфиги можно хранить не 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 редкое г... Наелся я его уже.

Про конфигмапы интересно. Спасибо большое.

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

не очень то и редкое, но говно то еще да

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

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

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

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

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

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

Да!

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

Ну вообще я говорил про деплоймент ямл... Да уж...

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

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

А да, еще хуки есть на жизненный цикл контейнера, да

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

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

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

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

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

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

Я просто нихрена не понимаю о чём вы пишете)