Как я могу автоматически развернуть свое приложение после git push (GitHub и node.js)?


92

У меня есть приложение (node.js), развернутое на VPS (linux). Я использую git hub в качестве репозитория. Как я могу автоматически развернуть приложение на git push?


4
проверили ли вы git hooks progit.org/book/ch7-3.html , а также проверяли на github help.github.com/test-webhooks
Павел Дубиль,

1
Обновление для ссылки progit выше: git-scm.com/book/en/Customizing-Git-Git-Hooks
Code

Git 2.10 добавит интересную функцию: параметры push stackoverflow.com/a/38770670/6309
VonC

Ответы:


64

Пример на PHP:

Перейдите на github в свой репозиторий github и нажмите «Admin».

перейдите на вкладку 'Service Hooks' => 'WebHook URLs'

и добавить

http://your-domain-name/git_test.php

затем создайте git_test.php

<?php 
try
{
  $payload = json_decode($_REQUEST['payload']);
}
catch(Exception $e)
{
  exit(0);
}

//log the request
file_put_contents('logs/github.txt', print_r($payload, TRUE), FILE_APPEND);


if ($payload->ref === 'refs/heads/master')
{
  // path to your site deployment script
  exec('./build.sh');
}

В build.sh вам нужно будет поместить обычные команды для получения вашего сайта из github


6
Привет, большое спасибо. Что мешает Бобу выполнить мой сценарий развертывания?
Advanced

16
@Advanced 1 возможно, разрешения скрипта, флаг выполнения ... 2 добавление закрывающего тега в PHP - плохая практика.
Павел Дубель

3
@Advanced Один из способов убедиться, что Боб не выполняет ваш сценарий, - убедиться, что запрос POST поступает с серверов Github. Проверьте заголовки HTTP, которые они отправляют при выполнении запроса. Также вы можете создать «секретный» URL, который невозможно угадать.
jyap 04


1
@ Arius2038 Вы когда-нибудь слышали о том, что «каждый день узнаешь что-то новое»? ну это мое "что-то новенькое" сегодня. Спасибо, что поделился!
Purefan

23

Было несколько упоминаний хуков Git в качестве ответов / комментариев, которые срабатывали для меня в прошлом ... так что вот мой рецепт, если кому-то еще потребуется больше конкретики.

Я использую комбинацию git post-receive hook и node-supervisor для выполнения простого автоматического развертывания (при условии, что вы используете удаленный репозиторий git на этой машине).


Настройте крючок после получения

В вашем репозитории: sudo vi hooks/post-receive

И это должно выглядеть примерно так:

#!/bin/sh
GIT_WORK_TREE=/home/path/to/your/www
export GIT_WORK_TREE
git checkout -f

Установите права доступа к файлам: chmod +x hooks/post-receive

Git обновит файлы в каталоге вашего приложения после нажатия на репозиторий.


Запуск Node с Node-Supervisor

Вам нужно будет установить Node-Supervisor на свой компьютер в качестве модуля глобального узла: sudo npm install supervisor -g

Теперь просто запустите приложение node с помощью node-supervisor, и оно будет следить за изменениями файлов в вашем рабочем каталоге:

supervisor /home/path/to/your/www/server.js(примечание supervisorвместо node).


Это нормально, однако следует помнить о том, что если вы добавляете новый npm в свое локальное приложение, вам также необходимо выполнить установку npm для этого модуля на сервере. Если вы этого не сделаете, у вас, вероятно, будет сбой приложения.
k00k

2
Нет .. Любые модули узлов, от которых зависит мое локальное приложение, установлены в подкаталоге node_modules моего проекта, который является моим локальным репозиторием GIT, поэтому, когда я добавляю, фиксирую, а затем нажимаю на удаленный сервер, они также копируются.
Уэс Джонсон

8
Верно, но это означает, что если какой-либо из этих модулей имел код, который был скомпилирован (например, mhash), он может не работать на другом сервере с другой ОС и / или архитектурой. Использование package.json для отслеживания ваших зависимостей, а затем стратегия развертывания npm install -lна удаленном сервере - это разумно. Это, конечно, может быть связано с вашим методом с использованием обработчиков post-receive.
k00k

1
и вы можете просто добавить дерево работы Git в команду git checkout напрямую: git --work-tree = / var / www / tree --git-dir = / var / repo / deploy.git checkout -f (вместо создания переменная и экспорт ее в ваш скрипт.
JasonB

Однако вопрос касается Github.
Ной

18

Наверное, уже поздно отвечать здесь. Но я нашел этот проект на github и, кажется, делает то, что вы хотите, но гораздо чище.

https://github.com/logsol/Github-Auto-Deploy

Проверить это. Было бы также интересно узнать, что другие думают об этом с точки зрения комментариев и голосов.

Ура,
S


15
«Наверное, уже поздно отвечать здесь». Никогда не поздно. :) На самом деле вы вносите свой вклад в развитие всего сообщества (большинство из нас, гуглеров; вау, просто посмотрите на эти 20 тысяч просмотров!), Ни один парень не задал вопрос «какое-то время назад». Время само по себе не имеет значения: пока актуальна рассматриваемая технология , ваш ответ тоже будет актуален. (Спасибо за подсказку, кстати, проверяю ...)
Sz.

1
спасибо за внимание! ;) В то время у меня это работало отлично. Теперь я предпочитаю использовать travis (travis-ci.org) ( везде , где могу ) для автоматического развертывания. @lunakid
Кумар

8

В проекте, который я сейчас разрабатываю, я следую рекомендациям, изложенным в блестящей книге Джеза Хамбла «Непрерывная доставка» (которую стоит прочитать).

Это означает создание конвейера развертывания с использованием некоторой формы сервера непрерывной интеграции (я использую бесплатную версию Go сообщества Thoughtworks ), который отвечает за первую проверку вашего кода на качество, сложность и выполнение модульных тестов. Затем он может следовать конвейеру развертывания, что приводит к отправке на ваши производственные серверы.

Это звучит очень сложно, но не обязательно, и делает весь процесс написания кода безопасным и беспроблемным (никаких страшных дней выпуска!).

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


и еще +1 за рекомендацию книги! Я обнаружил, что к CI нельзя подходить случайно.
Меррик

ну люди задают простой вопрос, вы дадите полное решение :). Я должен сказать, что это перебор. Но если вы уже используете непрерывную доставку, возможно, вам стоит пойти по этому пути.
windmaomao

8

Я только что опубликовал решение вашей проблемы на основе узлов : node-cd

Он состоит из простого приложения узла, запущенного на вашем VPS, которое будет получать хуки после получения Github и выполнять сценарий, который вам нравится (например, сценарий оболочки, который убивает ваше приложение, git pull и перезапускает его).


+1, потому что это чистый node.js, поэтому постеру не нужно ничего добавлять в свой стек или использовать язык, который ему не подходит. Кроме того, действительно красиво оформленный код
code_monk

3

Вот еще одна простая реализация nodeJS.

Это очень простой сервер узла, который работает с настроенным вами именем хоста и портом и может быть настроен для обработки веб-хуков получения сообщений GitHub. А фактические действия pul / test / deploy можно настроить так, чтобы делать все, что вы хотите. В текущей реализации это команда оболочки, которая указана встроенным в сценарий сервера nodeJS. Также существует очень простая схема безопасности на основе secret_key.

https://github.com/shyam-habarakada/rscds

На моем промежуточном сервере уже был установлен и запущен узел, поэтому написать это было быстро и легко.


" yourdomain.com:8088/… " - ДЕЙСТВИТЕЛЬНО ?! "секретный" ключ передается в открытом виде в URL !!!! Никто не должен этим пользоваться.
Джулиан Найт

1
Выпей аспирин и успокойся, Джулиан. Параметры Get зашифрованы при использовании https.
Гэвин


2

Если вам нужно решение на основе python / tornado , я написал сценарий для обработки запросов POST от Github's Webhook Services . Вы можете найти его на https://github.com/Akobi/ops/tree/master/autodeploy.

Он в основном использует файл конфигурации JSON, чтобы перечислить, из каких репозиториев вы ожидаете отправки, какие команды вы хотите запускать при развертывании и в каком каталоге они должны запускаться. Все, что вам нужно сделать, это изменить файл конфигурации по своему вкусу и запустить сценарий!

Кроме того, я использую Nginx в качестве обратного прокси для пересылки этих POST-сообщений в свой скрипт. Вы можете найти конфигурацию Nginx в том же репозитории Github в папке nginx.

Удачного продвижения!


1

На мой взгляд, ответ PHP полностью законен, но если вы предпочитаете Ruby, я написал решение. это то же самое, что и ответ PHP, только на другом языке. вы используете веб-перехватчик, и у вас есть простой сценарий, который прослушивает соответствующие HTTP-запросы.

http://gilesbowkett.blogspot.com/2012/06/heroku-style-deployment-on-ec2.html


1

Я создал свой собственный элементарный инструмент развертывания, который автоматически загружал бы новые обновления из репозитория - https://github.com/jesalg/SlimJim - в основном он слушает github post-receive-hook и использует прокси для запуска скрипт обновления.


1

Я основатель https://commando.io, и недавно мы объявили об интеграции с GitHub через сервис. Интеграция позволяет запускать выполнение на серверах при отправке в репозиторий GitHub. Это прекрасная возможность для автоматического запуска сценариев развертывания при отправке кода.

Выполнение - это сценарий, который вы пишете внутри Commando.io, который может быть написан на bash, perl, python, ruby, go или node.js. Чтобы узнать больше и увидеть пример сценария выполнения git pull, см. Объявление в нашем блоге: http://blog.commando.io/run-executions-via-github-push/


1

Deepl.io кажется новым и многообещающим соперником в этой сфере.

Особенности (взяты с его веб-сайта):

  • Поймайте веб-перехватчики из GitLab и GitHub
  • Настроить несколько репозиториев
  • Настроить несколько веток для каждого репозитория
  • Используйте свои собственные сценарии развертывания: PHP, оболочку или и то, и другое.
  • Отправляет письма с подтверждением

1

Также обратите внимание, что существуют бесплатные / недорогие сервисы, такие как REPOMAN.IO, которые автоматизируют почти все это для вас.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.