Konventionen für unternehmensinterne URLs


8

Entwickler hier ... Ich möchte Ihre IT-Perspektive auf diese ...

Ich erstelle eine neue interne Web-App für mein Unternehmen und beginne darüber nachzudenken, wie sie bereitgestellt werden soll. Viele der hier vorhandenen Web-Apps sind wie folgt direkt mit ihren Servernamen verknüpft:

http://webserver123/someInternalApp/

Dies macht mich aus verschiedenen Gründen unwohl. Servernamen ändern sich, Server fallen aus und Benutzer sollten keine Servernamen kennen müssen, um ihre Webanwendung zu finden. Die Verwendung von Servernamen verhindert, dass wir Server austauschen oder Load Balancer hinzufügen können. Wenn Sie sich andere Gründe vorstellen können, die schlecht sind, lassen Sie es mich wissen, damit ich diese Praxis besser ändern kann.

In Zukunft möchte ich einige bessere Domainnamen in unserem internen DNS einrichten, die auf den entsprechenden Webserver und die entsprechende App verweisen. In meinem letzten Job folgten wir einer Konvention wie dieser:

  • Für die Produktion: http://someInternalApp.myCompany.com/
  • Zum Test: http://test.someInternalApp.myCompany.com/
  • Zur Entwicklung: http://dev.someInternalApp.myCompany.com/

Mir gefällt das besser , da der Anwendungsname ein wesentlicher Bestandteil des Domänennamens ist und die Bezeichnung der dev / test / prod-Umgebung einfach ist. Ich habe jedoch einige Vorbehalte:

  • Wenn Sie den App-Namen in die Subdomain einfügen, werden möglicherweise viele lange, eindeutige Subdomains erstellt. Ich mag es, unterschiedliche Domains für jede App zu haben, aber ich habe auch das Gefühl, dass die Verwaltung schwierig werden könnte.
  • Außer dem App-Namen gibt es nichts zu kennzeichnen, dass diese URL nur intern ist. Ich habe über andere Organisationen gelesen, die eine Subdomain wie "corp.myCompany.com" oder "int.myCompany.com" verwenden, was gut sein könnte. Ich möchte nicht, dass Benutzer den Eindruck bekommen, von zu Hause aus darauf zugreifen zu können.

Hier sind einige Optionen, auf die ich mich bei internen Domain-Namen neige:

App-Name in der internen Subdomain: (Sie werden etwas lang, aber ich denke, alles ist gut zusammen verpackt.)

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

App-Name als Unterverzeichnis: (kürzerer Domain-Name, impliziert jedoch, dass alle Apps Teil einer einheitlichen Site sind, was möglicherweise nicht der Fall ist, und trennt die Umgebungsbezeichnung von der App)

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

Also, lassen Sie uns diskutieren ... Was halten Sie von diesen Optionen? Gibt es etwas Besseres oder Häufigeres, das ich möglicherweise übersehen habe? Ich habe die Möglichkeit, mein Unternehmen in dieser Hinsicht auf einen besseren Weg zu bringen, daher würde ich gerne eine gute Konvention finden, die ich empfehlen kann.

Vielen Dank!


DNS-Tricks, URL-Umschreibung und virtuelles Hosting sind Ihre Freunde hier. Wird dies auf einem Microsoft-Stack oder Linux sein?
ewwhite

Microsoft ... .Net-Webanwendungen, die unter IIS unter Windows ausgeführt werden
Ben Brandt

Dinge zu benennen ist ein schwieriges Problem in der Informatik. Erwarten Sie, dass ein Schema (insbesondere bei automatisch inkrementierten Zahlen) irgendwann fehlschlägt. Weiterleitungen und DNS sind der Weg, um bestimmte Namen mehrdeutig zu machen.
Tedder42

Antworten:


7

Verlassen Sie sich niemals darauf, ob Ihre App intern oder extern ist. Entwickeln Sie sich immer so, als ob das Publikum der App außerhalb Ihrer Kontrolle liegt (weil es so ist).

Gehen Sie mit ENV.APPNAME.DOMAIN.TLD

Mit www. als Alias ​​für "Produktion".


Einfacher und solider Ansatz, ich mag es. Umso relevanter heutzutage mit Browsern wie Chrome, die Ihre Lesezeichen und Ihren Verlauf synchronisieren. Wenn ich eine interne Arbeitsplatz-App in Chrome mit einem Lesezeichen versehen kann, wird dieses Lesezeichen mit meinem Heim-PC und meinem Android-Gerät synchronisiert. Sobald das Lesezeichen dort ankommt, sollte es besser nicht auf etwas anderes im Internet verweisen.
Ben Brandt

3

Wenn Sie nur intern bereitstellen, haben Sie große Auswahlfreiheit. Da sich die Top-Level-Domains wie in letzter Zeit öffnen, sollten Sie jedoch darauf achten, dass keine Konflikte mit einem bevorstehenden neuen externen Namen auftreten.

Sie könnten beispielsweise als http://contact.app/ bereitstellen. Wenn jedoch die .app-TLD registriert wird, kann dies zu Konflikten führen.

Sie verwenden wahrscheinlich am besten etwas wie http: //contact.local/ oder http: //contact.lan/

Aus Gründen der Apple- und Bonjour-Dienstkompatibilität sollten Sie .local am besten vermeiden, also entscheiden Sie sich vielleicht für .lan

Alternativ würde nur http: //contact.ourcompany/ ziemlich gut funktionieren, wenn es sehr unwahrscheinlich ist, dass Ihr Firmenname jemals zu einer TLD wird.

Ich würde den App-Namen als Unterverzeichnis vermeiden, da er unnötig ist und ihn nur verlängert. Virtuelles Hosting ist der Weg dorthin mit einer eindeutigen URL pro App.

Und Sie vermeiden ganz richtig Servernamen, das ist definitiv ein Nein-Nein, weil Server kommen und gehen.

Bearbeiten 1 : Siehe RFC2606 und wählen Sie aus den verfügbaren TLDs für den internen Gebrauch aus, auf die dort verwiesen wird.

Nur als Hinweis zu den Kommentaren - .local und .lan, wie ich empfehle, können gemäß dem obigen RFC nicht registriert werden. Aus den gleichen Gründen können Sie auch .priv und .test verwenden.


5
Der einzige DNS-Namespace, über den Sie im Internet praktisch sicher sein können, sind Subdomains einer Domain der zweiten Ebene, die Sie besitzen. Jeder Idiot mit Geld kann heute eine TLD erstellen lassen, daher scheint es mir eine schlechte Idee zu sein, eine benutzerdefinierte TLD in einem Netzwerk zu verwenden. Ich würde mit Subdomains des Namens meines eigenen Unternehmens gehen und mit der Tatsache leben, dass die URLs länger sein werden.
Evan Anderson

@EvanAnderson Ich schlage einen KickStarter vor, um 185.000 USD für die Anmeldegebühr für die Registrierung der .localgTLD zu sammeln und eine permanente Lektion zur ordnungsgemäßen Konfiguration Ihrer Umgebungen zu erhalten.
Sammitch

Es wird nicht mehr empfohlen, eine TLD zu verwenden, die Sie nicht besitzen, oder DNS-Suchbereiche zu verwenden. Siehe Informationen zur ICANN-Namenskollision .
Michael Hampton

1

Diese Meinung basiert darauf, dass Sie, wenn Sie Ihre Anwendung nur intern bereitstellen, die volle Kontrolle haben und es dann wirklich egal ist, was Sie tun ...

Die meisten Benutzer werden Lesezeichen setzen, welche internen Webanwendungen sie ohnehin verwenden müssen. Ärgern Sie sich also nicht zu sehr über ihre URLs.

Als Systemadministrator würde ich mich über mehr Anwendungen freuen, die mir die Wahl geben, entweder in einem konfigurierbaren Unterverzeichnis oder im Stammverzeichnis einer Subdomain bereitzustellen, wobei ich die Wahl habe, Subdomains zu verwenden oder nicht.

Ein rücksichtsvollerer Entwickler muss nicht den "einfachen" Weg gehen und nur eine fest codierte (relative) Referenz " href=/images/bullet.png" auf einer zufälligen Seite einfügen und stattdessen eine Referenz aus einer Reihe von Bereitstellungs- / Konfigurationseinstellungen erstellen " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png"

Treffen Sie Ihre Bereitstellungsoptionen wie Hostnamen, Portnummern und Auswahlmöglichkeiten in den HTTP / HTTPS-Konfigurationseinstellungen und codieren Sie sie nicht fest.

Ich habe auf dem empfangenden Ende oft gewesen „Management will alle internen Anwendungen unter http://intranet/apps/da appname.intranetist soo verwirrend und das Gegenteil von unseren Lieferanten;. Wir brauchen appname.intranetfür unser Gerät / Anwendung , wie wir Prüfung gegen iframes-in gebaut haben, inlining Man-in-the -Mittelangriffe und Reverse Proxy ....

Ich habe festgestellt, dass viele kommerzielle Webanwendungen voraussichtlich im Stammverzeichnis des Webservers bereitgestellt werden und nicht zu zuverlässig funktionieren, wenn sie in einem zufälligen Unterverzeichnis bereitgestellt werden. Das heißt, sie enthalten beispielsweise mehr oder weniger fest codierte Pfade zu /css/main.cssUnterverzeichnissen, was es schwierig macht, mehrere Anwendungen auf demselben Host zu hosten. Aber diese Menge scheint auch nicht übermäßig besorgt über die Portabilität ihres Codes zu sein.


Die Installation mehrerer Apps, für die alle eine Root-Installation erforderlich ist, auf demselben Server wird trivial über virtuelles Hosting mit einem separaten DNS-Namen für jede App gelöst.
Ian Macintosh

Für den Laien (meinen damaligen Manager und CTO), der immer noch mehrere Server (wenn auch keine tatsächlichen Boxen) in dem Sinne erstellt, dass sie nicht als Intranet / Apps / Inventar und Intranet / Apps / Abrechnung angezeigt werden.
HBruijn
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.