Как организовать деплой Go приложения?

Question

[Максим]

В общем задача в следующем:

• Собирать из бинарников(http api + несколько демонов) deb пакет
  
• Работа демонов через systemd (или альтернативу)
  
• Запускать миграции для базы данных, при установке или запуске новой версии deb пакета
  
• На сервере не должно быть никаких утилит для деплоя, миграций и т.д., go мы туда не ставим. То есть deb пакет это самостоятельная единица, поставил заапдейтился, откалился - заролбечился.
  

Best way в интернетах не нашел, может кто может подсказать по следующим вопросам:

1. Как организовать репозиторий с сорцами go кода, нужно ли добавлять туда каркас deb пакета, может бинарники. Или нужно каждый раз создавать новую папку под новый пакет?
   
2. Как при установке запускать миграции? Должно ли это быть решение в основном приложении на go, а deb пакете прокидывать миграции, например, в /etc/app/migrations. Или создавать для этого отдельный бинарник, который сможет работать с конфигами нашего приложения.
   
3. Организация работы с systemd. Опыта работы с ним не имел. На что обратить внимание, натыкались ли на грабли? Может есть лучшие альтернативы?
   

Answer 1

[sim3x]

На практике

На сервере не должно быть никаких утилит для деплоя, миграций и т.д., go мы туда не ставим. То есть deb пакет это самостоятельная единица, поставил заапдейтился, откалился - заролбечился.

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

Работа демонов через systemd (или альтернативу)

тк альтернативы постепенно выпиливают из дистрибутивов, то и выбора та собственно -- нет

В теории

Как организовать репозиторий с сорцами go кода, нужно ли добавлять туда каркас deb пакета, может бинарники. Или нужно каждый раз создавать новую папку под новый пакет?

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

Как при установке запускать миграции? Должно ли это быть решение в основном приложении на go, а deb пакете прокидывать миграции, например, в /etc/app/migrations. Или создавать для этого отдельный бинарник, который сможет работать с конфигами нашего приложения.

в деб пакете у тебя должны быть все миграции (или все миграции, которые могут понадобиться хоть какой-то инсталяции)

В окружении у тебя должен быть файл или переменная окружения последней рабочей версии
Читаем переменную - запускаем свой файл для миграции для поднятия версии до текущей версии из пакета

Учти, что хороший тон, создавать как upgrade так и downgrade миграции

Роллбечить пакеты, я б не советовал -- проще поднять версию пакета и указать в нем, что ты хочешь откатиться на предыдущую версию

Comments

[Максим]

Пишу с телефона, поэтому могу косячить, заранее извиняюсь.
Говоря про роллбэк я имел ввиду именно мигоации, то есть юз кейс такой - выкатываем новую версию с миграциями, она оказывается забагованной(малая но вероятность есть) мы перестанавливая пакет хотим откатить и миграции. Идея с переменной окружения интересна. Изначально рассматривал дефолтную табличку в бл migrations. Соответственно и поэтому были выбраны деб пакеты так как откат на предыдущую версию приложения очень прост и реализуется на уровне дистрибутива.
Вопрос в том как эти миграции накатывать. Пока самая здравая идея которая у нас возникла, это в пакете распространять доп утилитку которая будет следить за мигрциями и запускаться в post install скрипте пакета. Но серверов много и тут может возникнуть проблема с тем что в одну базу будут стучаться несколько если использовать переменные среды, то тут уже напрашивается что то типо мастер сервера, чтобы только он накатывал миграции. Проблема предполагаемая, на практике не знаю, как это себя поведёт.
По systemd в основном вопрос как ведёт себя в нем го приложение, а если конкретнее горутины, с ними как я слышал при демонизации не работает стандартный fork. Нужно что то применять дополнительно или systemd умеет с этим бороться?

Спасибо за ответ!

[Максим]

Про несколько серверов в вопросе не написал, мой косяк.

[sim3x]

Максим:
деб пакеты использует яндекс для накатки своего софта на кластер - я понимаю, что ради даже 100 машин такое творить глупо. Если у тебя меньше 100 машин, то мучаться с пакетами не стоит -- ansible / pssh решит все твои вопросы меньшей болью, с большей еффективностью и контролем

Откат деб пакета не так прост и не так прозрачен, как ты думаешь https://wiki.debian.org/RollbackUpdate
И мне почему-то кажется, что в пакете нет сигнала, который вызовет скрипт при событии rollback
Потому тебе проще всегда двигаться только вперед по версиям
В версионировании для мелких правок есть две цифры

00.00.00-00
__________^^

Миграция для такого рода софта должна затронуть только локальные данные -- твоя софтина ни при каких раскладах не должна трогать общую БД
Общая БД уже должна иметь все правки до запуска обновления пакетов на твоих машинах
Проще говоря, твоя БД должна быть совместима со всеми запущенными версиями го-программки
Релизы для СУБД будут заключаться в том, что данные будут постепенно переливаться с предыдущей версии таблицы в текущую
И через тригеры или процедуры будет предоставляться доступ к реальным данным

Перед реализацией такой аритектуры стоит много раз подумать, о том насколько можно все разделить даже с потерей нормализации схемы БД

Про детали спаривания го и системд не подскажу

Answer 2

[Philipp]

capistrano

Answer 3

[vyachin]

ansible лучше)) нет нужды засорять систему установкой ruby . Ansible использует python, а он есть почти в любой linux системе

Answer 4

[Никита Павлов]

Может вообще в docker-е сделать и не париться?

Comments

[Илья]

Ждал, когда же уже упомянут докер. Ожидал, что быстрее будет.

[Максим]

У нас сейчас все тестовые стенды в докере. Но на проде деплоим фабриком(идёт переход на ансибл). Я не в курсе почему для прода не используется докер, так как сам на данном этапе не в курсе)

[Максим]

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

[Никита Павлов]

Максим: почему не подходит? просто надо решиться...