Как деплоить небольшие проекты?

Question

[beduin01]

А кто как деплоит небольшие проекты? Полноценный CI/CD поднимать не вижу смысла ввиду размеров. Однако хотелось бы все как-то автоматизировать. Разработку веду в одной ветке. Фронт и Бэк в отдельных репозитариях.
Вопросы такие:
1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое
2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?
3. Как быть с адресами и портами. К примеру в index.js на девелоперской машине у меня прописано windows.base_url = "localhost:1234" а на сервере мне нужно "10.1.2.6:9000" как это это автоматизировать?

Answer 1

[Stanislav Pugachev]

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

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

Comments

[Wentixon]

Подскажи, а разве на продакшн докер это правильное решение? Просто говорят если и юзать докер на проде, то только с kubernetes, но я так понимаю, что это для очень крупных сервисов. А здесь речь о более менее простых проектах, есть ли смысл их на докера поднимать?

[Stanislav Pugachev]

Wentixon,
"смотреть нада" (с)
конечно крутить все в kubernetes кластере это правильней, но это сильно крупнокалиберный инструмент для "мелкого проекта".
но поверьте настанет тот день, придет время когда мелкий проект оперится, вылетит из гнезда, попадет под нагрузку и поднимет глаза вверх и возопит "Спаси нас!", на сцену выйдет kubernetes и вы 5 раз мысленно поблагодарите меня за то что я посоветовал юзать докер в свое время. (у вас по факту уже все готово что б юзать кубернетес, проблема что инфраструктурно это сильно большое усилие для мелкого проекта, большому кораблю - большая торпеда)

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

[Wentixon]

Stanislav Pugachev, ну так можно его начинать использовать когда это становится необходимо. Разве так не лучше будет? А вообще я спросил о том, полезно было бы юзать докер на маленьком проекте БЕЗ kubernetes. То есть как вообще докер без него живёт и живёт ли если говорить об одном сервере

[Stanislav Pugachev]

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

[Евгений]

Stanislav Pugachev, я вот замечал что с докером всё работает медленнее в плане сетевого взаимодействия. Так что про всегда полезно я бы не сказал.

Answer 2

[Павел Волынцев]

1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое
2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?

Метки ставить можно. Даже полезно релизы метками отмечать. Всегда можно определить, на какой комит надо откатиться, чтобы локально восстановить версию кода как на сервере. И release notice писать по git log между метками, а не в памяти держать.

Постоянно чекать git не надо. Лишняя нагрузка на проц. Совершенно лишняя. Рекомендую веб-хуки или деплоить по SSH команде.

3. Как быть с адресами и портами.

Выносите в конфигурационные файлы или в параметры окружения

10+ вариантов на странице https://css-tricks.com/deployment/
Я для разного размера проектов пользовался
1. deployhq - как только обновляется ветка master - сервис обновляет сервер по SSH
2. веб-хуками из bitbacket + самописным веб-скриптом на PHP без таймлимита - как только приходит хук об обновлении ветки master, выполняется скрипт типа такого

cd /var/www/project
cp web/closed.bak web/closed.html # закрыть приложение
git pull
composer update && php yii migrate # как то код бэка обновить
npm run build # как то код фронта обновить
rm web/closed.html # открыть приложение

3. такой же командой, запускаемой через ssh, без веб-хуков. Это когда понадобилось сразу бэк и фронт пересобирать из разных репо и из разных веток. Ну типа демо из ветки develop, а релизы из ветки master на несколько серверов.
4. настраивали Jenkins для авто-установки

В принципе устраивает

Comments

[Даша Циклаури]

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

[Павел Волынцев]

Даша Циклаури, ничего против не имею. Пользовался ещё Capistrano и Deployer

Answer 3

[Denis Bedoyar]

3. У тебя должны быть отдельные конфиги под прод, тест и дев-машину.
1. Нормальная идея. Плюс в том, что пользоваться именем тега нагляднее чем хешем-коммита.

Answer 4

[Дмитрий Ларин]

1. возможно, но не вижу смысла.
2. зачем?
3. делать отдельные конфиги, в разных файлах.

Мое предложение - завести для деплоя отдельные ветку. Как только убедился что все работает - мержишь в боевую ветку изменения. На гите вебхук ловит это и запускает скрипт(допустим боевая ветка - master):
Коннектится к боевому серваку по ssl и запускает команды:
git fetch --all
git reser --hard origin/master
далее по вкусу миграци и тд и тп. Просто, дешево, сердито. Для мелочи идеально

Answer 5

[Vitsliputsli]

Раз вы работаете в Gitlab, то у вас уже есть инструмент для организации CI/CD.

1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое

Нет, это не очевидно и усложнит работу, если репы разные, то и версионирование у них должно быть разное. Если вам нужна последняя версия, вытаскивайте сразу master. А для обновления подключаемого внешнего ПО используйте специализированные программы (тот же composer в php).

2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?

А зачем постоянно чекать? В Gitlab есть хуки, если нужно какие-то действия осуществлять по push.

3. Как быть с адресами и портами. К примеру в index.js на девелоперской машине у меня прописано windows.base_url = "localhost:1234" а на сервере мне нужно "10.1.2.6:9000" как это это автоматизировать?

Все настройки должны быть в конфиге, при деплое конфиг настраивается в зависимости от среды. Можно сделать разные файлы для каждой среды, но все равно что-то придется менять конфиг при сборке (например, пароли к БД вы же не будете держать в репозитории).

Answer 6

[Vitaly Musin]

Пользуемся бесплатным CI gitlab, устанавливаешь на конечную тачку gitlab runner и привязываешь к проекту, в проекте описываешь деплой в виде yaml файла, который кладешь в корень. Это очень удобный и простой способ.

Answer 7

[roxblnfk]

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