Какова практика деплоя Golang проектов?

Question

[Степан И]

Пока еще не сталкивался с этим и хочется узнать заранее, какие существуют практики деплоя приложений на Golang?
Смущает вопрос тем, что изначально в Golang заложена бинарная дистрибуция. Т.е. по идее подразумевается один готовый бинарник закидывать на хост и дело в шляпе.
Тут есть определенные минусы связанные с размерами самого бинарника, и как известно у Golang они приличные.

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

Ну и хотелось бы почитать ответы людей уже имеющих опыт на практике.
Спасибо!

Comments

[Толстый Лорри]

Тащить бинарник плохо, а SDK - это хорошо?)

[Степан И]

Толстый Лорри, справедливо)

SDK один раз загрузил и все. Вроде как.

[chupasaurus]

Степан И., потом захотел/надо его обновить, и тащить заново. JDK 8 под Linux весит примерно 4,5 ГБ, например.

[Степан И]

chupasaurus, кошмар. Не думал об SDK вообще.

[Oleksiy Chechel]

chupasaurus Степан И., а зачем для go нужен JDK? Для сборки нужен только golang, который около 100Mb со всеми утилитами и ставится через пакетный менеджер.

[chupasaurus]

Олексiй Чечель, Я писал про то, что на серверах не должно быть ничего не имеющего отношения к работе приложения.
Кстати в Debian компилятор, линковщик и скомпилированнная стандартная библиотека без исходников весят больше 100 MB + сырцы оной 50 МБ в 1.9, в 1.10 RC - уже 60 МБ.

[Oleksiy Chechel]

chupasaurus, это вопрос удобства в каждом конкретном случае. Из разряда "бороду на одеяло ложить или под него". У нас настроен деплой из сорцов и все преотлично работает, за несколько лет не было никаких проблем. 100-200 метров SDK на сервере кого вообще вообще напрягают?

[chupasaurus]

Олексiй Чечель, Какой смысл деплоить исходники, когда нужен бинарник, который к тому же будет меньше?
Не путайте toolchain и SDK.

[Oleksiy Chechel]

chupasaurus, да точно, выше был разговор об SDK на сервере, потому так и написал.
В моем случае смысл в том, что в день множество мелких коммитов в десятки-сотни байт. На сервере с gitlab выполняются CI перед попаданием кода в мастерветку. А дальше по вебхуку сервер подтягивает с гита десяток байт изменений и собирает бинарник.

[Oleksiy Chechel]

chupasaurus, Еще немаловажный фактор, присутствие дополнительных файлов в сорцах. Условно - шаблоны, css, изображения и т.д. Которые в экзешник попросту не попадут, а в процессе разработки эти файлы могут в любой момент измениться и должны быть обновлены на сервере.

[chupasaurus]

Олексiй Чечель,

А дальше по вебхуку сервер подтягивает с гита десяток байт изменений и собирает бинарник.

Как давно вы собираете приложения на продакшене?

Еще немаловажный фактор, присутствие дополнительных файлов в сорцах.

Пакеты и контейнеры для этого и существуют.

[Oleksiy Chechel]

chupasaurus, хорошо. Давайте по другому. Опишите процесс автодеплоя веб-приложения, а я возьму на вооружение.
Дано: Десятки разработчиков, каждый работает в своей ветке, но при попадании в мастер должен произойти автоматический деплой (~50раз в сутки). Изменения происходят одновременно в коде, в шаблоне или json-файле, изображении. Размер проекта 400mb.

[chupasaurus]

Oleksiy Chechel, СI прогоняет тесты и собирает артефакт, который деплоится.

[Oleksiy Chechel]

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

[chupasaurus]

Oleksiy Chechel, Вы же не даёте конкретики (400 МБ сферических коней в вакууме). Деплоить можно rsync-ом, например.

Answer 1

[RidgeA]

собирать бинарник на продакшене - идея так себе.
даже образ 1.9-alpine занимает 83 метра + будут зависимости в GOPATH

Я делал следующим образом
В GitLab CI создавалась задача на тесты проекта, сборку его в бинарник и создания docker образа FROM: SCRATCH, где находится ТОЛЬКО этот бинарник.
На входе я получал образ размером с бинарник - без зависимостей в GOPATH и среды сборки - около 15 мб.

Есть ньюансы для сборки такого бинарника, но в большинстве случаев ИМХО они не существенны.
+ недостатком такого подхода является то, что просто так в контейнер не залезешь и не выполнишь какую-то bash команду, т.к. там ничего нет вообще, кроме бинарника.

вот статья. https://blog.codeship.com/building-minimal-docker-...

Answer 2

[chupasaurus]

У вас CI отклеился, хотя тесты и сборки гонять надо там.
Фокус с Golang в том, что кроме докер-образа с Alpine Linux + ваш бинарник больше ничего не надо, а размер такой пары гораздо меньше, чем полновесное окружение.

Comments

[Philipp]

Вдобавок его еще и заархивировать можно.

[chupasaurus]

Philipp, Если под заархивировать вы имели в виду сложить в репозиторий, то код уже должен быть заархивирован в VCS, а с бинарниками надо ещё что-то делать.

[Philipp]

chupasaurus, смотрите, у вас есть Go-lang код. Ваша CI создает контейнер, берет код из репозитария, собирает приложение, кладет его в контейнер, прогоняет интеграционные тесты для контейнера.
Если контейнер проходит тесты, он останавливается, а образ его сохраняется, архивируется и далее публикуется в сетевом хранилище. Сама процедура различается для разных CI. Но это все можно ручками собрать и положить на свой сервер и оттуда образ доставать своими скриптами.
По-хорошему ставится свой Docker-репозитарий и работа ведется с ним.
Если не очень хочется с этим всем ручным заморачиваться, смотрите в сторону таких решений.

[chupasaurus]

Philipp, Вернул пропущенное слово в моём комменте, из-за которого потерялся смысл.

Answer 3

[Symphel]

Немного смутило ваше видение.
1. Не иметь собранного биинарника плохо: если вдруг нарушен доступ к репозиторию с исходным кодом, вы не можете деплоить стенды
2. Тесты надо прогонять до того, как изменения попадают в релизный бранч
3. Независимо от способа доставки данных, для сборки вам нужны все исходники проекта и стандартной библиотеки, их размер по очевидным причинам больше бинарника
4. Вам придется тянуть зависимости еще и для тестов