Serwer cloud dla Ruby on Rails w Europie
Ruby on Rails pozostaje jednym z najbardziej produktywnych frameworków webowych do tworzenia aplikacji full-stack. Jego filozofia "konwencja nad konfiguracja" pozwala malym zespolom szybko dostarczac produkty. Ale Rails potrzebuje prawdziwego serwera - odpowiednio wymiarowanej, zawsze wlaczonej maszyny, która może obslugiwac zadania, zadania w tle i kompilacje assetów. Dla zespołów obslugujacych użytkowników europejskich, ten serwer powinien być w Europie.
Dlaczego hosting w UE jest wazny dla Ruby on Rails
Aplikacje Rails sa full-stack z natury. Serwuja HTML, obsluguja autentykacje, przetwarzaja płatności, wysylaja e-maile i często zarzadzaja przesylaniem plików. Każda z tych operacji wiaze sie z danymi osobowymi użytkowników. Zgodnie z GDPR, dane te musza być przetwarzane na infrastrukturze w UE, jesli obslugujecie mieszkańców UE.
Latencja sieci jest szczegolnie wazna dla Rails, poniewaz jego cykl zadania jest domyslnie synchroniczny. Hosting w Pradze daje 5-20 ms do większości Europy Zachodniej i Centralnej, w porównaniu z 100-150 ms od serwera w USA.
Minimalne wymagania serwera
Rails jest bardziej zasobochlannym niz lekksze frameworki. Kompilacja assetów jest szczegolnie wymagajaca.
- RAM - Minimum 2 GB do uruchomienia Puma i aplikacji Rails. Kompilacja assetów może być pika do 1,5-2 GB, dlatego zalecane jest 4 GB do wdrożeń produkcyjnych.
- CPU - Minimum 2 rdzenie. Wielowatkowy model Puma korzysta z rzeczywistego paralelizmu CPU.
- Dysk - Minimum 20 GB. SSD jest wymagany dla akceptowalnej wydajności bazy danych.
- Ruby - Wersja 3.2 lub nowsza. Ruby 3.3 oferuje znaczna poprawe wydajności.
- PostgreSQL - Wersja 15 lub nowsza.
Zalecana konfiguracja DCXV
Plany cloud VPS DCXV zaczynaja sie od EUR 15/miesiąc. Dla produkcyjnych wdrożeń z zadaniami w tle, plan 2 rdzenie / 4 GB RAM jest praktycznym punktem startowym.
Rails z Sidekiq uruchamia dwa procesy: Puma (serwer webowy) i Sidekiq (zadania w tle). Na 4 GB RAM mozna uruchomić Puma z 2-3 workerami, Sidekiq z 5-10 watkami i mieć jeszcze miejsce dla PostgreSQL.
Dla większych aplikacji dostepny jest dedykowany sprzęt DCXV od EUR 49/miesiąc. Wsparcie inżynierów 24/7 jest wlaczone w każdy plan. Szczegóły na https://dcxv.com/data-center#cloud
Przewodnik konfiguracji
# Zainstaluj Ruby 3.3 przez rbenv i zależności systemowe
sudo apt update && sudo apt install -y git curl libpq-dev postgresql postgresql-contrib redis-server nginx
git clone https://github.com/rbenv/rbenv.git ~/.rbenv && echo 'eval "$(~/.rbenv/bin/rbenv init -)"' >> ~/.bashrc
~/.rbenv/bin/rbenv install 3.3.0 && ~/.rbenv/bin/rbenv global 3.3.0
# Zainstaluj Bundler i gemy
gem install bundler
cd /var/www/myapp && bundle install --deployment --without development test
# Skompiluj assety i uruchom migracje
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate
# Uruchom Puma i Sidekiq przez systemd
sudo systemctl enable puma sidekiq && sudo systemctl start puma sidekiq
Oczekiwana wydajność
Aplikacja Rails na instancji 2 rdzenie / 4 GB w Pradze:
- Czas odpowiedzi - 50-150 ms dla typowych renderowan stron HTML z zapytaniami do bazy danych. Assety statyczne przez Nginx wracaja w poniżej 5 ms.
- Przepustowosc - 100-300 zadan na sekunde z Puma z 2 workerami i 5 watkami każdy.
- Zadania w tle - Sidekiq z 10 watkami przetwarza 200-500 zadan na minute.
- Latencja sieci - Poniżej 20 ms do Niemiec, Austrii, Polski i Czech z Pragi.
To oczekiwania dla sprzętu tej klasy, a nie pomiary z naszego laboratorium. Traktuj je jako punkt wyjścia do doboru rozmiaru i zmierz własne obciążenie: realne liczby zależą od twoich danych, zapytań i tuningu znacznie bardziej niż od dostawcy.
