☰

企业内部 URL 约定

tag-icon • tag-icon domain-name-system internal-dns url web-applications
企业内部 URL 约定

这里是开发人员...我希望听听您对此事的 IT 看法...

我正在为公司构建一个新的内部 Web 应用程序，并开始考虑如何部署它。此处的许多现有 Web 应用程序都直接使用其服务器名称进行链接，如下所示：

http://webserver123/someInternalApp/

出于各种原因，这让我感到不舒服。服务器名称会更改，服务器会宕机，用户不应该需要知道服务器名称才能找到他们的 Web 应用程序。使用服务器名称可以防止我们交换服务器或添加负载平衡器。如果您能想到其他不好的原因，请告诉我，这样我就可以提出更好的理由来改变这种做法。

展望未来，我希望在我们的内部 DNS 中设置一些更好的域名，这些域名将指向适当的 Web 服务器和应用程序。在我上一份工作中，我们遵循了如下惯例：

  • 对于生产：http://someInternalApp.myCompany.com/
  • 测试：http://test.someInternalApp.myCompany.com/
  • 对于发展：http://dev.someInternalApp.myCompany.com/

我喜欢这个更好的，因为应用程序名称是域名的关键部分，并且 dev/test/prod 环境指定很简单。但是，我有一些保留意见：

  • 将应用名称放在子域名中最终会创建大量很长且唯一的子域名。我喜欢为每个应用设置不同的域名，但我也觉得这样管理起来会比较困难。
  • 除了应用名称之外，没有任何内容可以表明此 URL 仅供内部使用。我读到过其他组织使用“corp.myCompany.com”或“int.myCompany.com”等子域名，这可能是个不错的选择。我不希望用户觉得他们可以在家访问这些网站。

以下是我倾向于使用的内部域名的一些选项：

内部子域中的应用程序名称：（它们有点长，但我认为所有内容都打包得很好）

  • http://someInternalApp.corp.myCompany.com/
  • http://dev.someInternalApp.corp.myCompany.com/

应用程序名称作为子目录：（较短的域名，但它意味着所有应用程序都是一个统一站点的一部分，但事实可能并非如此，并且它断开了环境指定与应用程序之间的联系）

  • http://corp.myCompany.com/someInternalApp
  • http://dev.corp.myCompany.com/someInternalApp

那么，让我们讨论一下……您觉得这些选项怎么样？我可能错过了哪些更好或更常见的内容？我有机会让我的公司在这方面走上更好的道路，所以我想找到一个好的惯例来推荐。

谢谢！

答案1

永远不要依赖你的应用是内部的还是外部的。开发时，一定要假设应用的受众不受你控制（因为事实确实如此）。

使用 ENV.APPNAME.DOMAIN.TLD

以 www. 作为“production”的别名。

答案2

如果您只在内部部署，则在选择方面有很大的自由。但是，随着顶级域名最近开放，您确实需要注意不要与即将推出的新外部名称发生冲突。

例如，你可以部署为http://contact.app/但如果 .app TLD 被注册，那么您可能会发现自己存在冲突。

因此，你最好使用类似http://contact.local/或者http://contact.lan/

出于 Apple 及其 Bonjour 服务兼容性的原因，最好避免使用 .local，而应该使用 .lan

或者只是http://contact.ourcompany/如果您的公司名称不太可能成为 TLD，那么这个方法就非常有效。

我会避免将应用程序名称作为子目录，因为这样没有必要，而且只会让目录变长。虚拟托管是实现该目的的方法，每个应用程序都有唯一的 URL。

而且您避免使用服务器名称是完全正确的，这绝对是不行的，因为服务器来来去去。

编辑1： 看RFC2606并从那里引用的可用内部使用 TLD 中进行选择。

需要注意的是，我建议的 .local 和 .lan 不能按照上述 RFC 注册。出于同样的原因，您也可以使用 .priv 和 .test。

答案3

这是基于某种观点的，因为当您仅在内部部署应用程序时，您拥有完全的控制权，那么您做什么并不重要......

大多数用户都会将他们需要使用的内部网络应用程序添加到书签中，因此不必太担心他们的 URL。

作为系统管理员，我希望有更多应用程序可以让我选择在可配置的子目录或子域的根目录中部署，并允许选择是否使用子域。

需要更体贴的开发人员不要走“简单”路线，而只是href=/images/bullet.png在随机页面上包含硬编码（相对）引用“ ”，而不是从多个部署/配置设置构建引用“ href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png”

请做出您的部署选择，例如任何主机名、端口号、HTTP/HTTPS 配置设置中的选择，并且不要对其进行硬编码。

我经常处于这样的境地：“管理层希望所有内部应用程序都遵循这一规则，http://intranet/apps/因为appname.intranet这太令人困惑了。而我们的供应商则恰恰相反；我们需要appname.intranet我们的设备/应用程序，因为我们有内置的 iframe 检查、内联中间人攻击和反向代理……

我发现很多商业 Web 应用程序都希望部署在 Web 服务器的根目录中，而部署在某个随机子目录中时，它们的工作可靠性会降低。例如，它们或多或少包含/css/main.css子目录的硬编码路径，这使得在同一台主机上托管多个应用程序变得很困难。但这些人似乎也不太担心其代码的可移植性。

相关内容