Изменения коснулись пути доступа к PID-файлам проектов. Новое значение пути выглядит так:

/var/run/unicorn/#{user}/#{application}.#{login}.pid

То есть, к пути необходимо добавить еще один каталог, название которого совпадает с названием системного пользователя хостинга. Если вы используете автоматически сгенерированный deploy.rb, вам нужно заменить строку

set :unicorn_pid, "/var/run/unicorn/#{application}.#{login}.pid"

на строку

set :unicorn_pid, "/var/run/unicorn/#{user}/#{application}.#{login}.pid"

Указанные изменения путей не касаются работоспособности уже запущенных проектов, но без внесения этих изменений перезапустить остановленный проект невозможно.

Rvm, Bundler, Capistrano — все эти инструменты сильно облегчают жизнь разработчику и администратору проекта, но могут изрядно запутать. В этой статье мы наглядно покажем процесс деплоя распространенной системы управления проектами Redmine.

Создаем новый Ruby On Rails проект

1. Выбираем тип проекта «Ruby on Rails»
2. Задаем имя будущему проекту
3. Создаем. Панели нужно две-три минуты, чтобы создать всё необходимое для работы проекта, после чего можно продолжать. Около 15 минут необходимо, чтобы проект начал отзываться по присвоенному ему DNS-имени.

Обратите внимание на созданную базу данных, она нам еще пригодится.

Загружаем дистрибутив

Новые версии Redmine замечательно работают с Ruby 1.9.3, поэтому, настройки проекта по умолчанию нам подойдут. Мы будем ставить последнюю на момент написания статьи стабильную версию Redmine 2.0.3.

Узнаём параметры входа на сервер по ssh

Начинаем работать с терминалом. Заходим на сервер

Переходим с свежесозданный каталог проекта

$ cd projects/redmine

Удаляем автоматически созданные файлы

$ rm -rf ./current/*

Загружаем архив с исходниками Redmine

$ wget http://rubyforge.org/frs/download.php/76259/redmine-2.0.3.tar.gz

Распаковываем архив

$ tar xvf redmine-2.0.3.tar.gz

Переписываем симлинк current на распакованный Redmine

$ rm current
$ ln -s redmine-2.0.3 current

Подготавливаем окружение

На этом этапе можно открыть в соседней вкладке руководство по установке Redmine и сверяться с ним, если что-то пойдет не так. Также рекомендуем прочитать нашу статью об особенностях работы с rvm.

Переходим в каталог с исходниками

$ cd current

Подготавливаем бандл. Хотя Gemfile уже идет в поставке Redmine, хостинг Locum использует сервер приложений Unicorn для запуска проектов, поэтому в Gemfile необходимо внести изменения

$ echo 'gem "unicorn"' >> Gemfile

Теперь можно создать бандл

$ rvm use 1.9.3 do bundle install --path=~/projects/redmine/shared/gems --without development test

Этот процесс обычно занимает около пяти минут. Теперь нужно поправить конфигурацию базы данных для проекта. Узнаем параметры подключения к БД в панели управления хостингом. Заходим в «Услуги — Проекты», нажимаем «Подробнее» на проекте redmine, далее в графе «Ресурсы» нажимаем на ссылку с базой данных.

Возвращаемся в терминал. Копируем файл конфигурации БД из поставки Redmine

$ cp config/database.yml.example config/database.yml

Редактируем файл с настройками, вписываем параметры подключения нашей базы

Обратите внимание на адаптер базы, для Ruby 1.9 это должен быть mysql2. Вторая частая ошибка — имя хоста. Обязательно внесите хост со страницы с параметрами подключения БД.

Сохраняем изменения: Ctrl+O, Ctrl+X.

Выполняем настройку проекта

Следуем инструкции по установке, выполняем таски, необходимые для запуска проекта. Особенность хостинга — все команды нужно оборачивать в rvm и bundle.

$ rvm use 1.9.3 do bundle exec rake generate_secret_token
$ RAILS_ENV=production rvm use 1.9.3 do bundle exec rake db:migrate

В нашем примере мы загрузим тестовые данные в проект

$ RAILS_ENV=production rvm use 1.9.3 do bundle exec rake redmine:load_default_data

Правим права доступа к каталогам

$ chmod -R 755 files log tmp

Перезапускаем сервер приложений

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

$ kill -QUIT `cat /var/run/unicorn/hosting_redmine/redmine.redmine5.pid`
$ rvm use 1.9.3 do bundle exec unicorn_rails -Dc /etc/unicorn/redmine.redmine5.rb

Проверяем, что сервер приложений запустился и проект работает. В панели управления идем в «Услуги — Проекты», напротив проекта redmine нажимаем на ссылку с его доменом. Авторизуемся учетной записью по умолчанию admin/admin.

Можно приступать к настройке непосредственно самого Redmine.

Если что-то пошло не так, полезную информацию можно найти в логах в каталоге проекта ~/projects/current/log

• production.log — основной журнал Redmine. Ошибки уровня приложения пишутся сюда.
• unicorn.stderr.log — журнал ошибок запуска Unicorn. Недостающие библиотеки и проблемы запуска сервера приложений запишутся сюда.

Что случилось?

Мы долго шли к этому, и все-таки это состоялось. Теперь по умолчанию используется rvm и bundler на всех новых проектах. Старые проекты не будут затронуты до тех пор, пока вы сами не начнете переключать версию ruby в настройках. Подумайте — стоит ли делать это, если все работает.

Зачем?

Хотя бы потому что мы всегда стараемся предоставлять новые технологии, как только они становятся достаточно стабильны и удобны. К тому же поступило много просьб от наших пользователей о переходе на новую версию. Конечно, полный переход мы навязывать не стали, ведь есть много проектов, которые давно уже работают на 1.8.7, разработка не ведется и всех все устраивает, так зачем же ломать? Поэтому пришлось делать поддержку нескольких версий, ну а за одно и переключение между ними.

Ruby 1.8.7 уже устарел, тем более в новых версиях Ruby On Rails его поддержка со временем прекратится. Сейчас все наши пользователи могут использовать самые последние версии ruby, да и к тому же переключаться между ними. Переведите свой проект на 1.9.3 и наслаждайтесь производительностью. Конечно, перед этим необходимо установить нужные gem для этой версии ruby. Об этом читайте далее.

Как теперь все работает?

В качестве сервера приложений все так же используется unicorn — он довольно хорошо себя проявил за последнее время по сравнению со своими конкурентами. По крайней мере в разделяемой среде, где много проектов, мы пока не видим ему альтернативы.

Теперь для запуска процессов нужно будет указывать какая версия ruby вам нужна. Для этого используется Ruby Version Manager или сокращенно — RVM. Наверняка многие из вас уже знакомы с этим средством переключения между различными версиями ruby. Если нет — обратитесь к официальной документации, она довольно проста и понятна.

Как же теперь запускается unicorn?

Для этого нужно выполнить следующую команду:

rvm use <версия> do bundle exec unicorn_rails -Dc /etc/unicorn/<имя_проекта>.<логин_в_панель_управления>.rb

Вместо <версия> нужно подставить одно из следующих значений, что и будет определять версию ruby, которая используется на данный момент:

• 1.9.3
• 1.9.2
• ree-1.8.7 (это Ruby Enterprise Edition)
• 1.8.7

Перезагрузка кода

Тут ничего не поменялось, так как нам нужно всего лишь отправить сигнал USR2 мастер-процессу, это делается и без rvm:

kill -USR2 `cat /var/run/unicorn/<имя пользователя на сервере>/<имя_проекта>.<логин_в_панель_управления>.pid`

Как всегда логи находятся в logs/unicorn.*.log, и если вдруг после отправки сигнала ничего не поменялось — это хороший повод заглянуть в них. Полная остановка unicorn делается аналогично, но сигнал будет QUIT, вместо USR2.

Почему bundler а не rvm gemsets?

Этот вопрос может возникнуть у знакомых с работой rvm пользователей. Ответ довольно просто — gemsets не предназначены для работы в разделяемой среде между несколькими пользователям — будут проблемы прав доступа. Тем более bundler стал стандартным средством ограничение области видимости gem а так же их установки и обновления, независимо от того используется вообще rvm или нет. Большинство проектов у нас используют bundler уже сейчас, а уж все новые так и тем более должны это делать.

Куда ставить bundle?

Мы рекомендуем ставить в ../../shared/gems, сделать это можно указав нужный параметр при выполнении команды (предполагается, что команда выполняется в RAILS_ROOT):

bundle install --path ../../shared/gems

Shared — чтобы не переустанавливать все gem после каждого деплоя, а просто вызывать bundle update.

Как переключать версии?

Войдите в раздел «Услуги»->»Проекты», далее нажмите на ссылку «подробнее» напротив нужного проекта в таблице, откроются параметры проекта. Там вы увидите поле с версией ruby, выберите интересующую вас версию и нажмите кнопку сохранения параметров.

Что при этом произойдет?

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

Итак, по умолчанию у нас запущен проект с ruby 1.9.3, если мы сменили версию, то вначале будет удалена директория ../../shared/gems, так как система предполагает, что ваши gem стоят там. Удалять директорию приходится потому, что bundler не может понять иногда, что native extension того или иного gem собран был для другой версии ruby и попытается использовать его не пересобирая, что приведет к ошибке и падению unicorn. Конкретно такая проблема наблюдается при смене версии с 1.9.3 до 1.9.2, если не удалить все gem и не поставить снова.

После этого в RAILS_ROOT (projectname/current) будет выполнена команда bundle install —path ../../shared/gems, а затем — полная остановка unicorn и запуск его с указанием новой версии ruby для rvm.

Чтобы в процессе этого не возникало никаких ошибок убедитесь что ваш Gemfile валиден и код проекта сможет работать с выбранной вами версией, потому что иногда синтаксис все-таки не полностью совместим. Об отличиях между разными версиями ruby вы всегда сможете прочесть в официальных документах и описаниях каждого из релизов.

Почему не rvmrc?

rvmrc — это всего лишь шелл-скрипт, использование которого рассчитано на определенные настройки пользовательской оболочки. Мы не можем гарантировать что у всех эти настройки соблюдаются, а уж тем более не хотим это навязывать. К тому же в нескольких уровнях rvmrc легко запутаться. Мы никак не ограничиваем вас в использовании rvmrc, но изначально не навязываем его. Вы всегда можете самостоятельно настроить и пользоваться им как вам будет удобно. Подробно о работе rvmrc читайте в документации по rvm.

Что по умолчанию?

По умолчанию создается «пустой» rails-проект (по сути то, что получаем после rails new) с ruby 1.9.3 и rails 3.1.1

Кстати, не удивляйтесь, что ссылка «About your application’s environment» не работает — по идеологии Ruby On Rails она должна работать только в development-окружении, а на хостинге все запускается в production.

Что станет с Capistrano?

Как всегда мы предполагаем, что для размещения кода на сервере будет использоваться Capistrano. RVM этому никак не помешает, просто мы теперь генерируем deploy.rb c учетом использования rvm.

Получить deploy.rb для каждого конкретного проекта можно в вашей панели управления услугами Locum.ru. Войдите в раздел «Услуги»->»Проекты», далее нажмите на ссылку «подробнее» напротив нужного проекта в таблице, откроются параметры проекта. Там вы увидите кнопку для генерации deploy.rb, нажмите ее и получите содержание файла с учетом rvm.

Обычно для того, чтобы начать пользоваться Capistrano достаточно просто добавить в deploy.rb ссылку на вашу систему контроля версий, настроить авторизацию по ключам на наш сервер. а так же с нашего сервера к вашей системе контроля версий (git, svn, mercurial). Если вы нигде еще не разместили свой проект в контроле версий, то можете создать гит репозиторий на нашем сервере, об этом у нас есть соответствующая заметка в блоге.

Имейте ввиду, что если вы измените версию ruby для проекта, вам необходимо будет поменять ее и в вашем deploy.rb.

Что делать с моими старыми проектами?

Решение остается полностью за вами. Если вы знаете что такое rvm и понимаете зачем вам нужно перейти на новую версию, или даже если понимаете, что это не имеет смысла но хочется (бывает такое, не правда ли?), вы всегда можете это сделать. А так — просто не трогайте их, с ними ничего не произошло.

На что еще важно обратить внимание?

Всегда помните, что все команды ваши теперь следует запускать в rvm и bundle, т.е. вместо

rails c

мы используем

rvm use <версия> do bundle exec rails c

И только так входим в консоль. Мы всегда рекомендуем вызывать команду явно, а не полагаться на rvmrc, фазу луны или еще что-нибудь. Так меньше вероятность совершить ошибку, потому что довольно легко забыть изменить версию в rvmrc и потом долго думать от чего не работает.

Заключение

На этом у нас все. Ждем ваших комментариев и отзывов, спасибо, что выбираете Locum.ru. Мы же и впредь будем стараться радовать вас внедрением новых технологий.

Главный вопрос, возникающий после выбора системы контроля версий: где же хранить репозиторий, в котором будет лежать полная история развития вашего проекта?

В случае использования распределённой системы контроля версий Git и виртуального хостинга Locum, этот вопрос можно решить буквально одним движением руки, не прибегая к использованию дорогостоящих тарифных планов GitHub или Assembla.

Итак, допустим, что у нас есть некоторый проект, репозиторий которого можно сохранить на хостинге Locum, и пусть он находится в каталоге meet.git.

Для начала узнаем название вашего сервера виртуального хостинга. Эту информацию вы можете посмотреть в нашей клиентской панели: вкладка «Услуги» → раздел «FTP и SSH».

Зайдём на сервер виртуального хостинга через SSH и подготовим окружение для работы Git.

% ssh hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru

% mkdir -p ~/git/meet.git

% cd ~/git/meet.git

% git init --bare

Команда git init с ключом --bare создаст репозиторий в текущем каталоге, обеспечивая хранение исключительно служебной информации и блоков данных. При этом напрямую работать с сохранёнными файлами и каталогами будет невозможно: все данные проекта хранятся во внутреннем представлении Git.

Работа с репозиторием будет проводиться поверх протокола SSH, поэтому лучше избавиться от постоянного требования ввода пароля, добавив свой публичный SSH-ключ в список авторизованных ключей на сервере: достаточно просто скопировать ваш публичный SSH-ключ в конец файла ~/.ssh/authorized_keys, а если такого файла не существует, то достаточно будет просто создать его.

На самом деле, всё это можно легко автоматизировать. Выполните данную команду на вашем локальном компьютере:

% cat ~/.ssh/id_rsa.pub | ssh hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru 'cat >> ~/.ssh/authorized_keys' 

На всякий случай, стоит удостовериться, что директория .ssh и список авторизованных ключей закрыты для чтения остальными пользователями. Это требование продиктовано реализацией OpenSSH и здравым смыслом. Для этого достаточно выполнить команду на нашем сервере:

% ssh hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru 'chmod 0700 ~/.ssh' 

Отлично, теперь работа с нашими серверами при помощи SSH станет гораздо проще и комфортнее, без какого-либо ущерба безопасности. Главное — мы выполнили все приготовления для функционирования Git.

Создадим в директории вашего проекта на локальном компьютере Git-репозиторий:

% cd meet.git

% git init 

Добавим в учёт все файлы вашего проекта:

% git add . 

Пока не поздно, можно сделать ревизию состояния всех файлов:

% git status 

Необходимо принять изменения (выполнить commit). Каждое множество изменений обязано сопровождаться хотя бы кратким описанием. Поскольку это наш первый коммит, то описание будет соответствующим:

% git commit -m 'initial commit' 

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

Для того, чтобы Git обеспечил согласование вашего локального репозитория с его братом-близнецом на сервере Locum, нужно определить точку синхронизации. Это не является обязательным пунктом, ведь оба репозитория являются полноценными, и возможность согласования — всего лишь приятная возможность. В системе Git точки синхронизации называются remotes и являются именованными. Как правило, единственная точка синхронизации носит гордое имя origin.

% git remote add origin ssh://hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru/home/hosting_ПОЛЬЗОВАТЕЛЬ/git/meet.git 

Теперь попробуем впервые отправить наши данные на сервер. В терминологии Git это зовётся push. При этом необходимо указать целевую точку синхронизации и название ветке, в которую публикуются изменения. По-умолчанию все данные в Git лежат в ветке master.

% git push -u origin master

Counting objects: 3, done.

Writing objects: 100% (3/3), 211 bytes, done.

Total 3 (delta 0), reused 0 (delta 0)

To ssh://hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru/home/hosting_ПОЛЬЗОВАТЕЛЬ/git/meet.git

* [new branch] master -> master

Branch master set up to track remote branch master from origin. 

Команда push вызвана с ключом -u, который заставляет Git запомнить, что вы предпочитаете делать push и обратный ему процесс pull в ветке master точки синхронизации origin. С этого момента никаких дополнительных параметров для команд git push и git pull вам не понадобится.

Кстати, если после выполнения последней команды вы увидели аналогичный результат в вашем терминале, то Git функционирует корректно. Для того, чтобы это проверить, попробуем выполнить клонирование (скачивание) новоиспечённого репозитария. Попробуйте выполнить эту команду, находясь в какой-либо директории, не содержащей каталог meet-git:

% git clone 'ssh://hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru/home/hosting_ПОЛЬЗОВАТЕЛЬ/git/meet.git'

Cloning into meet-git...

remote: Counting objects: 3, done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (3/3), done. 

Удалось? Поздравляем, у вас теперь есть собственный приватный Git-репозиторий, в котором вы можете самостоятельно заниматься разработкой вашего проекта, не беспокоясь о сохранности исходного кода. Удачи!

Для дальнейшего чтения мы можем посоветовать русскоязычный перевод книги Pro Git.

P.S. Кстати, если вам нужно подключить к репозиторию своих сотрудников, то просто пропишите их публичные SSH-ключи в конец списка авторизованных ключей (см. выше) и попросите выполнить git clone с известным вам адресом.

Странные сообщения об ошибках

Если вы читаете эту статью, то вполне вероятно вы видели такую ошибку, несмотря на то, что gem  с нужной версией ruby on rails у вас установлен.

Missing the Rails 2.3.8 gem. Please `gem install -v=2.3.8 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.

Или может быть такую?

You have already activated ** rack** 1.1.0, but your Gemfile requires rack 1.0.1. Consider using bundle exec. (Gem::LoadError)

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

Rack и проблемы, связанные с ним

Всему виной rack, точнее несоответствие его версии тому, что хочет видеть rails. Причем первое сообщение об ошибке очень странное, никаким образом не упоминает rack и даже никак не намекает на него, но давайте посмотрим в код, который выводит это сообщение. Открывает config/boot.rb, и видим:

class GemBoot < Boot
   def load_initializer
       self.class.load_rubygems
       load_rails_gem
       require 'initializer'
   end
   def load_rails_gem
       if version = self.class.gem_version
          gem 'rails', version
      else
          gem 'rails'
      end
      rescue Gem::LoadError => load_error
          $stderr.puts %(Missing the Rails #{version} gem.

          Please `gem install -v=#{version} rails`,

          update your RAILS_GEM_VERSION setting in config/environment.rb

          for the Rails version you do have installed,

          or comment out RAILS_GEM_VERSION

          to use the latest version installed.)

          exit 1
      end

Тут-то и становится понятно, что это сообщение выводится не только когда не удается загрузить именно rails, но и в любом другом случае, когда возбуждается исключение Gem::LoadError. Стоит отметить, что в последующих версиях rails (где-то после 2.3.10), сообщение об ошибке стало более информативно, и пользователи перестали предпринимать отчаянные попытки установить нужный gem несколько раз подряд, до этого видимо авторы rails не подозревали, что такое исключение может возникнуть в иной ситуации.

Вторая ошибка уже более информативна и подсказывает нам, что дело тут в rack, как это на самом деле обстоит и в первом случае. Суть в том, что отличный сервер для rails — unicorn, использует rack для своей работы. Современные версии Ruby On Rails так же используют rack для своей работы, и необходимо, чтобы они использовали одну и ту же версию. Иначе будем получать такие вот ошибки, потому что вызов activate! у rack во время загрузки rails не пройдет.

Очевидным решением было бы добавить в config/environment.rb строку следующего вида:

config.gem 'rack', '=1.0.1'

Однако, попробовавшие это решение будут разочарованы — ничего не поменяется. Проблема в том, что unicorn вначале запускается сам, загружает свой код и активирует rack. Причем написан он довольно грамотно и активировать будет самую новую версию, которая есть, работает он с ней нормально. И уже только после этого unicorn будет пытаться загрузить Ruby On Rails, только тогда считается environment.rb и эта строка, но более новый rack уже будет активирован.

Еще одним простым решением будет просто удалить локальную инсталляцию более нового rack, оставив только нужную нашему rails-проекту версию, но такое решение подходит лишь для тех, у кого один проект, или на всех проектах нужен один и тот же rack. Если у вас есть проекты, например на rails 2.3.8, 2.3.11 и 3.0.2 — вам потребуется для каждого из них своя версия rack и вариант с удалением не подойдет.

Тут на выручку приходит bundler.

Решаем проблему с помощью bundle

Bundler — это средство управления различными окружениями gem. Он легко позволяет создать изолированную инсталляцию gem для конкретного проекта, чтобы остальные, установленные на локальной машине gem не мешали работать. Так же при помощи bundler удобно устанавливать большие пачки gem в системные или иные директории. На всех серверах Locum.ru bundler уже установлен. Если при попытке выполнить команду bundle вы получаете ошибку:

bash: bundle: команда не найдена

То убедитесь, что у вас правильно настроена переменная окружения PATH. Мы рекомендуем устанавливать следующее значение PATH=»/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/$HOME/.gem/ruby/1.8/bin:/var/lib/gems/1.8/bin».

Подробнее о том, как работать с bundler и что он позволяет вы всегда сможете узнать в официальной документации, тут же мы кратко рассмотрим только ограничение версий нужных нам gem. Итак, для начала создаем Gemfile. Gemfile — это такой список используемых в проекте gem, с указанием нужных версий. Если версию не указать — будет доступна самая последняя из установленных. Важно перечислить все gem, необходимые для работы проекта, так как то, что не указано в Gemfile, не будет доступно из кода ни rails, ни unicorn. Ровно по этой же причине необходимо добавить сам unicorn в список. Gemfile должен находиться в той директории, откуда запускается unicorn, т.е. в нашем случае это current в каталоге capistrano, RAILS_ROOT. Если вы используете систему контроля версий, рекомендуем поместить Gemfile  в нее, так как он будет нужен для каждого деплоя.

Вот пример Gemfile для запуска redmine из trunk:

source "http://rubygems.org"
gem "unicorn"
gem "rack", "1.1.0"
gem "rails", "2.3.11"
gem "rake", "0.8.7"
gem "i18n", "0.4.2"
gem "rubytree", "0.5.2", :require => "tree"
gem "RedCloth", "~>4.2.3", :require => "redcloth" # for CodeRay
gem "mysql"
gem "coderay", "~>0.9.7"

Сохранив такое содержимое рекомендуем выполняем следующие команды (все запускается из директории current):

bundle install --path ../../shared/gems

kill -QUIT `cat /var/run/unicorn/имя_пользователя_на_сервере/имя_проекта.логин_в_панели_управления.pid`

bundle exec unicorn_rails -Dc /etc/unicorn/имя_проекта.логин_в_панели_управления.rb

Первая команда должна установить все gem с нужными версиями (просто так, на всякий случай), важно не забывать про ключ —path, потому что иначе bundler будет пытаться установить все в системную директорию и требовать с вас пароль на sudo. Вторая — остановить уже запущенный экземпляр unicorn для проекта. Если он упал ранее по причине ошибки — ничего страшного, PID-file просто будет отсутствовать. Последняя команда стартует unicorn в созданном нами окружении bundle. После этого все должно работать, перезагрузка кода так же выполняется отправлением сигнала USR2. Так же для этого есть специальная кнопка в панели управления хостингом Locum.ru.

Если вы используете capistrano, как мы всем рекомендуем, то нужно добавить вызов bundle exec перед командой запуска unicorn в ваш deploy.rb.

Иногда при работе со старыми версиями Rails возникает ошибка, примерно следующего вида:

uninitialized constant ActiveSupport::Dependencies::Mutex (NameError)

Эта проблема не связана с bundle и rack, но возникает не редко, связанно это с изменениями в новых версиях rubygems, на которые не рассчитаны старые версии rails. Решается проблема добавлением вызова require ‘thread’ в config/environment.rb или config/boot.rb. Спорный вопрос в какой из этих файлов идеологически правильнее добавить вызов, но сработают оба варианта. Кто имеет четкое мнение по этому вопросу — напишите, пожалуйста, в комментариях. Что до меня, так идеологически правильным я вижу только одно решение — обновить версию rails до такой, где ошибки не возникает, а все остальное примерно одинаково костыль, но костыль абсолютно рабочий.

Подведем итог

Bundler — действительно удобное средство для решения таких проблем. Любая система установки дополнительных пакетов, вроде rubygems, которая позволяет держать много версий одной и той же библиотеки, в итоге должна столкнуться с проблемами конфликтов версий и как-то их решать. Недостатком является только то, что саму версию rubygems выбрать при помощи bundler никак не получится, но это нужно уже совсем редко, в таких ситуациях придется скорее всего решать проблему при помощи RVM. Процесс деплоя с bundler не сильно усложнился, тем более все это так же легко автоматизируется с Capistrano.  Ограничивать версию разных gem для rails можно было и раньше, используя вызовы config.gem в environment.rb и хорошим тоном всегда считалось перечислять там нужные gem. Сейчас просто ограничивается набор gem не только для rails, но и для сервера приложений, а вызов bundle install просто заменяет нам старое rake gems:install.

На этом прощаемся с вами, всем удачи в развитии своих проектов и их размещении на Locum.ru. Кстати, кто-нибудь сталкивался в своей практике с необходимостью ограничить версию чего-то еще не только для самого rails-приложения, но и для сервера, кроме Rack? Если да — напишите, пожалуйста, об этом в комментариях. Пока по общению с нашими клиентами и собственной практике разработки и деплоя мы не встречались с другими примерами.

В этой статье я расскажу как проще и удобнее всего разворачивать приложения на ruby on rails на нашем хостинге. Используя эту инструкцию вы сэкономите время и легко обнаружите ошибки, которые могут возникать при развертывании Rails-приложений. Так же будет информация о самых частых проблемах и о том, как их избежать. Описанный метод так же подходит и для Rack-приложений, с некоторыми оговорками и незначительными изменениями в конфигурационных файлах.

Сервер приложений.

На серверах locum.ru для Rails-приложений по умолчанию используется unicorn. По запросу можно создать проект, который будет использовать Phusion Passenger, но обычно это не требуется. Unicorn зарекомендовал себя как быстрый и очень гибкий в использовании сервер для rails и rack.

Определяем нужную версию Rails.

Итак, мы решили разместить приложение на ruby on rails на сервере locum.ru. Первое что нам нужно знать — версию Ruby On Rails, которую использует наше приложение. Если это Rails ветки 2.3 и версия выше 2.3.5 — дополнительные действия не нужны. Можно сразу переходить к следующему шагу. Приложение на Rails 2.3.5 и старше скорее всего не получится запустить на Unicorn, из-за несовместимости этих версий с нужной версией Rack. Стоит отметить, что для большинства приложений будет достаточно просто поменять версию фреймворка на 2.3.6 в config/environment.rb, чтобы все заработало на unicorn, например с популярным issue-трекером Redmine это легко решает проблему запуска.

Если наше приложение использует rails 3.X, первым делом следует войти по ssh на сервер и установить соответствующий gem. Для этого нужно выполнить команду:

gem install rails --user-install --no-rdoc --no-ri

Если хочется использовать Bundler и устанавливать gem вне стандартного пути «~/.gem»,  то нужно установить хотя бы rack версии 1.2 в стандартный путь для gem аналогичной командой:

gem install raсk --user-install --no-rdoc --no-ri

Дело в том, что unicorn при старте запускается вне bundle, поэтому он будет использовать rack 1.1, и не сможет запустить приложение, требующее более новую версию rack, так же как и не сможет заменить в процесс работы уже активированную версию rack на более новую. Это является особенностью работы rack и часто приводит к ошибкам, если не помнить о ней.

Создание проекта из панели управления.

Теперь нужно зайти в панель управления и создать проект для нашего приложения. Заходим в раздел «проекты», создаем новый проект с типом Ruby On Rails. Если планируется использовать отличную от MySQL базу данных, то отключаем пункт «создать базу данных», так как по умолчанию создается база именно этого типа.

Размещение кода на сервере.

Создание проекта занимает некоторое время, но после этого у вас на сервер в директории projects появится директория с именем проекта, а в ней стандартная структура каталогов для Сapistrano.  Удобнее всего использовать именно capistrano для загрузки кода на сервер. Это стандартное средство, которое позволяет легко обновлять версию кода, перезапускать сервер приложений, а так же многое другое. Пример конфигурационного файла, адаптированного для использования с нашим хостингом и unicorn можно скачать по следующей ссылке: http://locum.ru/examples/deploy.rb

Заменив в примере нужные значения вы сможете легко загрузить ваш проект на сервер и перезапустить unicorn командой «cap deploy».

Если не хочется использовать capistrano — это не проблема, можно обойтись и без  нее. Структура директорий такова:

имя проекта/
   current -> текущий каталог для unicorn, является символической ссылкой на одну из версий в релизах
   releases/ -> директория с версиям приложения
       initial_release/ -> созданное по умолчанию приложение

Вам нужно разместить код вашего приложения в директории внутри releases, имя выберите произвольно, а затем изменить ссылку current, чтобы она указывала на директорию с вашим приложением, вместо initial_release, сделать это можно командой ln -sf по ssh.

Типичной ошибкой является удаление директории initial_release или всех файлов в ней.  Дело в том, что у нас unicorn использует очень удобный метод перезапуска. Когда приходит команда на перезагрузку сервера, запускается новый экземпляр unicorn, загружается код и затем, если все в порядке — новый экземпляр замещает предыдущий, а старый завершается. Сам процесс немного сложнее, но полное описание работы unicorn выходит за рамки этой статьи. Так как старый процесс был запущен в то время, когда ссылка current указывала на каталог initial_release, то и лог пишется там. Если новый экземпляр unicorn не сможет запуститься, то информацию об ошибке следует искать в файле log/unicorn.stderr.log именно по старому пути. Если эти файлы удалить, unicorn будет все еще пытаться писать по открытому заранее дескриптору, но прочитать мы эти данные уже не сможем. Если директория initial_release вам чем-то мешает, то вы всегда сможете удалить ее позже, после того как эти файлы уже перестанут использоваться.

После того, как файлы размещены и ссылка current изменена следует зайти в подробности проекта в панели управления хостингом и нажать кнопку «перезагрузить сервер».  В случае использования capistrano, сервер будет перезапущен автоматически. Через минуту вы можете зайти на URL вашего проекта и увидеть свое приложение в работе.

Распространенные ошибки, где их искать и как избежать.

Опыт показывает, что самой распространенной проблемой при размещении rails-приложений на нашем хостинге является  нехватка того или иного gem или же нужной его версии. Этого можно избежать, если описывать все, необходимые для работы кода gem в environment.rb и выполнять rake gems:install перед перезагрузкой unicorn с новым кодом. Так же можно использовать bundler и выполнять bundle install. Имейте ввиду, что команда bundle по умолчанию будет пытаться установить gem в системные директории, что конечно же не удастся сделать без root-доступа. Поэтому не забывайте всегда использовать ключ —path с указанием пути, куда вы хотите устанавливать локальные gem. Можно делать это, например, в директорию «~/.gem».

Так же, некоторые пользователи банально забывают внести нужные настройки для базы данных в database.yml. Не забывайте, что на нашем хостинге все проекты запускаются в режиме ‘production’, а значит и настройки нужно вносить в соответствующей секции database.yml

Что делать, если после перезагрузки кода unicorn на сайте проекта ничего не поменялось? Это значит, что новый экземпляр unicorn не смог запуститься по какой-то причине. Для выяснения причины нужно посмотреть последние строки файла log/unicorn.stderr.log в той директории, где запущена версия unicorn, которая осталась работать. При загрузке нового приложения это будет releases/initial_release.

Еще одна частая ошибка, это попытка зайти на домен, созданный для проекта сразу после появления его в панели управления. Дело в том, что для перезагрузки конфигурации DNS-сервера требуется некоторое время, потому лучше подождать несколько минут. В противном случае можно оказаться в неприятной ситуации. DNS сервер вашего провайдера может кэшировать ответы на запросы, если вы зайдете слишком рано и получите ответ, что такого домена нет, и это попадет в кэш, может получиться, что после того, как наш DNS сервер уже начнет сообщать IP-адрес этого домена, вы  все еще будете получать ошибочный ответ из кэша.

Коллектив Locum.ru желает успеха всем нашим пользователям в разработке и размещении проектов.

У веб-разработчиков часто возникает вопрос: какой же метод запуска rails приложений выбрать? Попробуем рассмотреть плюсы и минусы каждого из них. Сразу оговоримся, что вариант jruby (запуск ruby кода в jvm) оставим без внимания, как специфический и для нашего проекта не очень интересный.

Mongrel

Первый метод, что приходит в голову, — Mongrel cluster. В основном, именно он описан в литературе по ruby on rails, он же используется для запуска rails-кода в режиме разработки (development environment). Все, что необходимо для запуска rails с mongrel cluster уже разработано и идет в стандартной поставке, также готовы и методы для capistrano. Казалось бы: бери, да пользуйся! Но, как говорится, без ложки дегтя тут не обходится.
Как же работает rails-приложение, запущенное при помощи mongrel cluster? Слово cluster в данном случае использовано не случайно. Дело в том, что сервер mongrel умеет обрабатывать одновременно только один запрос, поэтому запускается некоторое количество серверов на разных портах. Чтобы скрыть эти нюансы от посетителей сайта, используется прокси-сервер. Он распределяет между серверами mongrel запросы для своевременной их обработки. Каждый mongrel — это процесс, который выполняется независимо от своих «собратьев». Поскольку все они работают с одной базой данных и одной версией кода, запросы могут приходить на любой из них. Никаких проблем это не вызывает. Если ваш сервер перестал справляться с нагрузкой, вы легко можете добавить к нему еще один, запустив на нем еще некоторое количество серверов mongrel. Изменений в коде приложения для такой кластеризации делать не придется, ведь ruby on rails изначально рассчитан на данный подход. Единственное, придется обеспечить всем серверам доступ к хранилищу сессионных данных. Это могут быть и СУБД, и memcached, и примонтированная сетевая файловая система (NFS). Такое действие необходимо для того, чтобы при случайном распределении запросов по серверам сессия пользователя не терялась, т.к. первый его запрос может обрабатывать один mongrel, второй — уже другой и т.д.
А вот теперь пора поговорить о минусах. Самый очевидный из них заключается в том, что каждый из серверов mongrel в силу своей автономности будет загружать в память собственную копию кода rails, кода приложения и всех необходимых библиотек. Вот вам и обратная сторона простого кода сервера и легкой возможности кластеризации. При среднем проекте каждый mongrel запросто потребляет около 100М памяти. И если запускать на сайт по три сервера mongrel (т.к. одного явно недостаточно), то память будет потребляться в очень больших количествах. Да, сегодня 300-500 мегабайт памяти – цифра не слишком серьезная. Однако не стоит забывать, что речь идет о разделяемом хостинге, а значит число таких сайтов будет измеряться сотнями. В такой ситуации потребление памяти действительно становится проблемой.

Thin

Еще одной слабой стороной сервера приложений mongrel является то, что он обязательно занимает один порт. Это создает возможность для различных коллизий и трудно отслеживаемых ошибок. Например, пользователю A выделены порты 3001, 3002 и 3003. Он остановил на время свой mongrel-кластер, а пользователь B в это время взял и запустил на 3001-м порту собственный. При старте один из серверов mongrel пользователя A обязательно упадет, так как порт, который он собирается прослушивать, уже занят другим процессом. Пользователь A ничего не сможет с этим сделать, ведь он никак не может остановить процесс пользователя B. А тем временем один из трех запросов на сайт пользователя A будет попадать на чужой mongrel, так как фронтенд настроен именно на эти порты. Конечно, обратившись к администрации сервера, пользователь A решит свои проблемы, но осадочек останется… Есть ли выход? Дать определенному пользователю возможность прослушивать только конкретный список портов средствами современных операционных систем не так-то просто, все это лишь еще раз усложнит общую систему. Хорошим решением было бы слушать не порт, а unix сокет, но mongrel не обладает такой возможностью.Еще один известный метод запуска rails приложений – thin. Он разработан с использованием EventMachine и Rack, достаточно хорошо оптимизирован. Это делает его более производительным сервером, чем mongrel. Thin обладает теми же что и mongrel особенностями в вопросах одновременной обработки запросов и кластеризации. В сравнении с mongrel он потребляет меньше памяти, но по-прежнему загружает всю копию rails для каждого экземпляра. Большим и важным для хостеров плюсом thin является то, что он умеет «слушать» unix-сокеты вместо стандартных tcp портов. Это позволяет избежать неприятной проблемы, что была описана в примере для сервера mongrel. Ограничивать права на сокет, по сути являющийся файлом с атрибутами чтения и записи, гораздо проще и удобнее. К тому же работа через unix-сокеты ведется быстрее из-за отсутствия накладных расходов на tcp/ip стэк. Мы по возможности рекомендуем использовать unix-сокеты вместо tcp портов. Это действительно положительно сказывается на скорости работы приложения. В качестве подтверждения — ссылка на некоторые результаты сравнения серверов thin и mongrel с точки зрения производительности.
Настройка и запуск thin не сложнее чем у сервера mongrel, конфигурационный файл по-прежнему представляет из себя YML. Для capistrano так же легко добавить нужный код в deploy.rb, чтобы перезапуск серверов thin происходил автоматически при выкладывании новой версии кода. С thin вместо mongrel хостеру (а значит и пользователям) живется действительно легче. Однако проблема большого потребления памяти все еще остается. Ведь получается, что для каждого проекта независимо от текущего количества запросов будет запущено несколько серверов thin, а каждый из них поместит в память весь код rails и самого приложения.

Passenger

Попробуем решить проблему с памятью при помощи Phusion Passenger, известного также как mod_rails или mod_rack. Passenger — это модуль для популярных сегодня веб-серверов Apache и Nginx. Он изначально создан для запуска большого количества rails приложений. Passenger грамотно распределяет ресурсы и потребляет память по мере необходимости. Проблем с прослушиванием большого количества портов разными процессами тоже, по понятным причинам, нет. При этом в конфигурационном файле можно указать интерпретатор ruby, который будет использоваться для запуска rails. Это при желании позволит использовать ruby enterprise edition и выиграть в потреблении памяти еще до 30%. Для пользователя все опять же остается достаточно прозрачно. Для перезагрузки кода приложения теперь нужно просто создать файл tmp/restart.txt или изменить его время последнего доступа. Это легко автоматизируется средствами capistrano. Каждый проект до сих пор имеет возможность использовать свою версию rails, достаточно лишь установить необходимый gem. Passenger устанавливается при помощи rubygems, затем вам нужно будет скомпилировать модуль для вашего веб-сервера и включить его в сборку. По умолчанию код rails будет запускаться с правами пользователя, который владеет файлом environment.rb. Это поведение вполне удобно для хостера, но при желании его можно изменить соответствующими настройками, описанными в документации. Возможность кластеризации при этом остается, просто уже не диктуется необходимостью: ведь никто не мешает поставить несколько веб-серверов, на которых работает passenger за балансирующим прокси.
Phusion Passenger умеет работать не только с rails, но и с любым приложением, которое следует rack-интерфейсу. Это позволяет запускать код, разработанный с использованием фреймворков Merb, Sinatra и других rack-приложений. Мы выбрали для себя связку Nginx + Passenger как самую выгодную по производительности и удобству для нас и наших пользователей. Использование модуля Nginx вместо Apache обусловлено нежеланием поддерживать лишнее звено в цепи запуска rails приложений без явной необходимости. Ведь чем проще система, тем удобнее ее поддерживать, а значит и работа будет стабильнее.

Смотрите также:

Дорогие друзья! Дружная команда Locum поздравляет вас с Новым годом!

Уходящий 2009-й год ознаменовался запуском нашего проекта в широкую эксплуатацию. Сегодня, в предновогоднюю пору, уже можно подвести некоторые итоги работы Locum и поделиться планами на будущее. Итак, приступим.

За десять месяцев, прошедших со старта проекта, мы исправили более 200 ошибок и учли около 500  пожеланий клиентов. Мы постоянно стремимся обеспечивать самые высокие скорости работы ваших проектов. Среднее время непрерывной работы наших серверов составило около 50 дней, а их доступность — 99,56%.

Для вашего удобства мы запланировали и внедрили такие замечательные вещи как возможность размещения Django-проектов, Passenger для обработки Ruby on rails проектов, а также  услугу виртуального выделенного сервера на базе технологии Xen. Кардинальные изменения претерпел дизайн нашего сайта и панели управления, в итоге став более современным и удобным.

В новом году мы не собираемся останавливаться на достигнутом и будем радовать вас новыми услугами и специальными предложениями (в планах уже значатся более 150 различных усовершенствований!). В их числе:

• долгожданная поддержка Java-проектов на тарифах виртуального хостинга;
• легкая и быстрая установка популярных web-приложений — всего пара минут и вы сможете получить работающий блог или информационный сайт;

• SMS-уведомления пользователей;

• работы по улучшению панели инструментов;

• специально от отдела по работе с клиентами — новая партнерская программа.

Конечно же, это далеко не все, что мы собираемся внедрить в наступающем году. Ведь политика Locum идти навстречу пожеланиям клиентов, предоставляя сервис самого высокого качества по доступным ценам, остается неизменной. Каждая наша услуга основана прежде всего на стабильных и хорошо оттестированных системных компонентах, что позволяет вам всегда быть уверенными в полной стабильности и качестве предлагаемого продукта.

Накануне праздничных дней хочется сказать теплые слова и пожелания в адрес абсолютно всех наших клиентов! Особенно хочется поблагодарить самых активных посетителей, которые оставляют свои идеи и предложения в системе Reformal. Ни одна из этих здравых мыслей не осталась без внимания, а многие из них будут реализованы уже в самом ближайшем будущем. Следите за нашими анонсами
Отдельное спасибо также тем, кто публикует о нас такие положительные отзывы. Поверьте, нам очень приятно, что вы так высоко оцениваете нашу работу.

Еще раз с праздником! Здоровья и счастья вам и вашим близким! Пусть сбудутся все самые сокровенные и светлые мечты!

Locum — лучший дом для ваших интернет-проектов.

Web-приложения набирают все большую популярность, развиваются средства разработки таких приложений, появляются новые языки программирования и фреймворки. Понятие «сайт» практически стало синонимом «проект», когда от браузера требуется гораздо больше, чем просто показать страничку-другую текста.

Хостинговые технологии не должны отставать от технологий создания web-проектов. Необходимо обеспечивать работоспособность широкого спектра фреймворков, написанных на очень разных языках: от традиционного PHP до нетривиального Lisp.

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

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

Основное преимущество проектно-ориентированного подхода — это возможность одному пользователю создавать проекты разных типов без необходимости повторной регистрации или переключения на другой сервер. К одному аккаунту можно привязать как традиционный PHP-проект, так и Django-приложение, которое будет работать также прозрачно для пользователя. В будущем мы планируем значительно расширить список доступных типов проектов, наша архитектура позволяет сделать это без особого труда.

Пользуясь услугами хостинга, клиенты видят только веб-интерфейс панели управления и окно ftp-клиента. А ведь многим наверняка интересно узнать о том, каким же образом работает вся система? Вот вкратце принципы работы архитектуры, которую мы выбрали для предоставления общего интерфейса управления ресурсами хостинг-серверов.

Естественно, веб-интерфейс — это далеко не основной компонент системы. Он лишь принимает запрос пользователя, конвертирует его в удобный для системы формат и кладет в особую очередь задач для выполнения. Стоит заметить, что какое-либо атомарное с точки зрения интерфейса пользователя действие может на самом деле состоять из некоторого количества мелких операций. Например, пользователь, создавая новый сайт, кликает на соответствующую кнопку в своей панели управления. Та определяет, какие действия нужно выполнить: добавить DNS-имя, создать директорию сайта в домашней папке пользователя, скопировать в нее стандартные файлы-заглушки, создать конфигурационный файл веб-сервера и т.д. После того, как задачи отправлены в очередь, работа веб-интерфейса заканчивается. В дело вступает второе звено нашей системы — специальный процесс, который следит за очередью задач и их выполнением. Он постоянно получает запросы и отчеты от третьего звена — маленьких рабочих серверов, отвечающих за исполнение всех физических действий на той или иной машине. Обработчик очереди, руководствуясь системой приоритетов, а также специализацией конкретного сервера, видит запросы от этих приложений, анализирует текущую очередь задач и выбирает из них первоочередную. После этого задача получает статус «в работе», и обработчик очереди ожидает отчета об ее исполнении. Тут надо отметить, что некоторые задачи (регистрация доменного имени и др.) требуют достаточно много времени, поэтому была выбрана именно такая схема взаимодействия компонентов системы. Обработчик очереди не ждет мгновенного ответа от исполнителя, но помнит о каждой задаче и в любой момент готов принять отчет о ее исполнении.

Если все эти операции прошли без помех, то действия, которые пользователь хотел выполнить, обретают свое физическое воплощение. Если же произошла ошибка, этот факт логируется для дальнейшего разбирательства администратором. В любом случае, обработчик очереди получит отчет об удачном или неудачном исполнении каждой поставленной задачи. Когда задача выполнена, она получает соответствующий статус и покидает активную очередь. Однако все сведения о запрошенных действиях сохраняются, чтобы всегда можно было восстановить картину событий для поиска ошибок, а также сбора статистики. Настройка серверов организована таким образом, что пользователи, выполняя свои команды, никак не могут помешать друг другу. Сервера-исполнители задач выполняют физические действия от имени соответствующей учетной записи в системе. Такой подход позволяет при непредвиденных обстоятельствах максимально обезопасить данные наших клиентов.

Помимо постоянно функционирующих трех основных звеньев системы на главном сервере периодически запускаются вспомогательные процессы. Они предназначены для обработки биллинга, данных системы электронных платежей, API-регистра доменов и тому подобных внешних сервисов.

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

Такой подход нам представляется весьма удобным. Сложности, с которыми приходится сталкиваться при разработке данной системы, с лихвой окупаются в дальнейшем за счет удобства использования и масштабируемости.

С каждым днем отрасль IT бурно прогрессирует и новые технологии растут как грибы после дождя. С одной стороны, такие темпы радуют, но с другой — создают достаточно много сложностей. Хостерам (мы же все живые люди!) за динамикой развития технологий уследить также непросто. Отсюда и возникают проблемы при выполнении важнейшей задачи для любой хостинговой компании — как предоставить клиентам возможность использовать самые передовые IT-достижения, при этом не нарушив работу старых проектов? Ведь, с одной стороны, нельзя отставать от прогресса и конкурентов, а с другой — хочется стабильности и проверенных временем решений.

В таких ситуациях часто приходится балансировать на грани, к тому же разработчики языков программирования, фреймворков и серверов приложений иногда недостаточно заботятся об обратной совместимости своих продуктов.  Это сильно усложняет работу хостеров. Посудите сами: код, написанный под php 4, вовсе не обязательно будет стабильно работать с пятой версией этого популярного языка, с ruby 1.9 будет работать rails, но половина популярных gem-ов — не будет.

Многим IT-специалистам известен золотой принцип: «Работает — не трогай!». Он действительно помогает избежать лишних проблем, но, к сожалению, не универсален. С таким подходом легко превратиться в этакого IT-ретрограда, ведь на современном рынке хостинга можно и сейчас встретить серверы под управлением FreeBSD 4.11 (вышедшей еще в 2005 году), на которых предоставляется хостинг с php 4 и mysql четвертой ветки. В такой ситуации и сотрудники хостинговой компании, и их клиенты не могут использовать множество новых возможностей, появившихся в последующих версиях операционной системы и прочего программного обеспечения. В итоге хостер имеет стабильность ради стабильности, пожертвовав ради нее как своим удобством, так и новыми клиентами, которые хотят пользоваться всеми современными технологиями.
Постоянное обновление до последних версий в день их появления на свет тоже не будет разумным решением. Ведь помимо очевидных проблем с безопасностью и стабильностью это может привести к ситуации, когда у половины клиентов перестанут работать их проекты (просто потому, что разработчики не очень хорошо подумали о вопросах обратной совместимости, или были сделаны слишком принципиальные изменения, и добиться совместимости со старым кодом не представлялось возможным).
Таким образом, хороший хостер вынужден постоянно балансировать на грани между ретроградством и переднем краем разработок, изучать вопрос совместимости старого кода с новыми версиями языков и платформ, выделять новые сервера для запуска новых решений, а потом тестировать все это для выявления проблем с безопасностью и стабильностью работы.

Прежде чем внедрить какую-либо новую технологию в проект LOCUM, мы тщательно изучаем опыт других специалистов, чтобы убедиться в готовности данного решения для практического использования. Затем тестируем его на некотором количестве размещаемых у нас ресурсов, чтобы выявить очевидные проблемы с совместимостью старого кода. И уже только после этого предлагаем нашим клиентам использовать новинку. Если у кого-то после перехода на нее возникают проблемы, мы всегда готовы дать советы по запуску проекта под новой версией или предложить вариант с возможностью сохранения старой версии языка, фреймворка или сопутствующего программного обеспечения. Конечно, этот путь намного хлопотнее, чем просто не трогать то, что уже работает. Но  топтаться на месте — занятие бесполезное и скучное. А нам и нашим клиентам нужны широкие перспективы.