Как развернуть проект из github

wheekey / Развернуть проект create react app на сервере

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

1) Проект создан используя https://github.com/facebook/create-react-app

2) Разворачивание проекта на серваке:

2.1 Заливаем код

2.2 npm install

2.3 Делаем билд приложения:

npm build

2.4 Далее устанавливаем сервер

https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#deployment

npm install -g serve

2.5 Запускаем приложение serve -s build

Можно укзаать порт: serve -s build -p 5001. По умолчанию 5000.

2.6 Открываем порт (если CENTOS 7): https://stackoverflow.com/questions/24729024/open-firewall-port-on-centos-7

firewall-cmd —zone=public —add-port=5000/tcp —permanent

firewall-cmd —reload

2.7 Пока не разобрался как это запускать через pm2, поэтому запущу вот так: cd && nohup serve -s build > /dev/null 2>&1&

Как развернуть GitHub проект (Git репозиторий) на хостинге?

Как автоматически сделать развертывание GitHub проекта на хостинге с мориторингом изменений.

Вопрос задан более трёх лет назад
5825 просмотров

1 комментарий

Оценить 1 комментарий

На хостинге сложно что то развернуть, может есть скрипты для подобного.
Но если взять VDS который стоит 100р/мес, то развертывание ничем не будет отличатся от работы с собственным компьютером.

Решения вопроса 1

Ну и поиск в гугле по «Deploying from GitHub to a Server» и прочим запросам выдает кучу ответов.
Я бы еще мог понять ваш вопрос в ключе «я делал вот так, по этой инструкции и у меня не вышло».

Развертывание локального репозитория Git в Службе приложений Azure

В этом руководстве показано, как развернуть в службе приложений Azure собственное приложение из репозитория Git на локальном компьютере.

Необходимые компоненты

Выполните следующие шаги для изучения данного руководства.

Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
Установите Git.
Обеспечьте локальный репозиторий Git кодом, который вы хотите развернуть. Чтобы скачать пример репозитория, выполните следующую команду в локальном окне терминала.

git clone https://github.com/Azure-Samples/nodejs-docs-hello-world.git

Подготовка репозитория

Чтобы получать автоматические сборки с сервера сборки Службы приложений Azure, убедитесь, что корень репозитория содержит нужные файлы проекта.

Параметры выполнения	Файлы в корневом каталоге
ASP.NET (только для Windows)	\.SLN-файлы, \.CSPROJ-файлы или default.aspx
ASP.NET Core	\.SLN-файлы или \.CSPROJ-файлы
PHP	index.php
Ruby (только для Linux)	Gemfile
Node.js	server.js, app.js или package.json со сценарием запуска
Python	PY-файлы, requirements.txt или runtime.txt
HTML	default.htm, default.html, default.asp, index.htm, index.html или iisstart.htm
веб-задания;	/run. в папке App_Data/jobs/continuous для непрерывных веб-заданий App_Data/jobs/triggered для активируемых веб-заданий. См. сведения в документации по веб-заданиям Kudu.
Функции	Ознакомьтесь с разделом Непрерывное развертывание для Функций Azure.

Чтобы настроить развертывание, добавьте в корень репозитория DEPLOYMENT-файл. См. сведения о настройке развертываний и настраиваемом скрипте развертывания.

Если вы используете Visual Studio, позвольте Visual Studio создать репозиторий для вас. Ваш проект будет немедленно готов к развертыванию через Git.

Настойка пользователя развертывания

См. статью Настройка данных развертывания для службы приложений Azure. Можно использовать либо учетные данные области пользователя, либо учетные данные области приложения.

Создание приложения с поддержкой Git

Если у вас уже есть приложение Службы приложений и вы хотите настроить для него локальное развертывание на Git, см. раздел Настройка существующего приложения.

Запустите az webapp create с —deployment-local-git параметром. Например:

az webapp create --resource-group --plan --name --runtime "" --deployment-local-git

Выходные данные содержат URL-адрес следующего вида: https://@.scm.azurewebsites.net/.git . Используйте этот URL-адрес для развертывания приложения на следующем шаге.

Выполните команду New-AzWebApp из корня репозитория Git. Например:

New-AzWebApp -Name

При запуске этого командлета из каталога, который является репозиторием Git, он автоматически создает удаленный репозиторий Git для вашего приложения Службы приложений с именем azure .

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

Настройка существующего приложения

Если вы еще не создали приложение, см. статью Создание приложения с поддержкой Git.

az webapp deployment source config-local-git --name --resource-group

Этот URL-адрес содержит имя пользователя для развертывания области пользователя. При желании вместо этого можно использовать учетные данные области приложения .

Настройте scmType приложения, выполнив командлет Set-AzResource .

$PropertiesObject = @ < scmType = "LocalGit"; >Set-AzResource -PropertyObject $PropertiesObject -ResourceGroupName ` -ResourceType Microsoft.Web/sites/config -ResourceName /web ` -ApiVersion 2015-08-01 -Force

Shows how to enable local Git deployment for App Service in the Azure portal

На порталеAzure перейдите на страницу вашего приложения.
В меню слева выберите параметры Настройки центра развертывания. Выберите Локальный git в источнике, а затем нажмите кнопку Сохранить.
В разделе Local Git скопируйте Git clone URL для последующего использования. Этот URL не содержит никаких учетных данных.

Развертывание веб-приложения

В локальном окне терминала измените каталог на корень репозитория Git и добавьте удаленный Git с помощью URL-адреса, полученного из приложения. Если выбранный метод не предоставляет URL-адрес, используйте https://.scm.azurewebsites.net/.git с именем приложения в .

git remote add azure

Изменение ветви развертывания

Когда вы отправляете фиксации в репозиторий Службы приложений, Служба приложений по умолчанию развертывает файлы в ветви master . Так как многие репозитории Git перемещаются из master в main , необходимо убедиться в том, что вы выполняете отправку в правильную ветвь репозитория Службы приложений. Это можно сделать двумя способами.

git push azure main:master

az webapp config appsettings set --name --resource-group --settings DEPLOYMENT_BRANCH='main' git push azure main

Устранение неполадок с развертыванием

При использовании Git для публикации в приложении службы приложений в Azure могут отобразиться следующие распространенные сообщения об ошибках.

Сообщение	Причина	Решение
Unable to access ‘[siteURL]’: Failed to connect to [scmAddress]	Приложение не работает и не запущено.	запуск приложения на портале Azure. Развертывание Git недоступно, когда веб-приложение остановлено.
Couldn’t resolve host ‘hostname’	Неверные сведения об адресе удаленного ресурса Azure.	используйте команду git remote -v , чтобы вывести список всех удаленных репозиториев с соответствующими URL-адресами. Проверьте правильность URL-адреса удаленного репозитория «azure». При необходимости удалите и повторно создайте этот удаленный репозиторий, используя правильный URL-адрес.
No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as ‘main’.	Вы не указали ветвь в процессе git push или не задали push.default значение в .gitconfig .	Выполните команду git push еще раз, указав главную ветвь: git push azure main .
Error — Changes committed to remote repository but deployment to website failed.	Вы отправили локальную ветвь, которая не соответствует ветви развертывания приложения в Azure.	Убедитесь, что текущая ветвь — master . Чтобы изменить ветвь по умолчанию, используйте параметр приложения DEPLOYMENT_BRANCH (см. раздел Изменение ветви развертывания).
src refspec [branchname] does not match any.	Предпринята попытка принудительной отправки в удаленную ветвь Azure, отличную от Main.	Выполните команду git push еще раз, указав главную ветвь: git push azure main .
RPC failed; result=22, HTTP code = 5xx.	эта ошибка может возникнуть при попытке отправить большой репозиторий Git по протоколу HTTPS.	Измените конфигурацию Git на локальном компьютере, чтобы увеличить postBuffer . Например: git config —global http.postBuffer 524288000 .
Error — Changes committed to remote repository but your web app not updated.	Вы развернули приложение Node.js, содержащее файл package.json, в котором указаны дополнительные необходимые модули.	Проверьте npm ERR! сообщения об ошибках, предшествовавшие этой ошибке, для получения дополнительных сведений о сбое. Ниже перечислены известные причины этой ошибки и соответствующие npm ERR! сообщения.

Неправильно сформированный пакет файлов json: npm ERR! Couldn’t read dependencies.

Дополнительные ресурсы

Сервер сборки службы приложений (документация по проекту Kudu)
Непрерывное развертывание в Службе приложений Azure
Пример. Создание веб-приложения и развертывание кода из локального репозитория Git (Azure CLI)
Пример. Создание веб-приложения и развертывание кода из локального репозитория Git (PowerShell)

Деплой проекта на сервер из Github

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

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

А потом я наткнулся на ранее неизвестные мне возможности Git — его хуки.

Читаем документацию и видим, что

Хук post-merge запускается после успешного выполнения команды merge. Его можно использовать для восстановления данных в рабочей директории, которые Git не может отслеживать, такие как права доступа. Так же этот хук может проверять наличие внешних по отношению к Git файлов, которые вы захотите скопировать при внесении изменений.

А это значит, что мы можем запускать любые произвольные скрипты при успешном скачивании изменений из Git. Так что нам нужно сделать 6 простых шагов:

1. Генерируем SSH ключ для Github

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

сохраняем его в какую-нибудь временную директорию с именем id_rsa . Не затрите случайно свой основной ключ в системе!

Я сохраняю в директорию Downloads .

2. Добавляем публичную часть ключа в репозиторий своего проекта
Нам нужно вставить содержимое id_rsa.pub в настройки Deploy Keys проекта на Github:

cat ~/Downloads/id_rsa.pub

Allow write access не отмечаем! нам же не нужно, чтобы при взломе хостинга была возможность что-нибудь натворить с репозиторием проекта, правда?

3. Устанавливаем приватную часть ключа юзеру хостинга
Нужно скопировать содержимое cat ~/Downloads/id_rsa на своём компе и вставить в nano ~/.ssh/id_rsa на хостинге. Если на хостинге уже есть какой-то основной ключ у юзера — не затрите его! Лучше поищите как сохранять несколько ключей и использовать их раздельно для разных подключений.

Еще нужно указать строгие права на свой ключ: chmod 600 ~/.ssh/id_rsa

4. Скачиваем этот репозиторий в рабочую директорию сервера
Ну тут просто git clone git@github.com:username/project.git — смотрите точнее у себя на Github. Главное, чтобы доступ был именно по SSH — мы же для него ключ и установили.

Лично у меня каждый проект на сервере под своим юзером и в своей рабочей директории, поэтому я и скачиваю его в корень этой директории. Если Git будет ругаться, что файлы уже существуют, то нужно сделать pull во временную директорию, а потом перенести всё оттуда в корень, включая скрытую .git .

Вот так это выглядит в итоге:

Смысл в том, чтобы дальше вы могли делать git pull из корня проекта, и это бы обновляло все ваши файлы в нём из репозитория.
В принципе, подобная возможность скачивания обновлений уже решает некоторые проблемы, например когда из-за неустойчивого соединения при выгрузке из PhpStorm, весь сайт падает от того, что половина файлов новая, а другая еще нет.

5. Но мы идём дальше и создаём наш хук post-merge:

nano ~/.git/hooks/post-merge

Где пишем что-то вроде

#!/bin/bash /usr/bin/composer install --working-dir ~/core --no-dev php ~/core/vendor/bin/phinx migrate -c ~/core/phinx.php cd ~/frontend && ./node_modules/.bin/yarn install cd ~/frontend && ./node_modules/.bin/yarn build cd ~/frontend && ./node_modules/.bin/yarn restart

Ну или какие у вас там скрипты? Вот их и пишите.

Теперь при успешном git pull , когда есть какие-то изменения, будут запускаться эти команды.

6. Осталось только добавить проверку в cron

crontab -e

MAILTO=your_email@example.com */30 * * * * git pull

И тогда каждые 30 минут будет проверяться ваш репозиторий.

Вам нужно только пушить ваш протестированый код в основную ветку на Github, откуда его загрузит рабочий сервер, а хук post-merge запустит ваши скрипты. Отчеты об успешной работе или об ошибках (если таковые будут) прилетят на почту, указанную в MAILTO — их пришлёт сам cron.

При таком подходе вся работа производится через Git, вы сами не лезете на сервер, и не вносите там никаких изменений вручную. Это гарантирует, что в продакшне у вас всегда ровно тот код, который вы выгрузили в основную ветку.

Лично мне такая простая настройка проектов очень сильно облегчает жизнь уже полгода. Никаких недостатков за это время я не нашёл, так что делюсь этим способом с вами.

01 октября 2020, 11:54

Василий Наумкин /users/bezumkin modx.pro https://modx.pro

Комментарии: 23

01 октября 2020, 12:18
а можно ли как то вместе с этим и базу синхронизировать?
01 октября 2020, 12:24

Миграции и так синхронизируются — они в файлах, и хранятся в Git.

А содержимое БД версионировать это странная какая-то идея, она же на десятки гигабайт может быть.

01 октября 2020, 12:31

Ты просто никаким образом не пометил что это не для MODX, поэтому люди будут задавать такие вопросы 🙂
А вообще да в xpdo миграций нет, поэтому нужно сэтапить CI интеграции используя транспортные пакеты.

01 октября 2020, 15:50

Ты просто никаким образом не пометил что это не для MODX

А какая разница? Если MODX, то что, нужно всю БД в Git хранить?

Давно придуманы и Gitify, и файловые элементы.

А вообще да в xpdo миграций нет

А причём здесь xPDO? У меня миграциями Phinx занимается, ему не важно какие команды выполнять, хоть mysqli_execute пиши. Это же просто набор PHP скриптов, которые накатываются и откатываются в определённом порядке.

Заметка вообще про хуки Git, без привязки к системам.

01 октября 2020, 21:31

Подскажите, я полистал документацию по phinx. Я правильно понял что это не просто инструмент для создания таблиц на основании php миграций, а это полностью ORM? Вижу тут и работу с данными, и выборки и условия. То есть отдельно ORM вы в проекте уже не пользуетесь типа Eloquent или Doctrine?

02 октября 2020, 06:44

Я правильно понял что

Нет, это консольная утилита для запуска миграций.

Просто она из CakePHP, поэтому и в документации примеры по работе внутри этой системы. Но и без неё Phinx отлично самостоятельно запускает миграции.

То есть отдельно ORM вы в проекте уже не пользуетесь типа Eloquent или Doctrine?

Именно Eloquent я везде и использую.
02 октября 2020, 10:33

К этой схеме работы можно еще добавить плагин в phpStrom называется phinG. То есть в ручную запустить на удаленном сервере этот баш.
Мануал по нему somethingabout.ru/post/phing-deploy-proekta-na-prodakshen-v-1-klik

02 октября 2020, 10:43
Зачем какие-то плагины к IDE, если SSH и так умеет запускать команды на удалённом сервере?

ssh email@example.com ls -lsh

Это выведет тебе файлы в директории юзера, под которым ты авторизуешься.

Точно так же можно делать и git pull , но делать вручную мне это лень, так что я повесил задачу на cron.

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

02 октября 2020, 10:49

Дак я про альтернативу и не говорю. Это как раз для ленивых чтобы на сервер не заходить постоянно: prnt.sc/urq1ve
.
Можно любую команду удаленно выполнить.

02 октября 2020, 12:36

Основной посыл Василия понятен. Поскольку он при разработке пользуется всякими системами сборки типа вебпака, миграциями баз данных, то он автоматизирует процесс запуска этих моментов, написав некий bash скрипт, который выполняется как хук для git, а сам git запускается по крону. Хороший вариант и как информация — интересно.
Мне показалось слишком запутанным манипуляции с ssh ключами. Но я наверное не знаю что такое deploy ключи, всегда пользовался просто ssh ключем который можно указать в настройках аккаунта, а не отдельного репозитория.
Василий (а может и не только Василий), а поделитесь ка пожалуйста такой информацией если найдете минуту. Знаю вы активно используете webpack. Вчера у меня было время и я ради интереса решил ознакомится с инструментом этим. Разумеется поверхностно. И мне показалось что это хороший инструмент для верстки, для статичных сайтов или же для проектов на чистом js. И мое самое большое недоумение — это как этим пользоваться на php фреймворках. Как бы так описать, что вызвало это недоумение. Вебпак так или иначе собирает скрипты, стили в файлы и в имени файла есть некий хеш, чтобы избежать кеширования в браузере пользователя. Эти файлы должны как-то подключаться в шаблон. Так вот на всех примерах и видео которые я просмотрел, все это происходило так — был отдельно файл index.html в котором создавался html код. а потом вебпак при сборке этот файл обрабатывал, добавлял к нему подключение файлов c учетом хеша в имени. Но в php фреймворках у нас нет готового заранее html. Я вот использую например twig шаблонизатор и все что есть — это его файлы. Как это решаете вы? Как в ваши html шаблоны подключаются файлы, генерируемые вебпаком? И второе недоумение вызвал devServer вебпака. Удобная штука, хранит бандлы в оперативной памяти и все такое, но это ведь сервер на js? на node js вернее и он никак не сможет запустить php и отобразить страницу в браузере?

02 октября 2020, 14:33

так вебпак и не будет работать с php, если рассматривать связку вебпака с php бекендом, то это какраз получится spa приложение, где фронт отдельно, бэк отдельно, на фронте через вебпак собираются js, css, html делаются запросы к php и получается продукт. Вебпак может быть использован при сборке бекенда, но только если бекенд написан на nodejs.

02 октября 2020, 14:48

ну я просто в вебпаке совсем профан, но да — почувствовал вчера, что он совсем не годиться для обычного php фреймворка. Не какихто новомодных spa и прочих, а там где html формируется на сервере.
Спасибо, вы подтвердили мое мнение.

02 октября 2020, 15:40

Это ошибочное поспешное мнение.
Во первых webpack не обязательно создает хешированные имена файлов, а вполне себе способен перезаписывать один и тот же файл — достаточно при конфигурации имя указать.
Да собственно и все. Во-вторых писать не зачем.
Собираете фронт у себя на компьютере, выгружаете на сервер. Точно так же, как если бы работал с GULP сборщиком например.

02 октября 2020, 16:15

наверное вы правы, да.
Вроде бы и можно использовать, а вроде как из пушки по воробьям стрелять.
По крайней мере выгоды перед галпом никакой, а в изучении сложнее.
Да и например в фреймворке Yii2 там есть свой механизм перемещения статичных файлов (изображений, стилей, js — ок) в публичную директорию и мне кажется это будет конфликтовать.
Но это так — совершенно не на чем не основанные выводы, никогда не использовал ни webpack ни gulp, да и что-то подсказывает что не буду.
Вчера смотрел видео по webpack (хорошее и качественное) и ловил себя на мысли, что я не понимаю и не принимаю новых тенденций. В предыстории говориться, что в незапамятные времена скрипты в проект подключали просто ужасно через script src = и это так ужасно. Что человечество изобрело вебпак. И после этого начинается — установим nodejs, установим вебпак. А в это время в терминале где отображается ход установки — загружено 24658 файлов в node_modules. Установим кучу плагинов, создадим безумный конфигурационный файл, будем каждый раз запускать пересборку всего проекта, когда добавили строчку в код. И по итогу одна строка console.log(‘hello world’) в нашем скрипте превращяется в 100 строк (без шуток) кода в сгенерированном вебпаком файле, в котором код запускается через eval и… у всех это вызывает радость и восторг.
Наверное я просто не пишу настолько сложного кода, чтобы данный инструмент начал приносить удовольствие, а не раздражение.

02 октября 2020, 16:26

Ну если на JS только hello world писать — то конечно это бессмысленое занятие.
А если в проекте половина на JS написана — это уже другой разговор.
А попробуйте разделять код проекта на логические модули, каждый из которых находится в отдельном файле.
А попробуйте еще библиотеки и инструменты для работы подключать из npm например.

Чтобы еще раз не отвечать зачем вообще все эти node_modules если можно любую нужную библиотеку локально скачать — сразу отвечу. Чтобы через полгода одной командой npm update обновить сразу все используемые библиотеки и зависимости.
Вы же наверное следите чтобы версия MODX свежей была на тех проектах, за которые отвечаете.
Так и за другими составными частями следить нужно. А использовать NPM это самый простой способ.

И еще позволю себе совет — вместо того чтобы в каждой ветке новые длиннющие рассуждения писать — было бы полезно тратить этот час в день на самообразование. Но это лишь мое мнение, которое я просто оставлю здесь. Спасибо. Пойду займусь самообразованием ))