Qual é a melhor maneira de configurar o Apache ou AWS para suportar um aplicativo de multilocação do Rails que permite que cada cliente tenha seu próprio nome de domínio?

Question

Estou criando um site do Rails 3 SaaS que permite a multilocação.

Quando um cliente se inscreve, ele coloca seu próprio nome de domínio, por exemplo, example.com. Preciso de example.com para apontar para meu aplicativo SaaS e servi-los em seu conteúdo.

Minhas perguntas são as seguintes:

Preciso criar um vhost do Apache para cada cliente usando seu próprio domínio?

Existe uma maneira mais fácil com o CNAME de apenas fazer com que o cliente aponte para o endereço IP do (s) meu (s) servidor (es) que, em seguida, encaminha a solicitação para o meu aplicativo através de algum vhost?

Eu seria capaz de criar o registro CNAME para o cliente para que ele não precise fazer nenhuma configuração?

Este seria um caso mais adequado ao Amazon Web Services?

Qualquer ajuda ou explicação ou correções na minha compreensão do DNS seria apreciada. Eu sou um desenvolvedor, então a parte de operações do servidor é um pouco nublada.

    

Answer 1

Resposta curta:

Apache:

Use apenas um vhost catchall / wildcard. Torna o provisionamento de contas mais fácil.

DNS:

Permitir somente subdomínios e fazer com que seus clientes criem um CNAME com seu provedor DNS existente.

AWS:

O uso da AWS ou não não afetará a resposta da pergunta em questão.

Resposta longa:

Sobre a configuração do Apache vHost:

Você tem várias opções para a configuração do vhost, incluindo:

,

• Os dois que você já mencionou:
  1. vhosts individuais
  2. um catchall vhost e manipulá-lo no nível do aplicativo
• Numerosos outros. A documentação do Apache vinculada ao LavaScornedOven Review ( link ) é um bom recurso. Quão especificamente você deve fazer isso realmente está além do escopo de sua pergunta, e eu explicarei por que momentaneamente.

O tipo de configuração do vHost que você escolhe depende do seu aplicativo frontend e de outros fatores:

• O novo processo de inscrição do cliente usa o software que você desenvolveu ou algo em lata?
• Se o primeiro, qual método será mais fácil para você implementar no seu processo de inscrição?
• Se o último, já tem uma disposição para criar vhosts na inscrição? Em caso afirmativo, use o que vem com o software.
• O que você quer que aconteça se um não cliente apontar o domínio dele para o seu IP? Considere isso antes de usar qualquer tipo de vhost "catchall".
• Por fim, somente você pode determinar qual método funcionará melhor para você.

Sobre a configuração do DNS:

Em primeiro lugar, algo que você deve definitivamente evitar:

• CNAME no ápice da zona. ou seja, example.com NÃO deve ser um CNAME. Não há problema se www.example.com for embora.

Suas opções:

• Deixe tudo para o cliente:
  1. Forneça ao cliente um endereço IP para usar
  2. Peça ao cliente para fazer um registro A para o nome do host que aponta para esse IP
  3. Opcionalmente, forneça ao cliente um tutorial para criar o registro DNS.
  4. Prós:
     • Mais fácil para você, pelo menos antecipadamente.
     • Não requer a hospedagem de DNS de ninguém
  5. Contras:
     • Os clientes podem ter dificuldade em seguir as instruções
     • Quando / Se você renumerar e sempre houver um novo endereço IP, espere um influxo massivo de tickets de suporte - não importa quanto aviso antecipado você dê.
  
  
  
• Peça ao cliente que use seus registros do NS:
  1. Peça aos seus clientes que alterem os servidores de nome de seus domínios para os seus com o registrador ou, se estiverem usando um subdomínio, para delegar esse subdomínio a você usando registros NS.
  2. Opcionalmente, forneça aos seus clientes instruções detalhadas sobre como fazer isso
  3. Verifique se o seu processo de inscrição cria automaticamente as zonas relevantes no seu DNS
  4. Opcionalmente, forneça uma interface para que seus clientes adicionem outros registros à sua zona, como o MX, etc, ou faça o autoprovide deles e hospede o email do seu cliente também ....
  5. Prós:
     • Abordagem mais simples para seus clientes.
     • Evita toda a preocupação com o que acontece se você precisar renumerar no futuro
     • Evita todo o enigma do CNAME
  6. Contras:
     • Agora você se torna um hoster de DNS e também um app hoster
     • Etapas extras de integração com seu processo de inscrição
  
  
  
• Permitir apenas que os clientes usem um subdomínio (incluindo, possivelmente, www)
  1. Peça ao cliente para criar um CNAME para esse subdomínio
  2. Opcionalmente, instrua o cliente sobre como criar um redirecionamento HTTP de seu domínio simples para o subdomínio.
  3. Prós:
     • Possivelmente a abordagem mais fácil.
     • Como muitos outros serviços de aplicativos hospedados usam essa abordagem, é mais provável que o cliente esteja familiarizado com ela e, portanto, com menor probabilidade de causar uma desordem real.
     • Como a abordagem NS, evita problemas durante a renumeração
  4. Contras:
     • NÃO permite que o cliente use seu domínio simples com seu serviço
  5. Recomendo vivamente esta abordagem - pelo simples motivo de serem os clientes habituais. Você pode considerar a possibilidade de permitir os outros métodos caso a caso.