Servidor cloud para Ruby on Rails na Europa

Servidor cloud para Ruby on Rails na Europa

Servidor cloud para Ruby on Rails na Europa

Ruby on Rails continua sendo um dos frameworks web mais produtivos para criar aplicações full-stack. Sua filosofia de convencao sobre configuração permite que pequenas equipes entreguem rápido. Mas o Rails precisa de um servidor real - uma máquina corretamente dimensionada, sempre ativa, que possa lidar com requisições, trabalhos em segundo plano e compilação de assets. Para equipes que servem usuários europeus, esse servidor deve estar na Europa.

Por que o hosting na UE importa para Ruby on Rails

As aplicações Rails sao full-stack por natureza. Elas servem HTML, gerenciam autenticação, processam pagamentos, enviam e-mails e frequentemente gerenciam uploads de arquivos. Cada uma dessas operações envolve dados pessoais dos seus usuários. Sob o GDPR, esses dados devem ser processados em infraestrutura dentro da UE se você atende residentes da UE.

A latência de rede e especialmente importante para o Rails porque seu ciclo de requisições e sincrono por padrão. Hospedar em Praga oferece 5-20 ms para a maior parte da Europa Ocidental e Central, comparado a 100-150 ms de um servidor nos EUA.

Requisitos mínimos do servidor

Rails e mais intensivo em recursos do que frameworks mais leves. A compilação de assets e especialmente exigente.

  • RAM - Mínimo 2 GB para executar o Puma e a aplicação Rails. A compilação de assets pode atingir picos de 1,5-2 GB, então 4 GB e fortemente recomendado para implantações em produção.
  • CPU - Mínimo 2 núcleos. O modelo multi-thread do Puma se beneficia do paralelismo real da CPU.
  • Disco - Mínimo 20 GB. SSD e necessário para desempenho aceitável do banco de dados.
  • Ruby - Versão 3.2 ou posterior. Ruby 3.3 oferece melhorias significativas de desempenho.
  • PostgreSQL - Versão 15 ou posterior.

Configuração recomendada DCXV

Os planos cloud VPS da DCXV comecam a partir de EUR 15/mês. Para implantações em produção com trabalhos em segundo plano, o plano de 2 núcleos / 4 GB RAM e o ponto de partida prático.

Rails com Sidekiq executa dois processos: Puma (servidor web) e Sidekiq (trabalhos em segundo plano). Com 4 GB de RAM, você pode executar o Puma com 2-3 workers, o Sidekiq com 5-10 threads e ainda ter espaço para o PostgreSQL.

Para aplicações maiores, hardware dedicado da DCXV esta disponível a partir de EUR 49/mês. O suporte de engenheiros 24/7 esta incluído em todos os planos. Mais informações em https://dcxv.com/data-center#cloud

Guia de configuração

# Instalar Ruby 3.3 via rbenv e dependências do sistema
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

# Instalar Bundler e gems
gem install bundler
cd /var/www/myapp && bundle install --deployment --without development test

# Compilar assets e executar migracoes
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate

# Iniciar Puma e Sidekiq com systemd
sudo systemctl enable puma sidekiq && sudo systemctl start puma sidekiq

Expectativas de desempenho

Uma aplicação Rails em uma instância de 2 núcleos / 4 GB em Praga:

  • Tempo de resposta - 50-150 ms para renders tipicos de páginas HTML com consultas ao banco de dados. Assets estáticos via Nginx retornam em menos de 5 ms.
  • Throughput - 100-300 requisições por segundo com Puma com 2 workers e 5 threads cada.
  • Trabalhos em segundo plano - Sidekiq com 10 threads processa 200-500 trabalhos por minuto.
  • Latência de rede - Menos de 20 ms para Alemanha, Austria, Polonia e Republica Checa a partir de Praga.

Estas são expectativas para hardware desta classe, não medições do nosso próprio laboratório. Use-as como ponto de partida para o dimensionamento e meça a sua própria carga: os números reais dependem dos seus dados, das suas consultas e do seu tuning muito mais do que do fornecedor.

Starlink Mini 2 atrás de CGNAT: como chegar a um local que muda
networkingcloudinfrastructure

Starlink Mini 2 atrás de CGNAT: como chegar a um local que muda

A Starlink Mini 2 chegou, mas os planos normais ficam atrás de CGNAT. Contámos 990.208 IPv4 para 12+ milhões de clientes e comparamos quatro formas de acesso.

Protestos contra centros de dados na Europa: o que fazer
clouddedicatedinfrastructure

Protestos contra centros de dados na Europa: o que fazer

A 6 de novembro, centenas entraram na obra da Microsoft em Amesterdão. Os números da rede neerlandesa, a latência medida a hubs da UE e o que fazer agora.

EUA rejeitam centros de dados 45 a 1: lições para clientes
clouddedicatedinfrastructure

EUA rejeitam centros de dados 45 a 1: lições para clientes

47 votações sobre centros de dados nos EUA, o lado restritivo venceu em 45. Recontamos os dados brutos e explicamos o que muda para quem aluga servidores.

AWS BYOIP em 2026: $43.80 por IPv4 ou o seu próprio /24
ipv4pricingcloud

AWS BYOIP em 2026: $43.80 por IPv4 ou o seu próprio /24

A AWS cobra $0.005 por hora por IPv4 público, $43.80 por ano. O BYOIP não paga isso: quando um /24 comprado ou alugado compensa, com uma verificação de ROA.

Sair do VMware após a Broadcom: guia de migração verificado
clouddedicatedinfrastructure

Sair do VMware após a Broadcom: guia de migração verificado

A Broadcom acabou com licenças perpétuas, cortou parceiros e escondeu o VDDK. Como mover VMs para KVM, Proxmox ou Hyper-V, com datas e uma conversão OVA testada.