VPS для Ruby on Rails: puma и nginx

Rails на production — это связка puma как сервера приложений и nginx как reverse proxy. Разберём установку Ruby через rbenv, запуск puma под systemd через unix-сокет и настройку nginx.

Архитектура деплоя Rails

Классическая схема production-деплоя Rails состоит из двух слоёв. Puma — многопоточный сервер приложений, который держит Ruby-процессы. nginx стоит перед ним, отдаёт статику, терминирует TLS и балансирует нагрузку.

Связь между ними удобнее делать через unix-сокет, а не TCP-порт: это быстрее и не занимает сетевой порт. nginx обращается к сокету, puma слушает его.

• puma — сервер приложений, потоки и воркеры.
• nginx — статика, TLS, проксирование.
• unix-сокет — быстрая связь между ними.

Установка Ruby через rbenv

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

sudo apt update
sudo apt install -y git curl libssl-dev libreadline-dev zlib1g-dev build-essential libyaml-dev nginx nodejs
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc
rbenv install 3.3.4
rbenv global 3.3.4

Подготовка приложения

Клонируем код, ставим гемы в production-режиме, компилируем ассеты и мигрируем БД.

cd /opt/railsapp
bundle config set --local without 'development test'
bundle install
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate

Секретный ключ и переменные окружения задаём через RAILS_MASTER_KEY или .env, не коммитя их в репозиторий. Для базы данных в production используйте PostgreSQL, а строку подключения передавайте переменной DATABASE_URL — так конфигурация остаётся вне кода.

RAILS_ENV=production DATABASE_URL=postgres://user:pass@localhost/app_prod \
  bundle exec rails db:migrate

puma под systemd

Puma запускаем как systemd-сервис, слушающий unix-сокет. В config/puma.rb укажите bind на сокет.

# config/puma.rb
bind "unix:///opt/railsapp/tmp/sockets/puma.sock"
workers 2
threads 5, 5
environment "production"

[Unit]
Description=Puma for Rails
After=network.target

[Service]
User=deploy
WorkingDirectory=/opt/railsapp
ExecStart=/home/deploy/.rbenv/shims/bundle exec puma -C config/puma.rb
Restart=always
Environment=RAILS_ENV=production

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now puma
journalctl -u puma -f

Для фоновых задач Rails обычно поднимают отдельный процесс — Sidekiq или GoodJob — как самостоятельный systemd-сервис. Он живёт рядом с puma, читает ту же очередь и перезапускается независимо, что удобно при деплое.

nginx перед puma

nginx проксирует запросы в сокет puma и сам отдаёт скомпилированные ассеты из public — это разгружает Ruby.

upstream puma {
    server unix:///opt/railsapp/tmp/sockets/puma.sock;
}
server {
    listen 80;
    server_name example.com;
    root /opt/railsapp/public;
    location / {
        try_files $uri @puma;
    }
    location @puma {
        proxy_pass http://puma;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d example.com

Ресурсы и типичные ошибки

Каждый воркер puma держит копию приложения в памяти, поэтому Rails заметно требователен к RAM — планируйте от 2 ГБ. Сборка нативных гемов и precompile ассетов упираются в CPU и диск: AMD EPYC + NVMe у MAATRIX ускоряют деплой, а ежедневные бэкапы страхуют БД. Локации UK/США/РФ и оплата из России (карта РФ, СБП, крипта, MAAT) закрывают вопрос зарубежного сервера.

• Забыли precompile — стили и скрипты не грузятся в production.
• Нет RAILS_MASTER_KEY — приложение не расшифрует credentials и упадёт при старте.
• Слишком много воркеров — нехватка RAM и OOM.

Частые вопросы