Convalida e debug con gli strumenti di Dispatcher

Introduzione

Le sezioni seguenti descrivono la struttura del file in modalità flessibile, la convalida locale, il debug e la migrazione dalla modalità precedente alla modalità flessibile.

Questo articolo presuppone che la configurazione del dispatcher del progetto includa il file opt-in/USE_SOURCES_DIRECTLY, che consente all’SDK e al runtime di convalidare e distribuire la configurazione in modo migliore rispetto alla modalità precedente, rimuovendo le limitazioni relative al numero e alle dimensioni dei file.

Di conseguenza, se la configurazione del dispatcher non include il file di cui sopra, altamente consigliato la migrazione dalla modalità legacy alla modalità flessibile, come descritto nella Migrazione dalla modalità legacy alla modalità flessibile sezione.

Struttura del file

La struttura della sottocartella di Dispatcher del progetto è la seguente:

./
├── conf.d
│   ├── available_vhosts
│   │   ├── my_site.vhost # Created by customer
│   │   └── default.vhost
│   ├── dispatcher_vhost.conf
│   ├── enabled_vhosts
│   │   ├── README
│   │   └── my_site.vhost -> ../available_vhosts/my_site.vhost  # Created by customer
│   └── rewrites
│   │   ├── default_rewrite.rules
│   │   └── rewrite.rules
│   └── variables
|       ├── custom.vars
│       └── global.vars
│── opt-in
│   └── USE_SOURCES_DIRECTLY
└── conf.dispatcher.d
    ├── available_farms
    │   ├── my_farm.farm # Created by customer
    │   └── default.farm
    ├── cache
    │   ├── default_invalidate.any
    │   ├── default_rules.any
    │   ├── marketing_query_parameters.any
    │   └── rules.any
    ├── clientheaders
    │   ├── clientheaders.any
    │   └── default_clientheaders.any
    ├── dispatcher.any
    ├── enabled_farms
    │   ├── README
    │   └── my_farm.farm -> ../available_farms/my_farm.farm  # Created by customer
    ├── filters
    │   ├── default_filters.any
    │   └── filters.any
    ├── renders
    │   └── default_renders.any
    └── virtualhosts
    │   ├── default_virtualhosts.any
    │   └── virtualhosts.any

Di seguito è riportata una spiegazione dei file rilevanti che possono essere modificati:

File personalizzabili

I seguenti file sono personalizzabili e verranno trasferiti nell’istanza Cloud al momento dell’implementazione:

• conf.d/available_vhosts/<CUSTOMER_CHOICE>.vhost

Puoi avere uno o più di questi file. Contengono <VirtualHost> voci che corrispondono ai nomi host e consentono ad Apache di gestire ogni traffico di dominio con regole diverse. I file vengono creati in available_vhosts e abilitati con un collegamento simbolico nel enabled_vhosts directory. Dalla sezione .vhost saranno inclusi file, altri file come riscritture e variabili.

• conf.d/rewrites/rewrite.rules

Questo file è incluso dall'interno del tuo .vhost file. Ha una serie di regole di riscrittura per mod_rewrite.

• conf.d/variables/custom.vars

Questo file è incluso dall'interno del tuo .vhost file. Puoi aggiungere definizioni per le variabili Apache in questa posizione.

• conf.d/variables/global.vars

Questo file è incluso dall’interno di dispatcher_vhost.conf file. Puoi modificare il Dispatcher e riscrivere il livello di registro in questo file.

• conf.dispatcher.d/available_farms/<CUSTOMER_CHOICE>.farm

Puoi avere uno o più di questi file, che contengono farm con nomi host corrispondenti e consentono al modulo Dispatcher di gestire ogni farm con regole diverse. I file vengono creati in available_farms e abilitati con un collegamento simbolico nel enabled_farms directory. Dalla sezione .farm saranno inclusi file, altri file come filtri, regole di cache e altri.

• conf.dispatcher.d/cache/rules.any

Questo file è incluso dall'interno del tuo .farm file. Specifica le preferenze di caching.

• conf.dispatcher.d/clientheaders/clientheaders.any

Questo file è incluso dall'interno del tuo .farm file. Specifica le intestazioni di richiesta da inoltrare al backend.

• conf.dispatcher.d/filters/filters.any

Questo file è incluso dall'interno del tuo .farm file. Ha una serie di regole che modificano il tipo di traffico da filtrare e non lo rendono al backend.

• conf.dispatcher.d/virtualhosts/virtualhosts.any

Questo file è incluso dall'interno del tuo .farm file. Dispone di un elenco di nomi host o percorsi URI a cui deve corrispondere la corrispondenza glob. Questo determina il backend da utilizzare per distribuire una richiesta.

• opt-in/USE_SOURCES_DIRECTLY

Questo file abilita una configurazione del dispatcher più flessibile e rimuove le limitazioni precedenti relative al numero e alle dimensioni dei file. Inoltre, l’SDK e il runtime possono convalidare e distribuire la configurazione in modo migliorato.

I file di cui sopra fanno riferimento ai file di configurazione immutabili elencati di seguito. Le modifiche ai file immutabili non verranno elaborate da Dispatcher in ambienti Cloud.

File di configurazione immutabili

Questi file fanno parte del framework di base e applicano standard e best practice. I file sono considerati immutabili perché la loro modifica o eliminazione locale non avrà alcun impatto sulla distribuzione, in quanto non verranno trasferiti nell’istanza 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 di 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 host virtuale di esempio. Per il tuo host virtuale, crea una copia di questo file, personalizzalo, vai a conf.d/enabled_vhosts e crea un collegamento simbolico alla copia personalizzata.
Non copiare il file default.vhost direttamente in conf.d/enabled_vhosts.

Verificare che sia sempre disponibile un host virtuale corrispondente a ServerAlias \*.local nonché localhost, necessari per i processi di Adobe interni.

• conf.d/dispatcher_vhost.conf

Parte del framework di base, utilizzato per illustrare come vengono inclusi gli host virtuali e le variabili globali.

• conf.d/rewrites/default_rewrite.rules

Regole di riscrittura predefinite adatte a un progetto standard. Se hai bisogno di personalizzazione, modifica rewrite.rules. Nella personalizzazione, puoi comunque includere prima le regole predefinite, se soddisfano le tue esigenze.

• conf.dispatcher.d/available_farms/default.farm

Contiene un esempio di farm di Dispatcher. Per la tua farm, crea una copia di questo file, personalizzalo, vai a conf.d/enabled_farms e crea un collegamento simbolico alla copia personalizzata.

• conf.dispatcher.d/cache/default_invalidate.any

Parte del framework di base, viene generato all'avvio. Sei obbligatorio per includere questo file in ogni farm definita, nel cache/allowedClients sezione.

• conf.dispatcher.d/cache/default_rules.any

Regole di cache predefinite adatte a un progetto standard. Se hai bisogno di personalizzazione, modifica conf.dispatcher.d/cache/rules.any. Nella personalizzazione, puoi comunque includere prima le regole predefinite, se soddisfano le tue esigenze.

• conf.dispatcher.d/clientheaders/default_clientheaders.any

Intestazioni di richiesta predefinite per l’inoltro al backend, adatte a un progetto standard. Se hai bisogno di personalizzazione, modifica clientheaders.any. Nella personalizzazione, puoi comunque includere prima le intestazioni di richiesta predefinite, se soddisfano le tue esigenze.

• conf.dispatcher.d/dispatcher.any

Parte del framework di base, utilizzato per illustrare come vengono incluse le farm di Dispatcher.

• conf.dispatcher.d/filters/default_filters.any

Filtri predefiniti adatti a un progetto standard. Se hai bisogno di personalizzazione, modifica filters.any. Nella personalizzazione, puoi comunque includere prima i filtri predefiniti, se soddisfano le tue esigenze.

• conf.dispatcher.d/renders/default_renders.any

Parte del framework di base, questo file viene generato all’avvio. Sei obbligatorio per includere questo file in ogni farm definita, nel renders sezione.

• conf.dispatcher.d/virtualhosts/default_virtualhosts.any

Globbing host predefinito adatto a un progetto standard. Se hai bisogno di personalizzazione, modifica virtualhosts.any. Nella personalizzazione, non devi includere il globbing host predefinito, in quanto corrisponde a ogni richiesta in ingresso.

Moduli Apache supportati

Consulta Moduli Apache supportati.

Convalida locale

Utilizza il validate.sh script come mostrato di seguito:

$ validate.sh src/dispatcher
opt-in USE_SOURCES_DIRECTLY marker file detected
Phase 1: Dispatcher validator
Cloud manager validator 2.0.32
Phase 1 finished
Phase 2: httpd -t validation in docker image
values.csv not found in deployment folder: /Users/foo/src - using files in 'conf.d' and 'conf.dispatcher.d' subfolders directly
processing configuration subfolder: conf.d
processing configuration subfolder: conf.dispatcher.d
Running script /docker_entrypoint.d/10-check-environment.sh
Running script /docker_entrypoint.d/20-create-docroots.sh
Running script /docker_entrypoint.d/30-wait-for-backend.sh
Waiting until localhost is available
localhost resolves to ::1
Running script /docker_entrypoint.d/40-generate-allowed-clients.sh
Running script /docker_entrypoint.d/50-check-expiration.sh
Running script /docker_entrypoint.d/60-check-loglevel.sh
Running script /docker_entrypoint.d/70-check-forwarded-host-secret.sh
# Dispatcher configuration: (/etc/httpd/conf.dispatcher.d/dispatcher.any)
/farms {

...

}
Syntax OK
Phase 2 finished
Phase 3: Immutability check
reading immutable file list from /etc/httpd/immutable.files.txt

...

no immutable file has been changed - check is SUCCESSFUL
Phase 3 finished

Lo script prevede le tre fasi seguenti:

1. Esegue la convalida. Se la configurazione non è valida, lo script non riesce.
2. Esegue il httpd -t comando per verificare se la sintassi è corretta in modo che apache httpd possa avviarsi. In caso di esito positivo, la configurazione deve essere pronta per la distribuzione.
3. Verifica che il sottoinsieme dei file di configurazione dell’SDK di Dispatcher, destinati a essere immutabili come descritto in Sezione struttura file, non è stato modificato.

Durante l’implementazione di Cloud Manager, il httpd -t Verrà eseguito anche il controllo della sintassi e tutti gli errori verranno inclusi in Cloud Manager Build Images step failure log.

Fase 1

Se una direttiva non viene inserita nell'elenco Consentiti, lo strumento registra un errore e restituisce un codice di uscita diverso da zero. Inoltre, esegue un'ulteriore scansione di tutti i file con pattern conf.dispatcher.d/enabled_farms/*.farm e verifica che:

• Non esiste alcuna regola di filtro che utilizza allow tramite /glob (vedere CVE-2016-0957 per ulteriori dettagli.
• Nessuna funzione di amministrazione è esposta. Ad esempio, l’accesso a percorsi quali /crx/de or /system/console.

Lo strumento di convalida segnala solo l’uso vietato delle direttive Apache che non sono state inserite nell'elenco Consentiti. Non segnala problemi sintattici o semantici relativi alla configurazione di Apache, in quanto queste informazioni sono disponibili solo per i moduli Apache in un ambiente in esecuzione.

Di seguito sono illustrate le tecniche di risoluzione dei problemi per il debug degli errori di convalida comuni generati dallo strumento:

impossibile individuare un 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 una farm inconf.dispatcher.d/enabled_farms

Le farm abilitate devono trovarsi nella sottocartella indicata.

il nome del file incluso (…) deve essere: …

Nella configurazione della farm sono disponibili due sezioni: deve includi un file specifico: /renders e /allowedClients nel /cache sezione. Tali sezioni devono essere visualizzate come segue:

/renders {
    $include "../renders/default_renders.any"
}

e:

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

file incluso in una posizione sconosciuta: …

Nella configurazione della farm sono disponibili quattro sezioni in cui è possibile includere il file: /clientheaders, filters, /rules in /cache sezione e /virtualhosts. I file inclusi devono essere denominati come segue:

In alternativa, è possibile includere predefinito versione di tali file, i cui nomi sono preceduti dalla parola default_ad esempio: ../filters/default_filters.any.

include istruzione in (…), al di fuori di qualsiasi posizione nota: …

Oltre alle sei sezioni menzionate nei paragrafi precedenti, non è consentito utilizzare $include L'istruzione seguente, ad esempio, genererebbe questo errore:

/invalidate {
    $include "../cache/invalidate.any"
}

i client/rendering consentiti non sono inclusi da: …

Questo errore viene generato quando non si specifica un'inclusione per /renders e /allowedClients nel /cache sezione. Consulta la
il nome del file incluso (…) deve essere: … per ulteriori informazioni.

il filtro non deve utilizzare il modello glob per consentire le richieste

Non è sicuro consentire richieste con un /glob regola di stile, corrispondente alla riga di richiesta completa, ad esempio

/0100 {
    /type "allow" /glob "GET *.css *"
}

Questa istruzione ha lo scopo di consentire le richieste di css ma consente anche di richiedere 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

Per impostazione predefinita, è possibile specificare due tipi di file nella configurazione dell’host virtuale Apache: riscritture e variabili.

In modalità flessibile, è possibile includere anche altri file, purché si trovino in sottodirectory (a qualsiasi livello) di conf.d directory con il prefisso seguente.

Ad esempio, puoi includere un file in una directory appena creata in conf.d/includes come segue:

Include conf.d/includes/mynewdirectory/myincludefile.conf

In alternativa, è possibile includere predefinito versione delle regole di riscrittura, il cui nome è conf.d/rewrites/default_rewrite.rules.
Nota: 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 versione 1 obsoleto, contenente una configurazione Apache completa e file con ams_ prefissi. Anche se questo è ancora supportato per la compatibilità con le versioni precedenti, è necessario passare al nuovo layout.

La prima fase può anche essere esegui separatamente, anziché dall'involucro validate.sh script.

Quando esegui su un artefatto Maven o dispatcher/src sottodirectory, segnalerà gli errori di convalida:

$ validator full -relaxed dispatcher/src
Cloud manager validator 1.0.4
2019/06/19 15:41:37 Apache configuration uses non-allowlisted 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

In Windows, la convalida del dispatcher distingue tra maiuscole e minuscole. Di conseguenza, potrebbe non essere possibile convalidare la configurazione se non si rispetta la combinazione di maiuscole e minuscole del percorso in cui si trova la configurazione, ad esempio:

bin\validator.exe -relaxed full src
Cloud manager validator 2.0.xx
2021/03/15 18:15:40 Dispatcher configuration validation failed:
  conf.dispatcher.d\available_farms\default.farm:15: parent directory outside server root: c:\k\a\aem-dispatcher-sdk-windows-symlinks-testing3\dispatcher\src

Evitare questo errore copiando e incollando il percorso da Esplora risorse e quindi al prompt dei comandi utilizzando un cd in tale percorso.

Fase 2

Questa fase controlla la sintassi Apache avviando Docker in un’immagine. Docker deve essere installato localmente, ma non è necessario che l’AEM sia in esecuzione.

Questa fase può anche essere eseguita in modo indipendente tramite bin/docker_run.sh src/dispatcher host.docker.internal:4503 8080.

Durante l’implementazione di Cloud Manager, il httpd -t Verrà inoltre eseguito il controllo della sintassi e tutti gli errori verranno inclusi nel registro degli errori del passaggio Immagini build di Cloud Manager.

Fase 3

Se si verifica un errore in questa fase, significa che Adobe ha modificato uno o più file immutabili e devi sostituire i file immutabili corrispondenti con la nuova versione distribuita in src dell’SDK. L’esempio di registro seguente illustra questo problema:

Phase 3: Immutability check
reading immutable file list from /etc/httpd/immutable.files.txt
(...)
checking existing 'conf.dispatcher.d/clientheaders/default_clientheaders.any' for changes
immutable file 'conf.dispatcher.d/clientheaders/default_clientheaders.any' has been changed:
--- /etc/httpd/conf.dispatcher.d/clientheaders/default_clientheaders.any
+++ /etc/httpd-actual/conf.dispatcher.d/clientheaders/default_clientheaders.any
@@ -40,4 +40,3 @@
"Sling-uploadmode"
"x-requested-with"
"If-Modified-Since"
-"Authorization"
** error: immutable file 'conf.dispatcher.d/clientheaders/default_clientheaders.any' has been changed!

Questa fase può anche essere eseguita in modo indipendente tramite bin/docker_immutability_check.sh src/dispatcher.

Debug della configurazione di Apache e Dispatcher

Tieni presente che puoi eseguire Apache Dispatcher localmente utilizzando ./bin/docker_run.sh src/dispatcher docker.for.mac.localhost:4503 8080.

Come indicato in precedenza, Docker deve essere installato localmente e non è necessario che l’AEM sia in esecuzione. Gli utenti di Windows devono utilizzare Windows 10 Professional o altre distribuzioni che supportano Docker. Questo è un prerequisito per l’esecuzione e il debug di Dispatcher su un computer locale.

La seguente strategia può essere utilizzata per aumentare l’output del registro per il modulo Dispatcher e visualizzare i risultati della RewriteRule valutazione in 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 parte pertinente è la seguente:

# 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 Dispatcher viene eseguito localmente, i registri vengono stampati direttamente nell’output del terminale. Nella maggior parte dei casi, si desidera che questi registri siano in DEBUG, operazione che può essere eseguita passando il livello di debug come parametro durante l’esecuzione di Docker. Esempio: DISP_LOG_LEVEL=Debug ./bin/docker_run.sh src docker.for.mac.localhost:4503 8080.

I registri per gli ambienti cloud vengono esposti tramite il servizio di registrazione disponibile in Cloud Manager.

Ricaricamento e convalida automatici

Invece di eseguire la convalida locale (validate.sh) e avvio del contenitore docker (docker_run.sh) ogni volta che la configurazione viene modificata, in alternativa è possibile eseguire il comando docker_run_hot_reload.sh script. Lo script controlla eventuali modifiche alla configurazione, la ricarica automaticamente ed esegue nuovamente la convalida. Utilizzando questa opzione è possibile risparmiare molto tempo durante il debug.

È possibile eseguire lo script utilizzando il comando seguente: ./bin/docker_run_hot_reload.sh src/dispatcher host.docker.internal:4503 8080

Tieni presente che le prime righe di output avranno un aspetto simile a quello per cui vengono eseguite docker_run.sh, ad esempio:

~ bin/docker_run_hot_reload.sh src host.docker.internal:8081 8082
opt-in USE_SOURCES_DIRECTLY marker file detected
Running script /docker_entrypoint.d/10-check-environment.sh
Running script /docker_entrypoint.d/15-check-pod-name.sh
Running script /docker_entrypoint.d/20-create-docroots.sh
Running script /docker_entrypoint.d/30-wait-for-backend.sh
Waiting until host.docker.internal is available
host.docker.internal resolves to 192.168.65.2
Running script /docker_entrypoint.d/40-generate-allowed-clients.sh
Running script /docker_entrypoint.d/50-check-expiration.sh
Running script /docker_entrypoint.d/60-check-loglevel.sh
Running script /docker_entrypoint.d/70-check-forwarded-host-secret.sh
Running script /docker_entrypoint.d/80-frontend-domain.sh
Running script /docker_entrypoint.d/zzz-import-sdk-config.sh
WARN Mon Jul  4 09:53:54 UTC 2022: Pseudo symlink conf.d seems to point to a non-existing file!
INFO Mon Jul  4 09:53:55 UTC 2022: Copied customer configuration to /etc/httpd.
INFO Mon Jul  4 09:53:55 UTC 2022: Start testing
Cloud manager validator 2.0.43
2022/07/04 09:53:55 No issues found
INFO Mon Jul  4 09:53:55 UTC 2022: Testing with fresh base configuration files.
INFO Mon Jul  4 09:53:55 UTC 2022: Apache httpd informationServer version: Apache/2.4.54 (Unix)

Diverse configurazioni del Dispatcher per ambiente

Attualmente, la stessa configurazione di Dispatcher viene applicata a tutti gli ambienti AEM as a Cloud Service. 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 di Apache, la variabile può essere utilizzata direttamente in un’espressione. In alternativa, è possibile utilizzare la definizione per generare la 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 di Dispatcher, è disponibile la stessa variabile di ambiente. Se è necessaria più logica, definisci le variabili come mostrato nell’esempio precedente e quindi utilizzale nella sezione di configurazione di Dispatcher:

/virtualhosts {
  { "${VIRTUALHOST}" }
}

In alternativa, puoi utilizzare le variabili di ambiente Cloud Manager nella configurazione httpd/dispatcher, anche se non i segreti dell’ambiente. Questo metodo è particolarmente importante se un programma ha più ambienti di sviluppo e alcuni di questi hanno valori diversi per la configurazione di httpd/dispatcher. Viene utilizzata la stessa sintassi ${VIRTUALHOST} come nell’esempio precedente, ma non le dichiarazioni Define nel file delle variabili precedente. Leggi le Documentazione di Cloud Manager per istruzioni sulla configurazione delle variabili di ambiente Cloud Manager.

Quando esegui il test della configurazione locale, puoi simulare diversi tipi di ambiente trasmettendo la variabile DISP_RUN_MODE al docker_run.sh script direttamente:

$ DISP_RUN_MODE=stage docker_run.sh src 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, esegui lo script docker_run.sh senza argomenti.

Visualizzazione della configurazione del Dispatcher utilizzata dal contenitore Docker

Con configurazioni specifiche per l’ambiente, può essere difficile determinare l’aspetto della configurazione effettiva di Dispatcher. Dopo aver avviato il contenitore docker con docker_run.sh può essere scaricato come segue:

• Determina l’ID del contenitore docker in uso:

$ docker ps
CONTAINER ID       IMAGE
d75fbd23b29        adobe/aem-ethos/dispatcher-publish:...

• Esegui la seguente riga di comando con tale ID contenitore:

$ docker exec d75fbd23b29 httpd-test
# Dispatcher configuration: (/etc/httpd/conf.dispatcher.d/dispatcher.any)
/farms {
  /publishfarm {
    /clientheaders {
...

Migrazione dalla modalità legacy alla modalità flessibile

Con la versione 2021.7.0 di Cloud Manager, i nuovi programmi Cloud Manager generano strutture di progetto Maven con Archetipo AEM 28 o superiore, che include il file opt-in/USE_SOURCES_DIRECT. Questo elimina le limitazioni precedenti del modalità legacy intorno al numero e alle dimensioni dei file, consentendo all’SDK e al runtime di convalidare e distribuire la configurazione in modo migliorato. Se la configurazione del dispatcher non dispone di questo file, si consiglia vivamente di eseguire la migrazione. Utilizza i seguenti passaggi per garantire una transizione sicura:

1. Test locale. Utilizzando l’SDK degli strumenti del dispatcher più recente, aggiungi la cartella e il file opt-in/USE_SOURCES_DIRECTLY. Segui le istruzioni di "convalida locale" in questo articolo per verificare che Dispatcher funzioni localmente.

2. Test di sviluppo cloud:

   • Esegue il commit del file opt-in/USE_SOURCES_DIRECTLY a un ramo Git distribuito dalla pipeline non di produzione in un ambiente di sviluppo Cloud.
   • Utilizza Cloud Manager per la distribuzione in un ambiente di sviluppo Cloud.
   • Effettua il test completo. È fondamentale verificare che la configurazione di Apache e Dispatcher si comporti come previsto prima di distribuire le modifiche agli ambienti superiori. Controlla tutti i comportamenti relativi alla configurazione personalizzata. Se ritieni che la configurazione dispatcher implementata non rifletta la configurazione personalizzata, invia una segnalazione all’assistenza clienti.
   NOTA

   In modalità flessibile è necessario utilizzare percorsi relativi invece di percorsi assoluti.

   1. **Distribuisci in produzione:** * Esegue il commit del file `opt-in/USE_SOURCES_DIRECTLY` a un ramo Git distribuito dalla pipeline di produzione negli ambienti di staging e produzione Cloud. * Utilizza Cloud Manager per la distribuzione nell’ambiente di staging. * Effettua il test completo. È fondamentale verificare che la configurazione di Apache e Dispatcher si comporti come previsto prima di distribuire le modifiche agli ambienti superiori. Controlla tutti i comportamenti relativi alla configurazione personalizzata. Se ritieni che la configurazione dispatcher implementata non rifletta la configurazione personalizzata, invia una segnalazione all’assistenza clienti. * Utilizza Cloud Manager per continuare la distribuzione in produzione.

Risorse Business.Adobe.com