Debug delle build e delle implementazioni di AEM as a Cloud Service
Adobe Cloud Manager facilita la creazione e la distribuzione del codice in AEM as a Cloud Service. Possono verificarsi errori durante le fasi del processo di compilazione, che richiedono un'azione per risolverli. Questa guida illustra come comprendere gli errori comuni in nell’implementazione e come affrontarli nel modo migliore.
Convalida
Il passaggio di convalida assicura semplicemente la validità delle configurazioni di base di Cloud Manager. Gli errori comuni di convalida includono:
L’ambiente è in uno stato non valido
- Messaggio di errore: l'ambiente è in uno stato non valido.
- Causa: L'ambiente di destinazione della pipeline è in uno stato di transizione e non può accettare nuove build.
- Risoluzione: attendere la risoluzione dello stato in esecuzione (o aggiornamento disponibile). Se l’ambiente viene eliminato, ricrealo o scegli un altro ambiente in cui generare la build.
Impossibile trovare l’ambiente associato alla pipeline
- Messaggio di errore: l'ambiente è contrassegnato come eliminato.
- Causa: L'ambiente che la pipeline è configurata per l'utilizzo è stato eliminato.
Anche se viene ricreato un nuovo ambiente con lo stesso nome, Cloud Manager non associa automaticamente la pipeline a tale ambiente con lo stesso nome. - Risoluzione: modificare la configurazione della pipeline e selezionare nuovamente l'ambiente in cui eseguire la distribuzione.
Impossibile trovare il ramo Git associato alla pipeline
- Messaggio di errore: pipeline non valida: XXXXXX. Reason=Branch=xxxx non trovato nell'archivio.
- Causa: Il ramo Git configurato per l'utilizzo della pipeline è stato eliminato.
- Risoluzione: ricreare il ramo Git mancante utilizzando lo stesso nome o riconfigurare la pipeline in modo che venga generata da un ramo esistente diverso.
Build e unit test
La fase Build e Unit Testing esegue una build Maven (mvn clean package) del progetto estratto dal ramo Git configurato della pipeline.
Gli errori identificati in questa fase devono essere riproducibili nella creazione locale del progetto, con le seguenti eccezioni:
-
Viene utilizzata una dipendenza Maven non disponibile in Maven Central e l'archivio Maven contenente la dipendenza è:
- Non raggiungibile da Cloud Manager, ad esempio un archivio Maven interno privato, o l’archivio Maven richiede l’autenticazione e sono state fornite credenziali errate.
- Registrazione non esplicita in
pom.xmldel progetto. Tieni presente che, includere gli archivi Maven è sconsigliato in quanto aumenta i tempi di creazione.
-
Gli unit test non riescono a causa di problemi di tempistica. Ciò può verificarsi quando gli unit test sono sensibili agli intervalli. Un indicatore sicuro si basa su
.sleep(..)nel codice di test. -
Utilizzo di plug-in Maven non supportati.
Scansione del codice
La scansione del codice esegue l’analisi del codice statico utilizzando una combinazione di best practice specifiche per Java e AEM.
Se nel codice sono presenti vulnerabilità di sicurezza critiche, l’analisi del codice genera un errore di build. Le violazioni meno importanti possono essere ignorate, ma si consiglia di correggerle. La scansione del codice non è perfetta e può causare falsi positivi.
Per risolvere i problemi di scansione del codice, scarica il rapporto in formato CSV fornito da Cloud Manager tramite il pulsante Scarica dettagli e controlla eventuali voci.
Per ulteriori dettagli, vedi Regole specifiche per l'AEM, vedi la documentazione di Cloud Manager regole di scansione del codice personalizzate per l'AEM.
Immagini di build
L’immagine della build è responsabile della combinazione degli artefatti di codice creati nel passaggio Build e Unit Testing con la versione dell’AEM, per formare un singolo artefatto distribuibile.
Anche se durante la generazione e il testing di unità vengono riscontrati problemi di compilazione e compilazione del codice, possono esserci problemi di configurazione o strutturali identificati quando si tenta di combinare l’artefatto di compilazione personalizzato con la versione dell’AEM.
Configurazioni OSGi duplicate
Quando più configurazioni OSGi si risolvono tramite la modalità di esecuzione per l’ambiente AEM di destinazione, il passaggio Genera immagine non riesce e viene visualizzato il messaggio di errore:
[ERROR] Unable to convert content-package [/tmp/packages/enduser.all-1.0-SNAPSHOT.zip]:
Configuration 'com.example.ExampleComponent' already defined in Feature Model 'com.example.groupId:example.all:slingosgifeature:xxxxx:X.X',
set the 'mergeConfigurations' flag to 'true' if you want to merge multiple configurations with same PID
Causa 1
- Causa: il pacchetto tutto del progetto AEM contiene più pacchetti di codice e la stessa configurazione OSGi è fornita da più pacchetti di codice, causando un conflitto. Il passaggio Genera immagine non è in grado di decidere quale deve essere utilizzata, pertanto la compilazione non riesce. Questo non si applica alle configurazioni di fabbrica OSGi, purché abbiano nomi univoci.
- Risoluzione: esamina tutti i pacchetti di codice (inclusi eventuali pacchetti di codice di terze parti) distribuiti come parte dell'applicazione AEM, cercando configurazioni OSGi duplicate che risolvono l'ambiente di destinazione tramite la modalità di esecuzione. La guida del messaggio di errore "imposta il flag mergeConfigurations su true" non è possibile in AEM as a Cloud Service e deve essere ignorata.
Causa 2
- Causa: il progetto AEM include erroneamente lo stesso pacchetto di codice due volte, causando la duplicazione di qualsiasi configurazione OSGi contenuta in tale pacchetto.
- Risoluzione: Rivedi tutti i pom.xml dei pacchetti incorporati nel progetto all e assicurati che la
filevault-package-maven-pluginconfigurazione sia impostata su<cloudManagerTarget>none</cloudManagerTarget>.
Script di repoinit non valido
Gli script Repoinit definiscono il contenuto della linea di base, gli utenti, gli ACL, ecc. In AEM as a Cloud Service, gli script di repoinit vengono applicati durante la generazione dell’immagine, ma nell’avvio rapido locale dell’SDK dell’AEM vengono applicati quando la configurazione della factory di repoinit OSGi è attivata. Per questo motivo, gli script Repoinit potrebbero non riuscire (con la registrazione) nell’avvio rapido locale dell’SDK dell’AEM, ma il passaggio Build Image non riesce, interrompendo la distribuzione.
- Causa: Uno script di repoinit non è valido. Questo potrebbe lasciare l’archivio in uno stato incompleto, in quanto eventuali script di repoinit dopo lo script non riuscito non vengono eseguiti nell’archivio.
- Risoluzione: controlla l'avvio rapido locale dell'SDK AEM quando viene distribuita la configurazione OSGi dello script di repoinit per determinare se e quali sono gli errori.
Dipendenza contenuto repoinit non soddisfatta
Gli script Repoinit definiscono il contenuto della linea di base, gli utenti, gli ACL, ecc. Nel quickstart locale dell'SDK dell'AEM, gli script di repoinit vengono applicati quando la configurazione di fabbrica OSGi di repoinit è attivata, o in altre parole, dopo che l'archivio è attivo e potrebbe aver subito modifiche al contenuto direttamente o tramite pacchetti di contenuti. In AEM as a Cloud Service, gli script repoinit vengono applicati durante la generazione dell’immagine in un archivio che potrebbe non contenere contenuto da cui dipende lo script repoinit.
- Causa: Uno script di repoinit dipende da contenuto inesistente.
- Risoluzione: Verificare che esista il contenuto da cui dipende lo script Repoinit. Spesso questo indica una definizione inadeguata degli script di repoinit con direttive mancanti che definiscono queste strutture di contenuto mancanti, ma necessarie. Questa operazione può essere riprodotta localmente eliminando l’AEM, decomprimendo il file JAR e aggiungendo la configurazione OSGi repoinit contenente lo script repoinit alla cartella di installazione e avviando l’AEM. L’errore si presenterà nel file error.log del quickstart locale dell’SDK dell’AEM.
La versione dei Componenti core dell’applicazione è successiva alla versione implementata
Questo problema riguarda solo gli ambienti non di produzione che NON eseguono l'aggiornamento automatico alla versione più recente dell'AEM.
AEM as a Cloud Service include automaticamente la versione più recente dei Componenti core in ogni versione AEM, ovvero dopo che a un ambiente AEM as a Cloud Service viene, automaticamente o manualmente, installata la versione più recente dei Componenti core.
È possibile che il passaggio Genera immagine non riesca quando:
- L'applicazione che distribuisce aggiorna la versione della dipendenza Maven dei Componenti core nel progetto
core(bundle OSGi) - L’applicazione di distribuzione viene quindi distribuita in un ambiente AEM as a Cloud Service sandbox (non di produzione) che non è stato aggiornato per l’utilizzo di una versione AEM contenente la nuova versione dei Componenti core.
Per evitare questo errore, ogni volta che è disponibile un aggiornamento dell’ambiente AEM as a Cloud Service, includi l’aggiornamento come parte della build/distribuzione successiva e assicurati sempre che gli aggiornamenti vengano inclusi dopo l’incremento della versione dei Componenti core nella base di codice dell’applicazione.
-
Sintomi:
Il passaggio Genera immagine non riesce e viene visualizzato un messaggio di ERRORE in cui si segnala checom.adobe.cq.wcm.core.components...pacchetti in intervalli di versione specifici non possono essere importati dal progettocore.code language-none [ERROR] Bundle com.example.core:0.0.3-SNAPSHOT is importing package(s) Package com.adobe.cq.wcm.core.components.models;version=[12.13,13) in start level 20 but no bundle is exporting these for that start level in the required version range. [ERROR] Analyser detected errors on feature 'com.adobe.granite:aem-ethos-app-image:slingosgifeature:aem-runtime-application-publish-dev:1.0.0-SNAPSHOT'. See log output for error messages. [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ -
Causa: Il bundle OSGi dell'applicazione (definito nel progetto
core) importa le classi Java dalla dipendenza core dei Componenti core a un livello di versione diverso da quello distribuito in AEM as a Cloud Service. -
Risoluzione:
- Utilizzando Git, ripristina un commit di lavoro esistente prima dell’incremento di versione dei Componenti core. Invia questo commit a un ramo Git di Cloud Manager ed esegui un aggiornamento dell’ambiente da questo ramo. Questo aggiornerà AEM as a Cloud Service all’ultima versione dell’AEM, che includerà la versione più recente dei Componenti core. Dopo aver aggiornato AEM as a Cloud Service alla versione più recente dell’AEM, che avrà la versione più recente dei Componenti core, ridistribuisci il codice che originariamente non riusciva.
- Per riprodurre il problema localmente, assicurati che la versione dell’SDK per AEM sia la stessa della versione dell’AEM in uso nell’ambiente AEM as a Cloud Service.
Creazione di un caso di supporto Adobe
Se gli approcci di risoluzione dei problemi sopra descritti non risolvono il problema, crea un caso di supporto Adobe tramite:
-
Adobe Admin Console > Scheda Supporto > Crea caso
Se sei membro di più organizzazioni di Adobe, assicurati che l'organizzazione di Adobe con pipeline non riuscita sia selezionata nel selettore delle organizzazioni di Adobe prima di creare il caso.
Distribuisci in
Il passaggio Distribuisci a è responsabile dell’acquisizione dell’artefatto di codice generato nell’immagine di creazione, avvia i nuovi servizi di authoring AEM e Publish che lo utilizzano e, in caso di esito positivo, rimuove tutti i vecchi servizi di authoring AEM e Publish. Anche in questo passaggio vengono installati e aggiornati pacchetti e indici di contenuto variabile.
Acquisisci familiarità con registri AEM as a Cloud Service prima di eseguire il debug del passaggio Distribuisci a. Il registro aemerror contiene informazioni sull'avvio e l'arresto dei pod che possono essere pertinenti per la distribuzione in caso di problemi. Il registro disponibile tramite il pulsante Download Log nel passaggio Distribuisci su di Cloud Manager non è il registro aemerror e non contiene informazioni dettagliate relative all'avvio delle applicazioni.
I tre motivi principali per cui la distribuzione al passaggio potrebbe non riuscire:
La pipeline di Cloud Manager contiene una vecchia versione dell’AEM
-
Causa: una pipeline Cloud Manager contiene una versione precedente dell'AEM rispetto a quella distribuita nell'ambiente di destinazione. Questo può accadere quando una pipeline viene riutilizzata e puntata a un nuovo ambiente che esegue una versione successiva dell’AEM. Questo può essere identificato controllando per vedere se la versione dell’AEM dell’ambiente è maggiore della versione dell’AEM della pipeline.
-
Risoluzione:
- Se nell'ambiente di destinazione è disponibile un aggiornamento, selezionare Aggiorna dalle azioni dell'ambiente, quindi eseguire nuovamente la build.
- Se nell’ambiente di destinazione non è disponibile un aggiornamento, significa che è in esecuzione la versione più recente dell’AEM. Per risolvere questo problema, elimina la pipeline e ricreala.
Cloud Manager timeout
Il codice in esecuzione durante l’avvio del servizio AEM appena implementato richiede così tanto tempo che Cloud Manager va in timeout prima che la distribuzione possa essere completata. In questi casi, la distribuzione potrebbe riuscire, anche se lo stato del Cloud Manager segnalato come Non riuscito.
- Causa: il codice personalizzato può eseguire operazioni, ad esempio query di grandi dimensioni o attraversamenti di contenuto, attivate in anticipo nel bundle OSGi o nei cicli di vita dei componenti, ritardando notevolmente l'ora di avvio dell'AEM.
- Risoluzione: verifica l'implementazione del codice che viene eseguito all'inizio del ciclo di vita del bundle OSGi, quindi controlla i
aemerrorregistri per i servizi AEM Author e Publish intorno al momento dell'errore (tempo di accesso in GMT) come mostrato da Cloud Manager e cerca i messaggi di registro che indicano eventuali processi di esecuzione di registro personalizzati.
Codice o configurazione non compatibile
La maggior parte delle violazioni di codice e configurazione viene rilevata in una fase precedente della build, tuttavia il codice personalizzato o la configurazione possono essere incompatibili con AEM as a Cloud Service e non vengono rilevate finché non vengono eseguite nel contenitore.
-
Causa: il codice personalizzato può richiamare operazioni lunghe, ad esempio query di grandi dimensioni o attraversamenti di contenuto, attivate in anticipo nel bundle OSGi o nei cicli di vita dei componenti, ritardando notevolmente il tempo di avvio dell'AEM.
-
Risoluzione: esamina i registri
aemerrorper i servizi di creazione AEM e Publish nel periodo di tempo (tempo di registrazione in GMT) dell'errore, come mostrato da Cloud Manager.- Esamina i registri per individuare eventuali ERRORI generati dalle classi Java fornite dall’applicazione personalizzata. Se vengono rilevati problemi, risolvi questi, invia il codice corretto e ricompila la pipeline.
- Esamina i registri per individuare eventuali ERRORI segnalati da aspetti dell’AEM che stai estendendo/interagendo con nell’applicazione personalizzata e analizzali; questi ERRORI potrebbero non essere attribuiti direttamente alle classi Java. Se vengono rilevati problemi, risolvi questi, invia il codice corretto e ricompila la pipeline.
Inclusione di /var nel pacchetto di contenuti
/var è modificabile e contiene diversi contenuti temporanei e di runtime. Inclusione di /var in pacchetti di contenuti (ad es. ui.content) distribuita tramite Cloud Manager potrebbe impedire il completamento della distribuzione.
Questo problema è difficile da identificare in quanto non si verifica un errore nella distribuzione iniziale, ma solo nelle distribuzioni successive. I sintomi più evidenti includono:
- La distribuzione iniziale ha esito positivo, anche se il contenuto mutabile nuovo o modificato, che fa parte della distribuzione, non sembra esistere nel servizio Publish dell’AEM.
- L’attivazione/disattivazione dei contenuti nell’istanza di creazione AEM è bloccata
- Le distribuzioni successive non riescono nel passaggio di implementazione a, con la distribuzione a un passaggio che non riesce dopo circa 60 minuti.
Per convalidare questo problema, la causa è il comportamento errato:
-
Determinando che almeno un pacchetto di contenuti che fa parte della distribuzione, scrive in
/var. -
Verifica che la coda di distribuzione primaria (in grassetto) sia bloccata in:
-
AEM Author > Tools > Deployment > Distribution (Creazione > Strumenti > Implementazione > Distribuzione)
-
-
In caso di mancata distribuzione successiva, scarica i registri di Cloud Manager "Deploy to" utilizzando il pulsante Download Log (Scarica registro):
… e verificare che trascorrano circa 60 minuti tra le istruzioni di registro:
code language-none 2020-01-01T01:01:02+0000 Begin deployment in aem-program-x-env-y-dev [CorrelationId: 1234]… e …
code language-none 2020-01-01T02:04:10+0000 Failed deployment in aem-program-x-env-y-devTieni presente che questo registro non conterrà questi indicatori sulle distribuzioni iniziali che riportano come riuscite, ma solo sulle distribuzioni successive con errori.
-
Causa: l'utente del servizio di replica dell'AEM utilizzato per distribuire pacchetti di contenuti al servizio Publish dell'AEM non è in grado di scrivere in
/varsu AEM Publish. In questo modo la distribuzione del pacchetto di contenuti al servizio Publish dell’AEM non riesce. -
Risoluzione: I seguenti modi per risolvere i problemi sono elencati in ordine di preferenza:
- Se le risorse
/varnon sono necessarie, rimuovere le risorse in/vardai pacchetti di contenuto distribuiti come parte dell'applicazione. - Se le risorse
/varsono necessarie, definire le strutture dei nodi utilizzando repoinit. Gli script Repoinit possono essere indirizzati a AEM Author, AEM Publish o a entrambi, tramite le modalità di esecuzione OSGi. - Se le risorse
/varsono necessarie solo per l'autore di AEM e non possono essere modellate in modo ragionevole utilizzando repoinit, spostarle in un pacchetto di contenuti discreti, installato solo in AEM Author mediante incorporamento nel pacchettoallin una cartella in modalità di esecuzione AEM Author (<target>/apps/example-packages/content/install.author</target>). - Fornire le ACL appropriate all'utente del servizio
sling-distribution-importercome descritto in questo Adobe KB.
- Se le risorse
Creazione di un caso di supporto Adobe
Se gli approcci di risoluzione dei problemi sopra descritti non risolvono il problema, crea un caso di supporto Adobe tramite:
-
Adobe Admin Console > Scheda Supporto > Crea caso
Se sei membro di più organizzazioni di Adobe, assicurati che l'organizzazione di Adobe con pipeline non riuscita sia selezionata nel selettore delle organizzazioni di Adobe prima di creare il caso.