(Инструкция, которую приходится копировать из проекта в проект, поэтому пусть будет и в блоге.)

Предполагается, что Deployer доступен уже в проекте, либо как файл `./dep`, либо как установленный composer пакет через `./vendor/bin/dep`. Он добавляется и хранится в гит-репозитории.

Также важно настроить конфиги, указав хост в `./deploy.php`. Они также хранятся в репозитории.

Обычные / регулярные деплои

`./dep deploy `, где в качестве можно выбрать любой хост из deploy.php файла. В этом файле у хоста указана нужная ветка. Однако, делать это обычно не нужно, так как на проекте настрое Gitlab CI (см файл `.gitlab-ci.yaml`), который зарелизит код по коммиту.

Как сменить деплой-ветку для хоста

Предположим, вы хотите сменить на `dev` ветку с `develop` на `feature/TASK-82-history-mypractice`.

Простой и быстрый вариант для быстрых тестов

Вы можете это сделать, поменяв `→set(’branch’, ’feature/TASK-82-history-mypractice’)` в deploy.php для хоста `dev`, а потом запустить `./dep deploy dev`.

Этот способ хорош, если хочется быстро показать ветку, и мы не ожидаем, что будет много фиксов, так как Gitlab CI всё ещё останется настроен на `develop` ветку. И поэтому:

• при коммите в `develop` ветку, Gitlab CI запустит `./dep deploy dev` и задеплоит `feature/TASK-82-history-mypractice` на `dev`. Но это неправильно, так как мы не хотим деплоить эту ветку на дев по коммиту в `develop`, мы хотим деплоить по коммиту в ветку `feature/TASK-82-history-mypractice`
• при коммите в `feature/TASK-82-history-mypractice` ветку CI ничего не сделает, так как в версии конфига `.gitlab-ci.yaml` из этой ветки нет никакого правила для ветки `feature/TASK-82-history-mypractice`.

Правильный вариант с обновлением Gitlab CI правил

1. Переключиться в `develop` ветку, изменить branch в deploy.php для нужного хоста и в `.gitlab-ci.yaml` изменить параметр `only:` для этого же хоста.
2. Закоммитить. CI теперь не запустит деплой на `dev`, так как мы поменяли ветку на `feature/TASK-82-history-mypractice`.
3. Переключиться в ветку `feature/TASK-82-history-mypractice` в git и вмерджить в неё свежий `develop`. Вместе с develop придут изменения для `deploy.php` и `.gitlab-ci.yaml`. Поэтому если сразу закоммитить вмёрдженное, то Gitlab CI запустит деплой feature-ветки на `dev`.
4. Важно! Перед мерджем ветки в `develop` нужно изменить `deploy.php` и `.gitlab-ci.yaml` и заменить feature-ветку в них обратно на `develop`. Потом смерджить и Gitlab CI, увидев этот коммит в develop, сразу продеплоит `develop` на `dev`.

Как переключить хост с feature1-ветки на другую feature-2 ветку:

1. Переключиться в develop ветку и изменить в ней `deploy.php` и `.gitlab-ci.yaml`, указав feature2 вместо feature1 для нужного хоста.
2. Вмерджить develop ветку сначала в feature1 ветку, потом в feature2 ветку.

Удобные команды

1. `./dep ssh ` — команда подключится к хосту по конфигу из deploy.php и сделает перейдёт в папку current релиза.
2. `./dep run «»` — запускает команду на удалённых серверах. После запуска она спросит на каких серверах запустить.
3. `./dep ` — запускает любую определённую в deploy.php `task(’’, )` на нужно сервере.
4. Можно указать «теги» для серверов и запускать всё выше написанное сразу пачками.

Первый деплой / создание окружения

1. `./dep deploy develop2` — первый раз закончится с ошибкой, но Deployer создаст структуру файлов по пути из deploy.php для develop2. Он создаст папки
   1. `/var/www/dev.project.name/releases` — тут будут располагаться папки с каждым новым релизом и копиться последние N штук.
   2. `/var/www/dev.project.name/shared` — тут хранятся файлы, которые должны быть сохранены и перенесены между релизами. Например, логи, web/assets, storage, etc. Эти папки задаются в deploy.php как shared_folder и shared_files. Во время деплоя эти папки будут заменены на симлинки из shared папки.
   3. `/var/www/dev.project.name/current` — симлинк на последний успешный релиз из папки releases.
2. После создания структуры нужно перенести/создать файлы в shared:
   1. `./shared/.env`
   2. `./shared/web/XXXXXXX` — можно посмотреть, какие папки создадутся на сервере, либо какие папки указаны в shared_folder в deploy.php (с учётом тех, что указаны во фреймворк-специфичном recipe, подключённом в deploy.php).
3. Повторить деплой `./dep deploy develop2`
4. Также нужно залить данные в БД / импортнуть из sql дампа по параметрам из `.env`.

Проблема

Под root-пользователем работать небезопасно, равно как и делать весь проект доступным www-data.
Кроме того, во многих веб-приложениях пользователи имеют возможность загружать свои файлы. И очень часто с такими файлами возникают конфликты, так как пишутся они под www-data:www-data, а деплоим под другим пользователем. Даже если деплоить под root, то скорее всего права на папку перепишутся и www-data потеряет доступ к нужным файлам.

Решение

Создать нового пользователя deploy с правами на коннект к серверу по ssh, доступом только к папке с проектом и возможностью изменять файлы в ./public/uploads и ./var.

Создаём на сервере пользователя deploy из-под root:

ssh root@вашсервер
useradd --create-home -s /bin/bash deploy

Настроим доступ по ssh через ключи

mkdir /home/deploy/.ssh
touch /home/deploy/.ssh/authorized_keys

Вставьте содержимое одного из публичного ключа своего локального пользователя в файл authorized_keys и сохраните. Вывести публичный ключ локально можно командой: cat ~/.ssh/id_rsa.pub (название ключа id_rsa.pub у вас может отличаться).

vim /home/deploy/.ssh/authorized_keys

Меняем права на более строгие

chown -R deploy:deploy /home/deploy
chmod 600 /home/deploy/.ssh/authorized_keys

Определим пользователя нашего веб-сервера (в примере ниже это www-data)

ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\  -f1
> www-data

Добавляем пользователя deploy в группу www-data (группа веб-сервера)

usermod -a -G www-data deploy

Выставляем права на папку проекта

chown -R deploy:deploy /var/www/project
chmod -R 0775 /var/www/project

Проверим, есть ли setfacl в системе setfacl -h и установим, если его нет. Команда для Ubuntu:

sudo apt-get install acl

Выдадим права на папки с кэшем, логами и загруженными пользовательскими файлами

sudo setfacl -dR -m u:www-data:rwX -m u:deploy:rwX /var/www/project/var /var/www/project/public/uploads
sudo setfacl -R -m u:www-data:rwX -m u:deploy:rwX /var/www/project/var /var/www/project/public/uploads

Готово.

Для самого деплоймента я обычно использую Deployer c параметром writable_mode=acl.