Конфигурация развертывания git / github и веб-сервера

Question

Я использую веб-сервер Apache, и мне было интересно, как лучше всего внедрить изменения (из github) на веб-сервере?

/ var / www / прямо сейчас доступен для записи только пользователю root.

Должен ли я иметь свой проект git прямо в / var / www /? (поэтому он создает /var/www/.git/?)

Однако, когда мне нужно выполнить команды (то есть sudo git push) не будет работать (так как мои ssh-ключи не находятся под sudo).

Мне лучше сделать / var / www / доступным для записи самостоятельно (а не просто root)? Или я должен добавить ssh ключи для пользователя root? Или я должен сделать что-то еще полностью?

Спасибо.

Answer 1

Я использую rsync для синхронизации содержимого моего локального компьютера с сервером, и если вы просто развертываете на одном сервере, то это довольно просто (и Capistrano излишний.).Я поместил следующие псевдонимы в ~/.bash_profile:

alias eget='rsync -avie ssh matt@example.com:sites/example.com/www/ ~/Projects/example/example.com/www/ --exclude .DS_Store --exclude ".git*" --delete-after'
alias edep='rsync -avuie ssh ~/Projects/example/example.com/www/ matt@example.com:sites/example.com/www/ --exclude .DS_Store --exclude ".git*" --delay-updates --delete-after'

Затем из репозитория git на моей локальной машине.Я делаю:

git commit -am 'commit some changes'
git pull --rebase # pull any new changes from remote (--rebase prevents an unnecessary merge commit.)
eget -n # confirm which files I've changed

Если это выглядит подозрительно, я мог бы сделать eget без -n и затем просто сделать git diff -w.Затем я могу сделать git checkout -- path/to/file для файлов, для которых я хочу сохранить свои изменения.Затем я фиксирую изменения, которые были на сервере, которые я еще не получил.Это произойдет только в том случае, если файлы на сервере изменяются не так, как при развертывании.В противном случае вы знаете, что ваша локальная версия всегда более актуальна, чем файлы на сервере, и поэтому вам не нужно беспокоиться о перезаписи вещей на сервере, которых у вас еще нет на вашем локальном компьютере.Продолжить ...

edep -n # just see what files will be deployed/updated/etc.
edep # looks good. Deploy for real.

Готово!

Посетите страницу руководства rsync (1) Mac OS X для получения дополнительной информации.

Другойопция заключается в использовании Git post-receive hook .Но для этого вам нужно установить Git на сервере.Кроме того, я рекомендую размещать каталог .git вне общедоступного каталога www из соображений безопасности и чистоты.Вы можете сделать это с помощью опции конфигурации Git core.worktree.Например, с ~/git/example.com.git, сделайте git init --bare; git config core.worktree ~/sites/example.com/.Это делает ~/git/example.com.git как .git dir для ~/sites/example.com/.

Answer 2

Создайте центральный репозиторий, используйте ветвление git для создания разных веток для разных целей, и никогда не обслуживайте весь свой репозиторий публично, и при этом вы никогда не должны обслуживать свой каталог .git публично (поскольку это то же самое, что обслуживать все, что высделал с кодом или выложил в репозиторий для публики).Вдобавок ко всему, вот рекомендации, которые я рекомендую, исходя из моего собственного опыта:

• Создайте central / hub репозиторий для кода.(необязательно, но рекомендуется. Еще лучше использовать github.com для вашего центрального хранилища).Затем вы можете проверить локальные копии для локальных развертываний, например, когда вы хотите восстановить сайт на своем ноутбуке.Не обязательно, но очень удобно и гарантирует, что ваш сайт является портативным.Вы можете иметь промежуточное хранилище и промежуточную ветвь для целей разработки.У вас также может быть хранилище и филиал для производственных целей.

• Создайте явно открытый каталог в хранилище, который является , а не корнем хранилища: Например, СоздайтеКаталог / www / или / serve / или / public / в репозитории.Это то, что будет общедоступно и индексируется поисковыми системами, поэтому будьте осторожны, что там происходит.Предположим, что все, что идет туда, является общедоступным, кешируется на вечность и станет целью атак уязвимости безопасности (потому что это легко может быть правдой).

• Создайте репозиторий dev: git clone центрального репозитория на сервере (например, cd /home/tchal затем git clone git@github.com:tchalvak/ninjawars.git), хотя в идеале это должна быть папка с общими правами доступа для вашей группы разработчиков.

• Создать символическую ссылкудля вас разработка сайта: cd /var/www/, ln -s /url/to/shared/repository/public/ nickNameForDevSiteHere, создание символической ссылки только на обслуживаемые / публичные файлы сайта, создание простого уровня разработки сайта.(необязательно, но рекомендуется).Таким образом, сайт разработчика может быть легко доступен через некоторый ip и псевдоним, например, http://10.0.1.123/publicdevelopmentsitenickname без необходимости использования реального доменного имени.

• Укажите коммит живого и развернутого кода,Возможно, вы захотите создать live-branch для любого кода, который в данный момент является «живым», просто имейте в виду, что эту ветвь, вероятно, придется периодически перезаписывать, например, git branch live-branch git push -f origin live-branch.Считайте, что это снимок вашего кода, а не ветвь, которая останется стабильной.

• Если вы уверены, что сайт разработчика был достаточно хорошо протестирован, либо разверните live-branchкодируйте вручную, с помощью пользовательского сценария развертывания или используйте отдельный репозиторий с извлеченной в нем ветвью live-ветки, обслуживающей только явно общедоступный контент, аналогичный сайту dev.

  • createвиртуальный хост в apache для доменного имени.Например, вы можете использовать что-то вроде: <VirtualHost *> ServerName greatdomain.com ServerAlias www.greatdomain.com DocumentRoot /srv/greatdomain/www/ </VirtualHost> Это огромная тема, поэтому, если вы не знаете всех деталей, я рекомендую углубиться в изучение настройки виртуального хоста в apache.

  • Укажите свой DNS для доменного имени по ip-адресу сервера.

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