엔터프라이즈 내부 URL 규칙

여기 개발자가 되겠습니다. 이것에 대한 IT 관점을 원합니다 ...

회사를위한 새로운 내부 웹 응용 프로그램을 구축하고 배포 방법에 대해 생각하기 시작했습니다. 여기에있는 많은 기존 웹 앱은 다음과 같이 서버 이름을 직접 사용하여 연결됩니다.

http://webserver123/someInternalApp/

이것은 여러 가지 이유로 불편합니다. 서버 이름이 변경되고 서버가 다운되며 사용자는 웹 응용 프로그램을 찾기 위해 서버 이름을 몰라도됩니다. 서버 이름을 사용하면 서버를 교체하거나로드 밸런서를 추가 할 수 없습니다. 다른 이유를 생각할 수 없다면이 연습을 변경하기위한 더 나은 사례를 만들 수 있도록 알려주십시오.

앞으로 내부 DNS에 더 나은 도메인 이름을 설정하여 적절한 웹 서버 및 앱을 가리키고 싶습니다. 마지막 작업에서 우리는 다음과 같은 규칙을 따랐습니다.

• 생산 용 : 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

그럼 논의 해 봅시다 ...이 옵션에 대해 어떻게 생각하십니까? 내가 놓친 더 좋거나 더 일반적인 것이 있습니까? 이와 관련하여 회사를 더 나은 길로 인도 할 수있는 기회가 있으므로 추천 할만한 컨벤션을 찾고 싶습니다.

감사!

앱이 내부 또는 외부인지 여부에 의존하지 마십시오. 앱의 독자가 제어 할 수없는 것처럼 항상 개발하십시오.

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도 같은 이유로 사용할 수 있습니다.

내부적으로 응용 프로그램을 배포 할 때 모든 권한을 가지며 실제로 수행하는 작업이 중요하지 않기 때문에 이러한 의견에 근거합니다.

대부분의 사용자는 어쨌든 사용해야하는 내부 웹 응용 프로그램에 책갈피를 지정하므로 URL에 대해 너무 걱정하지 마십시오.

sysadmin으로서 구성 가능한 하위 디렉토리 또는 하위 도메인의 루트에 배포하여 하위 도메인 사용 여부를 선택할 수있는 더 많은 응용 프로그램을 원합니다.

개발자가 "쉬운"경로를 따르지 않고 href=/images/bullet.png임의의 페이지에 하드 코딩 된 (상대) 참조 " "를 포함시키는 대신 여러 배포 / 구성 설정 " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png" 에서 참조를 작성하는 것이보다 신중해야합니다.

호스트 이름, 포트 번호, HTTP / HTTPS 구성 설정의 선택과 같은 배치를 선택하고 하드 코딩하지 마십시오.

나는 종종 수신 끝에왔다 "관리 아래에있는 모든 내부 애플리케이션 싶어 http://intranet/apps/하기 때문 appname.intranet. 김 혼란입니다 그리고 우리 업체의 반대를 우리가 필요로 appname.intranet우리가 내장되어 있습니다로 iframe을 상대로 체크 인라인, 우리의 장비 / 응용 프로그램에 대한 사람 - 더는 중간 공격 및 리버스 프록시 ....

많은 상용 웹 응용 프로그램이 웹 서버의 루트에 배포 될 것으로 예상하고 임의의 하위 디렉토리에 배포 할 때 너무 안정적으로 작동하지 않는다는 것을 알았습니다. 즉, /css/main.css하위 디렉토리 로의 하드 코딩 된 경로가 많거나 적어 같은 호스트에서 여러 응용 프로그램을 호스팅하기가 어렵습니다. 그러나 그 로트는 코드의 이식성에 대해 너무 걱정하지 않습니다.