Самая-самая последняя статья о настройке сервера для Rails

    Были времена на Хабре, когда каждый уважающий (и не очень) себя рельсовик зачем-то выкладывал свои рецепты настройки боевого сервера и деплоя приложения на Ruby on Rails. Таких статей было 60% от всех статей в хабе Rails, и отголоски того времени до сих пор всплывают: так, например, за август я нашёл две статьи про деплой рельс.

    Надоело.

    $ gem install from-scratch
    $ scratchify your_app_name your.host.com
    


    Что это за магия, читайте под катом.





    Gem «from-scratch»

    Больше всего на свете программисты любят решать задачи. Меньше всего на свете программисты любят решать задачи, которые до них решали уже тысячу раз. Я сам лично не один десяток раз вручную поднимал среду на очередной VPS для очередного проекта. В компаниях побогаче для этого есть DevOps'ы. Ну а когда их нет, то рано или поздно программист начинает осваивать автоматизацию сам. И либо пишет простенький bash-скрипт, либо разбирается с Chef.

    Собственно, магия вот в чём: команда генерирует типовой конфиг для Chef под указанный хост и имя проекта и запускает Chef Solo (режим, не требующий запуска сервера конфигурации). Только делает это всё так, чтобы вам не нужно было ничего понимать в Chef. Вот, что предусмотрено в данной конфигурации:

    • Установить все нужные пакеты
    • Создать «бесправного» пользователя
    • Установить в него RVM вместе с последним MRI
    • Установить PostgreSQL, запустить pgtune
    • Создать схему в PG, создать под неё пользователя
    • Сгенерировать database.yml и secrets.yml
    • Установить nginx
    • Загрузить типовой конфиг для nginx с upstream под любой rack-based сервер приложения через unix-сокет


    И не задавать никаких лишних вопросов.

    Всё, что вам останется — это настроить Capistrano:

    # config/deploy/production.rb
    server 'your.host.com', user: 'deploy', roles: %w(app db web)
    set :deploy_to, "/home/deploy/your_app_name"
    
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 20

      0
      Не хватает возможности юзать mysql вместо postgresql, а так же использовать passenger
        0
        я думал об этом, но если возьмусь за добавление такой возможности, то в отдельном геме. хочу этот оставить максимально простым.
          +1
          Ну вроде как на «сложность» гема не влияет. Добавить темплейты на базу с мускулем, темплейт на конфиг nginx'a с пассенджером. И передавать в качестве параметра --database=pgsql/mysql при создании сервера
        –1
        Да когда уже рубисты перестанут закатывать солнце вручную и начнут использовать системное.
          0
          не говорите загадками, поясните, о чём речь.
            –1
            Взять nginx из репозитория, взять сервер приложений из репозитория. А не давайте сами соберем nginx, сами соберем сервер приложений.
              0
              nginx устанавливается из репозитория. сервер приложения берётся из rubygems через Gemfile самого приложения, как и в любом приложении на Rails. ещё вопросы?
                +1
                сервер приложения берётся из rubygems через Gemfile самого приложения, как и в любом приложении на Rails. ещё вопросы?

                А из репозитория не? К примеру uwsgi.
                  –1
                  о проекте uwsgi я слышал только краем уха, и о том, что он поддерживает rack, я не знал (как и не знает большая часть rails сообщества).
                  я из интереса посмотрю потом, погоняю бенчмарки, но для типовых rails-проектов выбирать такую редкую птицу было бы непредусмотрительно.
                    0
                    Ну а что выбирать? Этих серверов как собак не резанных. Еще больше чем в java :)
                      +1
                      uwsgi — редкая птица? Или не верно понял?

                      uwsgi часто используется в стеке с Python.
                        +1
                        редкая в стеке Ruby.
            0
            Нормальные пацаны используют rbenv.
            </irony>

            А если по делу, зачем создавать отдельную схему в постгресе, а не отдельную бд? Если у юзера не будет прав на всю базу, потом аукнется, когда надо будет расширения ставить вроде hstore — прав не хватать будет. Либо вручную каждый раз лезть на сервер, либо при создании пользователя ему надо будет добавить права на pg_catalog.
              0
              ну потому что несекьюрно. если у вас будет два приложения крутиться на одном сервере, то при взломе одного из них с вашим решением второй тоже будет сразу дескредитирован. отдельный пользователь со своей БД под каждое приложение считается более правильной практикой.
                0
                Ну так это еще одна причина. У вас же:
                Создать схему в PG, создать под неё пользователя
                  0
                  мне кажется, мы с вами запутались в терминах «БД» и «схема».
            0
            Спасибо, как ни странно простых решений действительно не хватает, а необходимость каждый раз вручную прописывать одни и те же скрипты слегка достаёт.
            Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.
              0
              а что с воркерами не так? для delayed_job ничего лишнего устанавливать не надо, а для sidekiq нужен только redis, и я его не хочу в дефолтную поставку добавлять. наверху предлагали добавить возможность выбора через параметры, может позже добавлю --redis
                0
                Ну нужен 1) redis 2) скрипты для старта sidekiq при загрузке сервера. Последние постоянно приходится писать вручную, что в общем немного каменный век с учётом того что по факту sidekiq уже давно часть стандартного комплекта Rails.

            Only users with full accounts can post comments. Log in, please.