Загружаем изображение…
Мамкин DevOps или CI/CD на коленке
Для всех, кто знает боль ручного деплоя.
Тем, кто делал git pull на проде в пятницу вечером.
Всем кто помнит адреса серверов наизусть.
Всем беспризорным душам посвящается.
tl;dr
Да, сегодня на повестке дня рутина - ручная накатка обновлений на сервер. Но и эту скучную работу можно и нужно автоматизировать.
Речь пойдёт о максимально простом варианте CI/CD. Без GitLab Runner, Kubernetes, Jenkins и прочих инструментов взрослых и серьёзных дядек. Сегодня нам понадобятся только GitLab, webhook и небольшой серверный обработчик.
Что такое webhook
Если отбросить умные определения, webhook — это обычный HTTP-запрос по событию. Произошёл push в репозиторий — GitLab отправил запрос на указанный URL. Для наших целей webhook будет выполнять одну простую задачу — запускать обновление проекта.
Как это работает
-- На сервере создаём
-- В GitLab настраиваем
--
--
-- Сервер проверяет токен.
-- Сервер выполняет деплой.
Всё - один сервер вежливо сообщает другому, что пора обновляться.
Настраиваем GitLab
В проекте открываем:
Далее указываем:
-- URL обработчика;
-- Secret Token;
-- событие Push Events;
-- при необходимости ограничиваем веткой main.
После сохранения
Настраиваем сервер
На сервере потребуется обработчик, который:
-- принимает только POST-запросы;
-- проверяет токен;
-- убеждается, что прилетел нужный branch;
-- запускает обновление проекта;
-- пишет лог.
В результате у нас не проект, а автономный зверь, который обновляется сам.
Для небольших проектов, внутренних стендов и пет-проектов этого часто хватает с головой. А главное — больше не придётся вспоминать, обновил ли ты этот сервер вчера или только собирался.
А главное — больше не придётся вспоминать, обновил ли ты этот сервер вчера или только собирался.
#cicd #devops #gitlab #webhook #deploy #разработка #backend #automation
Для всех, кто знает боль ручного деплоя.
Тем, кто делал git pull на проде в пятницу вечером.
Всем кто помнит адреса серверов наизусть.
Всем беспризорным душам посвящается.
tl;dr
GitLab webhook + простой серверный обработчик = автоматизированный git pull. Дёшево, сердито и без регистраций и смс.
Да, сегодня на повестке дня рутина - ручная накатка обновлений на сервер. Но и эту скучную работу можно и нужно автоматизировать.
Речь пойдёт о максимально простом варианте CI/CD. Без GitLab Runner, Kubernetes, Jenkins и прочих инструментов взрослых и серьёзных дядек. Сегодня нам понадобятся только GitLab, webhook и небольшой серверный обработчик.
Что такое webhook
Если отбросить умные определения, webhook — это обычный HTTP-запрос по событию. Произошёл push в репозиторий — GitLab отправил запрос на указанный URL. Для наших целей webhook будет выполнять одну простую задачу — запускать обновление проекта.
Как это работает
-- На сервере создаём
endpoint для webhook.-- В GitLab настраиваем
webhook на этот URL.--
GitLab получает push.--
GitLab отправляет POST-запрос.-- Сервер проверяет токен.
-- Сервер выполняет деплой.
Всё - один сервер вежливо сообщает другому, что пора обновляться.
Настраиваем GitLab
В проекте открываем:
Settings → WebhooksДалее указываем:
-- URL обработчика;
-- Secret Token;
-- событие Push Events;
-- при необходимости ограничиваем веткой main.
После сохранения
GitLab начнёт отправлять запросы при каждом пуше в целевую ветку.Настраиваем сервер
На сервере потребуется обработчик, который:
-- принимает только POST-запросы;
-- проверяет токен;
-- убеждается, что прилетел нужный branch;
-- запускает обновление проекта;
-- пишет лог.
В результате у нас не проект, а автономный зверь, который обновляется сам.
Для небольших проектов, внутренних стендов и пет-проектов этого часто хватает с головой. А главное — больше не придётся вспоминать, обновил ли ты этот сервер вчера или только собирался.
А главное — больше не придётся вспоминать, обновил ли ты этот сервер вчера или только собирался.
#cicd #devops #gitlab #webhook #deploy #разработка #backend #automation
Просмотры: 49