Show Menu
ARGOMENTI×

Dispatcher nel cloud

Configurazione e test Apache e Dispatcher

In questa sezione viene descritto come strutturare AEM come configurazioni di Apache e Dispatcher del servizio Cloud, nonché come convalidarlo ed eseguirlo localmente prima di distribuirlo negli ambienti Cloud. Inoltre, descrive il debug negli ambienti Cloud. Per ulteriori informazioni sul dispatcher, consultate la documentazione di AEM Dispatcher.
Gli utenti Windows dovranno utilizzare Windows 10 Professional o altre distribuzioni che supportano Docker. Questo è un prerequisito per l'esecuzione e il debug del dispatcher su un computer locale. Le sezioni seguenti includono comandi che utilizzano le versioni Mac o Linux dell'SDK, ma l'SDK di Windows può essere utilizzato in modo simile.
Utenti Windows: la versione corrente di AEM come strumento di dispatcher locale del servizio cloud (v2.0.20) non è compatibile con Windows. Contattate il supporto home.html Adobe per ricevere gli aggiornamenti sulla compatibilità con Windows.

Strumenti Dispatcher

Gli strumenti Dispatcher fanno parte di AEM nel suo complesso come SDK per servizi cloud e forniscono:
  • una struttura di file di vaniglia contenente i file di configurazione da includere in un progetto di speditore di lievito;
  • Collaborazione per consentire ai clienti di convalidare localmente una configurazione dispatcher;
  • Un'immagine Docker che riproduce localmente il dispatcher.

Download ed estrazione degli strumenti

Gli strumenti Dispatcher possono essere scaricati da un file zip sul portale Software Distribution . L'accesso agli elenchi dell'SDK è limitato a quelli con AEM Managed Services o AEM come ambienti di servizio cloud. Qualsiasi nuova configurazione disponibile nella nuova versione del dispatcher Tools può essere utilizzata per distribuire agli ambienti Cloud in cui è in esecuzione tale versione di AEM nel Cloud o in una versione successiva.
Per macOS e Linux , scaricate lo script shell in una cartella del computer, rendetelo eseguibile ed eseguitelo. Estrarre automaticamente i file Dispatcher Tools sotto la directory in cui version è memorizzato (dove si trova la versione del dispatcher Tools).
$ chmod +x DispatcherSDKv<version>.sh
$ ./DispatcherSDKv<version>.sh
Verifying archive integrity...  100%   All good.
Uncompressing DispatcherSDKv<version>  100% 

Per Windows , scaricate l’archivio ZIP ed estraetelo.

Struttura file

La struttura della sottocartella dispatcher del progetto è descritta di seguito e deve essere copiata nella cartella del dispatcher del progetto maven:
./
├── conf.d
│   ├── available_vhosts
│   │   └── default.vhost
│   ├── dispatcher_vhost.conf
│   ├── enabled_vhosts
│   │   ├── README
│   │   └── default.vhost -> ../available_vhosts/default.vhost
│   └── rewrites
│   │   ├── default_rewrite.rules
│   │   └── rewrite.rules
│   └── variables
|       ├── custom.vars
│       └── global.vars
└── conf.dispatcher.d
    ├── available_farms
    │   └── default.farm
    ├── cache
    │   ├── default_invalidate.any
    │   ├── default_rules.any
    │   └── rules.any
    ├── clientheaders
    │   ├── clientheaders.any
    │   └── default_clientheaders.any
    ├── dispatcher.any
    ├── enabled_farms
    │   ├── README
    │   └── default.farm -> ../available_farms/default.farm
    ├── filters
    │   ├── default_filters.any
    │   └── filters.any
    ├── renders
    │   └── default_renders.any
    └── virtualhosts
        ├── default_virtualhosts.any
        └── virtualhosts.any

Di seguito è riportata una spiegazione dei file importanti che possono essere modificati:
File personalizzabili
I file seguenti sono personalizzabili e verranno trasferiti nell'istanza di Cloud al momento della distribuzione:
  • conf.d/available_vhosts/<CUSTOMER_CHOICE>.vhost
Potete avere uno o più di questi file. Contiene <VirtualHost> voci che corrispondono ai nomi host e consentono ad Apache di gestire ogni traffico di dominio con regole diverse. I file vengono creati nella available_vhosts directory e attivati con un collegamento simbolico nella enabled_vhosts directory. Da questi .vhost file, verranno inclusi altri file come le riscritture e le variabili.
  • conf.d/rewrites/rewrite.rules
Questo file è incluso dall'interno .vhost dei file. Ha una serie di regole di riscrittura per mod_rewrite .
Al momento, è necessario utilizzare un singolo file di riscrittura anziché file specifici del sito. La dimensione del file deve essere inferiore a 1 MB.
  • conf.d/variables/custom.vars
Questo file è incluso dall'interno .vhost dei file. In questa posizione potete inserire le definizioni per le variabili Apache.
  • conf.d/variables/global.vars
Questo file è incluso dall'interno del dispatcher_vhost.conf file. È possibile modificare il livello del dispatcher e riscrivere di nuovo il livello di registro in questo file.
  • conf.dispatcher.d/available_farms/<CUSTOMER_CHOICE>.farm
È possibile avere uno o più di questi file, che contengono farm che corrispondono ai nomi host e consentono al modulo dispatcher di gestire ogni farm con regole diverse. I file vengono creati nella available_farms directory e attivati con un collegamento simbolico nella enabled_farms directory. Da questi .farm file saranno inclusi altri file come filtri, regole della cache e altri.
  • conf.dispatcher.d/cache/rules.any
Questo file è incluso dall'interno .farm dei file. Specifica le preferenze di memorizzazione nella cache.
  • conf.dispatcher.d/clientheaders/clientheaders.any
Questo file è incluso dall'interno .farm dei file. Specifica quali intestazioni di richiesta devono essere inoltrate al back-end.
  • conf.dispatcher.d/filters/filters.any
Questo file è incluso dall'interno .farm dei file. Ha una serie di regole che modificano il traffico da filtrare e non arrivare al backend.
  • conf.dispatcher.d/virtualhosts/virtualhosts.any
Questo file è incluso dall'interno .farm dei file. Contiene un elenco di nomi host o di percorsi URI che devono essere associati dalla corrispondenza di tipo GSM. Questo determina il backend da utilizzare per distribuire una richiesta.
I file di cui sopra fanno riferimento ai file di configurazione immutabili elencati di seguito. Le modifiche ai file immutabili non verranno elaborate dai dispatcher negli ambienti Cloud.
File di configurazione immutabili
Questi file fanno parte del framework di base e applicano gli standard e le best practice. I file sono considerati immutabili perché modificarli o eliminarli localmente non avranno alcun impatto sulla distribuzione, in quanto non verranno trasferiti nell’istanza di Cloud.
Si consiglia che i file di cui sopra facciano riferimento ai file immutabili elencati di seguito, seguiti da eventuali istruzioni o sostituzioni aggiuntive. Quando la configurazione del dispatcher viene distribuita in un ambiente cloud, verrà utilizzata la versione più recente dei file immutabili, indipendentemente dalla versione utilizzata nello sviluppo locale.
  • conf.d/available_vhosts/default.vhost
Contiene un esempio di host virtuale. Per il vostro host virtuale, create una copia di questo file, personalizzatelo, passate a conf.d/enabled_vhosts e create un collegamento simbolico alla vostra copia personalizzata.
  • conf.d/dispatcher_vhost.conf
Parte del framework di base, utilizzata per illustrare il modo in cui gli host virtuali e le variabili globali sono inclusi.
  • conf.d/rewrites/default_rewrite.rules
Regole di riscrittura predefinite adatte a un progetto standard. Se avete bisogno di personalizzazione, modificate rewrite.rules . Nella personalizzazione, potete comunque includere prima le regole predefinite, se sono adatte alle vostre esigenze.
  • conf.dispatcher.d/available_farms/default.farm
Contiene una farm di dispatcher di esempio. Per la vostra farm, create una copia di questo file, personalizzatelo, passate a conf.d/enabled_farms e create un collegamento simbolico alla vostra copia personalizzata.
  • conf.dispatcher.d/cache/default_invalidate.any
Parte del framework di base, viene generato all'avvio. È necessario includere questo file in ogni farm definita, nella cache/allowedClients sezione.
  • conf.dispatcher.d/cache/default_rules.any
Regole predefinite per la cache adatte a un progetto standard. Se avete bisogno di personalizzazione, modificate conf.dispatcher.d/cache/rules.any . Nella personalizzazione, potete comunque includere prima le regole predefinite, se sono adatte alle vostre esigenze.
  • conf.dispatcher.d/clientheaders/default_clientheaders.any
Intestazioni di richiesta predefinite da inoltrare al back-end, adatte a un progetto standard. Se avete bisogno di personalizzazione, modificate clientheaders.any . Nella personalizzazione, potete comunque includere per primo le intestazioni di richiesta predefinite, a seconda delle vostre esigenze.
  • conf.dispatcher.d/dispatcher.any
Parte del framework di base, utilizzata per illustrare il modo in cui vengono incluse le farm dispatcher.
  • conf.dispatcher.d/filters/default_filters.any
Filtri predefiniti adatti per un progetto standard. Se avete bisogno di personalizzazione, modificate filters.any . Nella personalizzazione, potete comunque includere prima i filtri predefiniti, a seconda delle vostre esigenze.
  • conf.dispatcher.d/renders/default_renders.any
Parte del framework di base, questo file viene generato all'avvio. È necessario includere questo file in ogni farm definita, nella renders sezione.
  • conf.dispatcher.d/virtualhosts/default_virtualhosts.any
Globo host predefinito adatto a un progetto standard. Se avete bisogno di personalizzazione, modificate virtualhosts.any . Nella personalizzazione, non devi includere il globbing host predefinito, in quanto corrisponde a ogni richiesta in entrata.
AEM come archetipo di cloud service genererà la stessa struttura di file di configurazione del dispatcher.
Le sezioni seguenti descrivono come convalidare la configurazione localmente in modo che possa superare il gate di qualità associato in Cloud Manager durante la distribuzione di una versione interna.

Convalida locale della configurazione del dispatcher

Lo strumento di convalida è disponibile nell’SDK bin/validator come binario Mac OS, Linux o Windows, per consentire ai clienti di eseguire la stessa convalida che Cloud Manager eseguirà durante la creazione e la distribuzione di una versione.
Viene richiamato come: validator full [-d folder] [-w whitelist] zip-file | src folder
Lo strumento convalida la configurazione Apache e dispatcher. Consente di analizzare tutti i file con il pattern conf.d/enabled_vhosts/*.vhost e di verificare che vengano utilizzate solo le direttive inserite nella lista bianca. Le direttive consentite nei file di configurazione Apache possono essere elencate eseguendo il comando whitelist del validatore:
$ validator whitelist
Cloud manager validator 2.0.4
 
Whitelisted directives:
  <Directory>
  ...
  

La tabella seguente mostra i moduli apache supportati:
Nome modulo
Pagina di riferimento
core
mod_access_compat
mod_alias
mod_allowmethods
mod_auth_basic
mod_authn_core
mod_authn_file
mod_authz_core
mod_authz_groupfile
mod_deflate
mod_dir
mod_env
mod_filter
mod_headers
mod_mime
mod_remoteip
mod_reqtimeout
mod_rewrite
mod_security
mod_setenvif
mod_substitute
mod_userdir
I clienti non possono aggiungere moduli arbitrari, ma in futuro potrebbero essere presi in considerazione moduli aggiuntivi per l'inclusione nel prodotto. I clienti possono trovare l'elenco delle direttive disponibili per una determinata versione del dispatcher eseguendo la whitelist di convalida nell'SDK, come descritto nella documentazione di Dispatcher Tools.
La whitelist contiene un elenco di direttive Apache consentite in una configurazione cliente. Se una direttiva non viene inserita nella white list, lo strumento registra un errore e restituisce un codice di uscita diverso da zero. Se sulla riga di comando non viene visualizzata alcuna whitelist (che rappresenta il modo in cui dovrebbe essere richiamata), lo strumento utilizza una whitelist predefinita che Cloud Manager utilizzerà per la convalida prima di distribuirla negli ambienti Cloud.
Inoltre, analizza ulteriormente tutti i file con il pattern conf.dispatcher.d/enabled_farms/*.farm e verifica che:
  • Non esiste una regola del filtro che utilizza la funzione /glob (per ulteriori informazioni, consultate CVE-2016-0957 )
  • Nessuna funzione di amministrazione esposta. Ad esempio, l'accesso a percorsi come /crx/de or /system/console .
Se eseguito contro il tuo artefatto del cielo o la tua dispatcher/src sottodirectory, segnalerà gli errori di convalida:
$ validator full dispatcher/src
Cloud manager validator 1.0.4
2019/06/19 15:41:37 Apache configuration uses non-whitelisted directives:
 conf.d/enabled_vhosts/aem_publish.vhost:46: LogLevel
2019/06/19 15:41:37 Dispatcher configuration validation failed:
 conf.dispatcher.d/enabled_farms/999_ams_publish_farm.any: filter allows access to CRXDE

Lo strumento di convalida segnala solo l'uso vietato di direttive Apache che non sono state inserite nella lista bianca. Non segnala problemi sintattici o semantici con la configurazione Apache, in quanto tali informazioni sono disponibili solo per i moduli Apache in un ambiente in esecuzione.
Se non viene segnalato alcun errore di convalida, la configurazione è pronta per la distribuzione.
Di seguito sono illustrate le tecniche di risoluzione dei problemi per il debug di errori di convalida comuni generati dallo strumento:
impossibile individuare una conf.dispatcher.d sottocartella nell'archivio
L’archivio deve contenere le cartelle conf.d e conf.dispatcher.d . Nota: non utilizzare il prefisso etc/httpd nell’archivio.
impossibile trovare alcuna fattoria in conf.dispatcher.d/enabled_farms
Le farm abilitate devono trovarsi nella sottocartella indicata.
il file incluso (...) deve essere denominato: ...
Nella configurazione della farm sono presenti due sezioni che devono includere un file specifico: /renders e /allowedClients nella /cache sezione. Queste sezioni devono avere il seguente aspetto:
/renders {
    $include "../renders/default_renders.any"
}

e:
/allowedClients {
    $include "../cache/default_invalidate.any"
}

file incluso in posizione sconosciuta: ...
Nella configurazione della farm sono presenti quattro sezioni in cui è possibile includere il proprio file: /clientheaders , filters , /rules nella /cache sezione e /virtualhosts . I file inclusi devono essere denominati come segue:
Sezione
Includi nome file
/clientheaders
../clientheaders/clientheaders.any
/filters
../filters/filters.any
/rules
../cache/rules.any
/virtualhosts
../virtualhosts/virtualhosts.any
In alternativa, è possibile includere la versione predefinita di tali file, i cui nomi sono preceduti dalla parola default_ , ad esempio ../filters/default_filters.any .
include l'istruzione in (...), al di fuori di qualsiasi posizione nota: ...
A parte le sei sezioni menzionate nei paragrafi precedenti, non è consentito utilizzare l' $include istruzione, ad esempio:
/invalidate {
    $include "../cache/invalidate.any"
}

i client/i rendering consentiti non sono inclusi da: ...
Questo errore viene generato quando non si specifica un'inclusione per /renders e /allowedClients nella /cache sezione. Vedere il nome del file incluso (...): ... per ulteriori informazioni.
il filtro non deve usare il pattern GSM per consentire le richieste
Non è sicuro consentire le richieste con una regola di /glob stile, che viene confrontata con la riga di richiesta completa, ad esempio
/0100 {
    /type "allow" /glob "GET *.css *"
}

Questa istruzione consente le richieste di css file, ma consente anche le richieste a qualsiasi risorsa seguita dalla stringa di query ?a=.css . È pertanto vietato utilizzare tali filtri (cfr. anche CVE-2016-0957).
il file incluso (...) non corrisponde ad alcun file noto
Nella configurazione dell'host virtuale Apache sono disponibili due tipi di file che possono essere specificati come include: riscrittura e variabili. I file inclusi devono essere denominati come segue:
Tipo
Includi nome file
Riscrittura
conf.d/rewrites/rewrite.rules
Variabili
conf.d/variables/custom.vars
In alternativa, potete includere la versione predefinita delle regole di riscrittura, il cui nome è conf.d/rewrites/default_rewrite.rules . Si noti che non esiste una versione predefinita dei file delle variabili.
Rilevato layout di configurazione obsoleto, abilitazione della modalità di compatibilità
Questo messaggio indica che la configurazione ha il layout obsoleto della versione 1, contenente una configurazione completeApache e file con ams_ prefissi. Anche se questo è ancora supportato per la compatibilità con le versioni precedenti, è necessario passare al nuovo layout.

Verifica locale della configurazione Apache e Dispatcher

È inoltre possibile testare localmente la configurazione Apache e Dispatcher. Richiede che Docker sia installato localmente e che la configurazione superi la convalida come descritto in precedenza.
Utilizzando il parametro " -d ", il validatore genera una cartella con tutti i file di configurazione necessari al dispatcher.
Quindi, lo docker_run.sh script può puntare a tale cartella, avviando il contenitore con la configurazione.
$ validator full -d out src/dispatcher
2019/06/19 16:02:55 No issues found
$ docker_run.sh out docker.for.mac.localhost:4503 8080
Running script /docker_entrypoint.d/10-create-docroots.sh
Running script /docker_entrypoint.d/20-wait-for-backend.sh
Waiting until aemhost is available
aemhost resolves to xx.xx.xx.xx
Running script /docker_entrypoint.d/30-allowed-clients.sh
Starting httpd server
...

Questo avvia il dispatcher in un contenitore con il relativo backend che punta a un'istanza AEM in esecuzione sul computer Mac OS locale alla porta 4503.

Debug della configurazione Apache e Dispatcher

La seguente strategia può essere utilizzata per aumentare l'output di registro per il modulo dispatcher e vedere il risultato della RewriteRule valutazione negli ambienti locali e cloud.
I livelli di registro per tali moduli sono definiti dalle variabili DISP_LOG_LEVEL e REWRITE_LOG_LEVEL . Possono essere impostati nel file conf.d/variables/global.vars . La sua parte relativa segue:
# Log level for the dispatcher
#
# Possible values are: Error, Warn, Info, Debug and Trace1
# Default value: Warn
#
# Define DISP_LOG_LEVEL Warn
 
# Log level for mod_rewrite
#
# Possible values are: Error, Warn, Info, Debug and Trace1 - Trace8
# Default value: Warn
#
# To debug your RewriteRules, it is recommended to raise your log
# level to Trace2.
#
# More information can be found at:
# https://httpd.apache.org/docs/current/mod/mod_rewrite.html#logging
#
# Define REWRITE_LOG_LEVEL Warn

Quando si esegue il dispatcher localmente, i file di registro vengono stampati anche direttamente nell'output del terminale. Nella maggior parte dei casi, questi registri devono essere in DEBUG, che può essere realizzato trasmettendo il livello Debug come parametro durante l'esecuzione di Docker. Ad esempio:
DISP_LOG_LEVEL=Debug ./bin/docker_run.sh out docker.for.mac.localhost:4503 8080
I registri per gli ambienti cloud saranno esposti tramite il servizio di registrazione disponibile in Cloud Manager.

Diverse configurazioni del dispatcher per ambiente

Al momento, la stessa configurazione del dispatcher viene applicata a tutti AEM come ambienti di servizio cloud. Il runtime avrà una variabile di ambiente ENVIRONMENT_TYPE che contiene la modalità di esecuzione corrente (dev, stage o prod) e una definizione. La definizione può essere ENVIRONMENT_DEV , ENVIRONMENT_STAGE o ENVIRONMENT_PROD . Nella configurazione Apache, la variabile può essere utilizzata direttamente in un'espressione. In alternativa, è possibile utilizzare la definizione per creare logica:
# Simple usage of the environment variable
ServerName ${ENVIRONMENT_TYPE}.company.com
 
# When more logic is required
<IfDefine ENVIRONMENT_STAGE>
  # These statements are for stage
  Define VIRTUALHOST stage.example.com
</IfDefine>
<IfDefine ENVIRONMENT_PROD>
  # These statements are for production
  Define VIRTUALHOST prod.example.com
</IfDefine>

Nella configurazione Dispatcher, è disponibile la stessa variabile di ambiente. Se è necessaria una maggiore logica, definite le variabili come illustrato nell’esempio precedente e utilizzatele nella sezione di configurazione del dispatcher:
/virtualhosts {
  { "${VIRTUALHOST}" }
}

Quando si esegue il test della configurazione localmente, è possibile simulare diversi tipi di ambiente trasferendo la variabile DISP_RUN_MODE allo docker_run.sh script direttamente:
$ DISP_RUN_MODE=stage docker_run.sh out docker.for.mac.localhost:4503 8080

La modalità di esecuzione predefinita quando non viene passato un valore per DISP_RUN_MODE è "dev". Per un elenco completo delle opzioni e delle variabili disponibili, eseguire lo script docker_run.sh senza argomenti.

Visualizzazione della configurazione del dispatcher in uso dal contenitore Docker

Con configurazioni specifiche per l'ambiente, può essere difficile determinare l'aspetto della configurazione effettiva del dispatcher. Dopo aver avviato il contenitore docker con docker_run.sh esso può essere scaricato come segue:
  • Determinare l'ID contenitore docker in uso:
$ docker ps
CONTAINER ID       IMAGE
d75fbd23b29        adobe/aem-ethos/dispatcher-publish:...

  • Esegui la riga di comando seguente con l'ID contenitore:
$ docker exec d75fbd23b29 httpd-test
# Dispatcher configuration: (/etc/httpd/conf.dispatcher.d/dispatcher.any)
/farms {
  /publishfarm {
    /clientheaders {
...

Differenze principali tra il dispatcher AMS e AEM come servizio cloud

Come descritto nella pagina di riferimento precedente, la configurazione Apache e Dispatcher in AEM come servizio cloud è abbastanza simile a quella di AMS. Le principali differenze sono:
  • In AEM come servizio cloud, alcune direttive Apache potrebbero non essere utilizzate (ad esempio Listen o LogLevel )
  • In AEM come servizio cloud, è possibile inserire solo alcuni elementi della configurazione del dispatcher, che includono file e la loro denominazione è importante. Ad esempio, le regole del filtro che si desidera riutilizzare tra host diversi devono essere inserite in un file denominato filters/filters.any . Per ulteriori informazioni, consultate la pagina di riferimento.
  • In AEM come servizio cloud è disponibile una funzione di convalida aggiuntiva per rifiutare le regole del filtro scritte con /glob per evitare problemi di sicurezza. Poiché deny * verranno utilizzati invece di allow * (che non possono essere utilizzati), i clienti trarranno vantaggio dall'esecuzione locale del Dispatcher e dall'esecuzione di tentativi ed errori, dall'analisi dei registri per sapere esattamente quali percorsi i filtri del Dispatcher bloccano per poter aggiungere tali percorsi.

Linee guida per la migrazione della configurazione del dispatcher da AMS ad AEM come servizio cloud

La struttura di configurazione del dispatcher presenta differenze tra i servizi gestiti e AEM come servizio cloud. Presentato di seguito, è una guida dettagliata su come migrare dalla configurazione di AMS Dispatcher versione 2 ad AEM come servizio cloud.

Come convertire un AMS in un AEM come configurazione del dispatcher di servizi cloud

La sezione seguente fornisce istruzioni dettagliate su come convertire una configurazione AMS. Presuppone di disporre di un archivio con una struttura simile a quella descritta nella configurazione del dispatcher di Cloud Manager

Estrarre l'archivio e rimuovere un eventuale prefisso

Estrarre l'archivio in una cartella e assicurarsi che le sottocartelle immediate inizino con conf , conf.d e conf.dispatcher.d conf.modules.d . In caso contrario, spostateli nella gerarchia.

Eliminare le sottocartelle e i file non utilizzati

Rimuovere sottocartelle conf e conf.modules.d , nonché i file corrispondenti conf.d/*.conf .

Eliminazione di tutti gli host virtuali non pubblicati

Rimuovete qualsiasi file host virtuale in conf.d/enabled_vhosts cui sia presente author , unhealthy , health o lc flush nel nome. È inoltre possibile rimuovere tutti i file host virtuali in conf.d/available_vhosts cui non è stato eseguito il collegamento.

Rimuovere o commentare sezioni di host virtuali che non fanno riferimento alla porta 80

Se i file host virtuali contengono ancora sezioni che fanno riferimento esclusivamente a porte diverse dalla porta 80, ad esempio
<VirtualHost *:443>
...
</VirtualHost>

rimuovete o commentateli. Le istruzioni in queste sezioni non verranno elaborate, ma se le si mantiene intorno, si potrebbe comunque finire per modificarle senza alcun effetto, il che crea confusione.

Verifica riscrittura

Enter directory conf.d/rewrites .
Rimuovete tutti i file denominati base_rewrite.rules e xforwarded_forcessl_rewrite.rules ricordate di rimuovere le istruzioni Include nei file host virtuali che vi fanno riferimento.
Se conf.d/rewrites ora contiene un singolo file, deve essere rinominato rewrite.rules e non dimenticare di adattare le Include istruzioni che fanno riferimento a tale file anche nei file host virtuali.
Se tuttavia la cartella contiene più file specifici dell'host virtuale, il relativo contenuto deve essere associato all' Include istruzione che li fa riferimento nei file host virtuali.

Verifica variabili

Enter directory conf.d/variables .
Rimuovete qualsiasi file denominato ams_default.vars e ricordate di rimuovere Include le istruzioni nei file virtualhost che vi fanno riferimento.
Se conf.d/variables ora contiene un singolo file, deve essere rinominato custom.vars e non dimenticare di adattare le Include istruzioni che fanno riferimento a tale file anche nei file host virtuali.
Se tuttavia la cartella contiene più file specifici dell'host virtuale, il relativo contenuto deve essere associato all' Include istruzione che li fa riferimento nei file host virtuali.

Rimuovi whitelist

Rimuovete la cartella conf.d/whitelists e rimuovete Include le istruzioni nei file host virtuali che fanno riferimento ad alcuni file nella sottocartella.

Sostituisce qualsiasi variabile non più disponibile

In tutti i file host virtuali:
Rinomina PUBLISH_DOCROOT in DOCROOT Rimuovi sezioni che fanno riferimento a variabili denominate DISP_ID , PUBLISH_FORCE_SSL oppure PUBLISH_WHITELIST_ENABLED

Controllare lo stato eseguendo la convalida

Eseguire il dispatcher validator nella directory, con il httpd sottocomando:
$ validator httpd .

Se si verificano errori relativi ai file di inclusione mancanti, verificate di aver rinominato correttamente tali file.
Se vengono visualizzate delle direttive Apache che non sono inserite nella white list, rimuoverle.

Eliminazione di tutte le farm non pubblicate

Rimuovete qualsiasi file della farm in conf.dispatcher.d/enabled_farms cui sia presente author , unhealthy , health o lc flush nel nome. È inoltre possibile rimuovere tutti i file della farm in conf.dispatcher.d/available_farms cui non è stato eseguito il collegamento.

Rinominare i file della farm

Tutte le farm in conf.d/enabled_farms devono essere rinominate in modo da corrispondere al pattern, *.farm pertanto, ad esempio, il file afarm chiamato customerX_farm.any deve essere rinominato customerX.farm .

Controlla cache

Enter directory conf.dispatcher.d/cache .
Rimuovete eventuali file con prefisso ams_ .
Se conf.dispatcher.d/cache è vuoto, copiate il file conf.dispatcher.d/cache/rules.any dalla configurazione del dispatcher standard in questa cartella. La configurazione del dispatcher standard si trova nella cartella src di questo SDK. Non dimenticare di adattare le $include istruzioni relative ai file delle ams_*_cache.any regole anche nei file della farm.
Se invece conf.dispatcher.d/cache ora contiene un singolo file con suffisso _cache.any , è necessario rinominarlo rules.any e non dimenticare di adattare le $include istruzioni relative a tale file anche nei file della farm.
Se tuttavia la cartella contiene più file specifici della farm con tale pattern, il relativo contenuto deve essere copiato nell' $include istruzione che li fa riferimento nei file della farm.
Rimuovete qualsiasi file con il suffisso _invalidate_allowed.any .
Copiate il file conf.dispatcher.d/cache/default_invalidate_any da AEM predefinito nella configurazione del dispatcher di Cloud a tale posizione.
In ciascun file della farm, rimuovete qualsiasi contenuto della cache/allowedClients sezione e sostituitelo con:
$include "../cache/default_invalidate.any"

Verifica intestazioni client

Enter directory conf.dispatcher.d/clientheaders .
Rimuovete eventuali file con prefisso ams_ .
Se conf.dispatcher.d/clientheaders ora contiene un singolo file con suffisso _clientheaders.any , è necessario rinominarlo clientheaders.any e non dimenticare di adattare le $include istruzioni relative a tale file anche nei file della farm.
Se tuttavia la cartella contiene più file specifici della farm con tale pattern, il relativo contenuto deve essere copiato nell' $include istruzione che li fa riferimento nei file della farm.
Copiate il file conf.dispatcher/clientheaders/default_clientheaders.any dall’applicazione predefinita AEM come configurazione del dispatcher del servizio cloud in tale posizione.
In ciascun file farm, sostituite le istruzioni include di tipo client che abbiano il seguente aspetto:
$include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_publish_clientheaders.any"
$include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_common_clientheaders.any"

con l'istruzione:
$include "../clientheaders/default_clientheaders.any"

Filtro controllo

Enter directory conf.dispatcher.d/filters .
Rimuovete eventuali file con prefisso ams_ .
Se conf.dispatcher.d/filters ora contiene un singolo file deve essere rinominato filters.any e non dimenticare di adattare le $include istruzioni che fanno riferimento a tale file anche nei file della farm.
Se tuttavia la cartella contiene più file specifici della farm con tale pattern, il relativo contenuto deve essere copiato nell' $include istruzione che li fa riferimento nei file della farm.
Copiate il file conf.dispatcher/filters/default_filters.any dall’applicazione predefinita AEM come configurazione del dispatcher del servizio cloud in tale posizione.
In ciascun file farm, sostituire eventuali istruzioni di filtro con le seguenti:
$include "/etc/httpd/conf.dispatcher.d/filters/ams_publish_filters.any"

con l'istruzione:
$include "../filters/default_filters.any"

Controllare i rendering

Enter directory conf.dispatcher.d/renders .
Rimuovete tutti i file presenti nella cartella.
Copiate il file conf.dispatcher.d/renders/default_renders.any dall’applicazione predefinita AEM come configurazione del dispatcher del servizio cloud in tale posizione.
In ciascun file della farm, rimuovete qualsiasi contenuto della renders sezione e sostituitelo con:
$include "../renders/default_renders.any"

Controllare i virtualhost

Rinominare la directory conf.dispatcher.d/vhosts in conf.dispatcher.d/virtualhosts e immetterla.
Rimuovete eventuali file con prefisso ams_ .
Se conf.dispatcher.d/virtualhosts ora contiene un singolo file deve essere rinominato virtualhosts.any e non dimenticare di adattare le $include istruzioni che fanno riferimento a tale file anche nei file della farm.
Se tuttavia la cartella contiene più file specifici della farm con tale pattern, il relativo contenuto deve essere copiato nell' $include istruzione che li fa riferimento nei file della farm.
Copiate il file conf.dispatcher/virtualhosts/default_virtualhosts.any dall’applicazione predefinita AEM come configurazione del dispatcher del servizio cloud in tale posizione.
In ciascun file farm, sostituire eventuali istruzioni di filtro con le seguenti:
$include "/etc/httpd/conf.dispatcher.d/vhosts/ams_publish_vhosts.any"

con l'istruzione:
$include "../virtualhosts/default_virtualhosts.any"

Controllare lo stato eseguendo la convalida

Eseguite AEM come strumento di convalida del dispatcher dei servizi cloud nella directory, con il dispatcher sottocomando:
$ validator dispatcher .

Se si verificano errori relativi ai file di inclusione mancanti, verificate di aver rinominato correttamente tali file.
Se vengono visualizzati errori relativi a una variabile non definita, rinominarla PUBLISH_DOCROOT in DOCROOT .
Per ogni altro errore, consultate la sezione Risoluzione dei problemi della documentazione sullo strumento di convalida.

Verificare la configurazione con una distribuzione locale (richiede l'installazione di Docker)

Utilizzando lo script docker_run.sh in AEM come strumenti di dispatcher dei servizi cloud, puoi verificare che la configurazione non contenga altri errori che potrebbero solo verificarsi come dislocazione:

Passaggio 1: Generazione di informazioni sulla distribuzione con il validatore

validator full -d out .

In questo modo viene convalidata la configurazione completa e vengono generate le informazioni sulla distribuzione in out

Passaggio 2: Avviare il dispatcher in un'immagine docker con tali informazioni di distribuzione

Con il server di pubblicazione AEM in esecuzione sul computer MacOS, in ascolto sulla porta 4503, potete avviare il dispatcher davanti al server come segue:
$ docker_run.sh out docker.for.mac.localhost:4503 8080

Verrà avviato il contenitore ed esporre Apache sulla porta locale 8080.

Utilizza la nuova configurazione dispatcher

Congratulazioni! Se la funzione di convalida non segnala più alcun problema e il contenitore docker viene avviato senza errori o avvisi, è possibile spostare la configurazione in una dispatcher/src sottodirectory del repository git.
I clienti che utilizzano la configurazione AMS Dispatcher versione 1 devono contattare l'assistenza clienti per effettuare la migrazione dalla versione 1 alla versione 2, in modo da seguire le istruzioni riportate sopra.