In IIS, è meglio ospitare più applicazioni come siti web indipendenti o come directory virtuali nel sito predefinito?

background

Recentemente ho sviluppato un'applicazione MVC per un client e vorrei ospitarlo, insieme ad alcune altre applicazioni sullo stesso server.

Sono più di uno sviluppatore che di un amministratore del server, ma il mio istinto è stato quello di creare un nuovo sito in IIS con il proprio legame di sotto-dominio.

  • IIS 7 - consente http per parte del sito, https per rest?
  • Quanto è limitato Windows Server per usi generali?
  • Block Bots con IIS 7.5 e 8.0
  • Spostare i file sul nuovo server, preservando le copie shadow
  • IIS ritorna casualmente INET_E_RESOURCE_NOT_FOUND
  • Vista shell cmd pensa che sia Windows Server 2008 DEBUG
  • Il client, tuttavia, desidera invece creare una directory virtuale nel sito predefinito che punta all'applicazione. Così, per esempio, avreste:

    COMPANY.COM/APP1 e COMPANY.COM/APP2

    Piuttosto che:

    APP1.COMPANY.COM e APP2.COMPANY.COM

    Questo funzionava; tuttavia, è in conflitto con gli URL relativi nel markup HTTP standard, un problema risolto rapidamente.

    Domanda

    È meglio ospitare più applicazioni web sullo stesso server come siti separati o come directory virtuali all'interno del sito predefinito? Ci sono delle insidie ​​con l'approccio della directory virtuale?

    Non sto valutando l'approccio della directory virtuale, è solo nuovo per me e voglio assicurare che non causerà problemi ora o in futuro.

    2 Solutions collect form web for “In IIS, è meglio ospitare più applicazioni come siti web indipendenti o come directory virtuali nel sito predefinito?”

    Ho sempre cercato di attenersi a siti individuali per applicazioni. Hai molto più controllo su tutto e se stai eseguendo ASP.NET non si esegue problemi di cascata web.config che sono facili da colpire. Inoltre, hai un controllo più granuloso sulle piscine applicative e potrai effettivamente guardare le performance di each singola applicazione. Questa è tutta la preferenza.

    Indipendentemente da ciò, probabilmente la risposta migliore è che si applicano le associazioni a livello di sito web e NON il livello di applicazione. Quindi, se each applicazione necessita di un proprio URL o di un SSL in contrasto con non SSL, è necessario guardare i singoli siti.

    Inoltre, come si menziona, è necessario programmare con il meccanismo di distribuzione in mente. Come qualsiasi uso di URL relativi interrompe un sacco di cose.

    Infine: perché non vogliono usare i sotto-domini? Fornisce bella separazione pulita RESTfulish delle risorse se mi chiedete.

    Direi che dipende … sono le applicazioni molto simili tra loro in quanto potresti essere comodo fare una singola modifica al livello più alto che sarebbe cascata fino a each directory virtuale che non avrebbe influenzato la funzionalità di un'applicazione singola? Se si dispone di un sito separato per each applicazione, è necessario gestire separatamente le impostazioni di ciascun sito (Certs, IP, porte, ecc.), Che potrebbero essere un mal di testa se ci sono molti, ma sono siti totalmente indipendenti. l'impostazione non influirebbe su un'altra applicazione. Il vero lavoro viene fatto dal process di lavoro / App Pool in modo che in entrambe le impostazioni è ansible condividere lo stesso pool di app per più applicazioni o avere uno separato per each applicazione.

    • Applicazioni su siti separati = controllo molto più granulare sull'applicazione e su come connettersi ad esso a un costo di maggiore manutenzione per each sito
    • Le applicazioni sullo stesso sito = sono più facili da gestire se sono tutte molto simili, ma si potrebbero eseguire problemi di configuration se le applicazioni dispongono di requisiti in conflitto
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.