Как организовать автодеплой на сервер в закрытом контуре?

Question

[balvardo]

Два сайта, один ВП, другой Битрикс. (не суть, но мало ли).
Их нужно разместить на сервере в закрытом контуре. Закрытый контур — к серваку не будет доступа по ssh в рабочем режиме. Доступ по ssh дадут на момент настройки, настолько, насколько надо.
Ставить можно все, что угодно, кроме руткитов, веб-файломенеджеров и т.д.
Нужно организовать возможность выкатывания релизов сайтов без подключения людей имеющих доступ к закрытому контуру.

Comments

[rPman]

Я очень надеюсь что автор не будет следовать рекомендациям пробиваться через закрытый контур.

ЛЮБОЙ механизм, обходящий ограничения контура - это серьезное нарушение безопасности, и рекомендации вставить бекдор в виде git или любой другой системы автообновления кода - это прямая дорога стать ответственным и крайним при любых проблемах в будущем.

без подключения людей имеющих доступ к закрытому контуру.

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

[VoidVolker]

rPman, так-то вы всё правильно говорите, но в данном случае ТС не указал свой контекст и ограничения. И раз у него стоит цель настроить деплой без SSH в закрытый контур, то значит разрешение на такой деплой у него уже есть. А если нет - ну, что ж, это уже его ответственность. Гитлаб из коробки умеет делать деплой.

Answer 1

[VoidVolker]

Ставите на целевой сервер gitlab-runner и далее настраиваете деплой стандартным способом через gitlab ci/cd. Триггеры деплоя - стандартные PR в master ветку только мэйнтэйнером или администратором проекта/группы. Все остальные разработчики работают по стандартному github-flow режиму ну или какой у вас там рабочий процесс принят. В идеале, конечно, следует делать деплой через SSH, как вариант - прокинуть сервер гитлаба в закрытый контур через любой шифрованный тунель, а внутри контура настроить прямой доступ к нему по DNS.
Раз стоит цель настроить деплой без SSH в закрытый контур, то значит разрешение на такой деплой уже есть. А если нет - ну, что ж, это уже ответственность ТС и что делать в этом случае это уже совсем другой вопрос.

Answer 2

[Евгений Хлебников]

к серваку не будет доступа по ssh в рабочем режиме

если нет выхода - уходите через вход
если нельзя запушить апдейт на сервер, значит на сервере что-то должно пуллить обновления.
Это может быть скедулированный скрипт, забирающий артефакты из надежного места, проверяющий их подписи, раскладывающий по правильным местам и перезапускающий сервисы (если надо).
Это так же может быть некий агент, который будет отчитываться управляющему серверу (однако обычно именно сервер дает команду агенту на деплой, а без доступа - если закрыт ssh то и другие порты скорее всего будут недоступны, контур то закрытый - мы опять приходим к скедулированным процессам апдейта)

Опять же вызывает вопросы "закрытость" контура: закрыт он от доступа извне или доступ наружу изнутри контура тоже отсутствует? Как тогда предполагается доставлять изменения?

Comments

[VoidVolker]

скедулированный скрипт

"скедулированный"???

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

[balvardo]

Доступ изнутри контура наружу имеется, вообще проблема ровно в том, что админ просто отбирает доступы "и проблемы индейцев..." Каких то хитрых политик безопасности не предусмотрено.

[Евгений Хлебников]

VoidVolker, а что вам не нравится?
технически, вариант с гитлаб раннером имеет право на существование (и предпочтителен в случае если есть гитлаб сервер. Раннер как раз занимается тем что постоянно опрашивает сервер а нет ли новой задачи. Каждые 3 секунды, кстати, насколько я помню, чем вам не scheduler :D ) но если гитлаба нет? Предлагаете еще один сервис запихать в ответственность (чью кстати? и надо ли оно ему)
balvardo, ну вот собственно вам и нужен инициатор деплоя изнутри. а так же отлаженные скрипты деплоя. упомянутый выше gitlab раннер - хорошее решение, но снаружи тоже надо об этом всем заботиться.
Вообще, если вы единственный разработчик этого добра и нет никаких противоречий у заказчика по безопасности - можно действительно водрузить внутри контура раннер, который подключите к вашему проекту на gitlab.com и деплоить будете CI-кой. Это будет красиво, контролируемо и хорошо

[VoidVolker]

Евгений Хлебников,

а что вам не нравится?

Само слово ) Есть же нормальный перевод, зачем так извращаться-то на языками?

технически, вариант с гитлаб раннером имеет право на существование (и предпочтителен в случае если есть гитлаб сервер. Раннер как раз занимается тем что постоянно опрашивает сервер а нет ли новой задачи. Каждые 3 секунды, кстати, насколько я помню, чем вам не scheduler :D ) но если гитлаба нет? Предлагаете еще один сервис запихать в ответственность (чью кстати? и надо ли оно ему)

Дык у нас тут раздел как раз про гитлаб, и раз человек в этом разделе спрашивает как настроить деплой - то очевидно, что у него гитлаб уже есть. А если нет - то тут уже вопрос к ТС и ему следует поправить вопрос и указать правильные теги.

balvardo

Доступ изнутри контура наружу имеется, вообще проблема ровно в том, что админ просто отбирает доступы "и проблемы индейцев..." Каких то хитрых политик безопасности не предусмотрено.

Ну вот, в таком случае можете спокойно использовать стандартный гитлаб ci/cd и/или прокинуть себе любой тунель для деплоя. Это у вас уже организационная проблема.

[Евгений Хлебников]

Дык у нас тут раздел как раз про гитлаб, и раз человек в этом разделе спрашивает как настроить деплой - то очевидно, что у него гитлаб уже есть. А если нет - то тут уже вопрос к ТС и ему следует поправить вопрос и указать правильные теги.

вы наверное хотели сказать:
Дык у нас тут раздел как раз про гитлаб и раз человек в этом разделе спрашивает как настроить развертывание - то очевидно что у него гитлаб уже есть. А если нет - то тут уже вопрос к ТС и ему следует поправить вопрос и указать правильные метки

Есть же нормальные переводы же :D

[Vitsliputsli]

Евгений Хлебников, зря ерничаете, нормальный - это значит общепринятый. То, что употребляют все, просто чтобы было удобнее. Разворачивать можно и ПО, но в данном контексте деплой всем понятнее. А теги... ну потому что здесь они называются теги.
А вот обсуждаемое слово, похожее на ругательство, я тоже охренел пытаясь понять что оно значит, когда первый раз увидел.

Answer 3

[Dmitry Roo]

Можно попробовать делать git pull в релизной ветке по крону и, если есть новый код, пересобирать/перезапускать приложение.