Грамотное разворачивание сайта без VCS 3 сентября 09

Ситуация: есть сервер с доступом по SSH и без каких-либо дополнительных программных средств. Есть код в git-репозитарии (даже не важно, что в git, главное, что под системой контроля версий). Задача: поместить код на сервер и периодически его обновлять, да так, чтоб не руками, чтоб не стыдно было, чтоб не гонять полную копию каждый раз. Займемся.

Ну да, не совсем без системы контроля версий, а при наличии отсутствия ее на сервере.

UPD: Еще проще и удобнее выливать сайты через sshfs.

Способ первый. Используем Capistrano

Для тех, кто в танке: Capistrano – это такая штука для выполнения команд на удаленных серверах с помощью SSH. Например, с ее помощью можно одной командой залезть на сервер, вытянуть туда код из репозитария, выполнить миграции и перезапустить сервер. Удобно.

К сожалению, вытянуть код прямо с сервера у нас не получится – там не знают о VCS.
«Папа, а правда, есть люди, которые не пользуются VCS? Нет, сынок, это фантастика.»

Для таких случаев у Capistrano есть стратегия copy.

#config/deploy.rb
 
set :deploy_via, :copy
set :copy_strategy, :export
 
set :scm, :git
set :branch, 'master' # или любая другая ветка
set :repository, 'git@my.server:repo/location.git'
 
set :deploy_path '/path/to/app/on/deploy/server'
role :web, 'the.deploy.server'

Все, вызываем cap:deploy, Capistrano вытягивает содержимое ветки, зажимает в gzip-архив и отправляет на сервер. Снова удобно.

К сожалению, на конкретном сервере у меня возникла проблема с использованием дерева каталогов Capistrano, а точнее, с симлинками в этом дереве. Если можно как-то обойтись без /current и /releases – напиши об этом в комментах, а я расскажу о дедовском способе.

Способ второй. Не такой модный, зато простой и тоже работающий

Shell-скрипт, который вытягивает содержимое репозитария и запихивает его на сервер rsync-ом. Его, наверное, можно было бы начинить переменными и комментариями, но мне лень.

#!/bin/sh
cd /tmp
rm -rf site_checkout
git clone git@my.server:repo/location.git site_checkout
cd site_checkout
git checkout master
rm -rf .git
rsync -zr -e ssh . the.deploy.server:/path/to/site/on/deploy/server
cd ..
rm -rf site_checkout

Кажись, это требует настройки параметров доступа к the.deploy.server в ~/.ssh/config, у меня так и есть.

Если что непонятно – я уточню.

Без рубрики.

Комментарии

  • gituliar 24 сентября 2009

    Не работал с git, но в mercurial есть команда push, которая изменения с текущего репозитория заливает на удаленный:
    > hg push DEST

    Единственная проблема — чтобы обновить файлы все равно наужно заходить на сервер и делать
    > hg update

    • Леонид Шевцов 24 сентября 2009

      Без обновления использование VCS теряет смысл.

  • Василий 27 сентября 2009

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

    и вот еще идея: создаем diff-path от ревизии на сервере до той ревизии, на которую хотим обновиться/откатиться. Если есть доступ по SSH и на сервере установлена утилита diff – патчим). Если SSH-доступа нет, но разрешена shell_exec – пробуем патчить.

    В самом крайнем случае – пишем парсер, который будет патчить.

    • Леонид Шевцов 27 сентября 2009

      На Rails ничего сложного в изменении базы нет – заливаешь на сервер новые миграции, выполняешь их, и все.

      По поводу diff: rsync делает то же самое, но автоматически. :)

  • gituliar 1 октября 2009

    Итак, вот как это работает с mercurial:

    1. Создаем репозиторий на сервере (или клонируем уже существующий с локальной машины) и открываем к нему доступ.

    2. Добавляем в .hgrc след. строки (source: http://mercurial.selenic.com
    /wiki/FAQ/CommonProblems):

    [hooks]
    changegroup = hg update >&2

    3. Вносим изменения и делаем коммит.

    4. Теперь после вызова «hg push» на сервере автоматически будет вызываться «hg update >&2″.

  • gituliar 1 октября 2009

    Если нет mercurial, то понятно что ничего работать не будет. Зачем тогда юзать VCS — юзай scp )))

  • gituliar 1 октября 2009

    Раз удобней, то юзай VCS на полную (в том числе и на сервере), как говориться «жить хорошо, а хорошо жить — еще лучше».

    PS. По поводу отсутствия mercurial на сервере, это довольно странно, потому как mercurial написан на Python’e, который в свою очередь стоит на большинстве UNIX-систем по умолчанию.

    • Леонид Шевцов 1 октября 2009

      Дык мораль в том, что сервер – это shared-хостинг, я туда ничего устанавливать не могу, а VCS использовать хочется, чтобы упростить себе жизнь.

      И кроме всего прочего, надо не Mercurial, а git. :)

  • Костег 30 мая 2010

    сеня зарелизил прототип прожки
    http://pyha.ru/forum/topic/4520.msg97106#msg97106

    Пока только ftp, mercurial. Потом будет больше протоколов и других систем контроля версий. И планируется добавить работу не в интерактивном режиме.

Оставить комментарий

  • (или OpenID)
  •