Коллеги, всем привет! Обращаюсь к вам за советом. Как у вас настроен

деплой сервисов и их настроек на сервера?

У нас сложилась такая ситуация, что написаны некоторые sh скрипты, которые ходят читать конфиги (кастомные), парсят их и оттуда получают версии контейнеров, которые нужно поднять. Мне как разработчику, чтобы замапить новый файл в докер , нужно сходить к OPS и попросить это вкорячить в эти скрипты. Скрипты просто вызывают docker run и пропихивают туда кучу параметров, типа волюмов, переменных и т.д.
Получается что я за..ался ходить просить их править скрипты, т.к доступа к ним у меня нет.
У меня дикое чувство злости от этого всего.
+ ко всему это говно скриптовое постоянно отъезжает из-за ошибок или недопонимания как этим пользоваться

Локально я использую docker-compose и горя не знаю. Все быстро и удобно.

Как вы работаете со своими конфигами, версионностью на разных стендах? Как деплоите скрипты?

P.S. облачные решения не подходят, т.к. серваки клиентов часто стоят в закрытых контурах без доступа в интернет.

Конфиги всех сервисов кладёшь в репу, делаешь автодеплой сервиса на мерже в эту репу.

Что значит: замапить новый файл в докер? И почему это нужно делать часто?

конфиги разные

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

У нас продукт. Сервис может работать у десятков клиентов но с разными конфигами

Ну если так, то наверное это хорошо, что клиентской конфигурацией заведуешь не ты?

Это философия, верно? Я попросил поделиться вариантами деплоя

Это обычная схема, обычно у девелоперов нет доступа на площадки и конфигурирование этих площадок лежит на имплементаторах или в вашем случае девопсах

Да я не против. Но когда это самописные велосипеды, то фиг пойми что где поехало и почему. Вопрос в том - что есть типа докер компоса?

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

И октопус представляет ui для деплоймента и конфигурации

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

У меня много разных сценариев деплоймента; на современных проектах я чаще всего просто всё пакую в Докер контейнер и пушу его когда захочу (на CI), а дальше оно разными путями доезжает до продакшена. Если часто надо шатать конфиг — это путь вникуда, так не должно быть. Сделайте чтоб не нужно было часто.

Ну так продукт работает. Мы не можем себе позволить под каждого клиента свой форк делать - это тоже путь в никуда)))

Дак ну не делайте. Зачем форк?

Ну ок. Я сделал фичу. Но она нужна не на всех проектах. Что мне зашить в докер? true или false?

Feature toggle сделай по паттерну. У аспнеткора была специальная либа, которая умеет централизованную конфигурацию этих тоглов и всякие вкусности.

То, что ты описал, это вопрос open-closed и dependency inversion. Тебе нужно сделать так, чтобы звали твой опциональный скрипт, и передавали тебе свой скрипт в виде лямбды для продолжения. Что то вроде паттерна с next в middleware от aspnet. Вместо лямбды можно передавать команду, которую ты выполнишь в sh, например.