Tenho um requisito de multilocação em que preciso hospedar alguns aplicativos em minha nuvem de serviço (AWS + lambda, EC2, S3). Eu tenho alguns aplicativos de UI em Angular (hospedados em AWS-S3) e uma API em Node (AWS lambda/EC2). Para o cliente padrão que sou eu, posso criá-lo como 5 vários subdomínios e redirecionar o registro A e tudo mais. Mas para outros locatários, eles apenas adicionarão um registro A a um de seus subdomínios, eles podem estar usando CPanel ou qualquer outro serviço regular ou pode ser hospedado em um VPS (domínios regulares).
Eu tenho uma configuração como esta, onde criei vários subdomínios e alterei seus registros A para apontar respectivamente
- api.me.com
- app1.me.com
- app2.me.com
- ...etc...
Mas para um inquilino diferente, tenho que criar uma configuração
- api.meuserviço.tenant-domain.com
- app1.meuserviço.tenant-domain.com
- app2.meuserviço.tenant-domínio.com
Como posso reduzir o esforço e não enfrentar desafios técnicos de domínios e registros A para meu locatário sempre que um novo locatário ingressa. Considere os desafios do certificado SSL para subdomínios
Posso perguntar às minhas novas opções de inquilino
- Opção 1: posso pedir ao meu locatário para adicionar um registro A a myservice.tenant-domain.com e usar href base para que todos os aplicativos estejam no mesmo subdomínio (não preferencial)
- Opção 2: peça ao locatário para criar subdomínios de vários níveis e, respectivamente, colocar registros A em cada aplicativo
- Opção 3: posso usar um curinga multinível de um subdomínio. Quais são os desafios aqui?
Por favor me ajude aqui.
Nada disso parece bom; mas existem outros métodos:
Opção 2b: Peça ao locatário para criar registros CNAME, apontando indiretamente através de algum subdomínio de sua escolha. Não tem efeito sobre os certificados, mas oferece flexibilidade para permitir que você altere os registros A por conta própria, se necessário.
Opção 2c: peça ao locatário para criar um registro DNAME, que também é um alias como CNAME, mas em vez de criar um alias para o próprio nome, ele cria um alias para todos os subdomínios. (É como um "CNAME curinga".)
Por exemplo, um "meuserviço.tenant-domínio.com. DNAME locatário3.seu-domínio.com." permitiria que você criasse app2.tenant3.your-domain.com em seu próprio nome e isso se tornaria automaticamente acessível como app2.myservice.tenant-domain.com. No entanto, nem todos os servidores DNS suportam a adição de registros DNAME.
Opção 4: peça ao locatário para criar um registro NS e delegar toda a subzona aos seus próprios servidores de nomes. Você terá então controle total dos registros DNS. (Claro, é sua responsabilidade fornecer servidores de nomes confiáveis.)
É o mesmo tipo de delegação que acontece quando você compra um domínio, mas na verdade pode ser feito em qualquer nível, apenas criando registros NS, o que qualquer servidor DNS pode fazer. No entanto, é provavelmente a opção de “maior esforço” da sua parte no que diz respeito à configuração de DNS.
Quanto aos certificados, só faz diferença para emissão; os navegadores clientes não se importam com o funcionamento dos subdomínios nos bastidores, desde que o certificado corresponda ao URL – não importa se o domínio é um curinga, um alias ou qualquer outra coisa. Para emissão com "desafio HTTP" todas as opções funcionam igualmente bem; para "desafio DNS" NS ou DNAME pode tornar as coisas mais fáceis.