я к тому что в gitlab-ci.yml можно сконфигуриваться всё тоже что и в docker-compose, по крайней мере для моего проекта достаточно и он также билдит и запускает контейнеры и почему бы только его не использовать. Я предполагаю что вы как и в статье выше тестите и собираете образы и пушите их в репо, а потом оттуда кубер забирает. Я же пытаюсь развернуть на текущей машине, где gitlab runner крутится. Плозая идея?
Идея имеет право на жизнь, у нас был раньше похожий сетап. Но у нас был(и есть) один дев сервак, и для деплоя на него мы туда ходим по ssh из раннера(раннеры тоже гонялись на этом серваке). И там уже просто компоуз запускаем. Это сделано было для того, чтобы шаред раннеры гитлаба тоже использовать.
Если же ты хочешь сделать деплой внутри джобы (то есть джоба живёт на всё время деплоя), то такого не делали, но в моём понимании это возможно и не особо сильно отличается от следующего способа.
Если же не важны шаред раннеры, есть только твоя машина, а компоуз будет в бэкграунде выполняться, то думаю это выполнимо. Хотя мне не особо понятно, почему есть желание так в прод деплоить.
По идее достаточно просто компоуз файлов, dind и маунта сокета докера в конфиге раннера. (До докера 18.09.8 работало без). Тогда сделав из джобы docker-compose up -d ты получишь свой деплой. Ну либо без компоуза можно просто docker run -d делать.
Если их нужно несколько разных на одном сервере, мы это делали с помощью nginx-proxy и разных VIRTUAL_HOST.
По поводу конфигов контейнеров в gitlab-ci.yml, не думаю, что верный подход, лучше как раз в компоуз всё задать + энв переменные использовать.
Я же правильно понимаю, что все джобы ты в докер контейнерах выполняешь?
Для мелкого проекта кстати можно просто executor shell поставить. Не совсем секьюрно, но будешь просто на машине все команды выполнять.
Но всё ещё не уверен, что отвечаю на тот вопрос.