Implementazione in AEM as a Cloud Service

Introduzione

Le basi dello sviluppo del codice sono simili in AEM come Cloud Service rispetto alle soluzioni AEM Premise e Managed Services. Gli sviluppatori scrivono il codice e lo sottopongono a test localmente, che vengono quindi spinti AEM remoti come ambienti di Cloud Service. Cloud Manager, uno strumento opzionale per la distribuzione dei contenuti per Managed Services, è richiesto. Questo è ora l'unico meccanismo per distribuire il codice da AEM come ambienti di Cloud Service.

L'aggiornamento della AEM versione è sempre un evento di distribuzione separato dal codice personalizzato. Visualizzate in un altro modo, le versioni di codice personalizzate dovrebbero essere testate rispetto alla versione AEM in produzione, in quanto questo è ciò che verrà distribuito nella parte superiore. AEM aggiornamenti delle versioni che si verificano dopo tale data, che saranno frequenti e vengono applicati automaticamente. Sono compatibili con il codice cliente già distribuito.

Il resto di questo documento descriverà come gli sviluppatori dovrebbero adattare le proprie pratiche in modo che lavorino con AEM come aggiornamenti versione di Cloud Service e aggiornamenti dei clienti.

Rilasci dei clienti

Codifica rispetto alla versione corretta AEM

Per le soluzioni AEM precedenti, la versione di AEM più recente è cambiata raramente (approssimativamente ogni anno con Service Pack trimestrali) e i clienti aggiornavano le istanze di produzione all'ultimo avvio rapido in base al proprio tempo, facendo riferimento alla API Jar. Tuttavia, AEM come applicazione di Cloud Service vengono automaticamente aggiornate alla versione più recente di AEM più spesso, pertanto il codice personalizzato per le versioni interne dovrebbe essere creato rispetto alla versione AEM più recente.

Come per le versioni di AEM non cloud esistenti, nella maggior parte dei casi sarà supportato uno sviluppo locale offline basato su uno specifico quickstart, che sarà lo strumento di scelta per il debug.

Per sviluppare il codice personalizzato per una versione interna, è necessario scaricare e installare la versione corrispondente del AEM come Cloud Service SDK. Per ulteriori informazioni sull'utilizzo del AEM come strumenti del dispatcher di Cloud Service, vedere questa pagina.

Il seguente video fornisce una panoramica di alto livello su come distribuire il codice da AEM come Cloud Service:

Distribuzione di pacchetti di contenuti tramite Cloud Manager e Package Manager

Implementazioni tramite Cloud Manager

I clienti distribuiscono il codice personalizzato agli ambienti cloud tramite Cloud Manager. È opportuno notare che Cloud Manager trasforma i pacchetti di contenuto assemblati localmente in un artefatto conforme al modello di funzioni Sling, che rappresenta la modalità con cui viene descritta un'applicazione AEM come Cloud Service quando viene eseguita in un ambiente cloud. Di conseguenza, quando si esaminano i pacchetti in Package Manager negli ambienti Cloud, il nome includerà "cp2fm" e i pacchetti trasformati hanno tutti i metadati rimossi. Non è possibile interagire con questi elementi, ovvero non possono essere scaricati, replicati o aperti. La documentazione dettagliata sul convertitore si trova qui a1/>.

I pacchetti di contenuto scritti per AEM come applicazioni di Cloud Service devono avere una separazione netta tra contenuto immutabile e mutabile e Cloud Manager lo applicherà non riuscendo a creare, generando un messaggio come:

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

Il resto di questa sezione descriverà la composizione e le implicazioni dei pacchetti immutabili e mutabili.

Pacchetti di contenuti immutabili

Tutto il contenuto e il codice memorizzati nell’archivio immutabile devono essere sottoposti a check-in e distribuiti tramite Cloud Manager. In altre parole, a differenza delle soluzioni AEM correnti, il codice non viene mai distribuito direttamente in un'istanza AEM in esecuzione. Questo garantisce che il codice in esecuzione per una determinata release in qualsiasi ambiente Cloud sia identico, eliminando il rischio di variazioni di codice non intenzionali durante la produzione. Ad esempio, la configurazione OSGI deve essere impegnata nel controllo del codice sorgente anziché gestita in fase di esecuzione tramite il gestore di configurazione della console Web AEM.

Poiché le modifiche dell'applicazione a causa del pattern di distribuzione Blu-Verde sono abilitate da uno switch, non possono dipendere dalle modifiche nell'archivio modificabile, ad eccezione degli utenti del servizio, dei relativi ACL, dei tipi di nodi e delle modifiche alla definizione dell'indice.

Per i clienti con basi di codice esistenti, è fondamentale seguire l'esercizio di ristrutturazione del repository descritto AEM documentazione per garantire che il contenuto precedentemente in /etc sia spostato nella posizione giusta.

Configurazione OSGI

Come già detto, la configurazione OSGI deve essere impegnata nel controllo del codice sorgente anziché tramite la console Web. Le tecniche per farlo includono:

• Apportare le modifiche necessarie nell'ambiente AEM locale dello sviluppatore con il gestore di configurazione della console Web AEM, quindi esportare i risultati nel progetto AEM nel file system locale
• La creazione manuale della configurazione OSGI nel progetto AEM sul file system locale fa riferimento al gestore di configurazione della console AEM per i nomi delle proprietà.

Per ulteriori informazioni sulla configurazione OSGI, vedere Configurazione di OSGi per AEM come Cloud Service.

Contenuto variabile

In alcuni casi potrebbe essere utile preparare le modifiche al contenuto nel controllo del codice sorgente in modo che possa essere distribuito da Cloud Manager ogni volta che un ambiente è stato aggiornato. Ad esempio, potrebbe essere ragionevole generare determinate strutture di cartelle principali o allineare le modifiche nei modelli modificabili per abilitare i criteri in quelli per i componenti che sono stati aggiornati dalla distribuzione dell'applicazione.

Esistono due strategie per descrivere il contenuto che verrà distribuito da Cloud Manager nell'archivio modificabile, i pacchetti di contenuto modificabile e le istruzioni di reindirizzamento.

Pacchetti di contenuti variabile

Contenuto come le gerarchie di percorsi di cartella, gli utenti del servizio e i controlli di accesso (ACL, Access Control) vengono generalmente impegnati in un progetto AEM basato su archetipo principale. Le tecniche includono l'esportazione da AEM o la scrittura direttamente come XML. Durante il processo di creazione e distribuzione, Cloud Manager crea pacchetti per il pacchetto di contenuto variabile risultante. Il contenuto modificabile viene installato in 3 momenti diversi durante la fase di distribuzione nella pipeline:

Prima dell'avvio della nuova versione dell'applicazione:

• definizioni di indice (aggiungere, modificare, rimuovere)

Durante l'avvio di una nuova versione dell'applicazione, ma prima del passaggio:

• Utenti del servizio (aggiungere)
• ACL utente servizio (add)
• tipi di nodi (add)

Dopo il passaggio alla nuova versione dell'applicazione:

• Tutti gli altri contenuti definibili tramite jackrabbit vault. Esempio:
  • Cartelle (aggiungere, modificare, rimuovere)
  • Modelli modificabili (aggiungere, modificare, rimuovere)
  • Configurazione in base al contesto (qualsiasi cosa in /conf) (aggiungere, modificare, rimuovere)
  • Script (i pacchetti possono attivare i ganci di installazione a varie fasi del processo di installazione del pacchetto)

È possibile limitare l'installazione di contenuti modificabili per creare o pubblicare i pacchetti incorporando i pacchetti in una cartella install.author o install.publish in /apps. Informazioni da trovare nella AEM documentazione sulla ristrutturazione del progetto consigliata.

Inoltre, non esiste alcun meccanismo per ripristinare le modifiche apportate al pacchetto di contenuto modificabile dopo che sono state applicate. Se i clienti rilevano un problema, possono scegliere di risolverlo nella release successiva del codice o come ultima risorsa, ripristinare l'intero sistema a un punto nel tempo prima della distribuzione.

I pacchetti di terze parti inclusi devono essere convalidati come AEM come compatibili con il servizio di Cloud Service, altrimenti la loro inclusione causerà un errore di distribuzione.

Come già detto, i clienti con basi di codice esistenti devono conformarsi all'esercizio di ristrutturazione del repository descritto in AEM documentazione.

Repoinit

Per i seguenti casi, è preferibile adottare l'approccio di codificare manualmente le istruzioni repoinit per la creazione di contenuti nelle configurazioni di fabbrica OSGI:

• Creare/eliminare/disabilitare gli utenti del servizio

• Creare ed eliminare gruppi

• Creare ed eliminare utenti

• Aggiunta di ACL

  NOTA

  La definizione di ACL richiede che le strutture dei nodi siano già presenti. Pertanto, prima di creare le istruzioni percorso potrebbe essere necessario.

• Aggiungi percorso (ad esempio per le strutture di cartelle principali)

• Aggiungere CND (definizioni dei tipi di nodo)

Repoinit è preferibile per questi casi di utilizzo supportati per la modifica del contenuto a causa dei seguenti vantaggi:

• Repoinit crea risorse all'avvio, in modo che la logica possa dare per scontata l'esistenza di tali risorse. Nell'approccio basato su pacchetti di contenuto variabile, le risorse vengono create dopo l'avvio, pertanto il codice dell'applicazione che si basa su di esse potrebbe non riuscire.
• Repoinit è un insieme di istruzioni relativamente sicuro in quanto si controlla esplicitamente l'azione da intraprendere. Inoltre, le uniche operazioni supportate sono additivi, ad eccezione di alcuni casi relativi alla sicurezza che consentono la rimozione di Utenti, Utenti di servizi e Gruppi. Al contrario, è esplicita la rimozione di qualcosa nell'approccio basato su pacchetti di contenuti variabili; quando definite un filtro, tutti gli elementi presenti coperti da un filtro verranno eliminati. Tuttavia, è necessario prestare attenzione, in quanto con qualsiasi contenuto esistono scenari in cui la presenza di nuovo contenuto può alterare il comportamento dell'applicazione.
• Repoinit esegue operazioni rapide e atomiche. I pacchetti di contenuto variabile, al contrario, possono dipendere notevolmente dalle prestazioni in base alle strutture coperte da un filtro. Anche se aggiornate un singolo nodo, potrebbe essere creata un'istantanea di una struttura ad albero grande.
• È possibile convalidare le istruzioni di ripristino in un ambiente di sviluppo locale in fase di esecuzione, dal momento che verranno eseguite quando la configurazione OSGi viene registrata.
• Le istruzioni Repoinit sono atomiche ed esplicite e ignorano se lo stato è già corrispondente.

Quando Cloud Manager distribuisce l'applicazione, esegue queste istruzioni, indipendentemente dall'installazione di qualsiasi pacchetto di contenuto.

Per creare delle istruzioni di reindirizzamento, attenersi alla procedura seguente:

1. Aggiungi la configurazione OSGi per il PID org.apache.sling.jcr.repoinit.RepositoryInitializer di fabbrica in una cartella di configurazione del progetto. Utilizzate un nome descrittivo per la configurazione come org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure.
2. Aggiungete istruzioni di reindirizzamento alla proprietà script della configurazione. La sintassi e le opzioni sono documentate in Documentazione Sling. Prima delle cartelle figlie, è necessario creare esplicitamente una cartella principale. Ad esempio, una creazione esplicita di /content prima di /content/myfolder, prima di /content/myfolder/mysubfolder. Per gli ACL impostati su strutture di basso livello, si consiglia di impostarli su un livello superiore e lavorare con una limitazione rep:glob. Esempio (allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs)).
3. Convalida nell'ambiente di sviluppo locale in fase di esecuzione.

Maggiori informazioni sul repoinit sono disponibili nella Documentazione Sling

Package Manager "one offs" per pacchetti di contenuto variabile

In alcuni casi, un pacchetto di contenuti deve essere installato come "una tantum". Ad esempio, l'importazione di contenuto specifico dalla produzione all'area di produzione per eseguire il debug di un problema di produzione. Per questi scenari, Package Manager può essere utilizzato in AEM come ambiente di Cloud Service.

Poiché Package Manager è un concetto di runtime, non è possibile installare contenuto o codice nell'archivio immutabile, pertanto questi pacchetti di contenuto devono essere costituiti solo da contenuto variabile (principalmente /content o /conf). Se il pacchetto di contenuti include contenuto misto (contenuto modificabile e non modificabile), verrà installato solo il contenuto modificabile.

Tutti i pacchetti di contenuto installati tramite Cloud Manager (sia modificabili che immutabili) verranno visualizzati in uno stato bloccato nell'interfaccia utente di AEM Package Manager. Questi pacchetti non possono essere reinstallati, rigenerati o persino scaricati e saranno elencati con un suffisso "cp2fm", a indicare che l'installazione è stata gestita da Cloud Manager.

Inclusi pacchetti di terze parti

È comune per i clienti includere pacchetti pre-costruiti da fonti di terze parti come fornitori di software come Adobi partner di traduzione. Si consiglia di ospitare questi pacchetti in un repository remoto e di farvi riferimento in pom.xml. Questo è possibile per i repository pubblici e anche per i repository privati con protezione tramite password, come descritto in repository protetti tramite password .

Se non è possibile memorizzare il pacchetto in un archivio remoto, i clienti possono inserirlo in un archivio Maven locale basato su file system, che viene impegnato a SCM come parte del progetto e a cui fanno riferimento qualsiasi cosa dipenda da esso. Il repository è dichiarato nei programmi di progetto illustrati di seguito:

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Tutti i pacchetti di terze parti inclusi devono essere conformi al AEM come linee guida di codifica del servizio di Cloud Service e di imballaggio descritte in questo articolo, altrimenti la sua inclusione comporterà un errore di distribuzione.

Il seguente snippet XML Maven POM mostra come incorporare i pacchetti di terze parti nel pacchetto “Container” del progetto, in genere denominato “all”, tramite la configurazione del plug-in Maven filevault-package-maven-plugin.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <subPackages>
           
          <!-- Include the application's ui.apps and ui.content packages -->
          ...
 
          <!-- Include any other extra packages such as AEM WCM Core Components -->
          <!-- Set the version for all dependencies, including 3rd party packages, in the project's Reactor POM -->
          <subPackage>
              <groupId>com.adobe.cq</groupId>
              <artifactId>core.wcm.components.all</artifactId>
              <filter>true</filter>
          </subPackage>
 
 
          <subPackage>
              <groupId>com.3rdparty.groupId</groupId>
              <artifactId>core.3rdparty.artifactId</artifactId>
              <filter>true</filter>
          </subPackage>
      <subPackages>
  </configuration>
</plugin>
...

Funzionamento delle implementazioni continue

Come AEM aggiornamenti, i rilasci dei clienti vengono distribuiti utilizzando una strategia di implementazione continua per eliminare i tempi di inattività del cluster di autori nelle circostanze giuste. La sequenza generale degli eventi è come descritto di seguito, dove Blue è la vecchia versione del codice cliente e Green è la nuova versione. Blu e Verde eseguono la stessa versione del codice AEM.

• La versione blu è attiva e un candidato per la release per Green è costruito e disponibile
• In presenza di definizioni di indice nuove o aggiornate, vengono elaborati gli indici corrispondenti. Nella distribuzione blu verranno sempre utilizzati i vecchi indici, mentre in verde verranno sempre utilizzati i nuovi indici.
• Il verde sta iniziando mentre il blu sta ancora servendo
• Blue è in esecuzione e servire mentre Green è controllato per la disponibilità tramite controlli di integrità
• Nodi verdi che sono pronti ad accettare il traffico e sostituire i nodi blu, che vengono ridotti
• Nel corso del tempo, i nodi blu vengono sostituiti da nodi verdi fino a quando non rimane solo verde, completando così la distribuzione
• Qualsiasi contenuto nuovo o modificato modificabile distribuito

Indici

Gli indici nuovi o modificati causeranno un ulteriore passaggio di indicizzazione o reindicizzazione prima che la nuova versione (verde) possa iniziare il traffico. Informazioni dettagliate sulla gestione dell'indice in AEM come Cloud Service sono disponibili in questo articolo. Puoi controllare lo stato del processo di indicizzazione nella pagina di compilazione di Cloud Manager e riceverai una notifica quando la nuova versione sarà pronta per il traffico.

Al momento, AEM come Cloud Service non funziona con strumenti di gestione degli indici come lo strumento ACS Commons Assicurare l'indice Oak.

Replica

Il meccanismo di pubblicazione è compatibile con le AEM API Java di replica.

Per sviluppare e testare la replica con il servizio di avvio rapido AEM cloud, le funzionalità di replica classica devono essere utilizzate con un’impostazione Autore/Pubblicazione. Nel caso in cui il punto di ingresso dell'interfaccia utente su AEM Author sia stato rimosso per il cloud, gli utenti passavano a http://localhost:4502/etc/replication per la configurazione.

Codice compatibile con le versioni precedenti per installazioni continue

Come indicato in precedenza, AEM come strategia di implementazione flusso implica che sia le versioni precedenti che quelle nuove possono funzionare contemporaneamente. Di conseguenza, prestate attenzione alle modifiche del codice che non sono compatibili con la versione precedente AEM che è ancora operativa.

Inoltre, la vecchia release deve essere testata per verificare la compatibilità con eventuali nuove strutture di contenuto modificabili applicate dalla nuova release in caso di rollback, dal momento che il contenuto modificabile non viene rimosso.

Utenti del servizio e modifiche ACL

La modifica degli utenti di servizi o degli ACL necessari per accedere al contenuto o al codice potrebbe causare errori nelle versioni AEM precedenti, con conseguente accesso a tale contenuto o codice con utenti di servizi non aggiornati. Per risolvere questo problema, una raccomandazione consiste nell'apportare modifiche distribuite su almeno 2 rilasci, con la prima release che funge da ponte prima di essere ripulita nella release successiva.

Modifiche indice

Se vengono apportate modifiche agli indici, è importante che la versione Blu continui a utilizzare i relativi indici fino a quando non viene terminata, mentre la versione Verde utilizza il proprio set modificato di indici. Lo sviluppatore deve seguire le tecniche di gestione dell'indice descritte in questo articolo.

Codifica conservativa per rollback

Se un errore viene segnalato o rilevato dopo la distribuzione, è possibile che sia necessario eseguire il rollback alla versione Blu. Sarebbe opportuno garantire che il codice blu sia compatibile con tutte le nuove strutture create dalla versione verde, in quanto le nuove strutture (eventuali contenuti modificabili) non verranno ripristinate. Se il codice precedente non è compatibile, è necessario applicare delle correzioni nelle versioni successive del cliente.

Modalità di esecuzione

Nelle soluzioni AEM esistenti, i clienti possono eseguire le istanze con modalità di esecuzione arbitrarie e applicare la configurazione OSGI o installare i bundle OSGI a tali istanze specifiche. Le modalità di esecuzione definite in genere includono il servizio (autore e pubblicazione) e l'ambiente (dev, stage, prod).

AEM come Cloud Service, invece, è più opinabile su quali modalità di esecuzione sono disponibili e su come possono essere mappati i bundle OSGI e la configurazione OSGI:

• Le modalità di esecuzione della configurazione OSGI devono fare riferimento a dev, stage, prod per l’ambiente o l’autore, publish per il servizio. È supportata una combinazione di <service>.<environment_type>, che devono essere utilizzate in questo ordine particolare (ad esempio author.dev o publish.prod). I token OSGI devono essere citati direttamente dal codice anziché mediante il metodo getRunModes, che non includerà più il environment_type in fase di esecuzione. Per ulteriori informazioni, vedere Configurazione di OSGi per AEM come Cloud Service.
• Le modalità di esecuzione dei bundle OSGI sono limitate al servizio (autore, pubblicazione). I bundle OSGI per modalità di esecuzione devono essere installati nel pacchetto di contenuto in install/author o install/publish.

Come per le soluzioni AEM esistenti, non è possibile utilizzare le modalità di esecuzione per installare solo contenuti per ambienti o servizi specifici. Se si desidera generare un ambiente di sviluppo con dati o HTML non presenti sul palco o sulla produzione, è possibile utilizzare il gestore pacchetti.

Le configurazioni di modalità di esecuzione supportate sono:

• config (l'impostazione predefinita si applica a tutti i servizi AEM)
• config.author (applicabile a tutti i servizi AEM Author)
• config.author.dev (si applica al servizio Dev Author AEM)
• config.author.stage (applicabile a AEM servizio di creazione temporanea)
• config.author.prod (applicabile al servizio Production Author AEM)
• config.publish (applicabile al servizio AEM Publish)
• config.publish.dev (si applica al servizio Dev Publish AEM)
• config.publish.stage (applicabile a AEM servizio pubblicazione temporanea)
• config.publish.prod (applicabile a AEM servizio di pubblicazione produzione)
• config.dev (*Si applica ai servizi AEM Dev)
• config.stage (*Si applica ai servizi di gestione AEM stato)
• config.prod (*Si applica ai servizi di produzione AEM)

Viene utilizzata la configurazione OSGI con le modalità di esecuzione più corrispondenti.

Quando si sviluppa localmente, è possibile passare un parametro di avvio in modalità di esecuzione per stabilire quale configurazione OSGI in modalità di esecuzione verrà utilizzata.

Configurazione delle attività di manutenzione nel controllo del codice sorgente

Le configurazioni delle attività di manutenzione devono essere mantenute nel controllo del codice sorgente, dal momento che la schermata Strumenti > Operazioni non sarà più disponibile negli ambienti Cloud. Questo ha il vantaggio di garantire che i cambiamenti siano intenzionalmente persistenti piuttosto che reattivamente applicati e forse dimenticati. Per ulteriori informazioni, fare riferimento all'articolo Attività di manutenzione.