Pull to refresh

Capifony. Или деплоим symfony проект через Capistrano

Symfony *
Я уже год программирую на PHP с использованием symfony framework и нахожу в этом истинное удовольствие. Однако, есть некоторые процессы разработки сайта, которые данный фрэймворк не полностью покрывает, да и не обязан =)
Одним из таких процессов является деплоймент или разворачивание и обновление проекта на рабочем сервере. Для выполнения подобной рутинной операции было написано множество скриптов и одним из самых популярных является Capistrano. Он чрезвычайно прост в освоении, совершенен функционально и крайне гибок в настройке, однако, из коробки заточен под деплой RoR приложений, для чего собственно и создавался.
Сегодня я постараюсь вам рассказать как использовать Capistrano для деплоймента symfony проектов.

Что такое capify?


Capistrano — ruby библиотека, выполняющая рутину по выкатыванию сайта и предоставляющая гибкие средства для своевременного отката проекта до предыдущей версии (предыдущий деплоймент).
Capistrano путем подключения через SSH оперирует удаленными директориями, создавая новую директорию с актуальным кодом и созданием нужных симлинков. Актуальный код Capistrano может копировать с любой другой машины по SSH серверу, использовать GIT или SVN репозитории. На этом возможности capify не заканчиваются. В принципе, скрипт при должной настройке способен выполнять любой набор unix комманд на любом количестве удаленных систем (к которым у вас есть доступ, естественно). Однако, наибольшее количество скриптов и настроек Capistrano имеет в основном для удаленного развертывания приложений, о котором мы сегодня и говорим.
capify — команда для создания конфига Capistrano

Стандартный процесс деплоймента


Выполнение процесса деплоймента разделено на атомарные операции-задачи (tasks), каждый из которых отвечает за отдельный аспект «выкатки». При этом глобальное выполнение деплоя ведет себя как полноценная транзакция и если хотя бы одна операция не выполняется — весь процесс отменяется, а удаленная файловая система возвращается к состоянию до деплоя.
Основные комманды для capistrano:
  1. capify . — создает в текущей директории файлы для конфигурации доступа к удаленной системе и настройки процесса. Файлы эти:
    1. Capfile — основной скрипт, подтягиваемый коммандой «capify»
    2. config/deploy.rb — настройки процесса, заинклуженные в Capfile. Именно в этот файл необходимо прописывать все наши пути до серверов и настройки перед выполнением следующих комманд

  2. cap deloy:setup — разворачивает на удаленном сервере/серверах (их может быть несколько) файловую структуру для последующих процессов деплоймента
  3. cap deploy — выполняет деплоймент. При этом создается новая директория для проекта, в ней делаются симлинки на общие (shared) ресуры и затем, делается симлинк current на эту директорию, подсовывая web серверу актуальный код
  4. cap rollback — откатываемся до предыдущего деплоймента. При этом удаляется директория с текущей версией (при хардовом роллбэке), а симлинк current перебивается на предыдущую директорию деплоя


Зачем нужен capifony?


Как я уже говорил, capistrano изначально создавался для деплоя RoR приложений и есть некоторые места, которые его (из коробки) привязывают именно к этому фрэймворку. Например, структура и список shared папок у Rails и symfony проектов разные. При деплойменте symfony проекта также необходимо выполнять некоторые таски, такие как symfony plugin:publish-assets для создания симлинков на ассеты из плагинов, symfony cc для сброса кэша и symfony fix-perms для восстановления пермишенов на папки cache и web/uploads.
Для решения всех этих проблем я слегка расширил базовые скрипты деплоймента capistrano, что дало рождение capifony
Скачать скрипт и поучаствовать в его разработке можно тут: http://github.com/everzet/capifony/tree/master.

Использование


Итак, у нас есть проект, который необходимо развернуть на рабочем сервере. Этот проект у нас хранится в удаленном git-репозитории на рабочем сервере (это может быть и не git и хранится код может где угодно, куда есть доступ по SSH и в любом виде, о котором знает Capistrano, а он знает много =) ).
Для начала мы переходим в локальную директорию с проектом, который необходимо залить и удаленный git-репозиторий которого находится на сервере:
  1. В корне мы выполняем комманду capify ., создающую нам Capfile в корне и deploy.rb в config/
  2. Скачиваем файл capifony.rb с гитхаба и кладем его в config/
  3. В конец Capfile дописываем load 'config/capifony'
  4. И последний штрих — прописываем настройки коннекта к удаленному серверу в deploy.rb:

    set :application, "YOUR_APPLICATION_NAME"<br>set :repository, "YOUR_SSH_SERVER_NAME:/PATH/TO/repos/#{application}.git"<br>set :deploy_to,  "/PATH/TO/www/#{application}.com"<br>set :scm,     "git"<br><br>default_run_options[:pty] = true<br>ssh_options[:forward_agent] = true<br><br>server "YOUR_SSH_SERVER_NAME", :web, :app, :db<br><br>* This source code was highlighted with Source Code Highlighter.


  5. Теперь из консоли вызываем cap deploy:setup, чтобы настроить удаленную файловую структуру и cap deploy, чтобы выполнить деплоймент. И не забываем, если что-то вдруг при последующих деплоях идет не так (деплой прошел, но сайт упал, к примеру) — cap rollback поможет


Стоит отметить, что директории log/, web/uploads в деплойменте не участвуют, т.к. являются shared ресурсами, которые сохряняются между деплоями. Поэтому, если вы уже накопили набор файлов под web/uploads, их нужно вручную залить на сервер по адресу /PATH/TO/www/#{application}.com/shared/web/uploads/
Вот и все. Если вам понравилась данная статья — дайте мне знать, возможно в следующий раз я расскажу о другом интересном аспекте разработки вместе с замечательным symfony...

upd: Забыл 1 вещь. По стандарту, когда symfony генерирует проект, она прописывает в config/ProjectConfiguration.class.php абсолютный путь до symfony, который на рабочей машине и продакшене может различаться. Для решения проблемы и на продакшене и на рабочей машине добавляем путь до директории с библиотеками (включая symfony) в include_path (прим.: include_path = ".:/php/includes:/opt/local/lib/php"), а путь в ProjectConfiguration.class.php меняем на относительный require_once 'symfony/autoload/sfCoreAutoload.class.php';
Tags:
Hubs:
Total votes 11: ↑9 and ↓2 +7
Views 7.4K
Comments Comments 13