Debug delle build e delle implementazioni as a Cloud Service da AEM

Adobe Cloud Manager facilita la creazione del codice e le distribuzioni 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 in cui 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 per il quale la pipeline è configurata è 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: Modifica la configurazione della pipeline e riseleziona 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 per il quale la pipeline è configurata è stato eliminato.
• Risoluzione: Ricrea il ramo Git mancante utilizzando lo stesso nome o riconfigura la pipeline per la generazione da un ramo esistente diverso.

Test di compilazione e di unità

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:

• Una dipendenza Maven non disponibile su Maven Central viene utilizzato 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.
  • Non registrato esplicitamente nel pom.xml. 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 forte indicatore si basa su .sleep(..) nel codice del 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 Dettagli del download e rivedere eventuali voci.

Per ulteriori dettagli, consulta Regole specifiche per l’AEM, consulta la documentazione di Cloud Manager. regole di scansione del codice specifiche per AEM personalizzate.

Genera immagini

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 all del progetto AEM contiene più pacchetti di codice e la stessa configurazione OSGi viene fornita da più pacchetti di codice, causando un conflitto che impedisce al passaggio Build Image di decidere quale utilizzare, causando un errore nella build. 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 si risolvono nell’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, con conseguente duplicazione di qualsiasi configurazione OSGi contenuta in tale pacchetto.
• Risoluzione: Rivedi tutti i pacchetti pom.xml incorporati nel progetto all e assicurati che abbiano filevault-package-maven-plugin configurazione imposta 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: 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 dell’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: Assicurati 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 all’ultima versione 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 aggiornata la versione più recente dei Componenti core implementata.

È possibile che il passaggio Genera immagine non riesca quando:

• L’applicazione che distribuisce aggiorna la versione della dipendenza Maven dei Componenti core in core Progetto (bundle OSGi)
• L’applicazione in distribuzione viene quindi distribuita in un ambiente as a Cloud Service AEM 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 as a Cloud Service AEM, 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 che segnala che
  com.adobe.cq.wcm.core.components... impossibile importare i pacchetti in intervalli di versioni specifici da core progetto.

  [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 core project) importa le classi Java dalla dipendenza principale dei Componenti core, a un livello di versione diverso da quello implementato 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 alla versione più recente dell’AEM, che includerà la versione più recente dei Componenti core. Una volta che l’AEM as a Cloud Service è stato aggiornato alla versione più recente dell’AEM, che avrà la versione più recente dei Componenti core, ridistribuisci il codice che originariamente non riusciva.
  • Per riprodurre questo problema localmente, assicurati che la versione dell’SDK per AEM sia la stessa versione dell’AEM utilizzata dall’ambiente as a Cloud Service AEM.

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, accertati che l’organizzazione di Adobe con pipeline non riuscita sia selezionata nel selettore Organizzazioni di Adobe prima di creare il caso.

Distribuisci in

Il passaggio Distribuisci su è responsabile dell’esecuzione dell’artefatto di codice generato nell’immagine di creazione, avvia i nuovi servizi Author e Publish di AEM e, una volta completato, rimuove tutti i vecchi servizi Author e Publish di AEM. 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 in. Il aemerror Il registro contiene informazioni sull’avvio e l’arresto dei pod che possono essere utili per la distribuzione in caso di problemi. Tieni presente che il registro disponibile tramite il pulsante Scarica registro nel passaggio Distribuisci in di Cloud Manager non è il 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 versione AEM precedente

• Causa: Una pipeline di 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.

Timeout di Cloud Manager

Il codice in esecuzione durante l’avvio del servizio AEM appena implementato richiede così tanto tempo che Cloud Manager scade prima che la distribuzione possa essere completata. In questi casi, la distribuzione potrebbe avere esito positivo anche se è stato segnalato lo stato di Cloud Manager Non riuscito.

• Causa: Il codice personalizzato può eseguire operazioni, come query di grandi dimensioni o attraversamenti di contenuti, attivate in anticipo nel bundle OSGi o nei cicli di vita dei componenti, ritardando notevolmente il tempo di avvio dell’AEM.
• Risoluzione: Esamina l’implementazione del codice che viene eseguito all’inizio del ciclo di vita del bundle OSGi, quindi controlla aemerror registra per i servizi AEM Author e Publish intorno al momento dell’errore (tempo di registrazione in GMT), come mostrato da Cloud Manager, e cerca i messaggi di registro che indicano eventuali processi di esecuzione del registro personalizzati.

Codice o configurazione non compatibile

La maggior parte del codice e delle violazioni della configurazione vengono rilevate in una fase precedente della build, tuttavia il codice personalizzato o la configurazione possono essere incompatibili con l’AEM as a Cloud Service e non vengono rilevate finché non vengono eseguite nel contenitore.

• Causa: Il codice personalizzato può richiamare operazioni lunghe, come query di grandi dimensioni o attraversamenti di contenuti, attivate in anticipo nel bundle OSGi o nei cicli di vita dei componenti, ritardando notevolmente il tempo di avvio dell’AEM.
• Risoluzione: Rivedi aemerror registra per i servizi di authoring e pubblicazione di AEM in qualsiasi momento (tempo di registrazione in GMT) dell’errore, come mostrato da Cloud Manager.
  1. 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.
  2. 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 è mutabile e contiene diversi contenuti transitori e di runtime. Inclusione /var in pacchetti di contenuti (ad es. ui.content) implementato tramite Cloud Manager potrebbe causare un errore del passaggio di 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, tuttavia il contenuto mutabile nuovo o modificato, che fa parte della distribuzione, non sembra esistere nel servizio di pubblicazione AEM.
• L’attivazione/disattivazione del contenuto in AEM Author è 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:

1. Determinando che almeno un pacchetto di contenuti che fa parte della distribuzione, scrive in /var.

2. Verifica che la coda di distribuzione primaria (in grassetto) sia bloccata in:

   • AEM Author > Strumenti > Implementazione > Distribuzione

     

3. In caso di mancata distribuzione successiva, scarica i registri di "Distribuisci in" di Cloud Manager utilizzando il pulsante Scarica registro:

   

   … e verificare che trascorrano circa 60 minuti tra le istruzioni di registro:

   2020-01-01T01:01:02+0000 Begin deployment in aem-program-x-env-y-dev [CorrelationId: 1234]
   

   … e …

   2020-01-01T02:04:10+0000 Failed deployment in aem-program-x-env-y-dev
   

   Tieni 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 AEM utilizzato per distribuire pacchetti di contenuti nel servizio di pubblicazione AEM non può scrivere in /var in AEM Publish. In questo modo la distribuzione del pacchetto di contenuti al servizio di pubblicazione AEM non riesce.
• Risoluzione: Per risolvere questo problema, vengono elencati i seguenti modi in ordine di preferenza:
  1. Se il /var risorse non necessarie rimuovere le risorse in /var da pacchetti di contenuti distribuiti come parte dell’applicazione.
  2. Se il /var risorse sono necessarie, definisci le strutture dei nodi utilizzando repoinit. Gli script Repoinit possono essere indirizzati ad AEM Author, AEM Publish o a entrambi, tramite le modalità di esecuzione OSGi.
  3. Se il /var Le risorse sono necessarie solo per l’autore dell’AEM e non possono essere ragionevolmente modellate utilizzando repoinit, spostali in un pacchetto di contenuti discreto, installato solo in AEM Author da incorporamento in all pacchetto in una cartella runmode di AEM Author (<target>/apps/example-packages/content/install.author</target>).
  4. Fornisci ACL appropriati al sling-distribution-importer utente del servizio come descritto ADOBE KB.

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, accertati che l’organizzazione di Adobe con pipeline non riuscita sia selezionata nel selettore Organizzazioni di Adobe prima di creare il caso.