#linux #nodejs #git #развертывание
Всем привет! Подскажите может уже есть готовое решение моей проблемы. Ситуация такая, есть у меня локально проект NodeJS допустим я сделал изменения и закомитил на гитхаб, хотелось бы что бы мой амазоновский сервер на Linux автоматически перекачал изменённые файлы и перезапустил проект. Такую систему я видел на OpenShift.
Ответы
Ответ 1
Когда вы делаете git push и на гитхабе появляется новый коммит, где-то должен выполниться код, который сделает всю работу. Исполнители Есть следующие варианты «исполнителей»: Использовать сервер непрерывной интеграции. Это приложение, которое реагирует на коммиты и выполняет какие-либо задачи с содержимым каждого коммита. Обычно эти задачи описываются в определенном файле проекта, который версионируется как любой другой код. Для того, чтобы его «уведомить» о появлении нового коммита, нужно будет использовать веб-хуки — HTTP POST запросы с заданным содержимым, которые отправляет GitHub. Документация к конкретному серверу расскажет вам, как интегрировать его с GitHub. Сервер CI – это современный, хорошо поддерживаемый и масштабируемый путь. Рекомендую. Примеры: облачные: Travis CI, Circle CI. Я также люблю GitLab CI, но он работает только с GitLab (т.е. не GitHub). Во всех трех есть бесплатные подписки для opensource-проектов. self-hosted: Jenkins, TeamCity, Bamboo. Сервер с приложением может сам выкачивать изменения, собирать и разворачивать проект, получая уведомление через веб-хук. Для этого понадобится держать на нём: Всё сборочное окружение, git и репозиторий с проектом, Открытый порт для получения команд. Этот способ плох по множеству причин: уязвимость, лишнее окружение, замусоренный сервер, плохо масштабируется, труднее восстанавливать «с чистого листа». Знайте, что так можно, но, пожалуйста, не делайте так. git hooks. Скрипты, которые запускает git на сервере при определенных условиях, например при получении коммитов. Хуки можно установить на свой сервер, например, если у вас self-hosted GitHub. На github.com, насколько я знаю, их установить нельзя. Вырожденный случай, наследующий всё плохое от последних двух вариантов, — когда один сервер используется как git-сервер для командной работы, с помощью гит-хуков сам на себе собирает код и публикует его сам себе куда-нибудь в /srv/www/project. Это отличный способ потерять всё и сразу. Задачи А работа состоит из следующих основных этапов: Сборка проекта из исходного кода. Так же, как вы обычно собираете сайт на своей машине. Артефакты сборки — это различные «полезные» файлы, которые являются результатом сборки. Например, папка с файлами сайта — это артефакт, а папка node_modules — не артефакт. Развертывание проекта в каком-либо окружении. Доставка артефактов и, если необходимо, операции администрирования. Развертывание в боевом окружении должно производиться из одной установленной стабильной ветки с осмысленным названием: master, production и т.п. Из других веток код разворачивается в тестовые окружения либо никуда. Тут подробнее про конкретные задачи и различные способы их выполнения: Деплой на мастер сервер. Вот очень устаревший ответ, описывающий доставку артефактов с помощью rsync и c помощью git (тот самый вырожденный случай). Из ценного там — про rsync. Настройка и развертывание проекта c помощью Git.
Комментариев нет:
Отправить комментарий