Serveur cloud pour Ruby on Rails en Europe
Ruby on Rails reste l'un des frameworks web les plus productifs pour la creation d'applications full-stack. Sa philosophie "convention plutôt que configuration" permet aux petites equipes de livrer rapidement. Mais Rails a besoin d'un vrai serveur - une machine correctement dimensionnee, toujours allumee, capable de traiter des requêtes, des tâches en arrière-plan et la compilation d'assets. Pour les equipes qui servent des utilisateurs européens, ce serveur doit être en Europe.
Pourquoi l'hébergement EU est important pour Ruby on Rails
Les applications Rails sont full-stack par nature. Elles servent du HTML, gèrent l'authentification, traitent les paiements, envoient des e-mails et gèrent souvent les uploads de fichiers. Chacune de ces operations implique des données personnelles de vos utilisateurs. En vertu du RGPD, ces données doivent être traitees sur une infrastructure au sein de l'UE si vous servez des residents de l'UE.
La latence réseau est particulierement importante pour Rails car son cycle de requêtes est synchrone par défaut. L'hébergement a Prague vous donne 5-20 ms vers la plupart de l'Europe Occidentale et Centrale, contre 100-150 ms depuis un serveur base aux États-Unis.
Exigences minimales du serveur
Rails est plus gourmand en ressources que les frameworks plus légers. La compilation d'assets est particulierement exigeante.
- RAM - Minimum 2 Go pour faire tourner Puma et l'application Rails. La compilation d'assets peut atteindre 1,5-2 Go, donc 4 Go est fortement recommandé pour les déploiements en production.
- CPU - Minimum 2 coeurs. Le modèle multi-thread de Puma beneficie du parallelisme CPU réel.
- Disque - Minimum 20 Go. Le SSD est nécessaire pour des performances de base de données acceptables.
- Ruby - Version 3.2 ou superieure. Ruby 3.3 offre des ameliorations de performance significatives.
- PostgreSQL - Version 15 ou superieure.
Configuration DCXV recommandée
Les plans cloud VPS de DCXV commencent a EUR 15/mois. Pour les déploiements en production avec des tâches en arrière-plan, le plan 2 coeurs / 4 Go de RAM est le point de depart pratique.
Rails avec Sidekiq execute deux processus: Puma (serveur web) et Sidekiq (tâches en arrière-plan). Avec 4 Go de RAM, vous pouvez faire tourner Puma avec 2-3 workers, Sidekiq avec 5-10 threads et encore avoir de la place pour PostgreSQL.
Pour les applications plus importantes, le matériel dédié DCXV est disponible a partir de EUR 49/mois. Le support ingenieur 24/7 est inclus dans chaque plan. Plus d'informations sur https://dcxv.com/data-center#cloud
Guide de configuration
# Installer Ruby 3.3 via rbenv et les dépendances système
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
# Installer Bundler et les gems
gem install bundler
cd /var/www/myapp && bundle install --deployment --without development test
# Compiler les assets et exécuter les migrations
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate
# Démarrer Puma et Sidekiq avec systemd
sudo systemctl enable puma sidekiq && sudo systemctl start puma sidekiq
Attentes de performance
Une application Rails sur une instance 2 coeurs / 4 Go a Prague:
- Temps de réponse - 50-150 ms pour les rendus de pages HTML typiques avec des requêtes de base de données. Les assets statiques via Nginx retournent en moins de 5 ms.
- Débit - 100-300 requêtes par seconde avec Puma avec 2 workers et 5 threads chacun.
- Tâches en arrière-plan - Sidekiq avec 10 threads traite 200-500 tâches par minute.
- Latence réseau - Moins de 20 ms vers l'Allemagne, l'Autriche, la Pologne et la République tchèque depuis Prague.
Ce sont des attentes pour du matériel de cette classe, pas des mesures issues de notre propre laboratoire. Prenez-les comme point de départ pour le dimensionnement et mesurez votre charge : les chiffres réels dépendent de vos données, de vos requêtes et de votre tuning bien plus que du fournisseur.
