(Инструкция, которую приходится копировать из проекта в проект, поэтому пусть будет и в блоге.)<\/p>\n
Предполагается, что Deployer доступен уже в проекте, либо как файл `.\/dep`, либо как установленный composer пакет через `.\/vendor\/bin\/dep`. Он добавляется и хранится в гит-репозитории.<\/p>\n
Также важно настроить конфиги, указав хост в `.\/deploy.php`. Они также хранятся в репозитории.<\/p>\n
`.\/dep deploy Предположим, вы хотите сменить на `dev` ветку с `develop` на `feature\/TASK-82-history-mypractice`.<\/p>\n Вы можете это сделать, поменяв `→set(’branch’, ’feature\/TASK-82-history-mypractice’)` в deploy.php для хоста `dev`, а потом запустить `.\/dep deploy dev`.<\/p>\n Этот способ хорош, если хочется быстро показать ветку, и мы не ожидаем, что будет много фиксов, так как Gitlab CI всё ещё останется настроен на `develop` ветку. И поэтому:<\/p>\n Под root<\/tt>-пользователем работать небезопасно, равно как и делать весь проект доступным www-data<\/tt>. Создать нового пользователя deploy с правами на коннект к серверу по ssh, доступом только к папке с проектом и возможностью изменять файлы в .\/public\/uploads<\/tt> и .\/var<\/tt>.<\/p>\n Создаём на сервере пользователя deploy<\/tt> из-под root<\/tt>:<\/p>\n Настроим доступ по ssh через ключи<\/p>\n Вставьте содержимое одного из публичного ключа своего локального пользователя в файл authorized_keys<\/tt> и сохраните. Вывести публичный ключ локально можно командой: cat ~\/.ssh\/id_rsa.pub<\/tt> (название ключа id_rsa.pub<\/tt> у вас может отличаться).<\/p>\n Меняем права на более строгие<\/p>\n Определим пользователя нашего веб-сервера (в примере ниже это www-data<\/tt>)<\/p>\n Добавляем пользователя deploy<\/tt> в группу www-data<\/tt> (группа веб-сервера)<\/p>\n Выставляем права на папку проекта<\/p>\n Проверим, есть ли setfacl в системе setfacl -h<\/tt> и установим, если его нет. Команда для Ubuntu:<\/p>\n Выдадим права на папки с кэшем, логами и загруженными пользовательскими файлами<\/p>\n Готово.<\/p>\nКак сменить деплой-ветку для хоста<\/h2>\n
Простой и быстрый вариант для быстрых тестов<\/h3>\n
\n
Правильный вариант с обновлением Gitlab CI правил<\/h3>\n
\n
Как переключить хост с feature1-ветки на другую feature-2 ветку:<\/h3>\n
\n
Удобные команды<\/h2>\n
\n
Первый деплой \/ создание окружения<\/h2>\n
\n
\n
\n
Проблема<\/h3>\n
\nКроме того, во многих веб-приложениях пользователи имеют возможность загружать свои файлы. И очень часто с такими файлами возникают конфликты, так как пишутся они под www-data:www-data<\/tt>, а деплоим под другим пользователем. Даже если деплоить под root<\/tt>, то скорее всего права на папку перепишутся и www-data<\/tt> потеряет доступ к нужным файлам.<\/p>\nРешение<\/h3>\n
ssh root@вашсервер\r\nuseradd --create-home -s \/bin\/bash deploy<\/code><\/pre>mkdir \/home\/deploy\/.ssh\r\ntouch \/home\/deploy\/.ssh\/authorized_keys<\/code><\/pre>vim \/home\/deploy\/.ssh\/authorized_keys<\/code><\/pre>chown -R deploy:deploy \/home\/deploy\r\nchmod 600 \/home\/deploy\/.ssh\/authorized_keys<\/code><\/pre>ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\\ -f1\r\n> www-data<\/code><\/pre>usermod -a -G www-data deploy<\/code><\/pre>chown -R deploy:deploy \/var\/www\/project\r\nchmod -R 0775 \/var\/www\/project<\/code><\/pre>sudo apt-get install acl<\/code><\/pre>sudo setfacl -dR -m u:www-data:rwX -m u:deploy:rwX \/var\/www\/project\/var \/var\/www\/project\/public\/uploads\r\nsudo setfacl -R -m u:www-data:rwX -m u:deploy:rwX \/var\/www\/project\/var \/var\/www\/project\/public\/uploads<\/code><\/pre>