[Инструкция] Как деплоить проект через Deployer

Максим Кузнецов — Tue, 15 Jul 2025 10:54:36 +0300

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

Предполагается, что 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 правил

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

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

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

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

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

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

`./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.
После создания структуры нужно перенести/создать файлы в shared:
1. `./shared/.env`
2. `./shared/web/XXXXXXX` — можно посмотреть, какие папки создадутся на сервере, либо какие папки указаны в shared_folder в deploy.php (с учётом тех, что указаны во фреймворк-специфичном recipe, подключённом в deploy.php).
Повторить деплой `./dep deploy develop2`
Также нужно залить данные в БД / импортнуть из sql дампа по параметрам из `.env`.

Установка и настройка Clickhouse на EC2

Максим Кузнецов — Mon, 13 Nov 2023 15:14:10 +0300

Нашёл отличный и исчерпывающий гайд по установке и подготовке Clickhouse для продакшена на AWS EC2.
Допустим, у нас уже есть VPC, в которую хочется добавиться сервер с CH.
Единственно, в качестве инстанса я взял машину попроще — m7g.large (~$60/mo) на Ubuntu и Arch64 архитектуре.

https://anthonynsimon.com/blog/clickhouse-deployment/

Как добавить новый сервис в systemd/systemctl и запускать его при старте Ubuntu

Максим Кузнецов — Wed, 10 May 2023 17:35:55 +0300

Задача

Есть docker-compose файл, поднимающий Zabbix. Есть небольшая обёртка в виде Makefile, которая позволяет запускать и останавливать docker-compose. Нужно добавить запуск этой команды при старте/рестарте системы.

Дано

Всё лежит в `/var/www/zabbix-server/`.
Содержание файла Makefile:

...
docker-up:
        docker-compose up -d

docker-down:
        docker-compose stop

Решение

Создать новый файл `vim /etc/systemd/system/zabbix.service`.

[Unit]
Description=Run Zabbix Docker Containers on Startup

[Service]
RemainAfterExit=True
Restart=always
RestartSec=1
WorkingDirectory=/var/www/zabbix-server
ExecStart=/usr/bin/make docker-up
ExecStop=/usr/bin/make docker-down

[Install]
WantedBy=default.target

chmod 644 /etc/systemd/system/zabbix.service
systemctl enable zabbix.service
systemctl start zabbix.service

Максим Кузнецов: заметки с тегом devops