здесь разработчик ... Мне хотелось бы узнать ваше мнение в области ИТ по этому поводу ...
Я создаю новое внутреннее веб-приложение для своей компании и начинаю думать о том, как оно будет развернуто. Многие из существующих здесь веб-приложений связаны напрямую с использованием своих имен серверов, например:
http://webserver123/someInternalApp/
Это доставляет мне дискомфорт по разным причинам. Имена серверов меняются, серверы выходят из строя, и пользователям не нужно знать имена серверов, чтобы найти свое веб-приложение. Использование имен серверов не позволяет нам менять серверы или добавлять балансировщики нагрузки. Если вы можете придумать другие причины, по которым это плохо, дайте мне знать, чтобы я мог лучше убедить меня в изменении этой практики.
Забегая вперед, я бы хотел, чтобы в нашем внутреннем DNS были настроены несколько более совершенных доменных имен, которые будут указывать на соответствующий веб-сервер и приложение. В моей последней работе мы следовали примерно такому соглашению:
http://someInternalApp.myCompany.com/http://test.someInternalApp.myCompany.com/http://dev.someInternalApp.myCompany.com/Мне это нравится лучше, поскольку имя приложения является ключевой частью имени домена, а обозначение среды dev / test / prod простое. Однако у меня есть некоторые оговорки:
Вот несколько вариантов того, к чему я склоняюсь для внутренних доменных имен:
Имя приложения во внутреннем поддомене: (они становятся немного длинными, но, я думаю, все хорошо упаковано)
http://someInternalApp.corp.myCompany.com/http://dev.someInternalApp.corp.myCompany.com/Имя приложения в качестве подкаталога: (более короткое доменное имя, но это означает, что все приложения являются частью одного единого сайта, чего они могут не быть, и это отключает обозначение среды от приложения)
http://corp.myCompany.com/someInternalApphttp://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/ будет работать очень хорошо, если название вашей компании вряд ли когда-либо станет TLD.
Я бы не стал использовать имя приложения в качестве подкаталога, потому что оно не нужно и просто увеличивает его длину. Виртуальный хостинг - это способ попасть туда с уникальным 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 для нашего устройства / приложения, так как у нас есть встроенная проверка на наличие фреймов, встраивание атак типа «человек посередине» и обратное проксирование ....
Я обнаружил, что многие коммерческие веб-приложения ожидают развертывания в корне веб-сервера и не работают слишком надежно при развертывании в каком-то случайном подкаталоге. Т.е. они включают, например, более или менее жестко запрограммированные пути к /css/main.css подкаталоги, что затрудняет размещение нескольких приложений на одном хосте. Но и эти люди, похоже, не слишком беспокоятся о переносимости своего кода.