Convenções de URL interno da empresa
desenvolvedor aqui ... Eu gostaria da sua perspectiva de TI neste ...
Estou criando um novo aplicativo Web interno para minha empresa e começando a pensar em como ele será implantado. Muitos dos aplicativos da web existentes aqui estão vinculados ao uso direto de seus nomes de servidor, assim:
Isso me deixa desconfortável por vários motivos. Os nomes dos servidores são alterados, os servidores ficam inativos e os usuários não precisam saber os nomes dos servidores para encontrar seu aplicativo Web. O uso de nomes de servidor nos impede de trocar servidores ou adicionar balanceadores de carga. Se você puder pensar em outras razões pelas quais isso é ruim, informe-me para que eu possa defender melhor a mudança dessa prática.
No futuro, gostaria de ter alguns nomes de domínio melhores configurados em nosso DNS interno que apontem para o servidor e aplicativo da web apropriados. No meu último trabalho, seguimos uma convenção mais ou menos assim:
Para produção: http://someInternalApp.myCompany.com/
Para teste: http://test.someInternalApp.myCompany.com/
Para desenvolvimento: http://dev.someInternalApp.myCompany.com/
Eu gosto mais disso , pois o nome do aplicativo é uma parte essencial do nome do domínio e a designação do ambiente dev / test / prod é simples. No entanto, tenho algumas reservas:
A colocação do nome do aplicativo no subdomínio acabará por criar muitos subdomínios longos e exclusivos. Gosto de ter domínios diferentes para cada aplicativo, mas também acho que pode ser difícil de gerenciar.
Além do nome do aplicativo, não há nada para designar que esse URL é apenas interno. Eu li sobre outras organizações usando um subdomínio como "corp.myCompany.com" ou "int.myCompany.com", o que pode ser bom. Não quero que os usuários tenham a impressão de que podem acessá-los em casa.
Aqui estão algumas opções sobre o que eu estou inclinado para nomes de domínio interno:
Nome do aplicativo no subdomínio interno: (eles ficam um pouco longos, mas tudo está bem embalado, acho)
Nome do aplicativo como subdiretório: (nome de domínio mais curto, mas implica que todos os aplicativos fazem parte de um site unificado, o que pode não ser, e desconecta a designação do ambiente do aplicativo)
Então, vamos discutir ... O que você acha dessas opções? Existe algo melhor ou mais comum que eu possa ter perdido? Tenho a oportunidade de colocar minha empresa em um caminho melhor nesse sentido, por isso gostaria de encontrar uma boa convenção para recomendar.
Truques de DNS, reescrita de URL e hospedagem virtual são seus amigos aqui. Isso será em uma pilha da Microsoft ou Linux?
Microsoft ... aplicações web Net em execução no IIS no Windows
nomear coisas é um problema difícil na ciência da computação. Espere que algum esquema (especialmente com números incrementados automaticamente) falhe em algum momento. Redirecionamentos e DNS são o caminho para ambiguar nomes específicos.
— Tdder42
Nunca dependa se seu aplicativo será interno ou externo. Sempre desenvolva como se o público do aplicativo estivesse fora do seu controle (porque está).
Vá com ENV.APPNAME.DOMAIN.TLD
Com www. como o alias para "produção".
Abordagem simples e sólida, eu gosto. Hoje em dia, é ainda mais relevante com navegadores como o Chrome que sincronizam seus favoritos e histórico. Se eu marcar um aplicativo de local de trabalho interno no Chrome, esse favorito será sincronizado com meu PC doméstico e meu dispositivo Android. Quando o marcador chegar, é melhor não apontar para outra coisa na internet.
Se você estiver implantando apenas interno, terá grande liberdade na seleção. No entanto, com a abertura dos domínios de nível superior, como recentemente, convém tomar cuidado para não entrar em conflito com um novo nome externo.
por exemplo, você pode implantar como http://contact.app/, mas se o TLD .app for registrado, poderá ser conflitante.
Portanto, provavelmente é melhor usar algo como http: //contact.local/ ou http: //contact.lan/
Por motivos de compatibilidade com a Apple e o serviço Bonjour, é melhor evitar o .local; talvez seja esse o caso
Como alternativa, apenas http: //contact.ourcompany/ funcionaria muito bem se o nome da sua empresa dificilmente se tornasse um TLD.
Eu evitaria o nome do aplicativo como um subdiretório, porque é desnecessário e apenas o torna mais longo. Hospedagem virtual é o caminho a percorrer com um URL exclusivo por aplicativo.
E você está certo em evitar nomes de servidores, isso é definitivamente não-não, porque os servidores vêm e vão.
Edit 1 : Veja RFC2606 e faça a sua escolha nos TLDs de uso interno disponíveis aqui mencionados.
Apenas como uma observação aos comentários - .local e .lan, como eu recomendo, não são registráveis ​​conforme a RFC acima. Você também pode usar .priv e .test pelos mesmos motivos.
O único espaço para nome DNS do qual você pode ter praticamente controle garantido, na Internet, são os subdomínios de um domínio de segundo nível que você possui. Qualquer idiota com dinheiro pode criar um TLD hoje, portanto, usar qualquer tipo de TLD personalizado dentro de uma rede parece uma má ideia para mim. Eu usava subdomínios do nome da minha própria empresa e vivia com o fato de que os URLs serão mais longos.
@EvanAnderson Proponho um KickStarter para arrecadar US $ 185 mil pela taxa de inscrição para registrar o .localgTLD e estabelecer uma lição permanente sobre como configurar adequadamente seus ambientes.
— Sammitch 11/09/14
Não é mais recomendável usar um TLD que você não possui, nem usar espaços de pesquisa de DNS. Consulte as informações sobre colisão de nomes da ICANN .
Essa opinião é baseada em alguma coisa, porque quando você implanta apenas seu aplicativo internamente, você tem controle total e isso realmente não importa o que você faz ...
A maioria dos usuários marcará quais aplicativos da Web internos eles precisam usar de qualquer maneira, portanto, não se preocupe muito com os URLs.
Como administrador do sistema, eu adoraria mais aplicativos que me dêem a opção de implantar em um subdiretório configurável ou na raiz de um subdomínio, permitindo a opção de usar subdomínios ou não.
É preciso um desenvolvedor mais atencioso para não seguir a rota "fácil" e incluir apenas uma referência "relativa" ( href=/images/bullet.png"relativa") em uma página aleatória e em vez de criar uma referência a partir de várias definições de implantação / configuração " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"
Faça suas escolhas de implantação, como nomes de host, números de portas, opções nas configurações de HTTP / HTTPS e não as codifique.
Muitas vezes estive do lado de quem recebe "o gerenciamento quer todos os aplicativos internos http://intranet/apps/porque appname.intraneté muito confuso. E o oposto de nossos fornecedores; precisamos appname.intranetdo nosso dispositivo / aplicativo, pois temos verificação interna contra iframes, destacando o homem-em-um -ataques médios e proxy reverso ....
Descobri que muitos aplicativos Web comerciais esperam ser implantados na raiz do servidor da Web e não funcionam de maneira confiável quando implantados em algum subdiretório aleatório. Ou seja, incluem, por exemplo, caminhos mais ou menos codificados para /css/main.csssubdiretórios, dificultando a hospedagem de vários aplicativos no mesmo host. Mas esses grupos também não parecem muito preocupados com a portabilidade de seu código.
A instalação de vários aplicativos com requisitos de instalação raiz no mesmo servidor é trivialmente resolvida por meio de hospedagem virtual com um nome DNS separado para cada aplicativo.
Para o leigo (meu então gerente e CTO) que ainda comporta vários servidores (embora não sejam caixas reais), no sentido de que eles não aparecem como intranet / apps / inventário e intranet / apps / billing.