Convenzioni di interni di Enterprise Enterprise

sviluppatore qui … mi piacerebbe la tua prospettiva IT su questo …

Sto costruendo una nuova web app interna per la mia azienda e comincio a pensare a come verrà distribuito. Molte delle applicazioni web esistenti qui sono collegate – per utilizzare direttamente i nomi dei server, come questo:

http://webserver123/someInternalApp/ 

Questo mi fa scomodo per una serie di motivi. I nomi dei server cambiano, i server scendono e gli utenti non dovrebbero conoscere i nomi dei server per trovare la propria applicazione web. Utilizzando i nomi dei server ci impedisce di scambiare server o di aggiungere barriere di carico. Se riesci a pensare ad altre ragioni, questo è un male, lasciami sapere in modo da poter fare un caso migliore per cambiare questa pratica.

Andando avanti, vorrei avere alcuni nomi di dominio migliori impostati nel nostro DNS interno che punterà al server web appropriato & app. Nel mio ultimo lavoro, abbiamo seguito una convenzione qualcosa di simile:

  • Per la produzione: http://someInternalApp.myCompany.com/
  • Per test: http://test.someInternalApp.myCompany.com/
  • Per lo sviluppo: http://dev.someInternalApp.myCompany.com/

Mi piace questo meglio , poiché il nome dell'applicazione è una parte fondamentale del nome di dominio e la designazione dell'ambiente dev / test / prod è semplice. Tuttavia, ho alcune riserve:

  • Mettere il nome dell'applicazione nel sottodominio alla fine creerà un sacco di sottodomini lunghi e unici. Mi piace avere diversi domini per each applicazione, ma anche mi sento che potrebbe diventare difficile gestire.
  • Oltre al nome dell'applicazione, non c'è nulla per indicare che questo URL è solo interno. Ho letto altre organizzazioni che usano un sottodominio come "corp.myCompany.com" o "int.myCompany.com" che potrebbe essere buono. Non voglio che gli utenti possano avere l'impressione di poter accedere a questi da casa.

Ecco alcune opzioni su ciò che mi impegno verso i nomi di dominio interni:

Nome dell'applicazione nel sottodominio interno: (si ottiene un po 'lungo, ma tutto è confezionato insieme bene penso)

  • http://someInternalApp.corp.myCompany.com/
  • http://dev.someInternalApp.corp.myCompany.com/

Nome dell'applicazione come sottodirectory: (nome di dominio più breve, ma implica che tutte le apps fanno parte di un sito unificato, che potrebbe non essere e disconnette la designazione dell'ambiente dall'applicazione)

  • http://corp.myCompany.com/someInternalApp
  • http://dev.corp.myCompany.com/someInternalApp

Quindi, discutiamo … Cosa pensi di queste opzioni? C'è qualcosa di meglio o più comune che mi possa mancare? Ho la possibilità di mettere la mia azienda su un path migliore in questo senso, quindi vorrei trovare una buona convenzione da raccomandare.

Grazie!

  • Come redirect la directory alla sottodirectory mantenendo l'URL nella barra degli indirizzi
  • Come configurare IIS 7.5 per consentire caratteri speciali in Url per ASP.NET 3.5?
  • Come aggiungere la documentazione in formato wiki (MediaWiki)?
  • Il mio URL rimarrà segreto se non mi lego mai ad esso?
  • Modo più veloce per pingare l'URL di curl
  • Gli URL riscritti con lunghezza di parametro> 255 non funzionano
  • Mapping Nginx url
  • Come modificare l'URL sul mio webserver Amazon EC2
  • 3 Solutions collect form web for “Convenzioni di interni di Enterprise Enterprise”

    Non fare mai affidamento su se la tua applicazione sarà interna o esterna. Sviluppare sempre come se il pubblico dell'app è fuori dal tuo controllo (perché lo è).

    Vai con ENV.APPNAME.DOMAIN.TLD

    Con www. come alias per la "produzione".

    Se si utilizza solo interno, si ha grande libertà nella selezione. Tuttavia, con i Top Level Domains che si aprono come hanno recentemente fatto, si desidera fare attenzione a non essere in conflitto con un nuovo nome esterno imminente.

    ad esempio, si potrebbe distribuire come http://contact.app/ ma se il .app TLD viene registrato allora si potrebbe trovare in conflitto.

    Quindi è probabilmente meglio utilizzare qualcosa come http: //contact.local/ o http: //contact.lan/

    Per motivi di Apple e la loro compatibilità di servizio Bonjour, è meglio evitare .local quindi forse andare con .lan

    In alternativa, solo http: //contact.ourcompany/ functionrebbe abbastanza bene se il tuo nome della società è estremamente improbabile che diventi sempre un TLD.

    Eviterò il nome dell'applicazione come una sottodirectory perché non è necessaria e lo rende più a lungo. L'hosting virtuale è il modo per andare lì con un URL univoco per app.

    E tu sei abbastanza corretto nell'eliminare i nomi dei server, che è un no-no definito perché i server vengono e vanno.

    Modifica 1 : Vedi RFC2606 e scegli la tua scelta dal TLD di uso interno a cui fa riferimento.

    Proprio come una nota ai commenti – .local e .lan come suggerisco non sono registrabili come per la RFC di cui sopra. Potresti usare anche .priv e .test per le stesse ragioni.

    Questo parere di qualche parte basato perché quando si distribuisce solo l'applicazione internamente si ha il pieno controllo e che non import davvero quello che fai …

    La maggior parte degli utenti metterà a segnare quali applicazioni web interne hanno bisogno per utilizzare comunque, quindi non preoccupatevi troppo del loro URL.

    Come sysadmin mi piacerebbe più applicazioni che mi danno la possibilità di implementare in una sottodirectory configurabile o nella root su un sottodominio, consentendo la scelta di utilizzare i sottodomini o less.

    Ci vuole uno sviluppatore più href=/images/bullet.png a non andare il path "facile" e includere semplicemente un riferimento " href=/images/bullet.png " rigido (relativo) su una pagina random e invece di build un riferimento da un certo numero di implementazioni / configurazioni impostazioni " href={HTTP-PROTO}://{IMG-HOST}/{IMG-BASEDIR}/bullet.png "

    Effettuare le scelte di distribuzione come i nomi di host, i numbers di port, le scelte nelle impostazioni di configuration HTTP / HTTPS e non codificarle.

    Ho spesso trovato l'estremità ricevente "la gestione vuole tutte le applicazioni interne in http://intranet/apps/ perché appname.intranet è appname.intranet confuso. E l'opposto dai nostri fornitori, abbiamo bisogno di appname.intranet per il nostro appliance / applicazione come noi hanno il controllo integrato contro iframes, inlining gli attacchi uomo-in-the-middle e proxy di inversione ….

    Ho scoperto che molte applicazioni web commerciali attendono di essere distribuite nella radice del server web e non funzionano in modo affidabile quando vengono distribuite in una qualche sottodirectory random. Ad esempio, comprendono routes più o less rigidi per /css/main.css sottodirectory /css/main.css , rendendo difficile l'hosting di più applicazioni sullo stesso host. Ma quei lotti non sembrano troppo preoccupati per la portbilità del loro codice.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.