Соглашения о внутренних URL-адресах предприятия

разработчик здесь ... Я хотел бы, чтобы ваш взгляд на это ...

Я создаю новое внутреннее веб-приложение для своей компании и начинаю думать о том, как оно будет развернуто. Многие из существующих веб-приложений здесь связаны напрямую с использованием имен своих серверов, например:

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 будет зарегистрирован, вы можете столкнуться с конфликтом.

Таким образом, вы, вероятно, лучше всего использовать что-то вроде http: //contact.local/ или http: //contact.lan/

По причинам Apple и их совместимости с сервисом Bonjour лучше избегать .local, поэтому, возможно, используйте .lan

В качестве альтернативы просто http: //contact.ourcompany/ будет работать очень хорошо, если название вашей компании вряд ли когда-либо станет ДВУ.

Я бы не использовал имя приложения в качестве подкаталога, потому что оно не нужно и просто делает его длиннее. Виртуальный хостинг - это способ использовать уникальный URL для каждого приложения.

И вы совершенно правильно избегаете имен серверов, это определенно нет-нет, потому что серверы приходят и уходят.

Изменить 1 : См. RFC2606 и выберите из доступного TLD внутреннего использования, на который есть ссылка.

Так же, как примечание к комментариям - .local и .lan, как я рекомендую, не регистрируются согласно вышеуказанному RFC. Вы можете использовать .priv и .test по тем же причинам.

Это мнение основано на мнении, потому что, когда вы разворачиваете приложение только внутренне, у вас есть полный контроль, и это не имеет значения, что вы делаете ...

Большинство пользователей в любом случае будут отмечать, какие внутренние веб-приложения им нужно использовать, поэтому не стоит слишком беспокоиться об их URL.

Как системный администратор я бы хотел больше приложений, которые дают мне возможность развертывания в настраиваемом подкаталоге или в корневом каталоге на поддомене, что позволяет выбирать использование поддоменов или нет.

Требуется более внимательный разработчик, чтобы не идти «легким» путем и просто включить жестко (относительную) ссылку « href=/images/bullet.png» на случайную страницу, а не создавать ссылку из ряда параметров развертывания / конфигурации href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png».

Пожалуйста, сделайте свой выбор развертывания, такой как любые имена хоста, номера портов, выбор в настройках конфигурации HTTP / HTTPS и не задавайте их жестко.

Я часто был на стороне получателя: «Руководство хочет, чтобы все внутренние приложения находились под угрозой, http://intranet/apps/потому что appname.intranetэто слишком запутанно. И наоборот, от наших поставщиков; нам нужно appname.intranetнаше устройство / приложение, так как мы встроили проверку на iframes, вставляя man-in-the-in». - средние атаки и обратное проксирование ....

Я обнаружил, что многие коммерческие веб-приложения ожидают развертывания в корневом каталоге веб-сервера и не работают слишком надежно при развертывании в некотором случайном подкаталоге. Т.е. они включают, например, более или менее жестко закодированные пути к /css/main.cssподкаталогам, что затрудняет размещение нескольких приложений на одном хосте. Но многие из них не слишком обеспокоены переносимостью своего кода.