Installare e configurare un sito o servizio web su server remoto

Installare e configurare un sito o servizio web su server remoto

Questa guida illustra le procedure comuni da eseguire per installare, configurare e verificare il funzionamento di un sito o servizio web su un server remoto di qualsiasi tipo: VPS, Server dedicato, web farm, cloud pubblico, cloud privato et. al.: non intende essere esaustiva e non copre ovviamente tutte le possibili configurazioni, ma può essere un riferimento utile per i SysAdmin alle prime armi sia per installare un nuovo servizio che per verificare il corretto funzionamento di siti o servizi esistenti.

Prerequisiti

La presente guida dà per scontato che siate già in possesso di:

  • un dominio web completo di pannello di gestione DNS, acquistato presso un Domain Name Registrar come Aruba, GoDaddy etc.
  • un server remoto fisico o virtuale opportunamente configurato e dotato di una installazione di IIS, Apache o altro Web Server analogo.
  • un sito o servizio web di qualsiasi tipo (HTML, PHP, ASP.NET, Phyton, Java etc.) ovvero un setup package di un framework come WordPress, Joomla, MediaWiki, PhpBB etc. pronto per l’installazione.

Hostname e IP

La prima cosa da fare è configurare l’ hostname e l’indirizzo IP associati al sito o servizio. Per far questo occorre:

  • Stabilire o identificare un IP pubblico da associare al sito/servizio (ad es. 5.189.148.122): nella maggior parte dei casi si tratta dell’IP (o di uno degli IP) che vi è stato fornito insieme al server fisico o virtuale che avete acquistato.
  • Stabilire gli hostname da associare al suddetto IP, ovvero l’indirizzo o gli indirizzi web ai quali il sito/servizio dovrà rispondere: nella maggior parte dei casi si tratta del dominio che avete acquistato presso il DNR (es. ryadel.com e www.ryadel.com) o un suo terzo livello (es. guide.ryadel.com).
  • Impostare il   relativo al’associazione IP/hostname stabilita o identificata sul pannello di gestione DNS del dominio relativo all’hostname scelto: tale pannello è messo a disposizione dal gestore del dominio (nel caso di Aruba, http://admin.aruba.it ).

Effettuare un test locale modificando il file hosts

Se volete, prima di configurare i record A sui DNS pubblici potete effettuare un test locale sulla vostra macchina creando delle eccezioni al DNS. Se utilizzate un sistema Windows il modo più semplice per farlo è modificare il file   che serve esattamente a tale scopo.

Il file   può essere aperto con un normale editor di testo e presenta una documentazione estremamente chiara su come aggiungere le regole di eccezione: ad esempio, se volete associare l’IP  5.189.148.122 all’hostname www.ryadel.com, dovrete aggiungere la seguente riga:

E’ importante ricordare che le regole presenti nel file degli host hanno la priorità sul DNS impostato per la macchina locale, quindi verranno utilizzate al posto di qualsiasi impostazione presente sui DNS pubblici ovvero effettuate con il pannello DNS del provider. Per questo motivo è opportuno rimuovere le eccezioni create al termine del test, onde evitare che questi routing forzati possano influenzare negativamente la configurazione della nostra rete in futuro.

Verifica

Potete controllare la corretta configurazione dell’associazione tra hostname e IP effettuando un semplice   utilizzando il prompt dei comandi, verificando che venga risolto sull’IP giusto. Una volta fatto questo potete passare al punto successivo.

Firewall e Routing

Nel caso in cui abbiate a disposizione un singolo server, l’unica cosa che dovete fare è aprire il Firewall alle connessioni in ingresso sulle porte 80 (per il servizio HTTP) e/o 443 (per connessioni in modalità HTTPS). Se utilizzate il firewall integrato di Windows è probabile che la procedura di installazione di IIS o Apache abbia già provveduto ad impostare le regole necessarie, come mostrato nella schermata seguente:

iis-firewall-rules

In caso contrario, dovrete farlo voi. Fate click sul collegamento New Rule… in alto a destra, quindi specificate che volete creare una regola di ingresso legata a una o più porte: nella schermata successiva inserite le porte 80 e/o 443 a seconda delle vostre esigenze:

iis-firewall-rules-manual

Nel caso in cui il server risieda su una Server Farm – fisica o virtuale che sia – è probabile che, per ragioni di sicurezza, tutti gli IP pubblici puntino a una singola macchina Firewall con OS dedicato (Kerio Connect, FreeBSD/PFSense o altro) la quale si occupa poi di instradare/reindirizzare il traffico proveniente da IP/porte specifiche su una classe di IP secondari, su rete interna e inaccessibile all’esterno, tra i quali vi è quello del nostro server web. Si tratta di una implementazione piuttosto comune, che in alcuni casi prevede anche altri servizi intermediari tra il Firewall e il web server – proxy, reverse proxy, load balancers et. al.: in questo articolo non ci addentreremo nelle configurazioni di routing dei servizi suddetti, anche perché sarebbe impossibile enumerarle tutte. Ci limiteremo a riassumere che, in tutti i casi, è necessario impostare sia il Firewall che eventuali servizi a cascata in modo che le connessioni alle porte 80 (http) e 443 (http) provenienti dall’IP pubblico determinato nel punto precedente vengano instradate lungo la catena di servizi utilizzati fino a raggiungere l’IP privato della macchina che ospita il servizio web. Se non sapete come fare, rivolgetevi al vostro amministratore di sistema: se l’amministratore di sistema siete voi, dovete scegliere se documentarvi meglio sui servizi che avete installato oppure eliminare qualche passaggio, semplificando sia la rete della vostra farm che la vostra vita da sistemisti in erba.

Verifica

Potete controllare che il Firewall (e l’eventuale routing interno) sia impostato correttamente collegandovi con un qualsiasi browser all’hostname relativo al sito o servizio web che state installando: in caso affermativo dovreste poter visualizzare la pagina di esempio del servizio web attivo (IIS, Apache o altro).

iis-tomcat-welcome

IIS e Web Server

Effettuata con successo la connessione, non resta che configurare il Server Web che riceverà le request relative al sito. I passaggi obbligati da effettuare sono generalmente i seguenti:

Pubblicare il sito web sul server

Nella maggior parte dei casi pubblicare un sito significa, banalmente, copiare i file di pubblicazione del sito nell’apposita cartella del server dedicata alla pubblicazione web:    ,    ,  o altra a seconda del servizio web e della configurazione adottati. L’operazione può avvenire tramite upload FTP, connessione RDP con supporto trasferimento file, VPN, strumenti previsti dal framework di sviluppo come il Web Site Publishing Tool di Visual Studio, et. al. Ovviamente, a seconda del sito/servizio installato e del servizio web utilizzato, occorrerà anche spendere qualche minuto per configurare correttamente i file  ,   e/o    del caso: tabella codici, stringhe di connessione al database, path assoluti e relativi e tutto quello che serve per far sì che il sito funzioni correttamente.

Configurazione del Web Service

A titolo esemplificativo descriveremo i passaggi fondamentali per configurare il sito su IIS 8: la stessa tipologia di operazioni, con le differenze del caso, può essere effettuata su Apache o su un qualsiasi altro servizio di pubblicazione web.

Creazione di un nuovo Sito Web

Aprite il tool di configurazione IIS dal Pannello di Controllo > Strumenti di Amministrazione e create un nuovo Sito Web.

iis-add-website

Una volta lì, aprite il pannello Basic Settings… e configurate la directory principale – ovvero quella dove sono stati copiati i file di produzione del sito nello step precedente – e l’Application Pool da utilizzare.

iis-basic-settings

Binding

Aprite il pannello Bindings… e configurate gli hostname e/o gli IP ai quali dovrà rispondere il vostro sito: nella maggior parte dei casi è consigliabile impostare soltanto gli hostname, così da non vincolare la configurazione del sito a un determinato indirizzo IP: questo perché gli IP cambiano nel corso del tempo, mentre gli hostname tendono a restare sempre gli stessi.

iis-bindings-configuration

Questo è un esempio di binding che renderà il nostro sito in grado di rispondere a richieste effettuate agli hostname ryadel.com e www.ryadel.com a prescindere dall’indirizzo IP:

Binding su HTTPS/SSL

Per fare in modo che il sito risponda anche a connessioni HTTPS occorre per prima cosa dotarsi di un certificato HTTPS (acquistabile presso qualsiasi rivenditore di certificati: uno dei più economici è GoDaddy ma ne esistono numerosi altrettanto validi): il certificato di per sé è piuttosto economico (30-60 euro), ma va rinnovato con cadenza annuale. Una volta acquistato e scaricato il certificato dovremo:

  • installarlo tramite lo strumento di gestione IIS utilizzando l’icona Server Certificates presente nel ramo principale dell’albero, relativo all’istanza IIS presente sul computer.
  • aggiungere una entry al pannello dei binding del sito web nel seguente modo:

iis-server-certificates

Nel caso dei binding HTTPS è necessario specificare anche due opzioni aggiuntive:

  • L’opzione Require Server Name Indication (solo su IIS 8 e superiori), che va abilitata per poter gestire più certificati SSL su uno stesso indirizzo IP. Per avere maggiori informazioni sulla funzionalità SNI è possibile leggere un interessante approfondimento sul sito ufficiale di IIS.
  • Il certificato da utilizzare (selezionare quello installato in precedenza tramite il pannello Server Certificates).

Verifica

Per controllare che il sito sia stato correttamente installato è necessario collegarsi con un qualsiasi browser a tutti gli hostname configurati nei binding relativi al sito o servizio web che si sta installando e verificare:

  • la corretta visualizzazione delle pagine accessibili a tutti gli utenti, con particolare riguardo a pagine che presentano contenuti provenienti da Database, web-service esterni etc. così da controllare anche l’avvenuta connessione ai provider di contenuti collegati.

Nel caso in cui il sito preveda l’autenticazione da parte degli utenti è inoltre consigliabile controllare anche:

  • il corretto login, logout ed eventuale creazione di sessione (osservando i cookie) di un utente registrato.
  • il corretto upload/download/eliminazione di file da parte di un utente registrato.

Per il momento è tutto: felice configurazione!

About Ryan

IT Project Manager, Web Interface Architect e Lead Developer di numerosi siti e servizi web ad alto traffico in Italia e in Europa. Dal 2010 si occupa anche della progettazione di App e giochi per dispositivi Android, iOS e Mobile Phone per conto di numerose società italiane. Microsoft MVP for Development Technologies dal 2018.

View all posts by Ryan

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.