エンタープライズ内部URL規則

ここに開発者...私はこれについてあなたのITの視点をお願いします...

私は社内向けの新しい内部Webアプリを構築しており、それをどのように展開するかについて考え始めています。ここにある既存のWebアプリの多くは、次のようにサーバー名を直接使用してリンクされています。

http://webserver123/someInternalApp/

これは、さまざまな理由で私を不快にさせます。サーバー名が変更され、サーバーがダウンし、ユーザーがWebアプリケーションを見つけるためにサーバー名を知っている必要はありません。サーバー名を使用すると、サーバーの入れ替えやロードバランサーの追加ができなくなります。これが悪い他の理由を考えられる場合は、私に知らせてください。そうすれば、この慣行を変更するためのより良い事例を作ることができます。

今後は、適切なウェブサーバーとアプリを指すように、内部DNSにいくつかのより良いドメイン名を設定したいと思います。私の最後の仕事では、次のような慣例に従いました。

• 生産用： http://someInternalApp.myCompany.com/
• テスト用： http://test.someInternalApp.myCompany.com/
• 開発用： http://dev.someInternalApp.myCompany.com/

Iこのような優れたアプリケーション名は、ドメイン名の重要な一部であり、開発/テスト/ prod環境の指定が簡単であるとして、。ただし、いくつかの予約があります。

• アプリ名をサブドメインに入れると、最終的には多くの長くユニークなサブドメインが作成されます。アプリごとに異なるドメインを設定するのが好きですが、管理が難しくなることもあると思います。
• アプリ名以外に、このURLが内部専用であることを指定するものはありません。「corp.myCompany.com」や「int.myCompany.com」のようなサブドメインを使用している他の組織について読んだことがあります。ユーザーが自宅からこれらにアクセスできるという印象を受けたくない。

以下は、内部ドメイン名を利用する方法のいくつかのオプションです。

内部サブドメインのアプリ名：（少し長くなりますが、すべてがうまくパッケージ化されていると思います）

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

サブディレクトリとしてのアプリ名：（短いドメイン名ですが、すべてのアプリが1つの統合サイトの一部であることを意味しますが、そうではない可能性があり、環境指定をアプリから切断します）

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

それでは、議論しましょう...これらのオプションについてどう思いますか？私が見逃したかもしれないより良いまたはより一般的なものはありますか？私はこの点に関して私の会社をより良い方向に導く機会があるので、私は推薦する良い大会を見つけたいと思います。

ありがとう！

アプリが内部か外部かに依存することはありません。アプリの対象者があなたのコントロールの外にいるように常に開発します（そうであるため）。

ENV.APPNAME.DOMAIN.TLDを使用する

www付き。「プロダクション」のエイリアスとして。

内部のみを展開する場合は、選択に大きな自由があります。ただし、トップレベルドメインが最近のように開いているため、次の新しい外部名と競合しないように注意する必要があります。

たとえば、http： //contact.app/ としてデプロイできますが、.app TLDが登録されると、競合する可能性があります。

したがって、おそらくhttp：//contact.local/またはhttp：//contact.lan/のようなものを使用するのが最善です。

AppleとそのBonjourサービスの互換性の理由から、.localは避けるのが最善です。

または、会社名がTLDになる可能性が非常に低い場合は、http：//contact.ourcompany/でも十分機能します。

アプリ名は不要であり、長くなるため、サブディレクトリとしてのアプリ名は避けます。仮想ホスティングは、アプリごとに一意のURLを使用する方法です。

そして、あなたはサーバー名を回避するのは全く正しいです、それはサーバーが行き来するので確かにノーノーです。

編集1：RFC2606を参照し、そこで参照されている利用可能な内部使用TLDから選択してください。

コメントへのメモとして-私が推奨する.localと.lanは、上記のRFCに従って登録できません。同じ理由で、.privと.testも使用できます。

このsomehwatの見解は、アプリケーションを内部的にデプロイするだけで完全に制御できるため、実際に何をしても問題ないためです...

ほとんどのユーザーは、とにかく使用する必要のある内部Webアプリケーションをブックマークするので、URLについてあまり気にしないでください。

私はシステム管理者として、構成可能なサブディレクトリまたはサブドメインのルートのいずれかにデプロイするかを選択できる、より多くのアプリケーションが好きです。サブドメインを使用するかどうかを選択できます。

「思いやりのある」ルートをたどらhref=/images/bullet.pngず、ランダムなページにハードコードされた（相対）参照を含めるだけでなく、多数のデプロイメント/構成設定から参照を構築するのではなく、より慎重な開発者が必要ですhref={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png。

ホスト名、ポート番号、HTTP / HTTPS構成設定での選択など、デプロイメントの選択を行い、ハードコーディングしないでください。

私はよく受け取り側にいます。「管理はすべての内部アプリを必要としています。http://intranet/apps/これappname.intranetは混乱を招くためです。ベンダーとは逆です。appname.intranetアプライアンス/アプリケーションには、iframeに対する組み込みチェックがあり、man-in-the -ミドルアタックとリバースプロキシ...

多くの商用WebアプリケーションがWebサーバーのルートに展開されることを期待しており、ランダムなサブディレクトリに展開された場合、信頼性があまり高くないことがわかりました。つまり、たとえば、/css/main.cssサブディレクトリへのハードコーディングされたパスが多かれ少なかれ含まれているため、同じホスト上で複数のアプリケーションをホストすることが困難になっています。しかし、それらの多くは、コードの移植性について過度に心配しているようにも見えません。