Hosting di ASP.NET Core in Linux con Apache

Di Shayne Boyer

Questa guida illustra come configurare Apache come server proxy inverso in CentOS 7 per reindirizzare il traffico HTTP a un'app Web ASP.NET Core in esecuzione nel Kestrel server. L'estensione mod_proxy e i moduli correlati creano il proxy inverso del server.

Prerequisiti

  • Server che esegue CentOS 7 con un account utente standard con privilegio sudo.
  • Installare il runtime .NET Core nel server.
    1. Visitare la pagina Scarica .NET Core.
    2. Selezionare la versione più recente di .NET Core non in anteprima.
    3. Scaricare il runtime non di anteprima più recente nella tabella in Esegui app - Runtime.
    4. Selezionare il collegamento Istruzioni di Gestione pacchetti Linux e seguire le istruzioni di CentOS.
  • Un'app ASP.NET Core esistente.

In qualsiasi momento in futuro dopo l'aggiornamento del framework condiviso, riavviare le app ASP.NET Core ospitate dal server.

Pubblicare e copiare l'app

Configurare l'app per una distribuzione dipendente dal framework.

Se l'app viene eseguita localmente nell'ambiente di sviluppo e non è configurata dal server per stabilire connessioni HTTPS sicure, adottare uno degli approcci seguenti:

  • Configurare l'app per la gestione di connessioni locali sicure. Per altre informazioni, vedere la sezione Configurazione HTTPS.

  • Configurare l'app per l'esecuzione nell'endpoint non sicuro:

    • Disattivare il middleware di reindirizzamento HTTPS nell'ambiente di sviluppo (Program.cs):

      if (!app.Environment.IsDevelopment())
      {
          app.UseHttpsRedirection();
      }
      

      Per altre informazioni, vedere Usare più ambienti in ASP.NET Core.

    • Rimuovere https://localhost:5001 (se presente) dalla applicationUrl proprietà nel Properties/launchSettings.json file.

Per altre informazioni sulla configurazione per ambiente, vedere Usare più ambienti in ASP.NET Core.

Eseguire dotnet publish dall'ambiente di sviluppo per creare un pacchetto di un'app in una directory ( ad esempio , bin/Release/{TARGET FRAMEWORK MONIKER}/publishdove il {TARGET FRAMEWORK MONIKER} segnaposto è il moniker framework di destinazione (TFM) che può essere eseguito nel server:

dotnet publish --configuration Release

È anche possibile pubblicare l'app come distribuzione completa se si preferisce non mantenere il runtime .NET Core nel server.

Copiare l'app ASP.NET Core sul server usando uno strumento integrato nel flusso di lavoro dell'organizzazione, ad esempio SCP o FTP. Le app Web si trovano in genere nella directory var, ad esempio, var/www/helloapp.

Nota

In uno scenario di distribuzione di produzione un flusso di lavoro di integrazione continua esegue le operazioni di pubblicazione dell'app e di copia degli asset nel server.

Configurazione di un server proxy

Un proxy inverso è una configurazione comune per la gestione delle app Web dinamiche. Il proxy inverso termina la richiesta HTTP e la inoltra all'app ASP.NET.

Un server proxy inoltra le richieste client a un altro server anziché soddisfare le richieste stesse. Un proxy inverso inoltra a una destinazione fissa, in genere per conto di client non autorizzati. In questa guida Apache è configurato come proxy inverso in esecuzione nello stesso server che Kestrel gestisce l'app ASP.NET Core.

Poiché le richieste vengono inoltrate dal proxy inverso, usare il middleware delle intestazioni inoltrate dal pacchetto Microsoft.AspNetCore.HttpOverrides. Il middleware aggiorna Request.Scheme usando l'intestazione X-Forwarded-Proto, in modo che gli URI di reindirizzamento e altri criteri di sicurezza funzionino correttamente.

Qualsiasi componente che dipende dallo schema, ad esempio l'autenticazione, la generazione di collegamenti, i reindirizzamenti e la georilevazione, deve essere inserito dopo aver richiamato il middleware delle intestazioni inoltrate.

Il middleware delle intestazioni inoltrate deve essere eseguito prima di altro middleware. Questo ordine garantisce che il middleware basato sulle intestazioni inoltrate possa usare i valori di intestazione per l'elaborazione. Per eseguire il middleware delle intestazioni inoltrate dopo il middleware di diagnostica e gestione degli errori, vedere Ordine del middleware delle intestazioni inoltrate.

Richiamare il UseForwardedHeaders metodo nella parte superiore di prima di Startup.Configure chiamare un altro middleware. Configurare il middleware per inoltrare le X-Forwarded-For intestazioni e X-Forwarded-Proto .

Aggiungere lo Microsoft.AspNetCore.HttpOverrides spazio dei nomi all'inizio del file:

using Microsoft.AspNetCore.HttpOverrides;

Nella pipeline di elaborazione dell'app:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Se non vengono specificate opzioni ForwardedHeadersOptions per il middleware, le intestazioni predefinite per l'inoltro sono None.

I proxy in esecuzione negli indirizzi di loopback (127.0.0.0/8, [::1]), incluso l'indirizzo localhost standard (127.0.0.1), sono considerati attendibili per impostazione predefinita. Se le richieste tra Internet e il server Web vengono gestite anche da altri proxy o reti attendibili all'interno dell'organizzazione, aggiungerli all'elenco di KnownProxies o KnownNetworks con ForwardedHeadersOptions. L'esempio seguente aggiunge un server proxy attendibile all'indirizzo IP 10.0.0.100 nel middleware delle intestazioni inoltrate KnownProxies in Startup.ConfigureServices:

Aggiungere lo System.Net spazio dei nomi all'inizio del file:

using System.Net;

Usare la registrazione del servizio seguente:

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Per altre informazioni, vedere Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico.

Installare Apache

Aggiornare i pacchetti CentOS alle versioni stabili più recenti:

sudo yum update -y

Installare il server Web Apache in CentOS con un singolo comando yum:

sudo yum -y install httpd mod_ssl

Esempio di output dopo l'esecuzione del comando:

Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm               | 2.7 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 
Verifying  : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 

Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.4

Complete!

Nota

In questo esempio, l'output rispecchia httpd.86_64 poiché la versione CentOS 7 è a 64 bit. Per verificare dove è installato Apache, eseguire whereis httpd da un prompt dei comandi.

Configurare Apache

I file di configurazione per Apache si trovano all'interno della directory /etc/httpd/conf.d/. In Apache in Ubuntu tutti i file di configurazione dell'host virtuale vengono archiviati in /etc/apache2/sites-available. Qualsiasi file con l'estensione .conf viene elaborato in ordine alfabetico, in aggiunta ai file di configurazione dei moduli in /etc/httpd/conf.modules.d/, che contiene tutti i file di configurazione necessari per caricare i moduli.

Creare un file di configurazione denominato helloapp.conf, per l'app:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}s
</VirtualHost>

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog ${APACHE_LOG_DIR}/helloapp-error.log
    CustomLog ${APACHE_LOG_DIR}/helloapp-access.log common
</VirtualHost>

Nota: le versioni di Apache precedenti alla versione 2.4.6 non richiedono che contengano :RequestHeader sets

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

Per altre informazioni, vedere %{VARNAME}s in Apache Module mod_headers.

Il blocco VirtualHost può comparire più volte, in uno o più file su un server. Nel file di configurazione precedente Apache accetta il traffico pubblico sulla porta 80. Il dominio www.example.com viene gestito e l'alias *.example.com viene risolto nello stesso sito. Per altre informazioni, vedere Supporto host virtuale basato su nomi. Le richieste vengono trasmesse tramite proxy alla radice sulla porta 5000 del server all'indirizzo 127.0.0.1. Per la comunicazione bidirezionale, sono necessari ProxyPass e ProxyPassReverse. Per modificare Kestrell'INDIRIZZO IP/porta, vedere Kestrel: Configurazione dell'endpoint.

Il blocco VirtualHost può comparire più volte, in uno o più file su un server. Nel file di configurazione precedente Apache accetta il traffico pubblico sulla porta 80. Il dominio www.example.com viene gestito e l'alias *.example.com viene risolto nello stesso sito. Per altre informazioni, vedere Supporto host virtuale basato su nomi. Le richieste vengono trasmesse tramite proxy alla radice sulla porta 5000 del server all'indirizzo 127.0.0.1. Per la comunicazione bidirezionale, sono necessari ProxyPass e ProxyPassReverse. Per modificare Kestrell'INDIRIZZO IP/porta, vedere Kestrel: Configurazione dell'endpoint.

Creare un collegamento simbolico alla directory per apache da leggere durante l'avvio /etc/apache2/sites-enabled :

sudo ln -s /etc/apache2/sites-available/helloapp.conf /etc/apache2/sites-enabled/

Avviso

Se non si specifica una direttiva ServerName corretta nel blocco VirtualHost, l'app può risultare esposta a vulnerabilità di sicurezza. L'associazione con caratteri jolly del sottodominio (ad esempio, *.example.com) non costituisce un rischio per la sicurezza se viene controllato l'intero dominio padre (a differenza di *.com, che è vulnerabile). Per altre informazioni, vedere RFC 9110: Semantica HTTP (sezione 7.2: host e :authority).

La registrazione può essere configurata per ogni VirtualHost usando le direttive ErrorLog e CustomLog. ErrorLog è la posizione in cui il server registra gli errori e CustomLog imposta il nome del file e il formato del file di log. In questo caso, si tratta della posizione in cui vengono registrate le informazioni sulla richiesta. È presente una riga per ogni richiesta.

Salvare il file e testare la configurazione. Se tutto ciò viene superato, la risposta deve essere Syntax [OK].

sudo apachectl configtest

Riavviare Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Per altre informazioni sui valori delle direttive di intestazione, vedere Apache Module mod_headers.

Monitorare l'app

Apache è ora configurato per inoltrare le richieste effettuate all'app http://localhost:80 ASP.NET Core in esecuzione in Kestrel .http://127.0.0.1:5000 Tuttavia, Apache non è configurato per gestire il Kestrel processo. Usare systemd e creare un file del servizio per avviare e monitorare l'app Web sottostante. systemd è un sistema di inizializzazione che offre molte funzionalità potenti per l'avvio, l'arresto e la gestione dei processi.

Creare il file del servizio

Creare il file di definizione del servizio:

sudo nano /etc/systemd/system/kestrel-helloapp.service

Un esempio di file del servizio per l'app:

[Unit]
Description=Example .NET Web API App running on CentOS 7

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

Nota: impostare la cartella per la local/bin distribuzione. Alcune versioni di Ubuntu richiedono ExecStart=/usr/bin/dotnet

Nell'esempio precedente l'utente che gestisce il servizio viene specificato dall'opzione User . L'utente (apache) deve esistere e avere la proprietà appropriata dei file dell'app.

Usare TimeoutStopSec per configurare il tempo di attesa prima che l'app si arresti dopo aver ricevuto il segnale di interrupt iniziale. Se l'app non si arresta in questo periodo, viene emesso il comando SIGKILL per terminare l'app. Specificare il valore in secondi senza unità di misura (ad esempio, 150), un valore per l'intervallo di tempo (ad esempio, 2min 30s) o infinity per disabilitare il timeout. Per impostazione predefinita, il valore di TimeoutStopSec viene impostato sul valore di DefaultTimeoutStopSec nel file di configurazione del sistema di gestione (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). Il timeout predefinito per la maggior parte delle distribuzioni è di 90 secondi.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Per alcuni valori (ad esempio, le stringhe di connessione SQL) è necessario usare caratteri di escape, in modo da consentire ai provider di configurazione di leggere le variabili di ambiente. Usare il comando seguente per generare un valore con caratteri di escape corretti per l'uso nel file di configurazione:

systemd-escape "<value-to-escape>"

I due punti (:) separatori non sono supportati nei nomi delle variabili di ambiente. Usare un doppio carattere di sottolineatura (__) al posto dei due punti. Il provider di configurazione delle variabili di ambiente converte le doppie sottolineature in due punti quando le variabili di ambiente vengono lette nella configurazione. Nell'esempio seguente la chiave della stringa di connessione ConnectionStrings:DefaultConnection è impostata nel file di definizione del servizio come ConnectionStrings__DefaultConnection:

I due punti (:) separatori non sono supportati nei nomi delle variabili di ambiente. Usare un doppio carattere di sottolineatura (__) al posto dei due punti. Il provider di configurazione delle variabili di ambiente converte le doppie sottolineature in due punti quando le variabili di ambiente vengono lette nella configurazione. Nell'esempio seguente la chiave della stringa di connessione ConnectionStrings:DefaultConnection è impostata nel file di definizione del servizio come ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

Salvare il file e abilitare il servizio:

sudo systemctl enable kestrel-helloapp.service

Avviare il servizio e verificare che sia in esecuzione:

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on CentOS 7
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll

Con il proxy inverso configurato e Kestrel gestito tramite systemd, l'app Web è completamente configurata e accessibile da un browser nel computer locale all'indirizzo http://localhost. Esaminando le intestazioni di risposta, l'intestazione Server indica che l'app ASP.NET Core viene gestita da Kestrel:

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

Visualizzare i log

Poiché l'app Web che usa Kestrel viene gestita tramite systemd, gli eventi e i processi vengono registrati in un journal centralizzato. Tuttavia, questo giornale include le voci per tutti i servizi e i processi gestiti da systemd. Per visualizzare le voci specifiche di kestrel-helloapp.service, usare il comando seguente:

sudo journalctl -fu kestrel-helloapp.service

Per il filtro di data e ora, specificare le opzioni di tempo con il comando. Ad esempio, usare --since today per filtrare in base al giorno corrente o --until 1 hour ago per visualizzare le voci dell'ora precedente. Per altre informazioni, vedere la pagina di manuale per journalctl.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Protezione dei dati

Lo stack di protezione dei dati core ASP.NET viene usato da diversi middleware di base ASP.NET, tra cui il middleware di autenticazione (ad esempio, cookie middleware) e le protezioni di richiesta intersito (CSRF). Anche se le DPAPI (Data Protection API) non vengono chiamate dal codice dell'utente, è consigliabile configurare la protezione dati per la creazione di un archivio di chiavi crittografiche permanente. Se non si configura la protezione dei dati, le chiavi vengono mantenute in memoria ed eliminate al riavvio dell'app.

Se il gruppo di chiavi viene archiviato in memoria quando l'app viene riavviata:

  • Tutti i token di autenticazione basati su cookie vengono invalidati.
  • Gli utenti devono ripetere l'accesso alla richiesta successiva.
  • Tutti i dati protetti con il gruppo di chiavi non possono più essere decrittografati. Possono essere inclusi i token CSRF e i cookie TempData di ASP.NET Core MVC.

Per configurare la protezione dei dati in modo da rendere persistente il gruppo di chiavi e crittografarlo, vedere:

Proteggere l'app

Configurare il firewall

Firewalld è un daemon dinamico per gestire il firewall con il supporto per le aree di rete. È comunque possibile usare iptables per gestire le porte e il filtro dei pacchetti. Firewalld dovrebbe essere installato per impostazione predefinita. È possibile usare yum per installare il pacchetto o verificare che sia installato.

sudo yum install firewalld -y

Usare firewalld per aprire solo le porte necessarie per l'app. In questo caso vengono usate le porte 80 e 443. I comandi seguenti impostano in modo permanente le porte 80 e 443 per l'apertura:

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent

Ricaricare le impostazioni del firewall. Verificare i servizi e le porte disponibili nell'area predefinita. Le opzioni sono disponibili controllando firewall-cmd -h.

sudo firewall-cmd --reload
sudo firewall-cmd --list-all
public (default, active)
interfaces: eth0
sources: 
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
forward-ports: 
icmp-blocks: 
rich rules: 

Configurazione HTTPS

Configurare l'app per connessioni locali sicure (HTTPS)

Il comando dotnet run usa il file dell'app Properties/launchSettings.json , che configura l'app per l'ascolto sugli URL forniti dalla applicationUrl proprietà , ad esempio https://localhost:5001;http://localhost:5000.

Configurare l'app per l'uso di un certificato nello sviluppo per il comando dotnet run o l'ambiente di sviluppo (F5 o CTRL+F5 in Visual Studio Code) usando uno degli approcci seguenti:

Configurare il proxy inverso per connessioni client sicure (HTTPS)

Avviso

La configurazione di sicurezza in questa sezione è una configurazione generale da usare come punto di partenza per un'ulteriore personalizzazione. Non è possibile fornire supporto per strumenti, server e sistemi operativi di terze parti. Usare la configurazione in questa sezione a proprio rischio. Per altre informazioni, accedere alle risorse seguenti:

Per configurare Apache per HTTPS, viene usato il modulo mod_ssl. Durante l'installazione del modulo httpd, è stato installato anche il modulo mod_ssl. Se non è stato installato, usare yum per aggiungerlo alla configurazione.

sudo yum install mod_ssl

Per imporre HTTPS, installare il modulo mod_rewrite per abilitare la riscrittura degli URL:

sudo yum install mod_rewrite

Modificare il file helloapp.conf per abilitare la comunicazione sicura sulla porta 443.

L'esempio seguente non configura il server per reindirizzare le richieste non sicure. È consigliabile usare il middleware di reindirizzamento HTTPS. Per altre informazioni, vedere Applicare HTTPS in ASP.NET Core.

Nota

Per gli ambienti di sviluppo in cui la configurazione del server gestisce il reindirizzamento sicuro anziché il middleware di reindirizzamento HTTPS, è consigliabile usare reindirizzamenti temporanei (302) anziché reindirizzamenti permanenti (301). La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo.

L'aggiunta di un'intestazione Strict-Transport-Security (HSTS) garantisce che tutte le richieste successive effettuate dal client siano tramite HTTPS. Per indicazioni sull'impostazione dell'intestazione Strict-Transport-Security , vedere Applicare HTTPS in ASP.NET Core.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:443>
    Protocols             h2 http/1.1
    ProxyPreserveHost     On
    ProxyPass             / http://127.0.0.1:5000/
    ProxyPassReverse      / http://127.0.0.1:5000/
    ErrorLog              /var/log/httpd/helloapp-error.log
    CustomLog             /var/log/httpd/helloapp-access.log common
    SSLEngine             on
    SSLProtocol           all -SSLv3 -TLSv1 -TLSv1.1
    SSLHonorCipherOrder   off
    SSLCompression        off
    SSLSessionTickets     on
    SSLUseStapling        off
    SSLCertificateFile    /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
    SSLCipherSuite        ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
</VirtualHost>

Nota

Questo esempio usa un certificato generato localmente. SSLCertificateFile deve essere il file del certificato primario per il nome di dominio. SSLCertificateKeyFile deve essere il file di chiave generato quando viene creato il CSR. SSLCertificateChainFile deve essere il file di certificato intermedio (se presente) che è stato fornito dall'autorità di certificazione.

Apache HTTP Server versione 2.4.43 o successiva è necessario per gestire un server Web TLS 1.3 con OpenSSL 1.1.1.

Nota

L'esempio precedente disabilita l'associazione OCSP (Online Certificate Status Protocol). Per altre informazioni e indicazioni sull'abilitazione di OCSP, vedere OCSP Stapling (documentazione di Apache).

Salvare il file e testare la configurazione:

sudo service httpd configtest

Riavviare Apache:

sudo systemctl restart httpd

Altri suggerimenti di Apache

Riavviare le app con gli aggiornamenti del framework condiviso

Dopo aver aggiornato il framework condiviso nel server, riavviare le app core ASP.NET ospitate dal server.

Intestazioni aggiuntive

Per proteggersi da attacchi dannosi, è necessario modificare o aggiungere alcune intestazioni. Verificare che il modulo mod_headers sia installato:

sudo yum install mod_headers

Proteggere Apache dagli attacchi di clickjacking

Il clickjacking, anche noto come attacco UI Redress, è un attacco dannoso in cui un visitatore di un sito Web viene indotto a fare clic su un collegamento o un pulsante in una pagina diversa da quella che sta attualmente visualizzando. Usare X-FRAME-OPTIONS per proteggere il sito.

Per contrastare gli attacchi di clickjacking:

  1. Modificare il file httpd.conf:

    sudo nano /etc/httpd/conf/httpd.conf
    

    Aggiungere la riga Header append X-FRAME-OPTIONS "SAMEORIGIN".

  2. Salvare il file.

  3. Riavviare Apache.

Analisi del tipo MIME

L'intestazione X-Content-Type-Options impedisce a Internet Explorer di eseguire l'analisi del tipo MIME, ovvero di determinare il Content-Type di un file dal contenuto del file. Se il server imposta l'intestazione Content-Type su text/html con l'opzione nosniff impostata, Internet Explorer esegue il rendering del contenuto come text/html, indipendentemente dal contenuto del file.

Modificare il file httpd.conf:

sudo nano /etc/httpd/conf/httpd.conf

Aggiungere la riga Header set X-Content-Type-Options "nosniff". Salvare il file. Riavviare Apache.

Bilanciamento del carico

Questo esempio illustra come configurare e configurare Apache in CentOS 7 e Kestrel nello stesso computer di istanza. Non avere un singolo punto di guasto; l'uso di mod_proxy_balancer e la modifica di VirtualHost consentono di gestire più istanze delle app Web dietro il server proxy Apache.

sudo yum install mod_proxy_balancer

Nel file di configurazione illustrato di seguito, viene configurata un'istanza aggiuntiva di helloapp da eseguire sulla porta 5001. La sezione Proxy è impostata con una configurazione del servizio di bilanciamento del carico, con due membri per il bilanciamento del carico di byrequests.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ProxyPass / balancer://mycluster/ 

    ProxyPassReverse / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5001/

    <Proxy balancer://mycluster>
        BalancerMember http://127.0.0.1:5000
        BalancerMember http://127.0.0.1:5001 
        ProxySet lbmethod=byrequests
    </Proxy>

    <Location />
        SetHandler balancer
    </Location>
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

Limiti di velocità

Usando mod_ratelimit, incluso nel modulo httpd, è possibile limitare la larghezza di banda del client:

sudo nano /etc/httpd/conf.d/ratelimit.conf

Il file di esempio limita la larghezza di banda a 600 KB al secondo nel percorso radice:

<IfModule mod_ratelimit.c>
    <Location />
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 600
    </Location>
</IfModule>

Campi di intestazione della richiesta di grandi dimensioni

Le impostazioni predefinite del server proxy limitano in genere i campi di intestazione della richiesta a 8.190 byte. Un'app può richiedere campi più lunghi del valore predefinito,ad esempio le app che usano l'ID Microsoft Entra. Se sono necessari campi più lunghi, la direttiva LimitRequestFieldSize del server proxy richiede una rettifica. Il valore da applicare dipende dallo scenario. Per altre informazioni, vedere la documentazione del server.

Avviso

Aumentare il valore predefinito di LimitRequestFieldSize solo se necessario. Se si aumenta il valore, si aumenta il rischio di sovraccarico del buffer (overflow) e di attacchi Denial of Service (DoS) da parte di utenti malintenzionati.

Risorse aggiuntive