Implementazione in AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Introduzione introduction

Le basi dello sviluppo del codice sono simili in AEM as a Cloud Service rispetto alle soluzioni AEM On Premise e Managed Services. Gli sviluppatori scrivono e testano localmente il codice, che viene quindi inviato agli ambienti AEM as a Cloud Service remoti. Cloud Manager, che era uno strumento opzionale per la distribuzione dei contenuti per Managed Services, è necessario. Questo è ora l’unico meccanismo per implementare il codice negli ambienti di produzione, staging e sviluppo di AEM as a Cloud Service. Per la convalida rapida delle funzionalità e il debug prima della distribuzione di tali ambienti, il codice può essere sincronizzato da un ambiente locale a un ambiente di sviluppo rapido.

L’aggiornamento della Versione AEM è sempre un evento di distribuzione separato dal push del codice personalizzato. In alternativa, le versioni del codice personalizzato devono essere testate rispetto alla versione di AEM in produzione, perché è su tale versione che viene distribuito. Gli aggiornamenti delle versioni di AEM che avvengono dopo di che (che sono frequenti e vengono applicati automaticamente) sono intesi per essere compatibili con le versioni precedenti del codice cliente già distribuito.

Il resto di questo documento descrive come gli sviluppatori adattano le loro pratiche per lavorare sia con gli aggiornamenti della versione di AEM as a Cloud Service che con gli aggiornamenti dei clienti.

Versioni dei clienti customer-releases

Codifica rispetto alla versione AEM corretta coding-against-the-right-aem-version

Per le soluzioni AEM precedenti, la versione di AEM veniva modificata raramente e i clienti aggiornavano le istanze di produzione all’avvio rapido più recente, facendo riferimento al file Jar dell’API. Tuttavia, le applicazioni AEM as a Cloud Service vengono aggiornate automaticamente alla versione più recente di AEM più spesso, pertanto il codice personalizzato per le versioni interne deve essere generato in base alla versione AEM più recente.

Come per le versioni esistenti di AEM non cloud, è supportato lo sviluppo locale e offline basato su un avvio rapido specifico, che in genere dovrebbe essere lo strumento principale per il debug.

Al fine di sviluppare un codice personalizzato per una versione interna, deve essere scaricata e installata la versione pertinente di SDK di AEM as a Cloud Service. Per ulteriori informazioni sull’utilizzo degli strumenti Dispatcher di AEM as a Cloud Service, vedere Dispatcher nel cloud.

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

Distribuzione di pacchetti di contenuti tramite Cloud Manager e Gestione pacchetti deploying-content-packages-via-cloud-manager-and-package-manager

Distribuzioni tramite Cloud Manager deployments-via-cloud-manager

I clienti distribuiscono il codice personalizzato agli ambienti cloud tramite Cloud Manager. Cloud Manager trasforma i pacchetti di contenuti assemblati localmente in un artefatto conforme al modello di funzione Sling. Questo modello descrive un’applicazione su AEM as a Cloud Service in esecuzione in un ambiente cloud. Di conseguenza, quando si esaminano i pacchetti nel Gestore di pacchetti negli ambienti cloud, il nome includerà “cp2fm” e nei pacchetti trasformati saranno rimossi tutti i metadati. Non è possibile interagire con questi elementi, ovvero non è possibile scaricarli, replicarli o aprirli. Per la documentazione dettagliata sul convertitore, vedi sling-org-apache-sling-feature-cpconverter su GitHub.

I pacchetti di contenuti per AEM as a Cloud Service devono separare il contenuto immutabile da quello mutabile. Cloud Manager installa solo il contenuto mutabile e restituisce un messaggio come il seguente:

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 immutabe-content-packages

Tutti i contenuti e il codice mantenuti nell’archivio immutabile devono essere controllati in git 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 flusso di lavoro assicura che il codice in esecuzione per una determinata versione in qualsiasi ambiente Cloud sia identico, eliminando il rischio di variazione involontaria del codice in 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.

Uno switch abilita le modifiche dell’applicazione dovute al modello di distribuzione, pertanto non possono dipendere da modifiche nell’archivio mutabile, ad eccezione degli utenti del servizio, dei relativi ACL, tipi di nodo e modifiche alla definizione dell’indice.

Per i clienti con basi di codice esistenti, è fondamentale seguire l’esercizio di ristrutturazione dell’archivio descritto nella documentazione di AEM per garantire che il contenuto che si trovava in /etc venga spostato nella posizione giusta.

Per questi pacchetti di codice si applicano alcune restrizioni aggiuntive, ad esempio hook di installazione non supportati.

Configurazione OSGI osgi-configuration

Come accennato in precedenza, la configurazione OSGI deve essere impegnata nel controllo del codice sorgente anziché attraverso la console web. Le tecniche per farlo includono:

Ulteriori informazioni sulla configurazione OSGI in Configurazione OSGi per AEM as a Cloud Service.

Contenuto modificabile mutable-content

A volte è utile preparare le modifiche al contenuto nel controllo del codice sorgente in modo che Cloud Manager le distribuisca ogni volta che un ambiente viene aggiornato. Ad esempio, è ragionevole eseguire il seeding di determinate strutture di cartelle principali. Per abilitare i componenti dei criteri aggiornati dall’implementazione dell’applicazione, allineare le modifiche nei modelli modificabili.

Cloud Manager distribuisce i contenuti nell’archivio modificabile utilizzando due strategie: pacchetti di contenuti modificabili e istruzioni repoinit.

Pacchetti di contenuti modificabili mutable-content-packages

Contenuti come gerarchie di percorsi di cartelle, utenti di servizi e controlli di accesso (ACL) vengono generalmente salvati in un progetto AEM basato su un archetipo maven. Le tecniche includono l’esportazione da AEM o la scrittura diretta come XML. Durante il processo di creazione e distribuzione, Cloud Manager crea un pacchetto con il pacchetto di contenuti mutabili risultante. Il contenuto mutabile viene installato in momenti diversi, durante la fase di distribuzione nella pipeline:

Prima dell’avvio della nuova versione dell’applicazione:

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

Dopo il passaggio alla nuova versione dell’applicazione:

È possibile limitare l’installazione di contenuti mutabili all’authoring o alla pubblicazione incorporando i pacchetti in una cartella install.author o install.publish in /apps. La ristrutturazione per riflettere questa separazione è stata eseguita in AEM 6.5 e i dettagli sulla ristrutturazione del progetto consigliata sono disponibili nella documentazione di AEM 6.5.

Inoltre, non esiste alcun meccanismo per eseguire il rollback delle modifiche del pacchetto di contenuti mutabili dopo la loro applicazione. Se i clienti rilevano un problema, possono scegliere di correggerlo nella versione successiva del codice o, come ultima risorsa, ripristinare l’intero sistema in un punto temporale prima della distribuzione.

Eventuali pacchetti di terze parti inclusi devono essere convalidati come compatibili con AEM as a Cloud Service; in caso contrario, la loro inclusione si traduce in un errore di distribuzione.

Come accennato in precedenza, i clienti con basi di codice esistenti si conformano all’esercizio di ristrutturazione dell’archivio necessario per le modifiche dell’archivio 6.5 descritte nella documentazione di AEM 6.5.

Repoinit repoinit

Nei casi seguenti, è preferibile adottare l’approccio della codifica manuale delle istruzioni repoinit per la creazione di contenuti espliciti nelle configurazioni di fabbrica OSGI:

Repoinit è preferibile per questi casi d’uso di modifica del contenuto supportati grazie ai seguenti vantaggi:

Quando Cloud Manager implementa l’applicazione, esegue queste istruzioni, indipendentemente dall’installazione di eventuali pacchetti di contenuti.

Per creare repoinit istruzioni:

Maggiori dettagli su repoinit sono disponibili nella documentazione Sling

Gestione pacchetti: una tantum per pacchetti di contenuti mutabili package-manager-oneoffs-for-mutable-content-packages

In alcuni casi un pacchetto di contenuti deve essere installato come un’installazione “una tantum”. Ad esempio, per eseguire il debug di un problema di produzione, è necessario importare contenuto specifico dalla produzione allo staging. Per questi scenari, è possibile utilizzare il Gestore di pacchetti in ambienti AEM as a Cloud Service.

Gestione pacchetti è un concetto di runtime. Non è possibile installare contenuto o codice nell’archivio immutabile e questi pacchetti di contenuti sono costituiti da contenuto mutabile (principalmente /content o /conf). Se il pacchetto di contenuti include contenuti misti (con contenuto mutabile e immutabile), verrà installato solo il contenuto mutabile.

Tutte le installazioni di Cloud Manager con pacchetti di contenuti (sia mutabili che immutabili) vengono visualizzate come bloccate nell’interfaccia utente di AEM Package Manager. Questi pacchetti non possono essere reinstallati, ricostruiti o scaricati e sono elencati con un suffisso “cp2fm”, che indica che Cloud Manager ha eseguito l’installazione.

Inclusione di pacchetti di terze parti including-third-party

È comune per la clientela includere pacchetti predefiniti da fonti terze, ad esempio fornitori di software come i partner di traduzione di Adobe. Si consiglia di ospitare questi pacchetti in un archivio remoto e farvi riferimento in pom.xml. Questo è possibile per gli archivi pubblici e anche per quelli privati con protezione tramite password, come descritto in archivi maven protetti da 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 è impegnato in SCM come parte del progetto. Qualunque cosa dipenda da essa, fa riferimento ad essa. L’archivio viene dichiarato nel pom del progetto come illustrato 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 rispettare le linee guida di codifica e creazione pacchetti di AEM as a Cloud Service descritte in questo articolo, altrimenti la loro inclusione si traduce in un errore di distribuzione.

Il seguente POM.xml snippet Maven mostra come incorporare i pacchetti di terze parti nel pacchetto “Contenitore” del progetto, in genere denominato “tutti”, 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>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Funzionamento delle distribuzioni continue how-rolling-deployments-work

Come per gli aggiornamenti AEM, le versioni dei clienti e delle clienti vengono distribuite utilizzando una strategia di distribuzione continua per eliminare i tempi di inattività dei cluster di authoring nelle giuste circostanze. La sequenza generale di eventi è descritta di seguito, dove i nodi con la versione precedente e nuova del codice del cliente eseguono la stessa versione del codice AEM.

Indici indexes

Gli indici nuovi o modificati causeranno un ulteriore passaggio di indicizzazione o reindicizzazione prima che la nuova versione possa assumere traffico. I dettagli sulla gestione degli indici in AEM as a Cloud Service sono disponibili in Ricerca e indicizzazione dei contenuti. Puoi controllare lo stato di indicizzazione delle pagine della build in Cloud Manager e ricevere una notifica quando la nuova versione è pronta per il traffico.

Al momento, AEM as a Cloud Service non funziona con strumenti di gestione degli indici come lo strumento indice Oak di ACS Commons Ensure.

Replica replication

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

Per sviluppare e testare la replica utilizzando il modulo quickstart di AEM pronto per il cloud, utilizza le funzionalità di replica classiche con una configurazione Author/Publish. Se il punto di ingresso dell’interfaccia utente in AEM Author viene rimosso per il cloud, gli utenti passano a http://localhost:4502/etc/replication per la configurazione.

Codice compatibile con le versioni precedenti per le distribuzioni continue backwards-compatible-code-for-rolling-deployments

Come descritto in precedenza, la strategia di distribuzione continua di AEM as a Cloud Service implica che sia la vecchia che la nuova versione funzionino contemporaneamente. Pertanto, presta attenzione alle modifiche al codice che non sono compatibili con le versioni precedenti della vecchia versione di AEM ancora operativa.

Inoltre, la vecchia versione deve essere testata per verificare la compatibilità con eventuali nuove strutture di contenuto mutabile applicate dalla nuova versione in caso di rollback, in quanto il contenuto mutabile non viene rimosso.

Utenti del servizio e modifiche ACL service-users-and-acl-changes

La modifica degli utenti del servizio, o degli ACL che accedono al contenuto o al codice, genera errori nelle versioni precedenti di AEM, che determinano l’accesso a tale contenuto o codice da parte di utenti del servizio obsoleti. Per risolvere questo problema, la raccomandazione consiste nell’apportare modifiche distribuite su almeno due versioni, con la prima versione che funge da ponte prima di essere ripulita nella versione successiva.

Modifiche all’indice index-changes

Se vengono apportate modifiche agli indici, è importante che la vecchia versione continui a utilizzare i suoi indici fino a quando non viene terminata, mentre la nuova versione utilizza il proprio set modificato di indici. Lo sviluppatore segue le tecniche di gestione dell’indice descritte in Ricerca e indicizzazione dei contenuti.

Codifica conservativa per i rollback conservative-coding-for-rollbacks

Se viene segnalato o rilevato un errore dopo l’implementazione, è possibile che sia necessario eseguire il rollback per ripristinare la versione precedente. È consigliato garantire che il nuovo codice sia compatibile con tutte le nuove strutture create dalla nuova versione, in quanto le nuove strutture (qualsiasi contenuto mutabile) non subiranno ripristini. Se il codice precedente non è compatibile, le correzioni dovranno essere applicate nelle versioni successive del cliente.

Ambienti di sviluppo rapido (RDE) rde

Gli ambienti di sviluppo rapido (o RDE) consentono agli sviluppatori di distribuire e rivedere rapidamente le modifiche. In questo modo si riduce al minimo il tempo necessario per testare le funzionalità già collaudate in un ambiente di sviluppo locale.

A differenza degli ambienti di sviluppo regolari, che distribuiscono il codice tramite la pipeline di Cloud Manager, gli sviluppatori utilizzano gli strumenti della riga di comando per sincronizzare il codice da un ambiente di sviluppo locale agli RDE. Dopo aver testato correttamente le modifiche in un RDE, implementale in un ambiente di sviluppo Cloud regolare tramite la pipeline di Cloud Manager, che inserisce il codice attraverso i gate di qualità appropriati.

Modalità di esecuzione runmodes

Nelle soluzioni AEM esistenti, i clienti possono eseguire istanze con modalità di esecuzione arbitrarie e applicare la configurazione OSGI o installare bundle OSGI a tali istanze specifiche. Le modalità di esecuzione definite includono solitamente il servizio (authoring e pubblicazione) e l’ambiente (RDE, sviluppo, staging, produzione).

AEM as a Cloud Service d’altra parte è più rigoroso su quali modalità di esecuzione sono disponibili e come i bundle OSGI e la configurazione OSGI possono essere mappati su di esse:

AEM as a Cloud Service non consente di utilizzare le modalità di esecuzione per installare contenuti per ambienti o servizi specifici. Se è necessario impostare un ambiente di sviluppo con dati o HTML non presenti negli ambienti di staging o di produzione, è possibile utilizzare Gestore di pacchetti.

Le configurazioni supportate per la modalità di esecuzione sono:

Viene utilizzata la configurazione OSGI dotata di modalità di esecuzione che hanno maggiore corrispondenza.

Quando viene sviluppato localmente, un parametro di avvio in modalità di esecuzione, -r, viene utilizzato per specificare la configurazione OSGI in modalità di esecuzione.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Configurazione delle attività di manutenzione nel controllo del codice sorgente maintenance-tasks-configuration-in-source-control

Le configurazioni delle attività di manutenzione devono essere persistenti nel controllo del codice sorgente, poiché la schermata Strumenti > Operazioni non sarà più disponibile negli ambienti Cloud. Questo vantaggio assicura che i cambiamenti siano persistenti intenzionalmente piuttosto che applicati e dimenticati in modo reattivo. Per ulteriori informazioni, vedere Attività di manutenzione in AEM as a Cloud Service.