Я уже год программирую на PHP с использованием symfony framework и нахожу в этом истинное удовольствие. Однако, есть некоторые процессы разработки сайта, которые данный фрэймворк не полностью покрывает, да и не обязан =)
Одним из таких процессов является деплоймент или разворачивание и обновление проекта на рабочем сервере. Для выполнения подобной рутинной операции было написано множество скриптов и одним из самых популярных является Capistrano. Он чрезвычайно прост в освоении, совершенен функционально и крайне гибок в настройке, однако, из коробки заточен под деплой RoR приложений, для чего собственно и создавался.
Сегодня я постараюсь вам рассказать как использовать Capistrano для деплоймента symfony проектов.
Capistrano — ruby библиотека, выполняющая рутину по выкатыванию сайта и предоставляющая гибкие средства для своевременного отката проекта до предыдущей версии (предыдущий деплоймент).
Capistrano путем подключения через SSH оперирует удаленными директориями, создавая новую директорию с актуальным кодом и созданием нужных симлинков. Актуальный код Capistrano может копировать с любой другой машины по SSH серверу, использовать GIT или SVN репозитории. На этом возможности capify не заканчиваются. В принципе, скрипт при должной настройке способен выполнять любой набор unix комманд на любом количестве удаленных систем (к которым у вас есть доступ, естественно). Однако, наибольшее количество скриптов и настроек Capistrano имеет в основном для удаленного развертывания приложений, о котором мы сегодня и говорим.
capify — команда для создания конфига Capistrano
Выполнение процесса деплоймента разделено на атомарные операции-задачи (tasks), каждый из которых отвечает за отдельный аспект «выкатки». При этом глобальное выполнение деплоя ведет себя как полноценная транзакция и если хотя бы одна операция не выполняется — весь процесс отменяется, а удаленная файловая система возвращается к состоянию до деплоя.
Основные комманды для capistrano:
Как я уже говорил, capistrano изначально создавался для деплоя RoR приложений и есть некоторые места, которые его (из коробки) привязывают именно к этому фрэймворку. Например, структура и список shared папок у Rails и symfony проектов разные. При деплойменте symfony проекта также необходимо выполнять некоторые таски, такие как
Для решения всех этих проблем я слегка расширил базовые скрипты деплоймента capistrano, что дало рождение capifony
Скачать скрипт и поучаствовать в его разработке можно тут: http://github.com/everzet/capifony/tree/master.
Итак, у нас есть проект, который необходимо развернуть на рабочем сервере. Этот проект у нас хранится в удаленном git-репозитории на рабочем сервере (это может быть и не git и хранится код может где угодно, куда есть доступ по SSH и в любом виде, о котором знает Capistrano, а он знает много =) ).
Для начала мы переходим в локальную директорию с проектом, который необходимо залить и удаленный git-репозиторий которого находится на сервере:
Стоит отметить, что директории 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';
Одним из таких процессов является деплоймент или разворачивание и обновление проекта на рабочем сервере. Для выполнения подобной рутинной операции было написано множество скриптов и одним из самых популярных является Capistrano. Он чрезвычайно прост в освоении, совершенен функционально и крайне гибок в настройке, однако, из коробки заточен под деплой RoR приложений, для чего собственно и создавался.
Сегодня я постараюсь вам рассказать как использовать Capistrano для деплоймента symfony проектов.
Что такое capify?
Capistrano — ruby библиотека, выполняющая рутину по выкатыванию сайта и предоставляющая гибкие средства для своевременного отката проекта до предыдущей версии (предыдущий деплоймент).
Capistrano путем подключения через SSH оперирует удаленными директориями, создавая новую директорию с актуальным кодом и созданием нужных симлинков. Актуальный код Capistrano может копировать с любой другой машины по SSH серверу, использовать GIT или SVN репозитории. На этом возможности capify не заканчиваются. В принципе, скрипт при должной настройке способен выполнять любой набор unix комманд на любом количестве удаленных систем (к которым у вас есть доступ, естественно). Однако, наибольшее количество скриптов и настроек Capistrano имеет в основном для удаленного развертывания приложений, о котором мы сегодня и говорим.
capify — команда для создания конфига Capistrano
Стандартный процесс деплоймента
Выполнение процесса деплоймента разделено на атомарные операции-задачи (tasks), каждый из которых отвечает за отдельный аспект «выкатки». При этом глобальное выполнение деплоя ведет себя как полноценная транзакция и если хотя бы одна операция не выполняется — весь процесс отменяется, а удаленная файловая система возвращается к состоянию до деплоя.
Основные комманды для capistrano:
capify .
— создает в текущей директории файлы для конфигурации доступа к удаленной системе и настройки процесса. Файлы эти:
- Capfile — основной скрипт, подтягиваемый коммандой «capify»
- config/deploy.rb — настройки процесса, заинклуженные в Capfile. Именно в этот файл необходимо прописывать все наши пути до серверов и настройки перед выполнением следующих комманд
cap deloy:setup
— разворачивает на удаленном сервере/серверах (их может быть несколько) файловую структуру для последующих процессов деплойментаcap deploy
— выполняет деплоймент. При этом создается новая директория для проекта, в ней делаются симлинки на общие (shared) ресуры и затем, делается симлинк current на эту директорию, подсовывая web серверу актуальный код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-репозиторий которого находится на сервере:
- В корне мы выполняем комманду
capify .
, создающую нам Capfile в корне и deploy.rb в config/ - Скачиваем файл capifony.rb с гитхаба и кладем его в config/
- В конец Capfile дописываем
load 'config/capifony'
- И последний штрих — прописываем настройки коннекта к удаленному серверу в 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.
- Теперь из консоли вызываем
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';