Angular2+ and ASP.NET WebAPI on IIS

[katit]

Если кто делал - расскажите как вы это все сетапнули.

Имеется Angular апп - это понятно, статический сайт, захостить где угодно можно.
Также имеется WebAPI REST API который нужен ангуляру. Тоже понятно как это захостить под IIS

Но появляется такой зверь как CORS и я этого пережить не могу Ну т.е. настроить чтоб работало нет вопросов но то что эта хрень присутствует меня не устраивает. Дополнительные round-trips это ужос.
Поэтому и хочу хостить так чтобы под одним доменом все работало без всяких CORS. Но и хочется чтоб деплоймент был красивым а не смесь .NET/Angular файлов в одной папке.

Если кто такое сделал - поделитесь какие настройки IIS и т.д. использовались..

[KVA]

За CORS я ничего не могу сказать, но какая разница как оно там лежит на сервере не понятно. Дефолтный Angular + . Net проект деплоется вполне красиво одной кнопкой что из VS что например через Teamcity.

[VovaK98]

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

Был бы тут Стенкин, он бы вообще сказал, что iis это фу. Но богу богово, как говорится.

Я сам плотно сижу в AngularJS и .net, про CORS (в контексте AWS) в курсе, но у меня свои заморочки, в которых нет Angular 2+.

[katit]

Мне уже ответили на стеке, все можно сделать как надо, но пока не пробовал:

Code: Select all

You can host both Frontend and API under one domain in IIS but stored in different folders. Example :
•The root app (frontend), with physical path on C:\inetpub\front and URL rewrite according to Angular needs. One thing to add is REQUEST_URI does not match ^/api/ with your API hosted on the path /api
•A Virtual Path inside your first one, with a virtual path on /api and physical path on C:\inetpub\api.

Both would have their own web.config, even separate application pool.
More information about virtual directories : https://docs.microsoft.com/en-us/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis

[VovaK98]

Мне уже ответили на стеке, все можно сделать как надо, но пока не пробовал:
..

То что они тебе прислали - больше похоже на generic ответ, типа как сконфигурить web application under website. Это в принципе всегда можно было, уже с IIS7 (Windows server 2008?), если не раньше, с 2003го сервера.
Не вижу необходимости в отдельном app pool для web application. Ну, если нужно только сделать отдельный security context/user, тогда да.
Помнится, ещё site/root web.config takes precedence over app web.config.

[katit]

Мне уже ответили на стеке, все можно сделать как надо, но пока не пробовал:
..

То что они тебе прислали - больше похоже на generic ответ, типа как сконфигурить web application under website. Это в принципе всегда можно было, уже с IIS7 (Windows server 2008?), если не раньше, с 2003го сервера.
Не вижу необходимости в отдельном app pool для web application. Ну, если нужно только сделать отдельный security context/user, тогда да.
Помнится, ещё site/root web.config takes precedence over app web.config.

Нет, все верно. Я хотел XCOPY deployment, таким образом я его получу. Будет один сайт с virtual directory внутрях. Раздельные конфиги. Ну и pools впридачу, почему бы и нет. Хотя бы из интереса чтобы видеть какой сколько ресурсов берет.

[VovaK98]

Нет, все верно. Я хотел XCOPY deployment, таким образом я его получу. Будет один сайт с virtual directory внутрях. Раздельные конфиги. Ну и pools впридачу, почему бы и нет. Хотя бы из интереса чтобы видеть какой сколько ресурсов берет.

Всё логично.

Для примера у меня есть Helpdesk сайт. Для простоты назовем его helpdesk.com. Тогда:
helpdesk.com (типа root) - public доступ для кастомеров, c главным web.config,
helpdesk.com/api - тоже как бы public для кастомеров, но уже для мобилок и Outlook add-ins, где свой web.config, и по умолчанию тот же app pool,
helpdesk.com/internal - secure доступ для IT/employees - это уже secured web application, со своим authorization, лучше с другим app pool.

Плюсы:
- CORS если нужно делать - проблем нет, так как все видится как один сайт,
- SSL сертификат - один дешёвый - опять же, потому что всё один сайт.

Минусы:
- если вдруг misconfigured main web.config, то это affect все web applications,
- если надо bring down public site for maintenance, то всё внутри тоже лежит,
- если изменить root website security, то это опять affect все applications.

Если же делать с подсайтами типа: helpdesk.com, api.helpdesk.com, secure.helpdesk.com,
то CORS уже как бы не работает, ну и сертификат нужно подороже покупать. (Слава богу, IIS8 поддерживает multiple SSLs per server, и wildcard уже не нужно. )
В такой конфигурации главный плюс - deployment/maintenance одного сайта не затрагивает другие вообще.

[KVA]

Деплоймент одной кнопкой, ага..

А что ага то? Такое впечатление что вы утверждаете что такого не бывает. Также впечатление что у вас деплоймет ручками происходит. Набрали типа xcopy в командной строке и та-да.

Не можете пояснить?

[VovaK98]

А что ага то? Такое впечатление что вы утверждаете что такого не бывает. Также впечатление что у вас деплоймет ручками происходит. Набрали типа xcopy в командной строке и та-да.
Не можете пояснить?

Я к тому, что прежде чем эта кнопка заработает, надо чтобы сначала её для вас кто-нибудь настроил. И не факт, что её настроили правильно, что не осталось дырок в виде открытых портов на production серверах, неотключенной incoming NTLM, итп.

[katit]

Минусы:
- если вдруг misconfigured main web.config, то это affect все web applications,

Разве? А если virtual directory имеет свой web.config, он ведь не будет также подхватывать основной?

[katit]

Деплоймент одной кнопкой, ага..

А что ага то? Такое впечатление что вы утверждаете что такого не бывает. Также впечатление что у вас деплоймет ручками происходит. Набрали типа xcopy в командной строке и та-да.

Не можете пояснить?

Конкретно в моем случае XCOPY это не буквально комманда. Это просто значит что во время деплоймента мы руками пишем новые файлы в директорию. Занимает все 5 минут.

[SergP]

Минусы:
- если вдруг misconfigured main web.config, то это affect все web applications,

Разве? А если virtual directory имеет свой web.config, он ведь не будет также подхватывать основной?

Virtual directory web.config работает как добавка к основному web.config.

[katit]

Минусы:
- если вдруг misconfigured main web.config, то это affect все web applications,

Разве? А если virtual directory имеет свой web.config, он ведь не будет также подхватывать основной?

Virtual directory web.config работает как добавка к основному web.config.

Shit. Блин. Надо дальше думать значит.

[KVA]

Конкретно в моем случае XCOPY это не буквально комманда. Это просто значит что во время деплоймента мы руками пишем новые файлы в директорию. Занимает все 5 минут.

Девелоперы деплоят руками? Ох ...

[katit]

Конкретно в моем случае XCOPY это не буквально комманда. Это просто значит что во время деплоймента мы руками пишем новые файлы в директорию. Занимает все 5 минут.

Девелоперы деплоят руками? Ох ...

Нет конечно, у нас в компании из 10 человек есть DevOps департмент, один человек пушит в staging, второй в production. И все secured. Ох...