Суть переноса сайта с хостинга на VPS в использовании при разработке веб-сайта Git. Выглядело интересно, осталось только это все реализовать. Здесь можно пойти несколькими путями. Самый, наверное, простой — инициализировать локальный репозиторий и позволить разработчику при коммите выкладывать файлы прямо на сервер. Минус здесь — мы фактически даем ему доступ на сервер. Поэтому лучше перестраховаться, и самым правильным вариантом будет использовать посредника с возможностью автоматического pull файлов после коммита. Так мы получаем еще один источник бэкапа. В качестве промежуточного сервиса был выбран сервис «ведро битов» Bitbucket, предлагающий всякие вкусности вроде бесплатных «private»-репозиториев и удобного интерфейса. Хотя, в принципе, это может быть любой другой подобный сервис — GitHub или Google Cloud Source Repositories.nМеханизм взаимодействия будет простым. Создаем репозиторий (можно в отдельной теме), инициализируем Git прямо в корне сайта (как вариант, можно переносить с другого каталога, но это не так интересно), добавляем удаленный репозиторий Bitbucket и подключаем сервер к аккаунту Bitbucket.nЧтобы коммит на Bitbucket сразу попадал на веб-сайт, будем использовать механизм хуков. Сам Git предоставляет такую возможность, а в Bitbucket есть даже два варианта.nДля пула можно использовать протокол HTTPS или Git — ставить эту схему в уже рабочий сайт или разворачивать с нуля. В случае HTTPS меньше настроек, просто после инициализации подключаем удаленный репозиторий и в последующем тянем из него изменения.n
# git initn# git clone https://аккаунт@bitbucket.org/тема/репозиторий.git
Но если придется экстренно вносить правки в файлы вручную, то возможен конфликт при будущих pull. Если же используем SSH, то настроек чуть больше, но зато, поправив файл, можем сразу сделать commit, избежав возможных проблем.n
# git commit -a -m "wp-config correction"
Для подключения через Git/SSH нужно на Bitbucket загрузить публичный ключ.nГенерируем:n
# ssh-keygen -t rsa -b 4096 -C "[email protected]"
В качестве имени вводим bitbucket, чтобы не путаться. На запрос пароля жмем ввод. Меняем сразу права, иначе будет ругаться.n
# chmod 0600 ~/.ssh/bitbucket
Проверяем, работает ли ssh-agent:n
# eval "$(ssh-agent -s)"nAgent pid 7782
Добавляем ключ:n
# ssh-add ~/.ssh/bitbucketnEnter passphrase for /root/.ssh/bitbucket:n# ssh-add -l
Смотрим, чтобы в ~/.ssh/config была информация для идентификации хостаnBitbucket:
nnДобавляем публичный ключ bitbucket.pub на Bitbucket в настройках учетной записи «Безопасность -> SSH-ключи». После этого должны заходить ssh -Tvv [email protected] без пароля. Теперь у нас два варианта: пустой или рабочий сайт. Если сайт пустой, а репозиторий содержит данные, то просто делаемn
# git clone [email protected]:аккаунт/тема/репозиторий.git
Это вариант самый беспроблемный, так как сайт фактически ставим с нуля и не будет конфликтов между локальными файлами и теми, что уже есть в репозитории. В других случаях следует инициализировать репозиторий и добавить удаленный.n
# git initn# git remote add origin [email protected]:аккаунт/тема/репозиторий.git
осле чего тянуть изменения git pull origin master. Главная проблема в том, что Git не хочет инициализировать репозиторий в каталоге, в котором уже есть файлы. Выкрутиться можно несколькими способами. Самый простой — проделать это все в отдельном каталоге, а затем скопировать в рабочий и проверить работу git pull. Но файлы в Git и локальные не должны различаться, иначе придется использовать git checkout, который набросает лишние строки в файле, в результате можем получить нерабочий сайт. Причем нет необходимости переносить весь сайт, достаточно перенести только каталог .git.nНе забываем про права доступа. Так как имя начинается с точки, то шаблон * не сработает, нужно указать явно.n
# chown -R www-data:www-data /var/www/site/.*
Для большего контроля следует в .gitignore внести все файлы, которых не должны касаться изменения. Например, для WP это могут быть основные файлы и каталоги.nn
n
wp-config.phpnwp-includes/nwp-admin/nwp-content/uploads/
Теперь разработчик может выкладывать код в Bitbucket, а мы забирать на сайт.nОсталось только автоматизировать процесс. В Git это позволяет система хуков — фактически скриптов, выполняющихся в зависимости от наступления определенного события. Реализованы хуки и в Bitbucket. Причем доступно сразу два варианта: веб-хук (Webhooks) и службы. В логах они выглядят так:n
"POST /post.php HTTP/1.0" 200 236 "-" "Bitbucket-Webhooks/2.0"n"POST /post.php HTTP/1.0" 200 703 "-" "Bitbucket.org"
Настраиваются они через API или веб-интерфейс (меню «Настройки»). На проект можно создать несколько хуков. Для настройки веб-хука нужно указать URL и событие (всего 21 событие). В Webhooks на указанный в установках URL отправляется POST-запрос с данными в JSON-формате (в интерфейсе есть возможность просмотра View requests), при необходимости можно их отобрать и обработать запрос в зависимости от параметров.nВ «Службах» можно выбрать несколько вариантов, включая и POST-запрос, Twitter и обращение к различным сервисам.nn
nnНам для нашей схемы достаточно, чтобы Bitbucket при пуше (repo:push) просто «дернул» URL в веб-хуке, а мы по этому событию вытянем коммит из репозитория. Создаем простой скрипт:
nВ целях безопасности можно его назвать как-нибудь случайно типа 124dgrt48.php и ограничить доступ к скрипту из сетей Bitbucket: 131.103.20.160/27,165.254.145.0/26, 104.192.143.0/24. Хотя иногда приходится его вызывать из браузера. Указываем файл в настройках веб-хука на событие Repository push. Теперь при пуше разработчиком веб-сервер вытянет коммит из Bitbucket. В зависимости от настройки хостинга может не хватить прав доступа. В этом случае ничего не остается, как разрешить выполнять команду через sudo:n
shell_exec("sudo /usr/bin/git pull origin master 2>&1");
Набираем команду visudo и в /etc/sudoers записываем:n
www-data ALL=(root) NOPASSWD:/usr/bin/git
Вам необходима настройка VPS для разработки и продуктивного использования, обращайтесь [email protected]