Автоматическое развертывание проектов на php

Очевидно, что любой проект должен оказаться на сервере, чтобы начать свою работу. Вопрос в том, как это сделать быстро, удобно и безопасно.

Автоматическое развертывание проектов (деплой)

Что же такое автоматическое развертывание проектов (деплой)? Для себя мы определили его как процесс переноса кода и структуры базы данных с локальной машины разработчика («песочницы», если угодно) на сервер (или кластер серверов), на котором в будущем и будет работать этот проект. В том числе в этот процесс входят и различного рода подготовительные операции, как, например, очистка и подогрев кэша.

Зачем он нужен? Каждый из нас на своем пути прошел разные варианты переноса проекта на «боевой» сервер: это и ftp (на нашей памяти были разработчики, которые сразу писали код на сервере, взаимодействуя с ним исключительно по ftp), и sftp, и rsycn, и git pull — все эти способы имеют множество недостатков, а главное, что они требуют монотонной рутинной работы. Мы решили, что лучше потратить это время на разработку, а всю монотонность доверить машине.

Требования к системе деплоя

Для начала мы определились с требованиями к подобной системе:

  1. должна быть возможность развертывать проект сразу на несколько площадок или на одну из них по выбору — для каждого проекта у нас есть, как минимум, две площадки (боевая и тестовая), кроме того, некоторые проекты используют кластер серверов,
  2. разворачивать проекты нужно из репозитория, а, кроме того, должна быть возможность развернуть разные ветки репозитория на разные площадки,
  3. должна быть возможность быстро откатиться к предыдущему релизу,
  4. процесс обновления должен быть максимально незаметным для пользователей сайта,
  5. система должна быть расширяемой и позволять вводить любые дополнительные операции, которые нам потребуются (установка пакетов composer, миграции бд и т.д.),
  6. сама система должна быстро разворачиваться и настраиваться для любого проекта,
  7. должна быть написана на php — очевидно, что у php-разработчика настроено окружение для работы с php и заставлять его настраивать ради деплоя окружение для работы с, например, ruby — бессердечно.

Скрипты деплоя для php

Мы начали искать подходящее готовое решение. Jenkins, Capistrano и т.д. были отброшены сразу же, несмотря на их популярность. Нам нужен был скрипт, написанный на php.

Тогда мы обратились к репозиторию на github, который выручал нас не раз. В нем авторы собирают наиболее полезные и удобные библиотеки для php. На момент написания статьи в разделе «Deployment» были только deployer, rocketeer и морально устаревший ныне phing.

Мы решили использовать именно rocketeer, прежде всего потому, что автор открыто пишет, что вдохновлялся capistrano, а с capistrano у нас был долгий и по большей части положительный опыт работы. Rocketeer из коробки поддерживает большую часть необходимого нам функционала, имеет удобный phar скрипт для своей работы, имеет багтрекер на github, документирован, легко и быстро настраивается для проекта с помощью команды ignite.

Требования к проектам для настройки rocketeer

Однако нам пришлось реструктурировать и свои проекты, для того, что бы применить к ним rocketeer. Конечно, это было совсем не обязательно, но, согласитесь, что в случае если тебе достается проект от другого разработчика, а ты уже знаешь где и что лежит, то это приятно греет душу.

Итак, вот структура файлов, которую мы используем для проектов на «1С-Битрикс: Управление сайтом»:

  • .rocketeer папка с настройками деплоя для rocketeer
  • documents папка, в которой должна содержаться вся документация по проекту.
  • examples папка, в которой должны лежать примеры файлов настройки «1С-Битрикс: Управление сайтом».

    • .settings.php
    • dbconn.php
  • frontend папка, в которой будут лежать файлы, необходимые для сборки frontend.
  • lib папка, в которой будут лежать файлы классов, которые были написаны специально для проекта.
  • vendor папка с библиотеками, загруженными с помощью composer.
  • web папка, которая будет доступна из web.

    • bitrix папка с файлами, принадлежащими дистрибутиву «1С-Битрикс: Управление сайтом».
    • local папка со всеми компонентами, шаблонами и модулями, которые потребовались для проекта.
  • .gitignore служебный файл git, который исключает некоторый файлы и папки из репозитория.
  • README.MD файл в формате markdown с кратким описанием проекта.
  • composer.json файл настройки composer.
  • composer.phar файл со скриптом Composer.
  • rocketeer.phar файл со скриптом Rocketeer.
    • Требования к настройке сервера

      Появились так же и требования к настройке сервера. В общем случае, rocketeer создает на сервере папку releases, в которой в отдельных папках клонирует базовый репозиторий. На том же уровне, что и папка releases, rocketeer создает символическую ссылку current, которая ведет на текущий активный релиз — все это позволяет быстро и незаметно переключать для пользователя сайта релизы. Там же есть и папка shared. Она предназначена для того, чтобы сохранять файлы между релизами. Например, мы в ней храним папку uploads для битрикса и файлы с настройками проекта на сервере (.settongs.php и dbconn.php).

      1-3

      Учитывая нашу структуру и структуру репозитория, получаем, что document root виртуального хоста должен указывать на «/папка_сайта/current/web/».

      Хотите больше автоматизации?

      Что бы не создавать постоянно из проекта в проект одну и ту же структуру папок, мы сделали проект для composer.

      Теперь, чтобы развернуть скелет проекта достаточно выполнить в консоли

      и вы получите всю структуру проекта, свежие версии composer, rocketeer и bitrixsetup.php. Чисто и быстро.

      Как же заставить это работать?

      Возможно, вначале настройка деплоя покажется вам сложной и ненужной, но мы гарантируем: стоит только попробовать и вы не сможете отказаться от rocketeer.

      Для примера, алгоритм из нашего внутреннего регламента по созданию нового проекта

      1. Разработчик сообщает серверному специалисту, что нужно настроить проект, сообщает название проекта латиницей.
      2. Разработчик создает репозиторий в своем аккаунте в gitlab и инициирует проект пустым README.MD файлом.
      3. Разработчик клонирует репозиторий на свой локальный стенд.
      4. Разработчик создает структуру папок согласно статье 3 данного регламента и наполняет все служебные файлы (.gitignore, composer.json, README.MD и т.д.) или разворачивает стандартный проект с помощью команды composer create-project marvin255/bitrix-base.
      5. Разработчик копирует в папку web файл bitrixsetup.php и с помощью него устанавливает «1С-Битрикс: Управление сайтом».
      6. Разработчик настраивает в файле /web/local/php_interface/init.php подключение файла /vendor/autoload.php.
      7. Разработчик инициирует composer командой php composer.phar install.
      8. Серверный специалист сообщает разработчику все данные по тестовому серверу.
      9. Разработчик настраивает в проекте Rocketeer согласно статье 6 данного регламента.
      10. Разработчик вносит все изменения с локальной машины в репозиторий.
      11. Разработчик на тестовом сервере создает ssh-ключ для пользователя проекта с помощью команды ssh-keygen. Ключ должен создаваться по стандартному пути ~/.ssh/id_rsa.pub, без указания пароля.
      12. Разработчик добавляет открытую часть ключа, созданного ранее, в deploy keys проекта в корпоративный gitlab.
      13. Разработчик добавляет домен корпоративного gitlab в authorized_keys для пользователя проекта.
      14. Разработчик создает на тестовом сервере в домашней папке проекта папки shared/web/upload и shared/web/bitrix/backup.
      15. Разработчик создает на тестовом сервере в домашней папке проекта файлы shared/web/bitrix/.settings.php и shared/web/bitrix/php_interface/dbconn.php и указывает в них верные данные для подключения к серверной базе данных.
      16. Разработчик переносит базу данных с помощью дампа с локальной машины на тестовый сервер.
      17. Разработчик заходит в папку проекта на своем локальном стенде в командной строке и выполняет команду php rocketeer.phar deploy.
      18. Разработчик проверяет работоспособность тестового сайта.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *