GearHead 29 окт 2015 в 04:46

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

2 мин

10K

Ruby * Ruby on Rails * Веб-разработка *

Комментарии 20

KriMs 29 окт 2015 в 07:04

Не хватает возможности юзать mysql вместо postgresql, а так же использовать passenger

GearHead 29 окт 2015 в 07:06

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

KriMs 29 окт 2015 в 07:10

Ну вроде как на «сложность» гема не влияет. Добавить темплейты на базу с мускулем, темплейт на конфиг nginx'a с пассенджером. И передавать в качестве параметра --database=pgsql/mysql при создании сервера

norguhtar 29 окт 2015 в 08:38

Да когда уже рубисты перестанут закатывать солнце вручную и начнут использовать системное.

GearHead 29 окт 2015 в 08:44

не говорите загадками, поясните, о чём речь.

norguhtar 29 окт 2015 в 08:59

Взять nginx из репозитория, взять сервер приложений из репозитория. А не давайте сами соберем nginx, сами соберем сервер приложений.

GearHead 29 окт 2015 в 09:12

nginx устанавливается из репозитория. сервер приложения берётся из rubygems через Gemfile самого приложения, как и в любом приложении на Rails. ещё вопросы?

norguhtar 29 окт 2015 в 11:43

сервер приложения берётся из rubygems через Gemfile самого приложения, как и в любом приложении на Rails. ещё вопросы?

А из репозитория не? К примеру uwsgi.

GearHead 29 окт 2015 в 12:20

о проекте uwsgi я слышал только краем уха, и о том, что он поддерживает rack, я не знал (как и не знает большая часть rails сообщества).
я из интереса посмотрю потом, погоняю бенчмарки, но для типовых rails-проектов выбирать такую редкую птицу было бы непредусмотрительно.

norguhtar 29 окт 2015 в 12:28

Ну а что выбирать? Этих серверов как собак не резанных. Еще больше чем в java :)

axsapronov 30 окт 2015 в 08:40

uwsgi — редкая птица? Или не верно понял?

uwsgi часто используется в стеке с Python.

GearHead 30 окт 2015 в 09:38

редкая в стеке Ruby.

Kroid 30 окт 2015 в 11:39

Нормальные пацаны используют rbenv.
</irony>

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

GearHead 30 окт 2015 в 12:49

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

Kroid 30 окт 2015 в 12:57

Ну так это еще одна причина. У вас же:

Создать схему в PG, создать под неё пользователя

GearHead 30 окт 2015 в 13:15

мне кажется, мы с вами запутались в терминах «БД» и «схема».

Kroid 30 окт 2015 в 16:34

Под схемой я понимаю это: www.postgresql.org/docs/9.1/static/ddl-schemas.html
т.е. иерархия такая: база -> схема -> таблица

malroc 30 окт 2015 в 12:23

Спасибо, как ни странно простых решений действительно не хватает, а необходимость каждый раз вручную прописывать одни и те же скрипты слегка достаёт.
Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.

GearHead 30 окт 2015 в 12:47

а что с воркерами не так? для delayed_job ничего лишнего устанавливать не надо, а для sidekiq нужен только redis, и я его не хочу в дефолтную поставку добавлять. наверху предлагали добавить возможность выбора через параметры, может позже добавлю --redis

malroc 30 окт 2015 в 13:09

Ну нужен 1) redis 2) скрипты для старта sidekiq при загрузке сервера. Последние постоянно приходится писать вручную, что в общем немного каменный век с учётом того что по факту sidekiq уже давно часть стандартного комплекта Rails.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий