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

Question

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

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

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

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

Буду ли я лучше создавать/var/www/writeable самостоятельно (а не только 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 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 Manual Page.

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

Answer 2

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

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

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

• Создание репозитория Dev: мерзавец клонировать центральное хранилище на сервере (например, 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-branchgit push -f origin live-branch. Считайте это снимком вашего кода, а не веткой, которая останется стабильной.

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

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

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

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