Как правильно деплоить проект?

#golang #docker #развертывание #bitbucket

Здравствуйте, есть restful сервис написанный на golang.
Раньше работал на локальном хосте, сейчас же появилась потребность деплоить все на
сервер.
Не могу понять как лучше осуществить деплой.
Создал репозиторий на бакете, а от дальше туплю.
Каждое изменение(А их будет много) копировать, билдить, потом закрывать процесс с
активным приложением go и запускать новый. Так как изменения будут очень частые и очень
интересует как можно автоматизировать этот процесс.
    

Ответы

Ответ 1

Есть такой подход, под названием Continuous Delivery (Непрерывное развертывание),
который предлагает решение описанной вами проблемы. 

Что это за зверь и с чем его едят, описано в книге Continuous Delivery: Reliable
Software Releases through Build, Test, and Deployment Automation / Непрерывное развертывание
ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ

Небольшая выжимка о CD (цитата отсюда):


  Основная идея CD в том, чтобы построить конвейер (Deployment
  Pipeline), позволяющий каждому изменению в системе контроля версий
  попасть в боевое окружения стандартным и полностью автоматизированным
  способом.
  
  Приблизительно это может выглядеть следующим образом:
  
  
  Изменения вносятся в систему контроля версий (СКВ).
  Запускается система непрерывной интеграции (Continuous Integration, CI), собирается
билд (если это компилируемый язык), прогоняются все необходимые тесты.
  В случае успешности предыдущего шага, билд выкатывается на окружение тестирования (QA).
  После успешного тестирования билд выкатывается на stage окружение (pre-production),
которое максимально приближено к боевому окружению.
  Если все прошло хорошо, то билд попадает в боевое окружение.
  
  
  Тут встает в полный рост вопрос, как сделать так, чтобы все окружения,
  начиная с окружения разработчиков, максимально соответствовали друг
  другу. Для этого существуют инструменты управления конфигурацией
  (Configuration management system). Самое главное, что конфигурация окружений — это
  такой же код, и к нему точно также применимы все вышеперечисленные
  подходы: хранение в СКВ, CI, тестирование.
  
  Так вот, если этот процесс отлажен, все изменения проходят по нему, и,
  потенциально, каждое изменение может быть выкачено в продакшен, то это
  и называется процессом непрерывной поставки ПО.


Ответ 2

Вам в любом случае нужны решения для CI (Continuous Integration) и CD (Continuous
Deployment).

Вот список, из которого вы можете выбрать(ссылка). 



Например, как это работает с Drone:


Через веб морду Drone, вы настраиваете Drone для получения проекта с репозитория
Git и выполнение "запуска". Что конкретно происходит при запуске описано в следующем шаге.
Вместе с кодом приложения в репозитории должен лежать .drone.yml файл, который говорит
Drone как устанавливать и запускать ваше приложение.
Далее вы делаете git push в ваш репозиторий, Drone проверяет репозиторий на недавно
залитый Docker образ (по вашему выбору), а затем стартует его.
На основе вашей конфигурации результатом успешного запуска может быть уведомление
(«Сборка выполнена успешно!»), создание бинарной версии или даже развертывание.
Наконец, Drone удаляет Docker контейнер  и переустанавливает его так, чтобы он был
в исходном и известном состоянии для следующей сборки.


P.S. по связке Drone + Docker есть неплохая статья на Хабре.