Informazioni sulla multitenanza e lo sviluppo simultaneo

Introduzione

Quando più team distribuiscono il proprio codice negli stessi ambienti AEM, esistono delle pratiche che devono seguire per garantire che i team possano lavorare nel modo più indipendente possibile, senza utilizzare le dita dei piedi degli altri team. Anche se non possono mai essere eliminati completamente, queste tecniche ridurranno le dipendenze tra i team. Affinché un modello di sviluppo concorrente abbia successo, è fondamentale una buona comunicazione tra i team di sviluppo.

Inoltre, quando più team di sviluppo lavorano sullo stesso ambiente AEM, è probabile che vi sia un certo grado di multi-tenancy in gioco. Molto è stato scritto sulle considerazioni pratiche relative al tentativo di supportare più tenant in un ambiente AEM, specialmente riguardo alle sfide che devono affrontare la gestione della governance, le operazioni e lo sviluppo. Questo documento illustra alcune delle problematiche tecniche relative all’implementazione di AEM in un ambiente multi-tenant, ma molti di questi consigli verranno applicati a qualsiasi organizzazione con più team di sviluppo.

È importante notare in anticipo che, sebbene AEM possa supportare più siti e anche più marchi implementati in un singolo ambiente, non offre una vera e propria multi-tenancy. Alcune configurazioni di ambiente e risorse di sistema saranno sempre condivise tra tutti i siti distribuiti in un ambiente. Il presente documento fornisce orientamenti per ridurre al minimo l'impatto di tali risorse condivise e offre suggerimenti per razionalizzare la comunicazione e la collaborazione in questi settori.

Vantaggi e sfide

L’implementazione di un ambiente multi-tenant comporta molte sfide.

Comprendono:

  • Complessità tecnica aggiuntiva
  • Maggiore sovraccarico per lo sviluppo
  • Dipendenze tra organizzazioni sulla risorsa condivisa
  • Maggiore complessità operativa

Nonostante le sfide, l’esecuzione di un’applicazione multi-tenant presenta vantaggi quali:

  • Riduzione dei costi hardware
  • Riduzione dei tempi di commercializzazione per i siti futuri
  • Riduzione dei costi di implementazione per i futuri locatari
  • Architettura standard e pratiche di sviluppo in tutta l'azienda
  • Una base di codice comune

Se l'azienda richiede una vera e propria multi-tenant, senza alcuna conoscenza di altri tenant e senza codice condiviso, contenuti o autori comuni, le istanze di authoring separate sono l'unica opzione possibile. L'aumento complessivo dello sforzo di sviluppo va confrontato con il risparmio dei costi di infrastruttura e licenze per determinare se questo approccio è il migliore.

Tecniche di sviluppo

Gestione delle dipendenze

Quando gestisci le dipendenze dei progetti Maven, è importante che tutti i team utilizzino la stessa versione di un determinato bundle OSGi sul server. Per illustrare cosa può andare storto quando i progetti Maven sono mal gestiti, vi presentiamo un esempio:

Il progetto A dipende dalla versione 1.0 della libreria, foo; la versione 1.0 di foo è incorporata nella relativa distribuzione al server. Il progetto B dipende dalla versione 1.1 della libreria, foo; la versione 1.1 di foo è incorporata nella relativa implementazione.

Inoltre, supponiamo che in questa libreria sia stata modificata un’API tra le versioni 1.0 e 1.1. A questo punto, uno di questi due progetti non funzionerà più correttamente.

Per risolvere questo problema, si consiglia di fare di tutti i progetti Maven figli di un progetto di reattore principale. Questo progetto di reattore ha due finalità: consente la costruzione e la realizzazione di tutti i progetti insieme, se lo desiderano, e contiene le dichiarazioni di dipendenza per tutti i progetti figlio. Il progetto padre definisce le dipendenze e le loro versioni, mentre i progetti figlio dichiarano solo le dipendenze necessarie, ereditando la versione dal progetto padre.

In questo scenario, se il team che lavora sul Progetto B richiede funzionalità nella versione 1.1 di foo, diventerà rapidamente evidente nell’ambiente di sviluppo che questa modifica interromperà il Progetto A. A questo punto i team possono discutere questa modifica e rendere il Progetto A compatibile con la nuova versione oppure cercare una soluzione alternativa per il Progetto B.

Tieni presente che questo non elimina la necessità che questi team condividano questa dipendenza: evidenzia i problemi in modo rapido e tempestivo, in modo che i team possano discutere qualsiasi rischio e concordare una soluzione.

Impedire la duplicazione del codice

Quando lavori su più progetti, è importante garantire che il codice non sia duplicato. La duplicazione del codice aumenta la probabilità di eventi difettosi, il costo delle modifiche al sistema e la rigidità complessiva nella base di codice. Per evitare duplicazioni, reimposta la logica comune nelle librerie riutilizzabili che possono essere utilizzate in più progetti.

Per soddisfare questa esigenza, consigliamo lo sviluppo e la manutenzione di un progetto di base a cui tutti i team possono dipendere e a cui possono contribuire. In tale contesto, è importante garantire che questo progetto fondamentale non dipenda, a sua volta, da nessuno dei progetti dei singoli team; questo consente una distribuzione indipendente e continua a promuovere il riutilizzo del codice.

Alcuni esempi di codice comunemente presenti in un modulo core includono:

  • Configurazioni a livello di sistema quali:
    • Configurazioni OSGi
    • Filtri servlet
    • Mappature ResourceResolver
    • Trasformatori Sling
    • Gestori di errori (o utilizza il gestore pagina di errore ACS AEM Commons1)
    • Servlet di autorizzazione per la memorizzazione in cache sensibile alle autorizzazioni
  • Classi di utilità
  • Logica aziendale di base
  • Logica dell’integrazione di terze parti
  • Sovrapposizioni dell’interfaccia utente di authoring
  • Altre personalizzazioni necessarie per l’authoring, ad esempio widget personalizzati
  • Lancio dei flussi di lavoro
  • Elementi di progettazione comuni utilizzati tra siti diversi

Architettura dei progetti modulari

Questo non elimina la necessità che più team dipendano da e possano aggiornare lo stesso set di codice. Creando un progetto di base, abbiamo ridotto le dimensioni della base di codice condivisa tra i team, diminuendo ma senza eliminare la necessità di risorse condivise.

Per garantire che le modifiche apportate a questo pacchetto principale non interrompano le funzionalità del sistema, si consiglia a uno sviluppatore senior o a un team di sviluppatori di mantenere il controllo. Un'opzione consiste nell'avere un unico team che gestisce tutte le modifiche al pacchetto; un altro consiste nell’richiedere ai team di inviare richieste di pull che siano esaminate e unite da queste risorse. È importante che un modello di governance sia progettato e concordato dai team e che gli sviluppatori lo seguano.

Gestione dell'ambito di implementazione

Poiché i diversi team implementano il codice nello stesso archivio, è importante che non sovrascrivano le modifiche reciproche. AEM dispone di un meccanismo per controllare questo aspetto durante la distribuzione dei pacchetti di contenuti, il filtro . file xml. È importante che non vi sia sovrapposizione tra i filtri. file xml, altrimenti la distribuzione di un team potrebbe potenzialmente cancellare la distribuzione precedente di un altro team. Per illustrare questo punto, vedi i seguenti esempi di file di filtro ben elaborati e problematici:

/apps/my-company vs. /apps/my-company/my-site

/etc/clientlibs/my-company vs. /etc/clientlibs/my-company/my-site

/etc/designs/my-company vs. /etc/designs/my-company/my-site

Se ogni team configura in modo esplicito il file di filtro fino al sito o ai siti su cui sta lavorando, ogni team può distribuire i propri componenti, librerie client e progettazioni del sito in modo indipendente senza cancellare le rispettive modifiche.

Poiché si tratta di un percorso di sistema globale e non è specifico per un sito, il seguente servlet deve essere incluso nel progetto principale, in quanto le modifiche apportate in questo caso potrebbero avere un impatto su qualsiasi team:

/apps/sling/servlet/errorhandler

Sovrapposizioni

Le sovrapposizioni vengono spesso utilizzate per estendere o sostituire la funzionalità integrata di AEM, ma l’utilizzo di una sovrapposizione interessa l’intera applicazione AEM (ovvero, eventuali modifiche di funzionalità saranno disponibili per tutti gli tenant). Ciò sarebbe ulteriormente complicato se gli inquilini avessero requisiti diversi per la sovrapposizione. Idealmente, i gruppi aziendali dovrebbero collaborare per concordare la funzionalità e l’aspetto delle console amministrative di AEM.

Se non si riuscirà a raggiungere un consenso tra le varie unità operative, una soluzione possibile sarebbe semplicemente quella di non utilizzare le sovrapposizioni. Al contrario, crea una copia personalizzata della funzionalità ed esporla tramite un percorso diverso per ciascun tenant. Questo consente a ogni tenant di avere un’esperienza utente completamente diversa, ma questo approccio aumenta anche i costi di implementazione e di successive attività di aggiornamento.

Moduli di avvio per flusso di lavoro

AEM utilizza i moduli di avvio del flusso di lavoro per attivare automaticamente l’esecuzione del flusso di lavoro quando vengono apportate modifiche specifiche nell’archivio. AEM fornisce diversi moduli di avvio pronti all’uso, ad esempio, per eseguire processi di generazione del rendering e estrazione dei metadati su risorse nuove e aggiornate. Anche se è possibile lasciare questi lanciatori così come sono, in un ambiente multi-tenant, se gli inquilini hanno diversi requisiti di lanciatore e/o modello di flusso di lavoro, è probabile che i singoli lanciatori dovranno essere creati e mantenuti per ogni tenant. Questi moduli di avvio dovranno essere configurati per eseguire gli aggiornamenti del tenant lasciando intatto il contenuto di altri tenant. Per farlo, puoi applicare i moduli di avvio a percorsi di archivio specifici per i tenant.

URL personalizzati

AEM fornisce funzionalità URL personalizzate che possono essere impostate su base pagina. Il problema di questo approccio in uno scenario multi-tenant è che AEM non garantisce l’univocità tra gli URL personalizzati configurati in questo modo. Se due utenti diversi configurano lo stesso percorso personalizzato per pagine diverse, si può osservare un comportamento imprevisto. Per questo motivo, si consiglia di utilizzare le regole mod_rewrite nelle istanze del dispatcher Apache, che consentono un punto centrale di configurazione insieme alle regole del Resource Resolver in uscita.

Gruppi di componenti

Quando si sviluppano componenti e modelli per più gruppi di authoring, è importante utilizzare in modo efficace le proprietà componentGroup e allowedPaths . Sfruttando in modo efficace queste funzioni con le progettazioni del sito, possiamo garantire che gli autori del marchio A vedano solo i componenti e i modelli creati per il sito, mentre gli autori del marchio B ne visualizzano solo i propri.

Test

Sebbene una buona architettura e canali di comunicazione aperti possano contribuire a prevenire l'introduzione di difetti in aree inaspettate del sito, questi approcci non sono a prova di inganno. Per questo motivo, è importante testare completamente ciò che viene implementato sulla piattaforma prima di rilasciare qualsiasi cosa in produzione. Ciò richiede il coordinamento tra i team sui loro cicli di rilascio e rafforza la necessità di una suite di test automatizzati che coprano il maggior numero possibile di funzionalità. Inoltre, poiché un sistema sarà condiviso da più team, le prestazioni, la sicurezza e il test di caricamento diventano più importanti che mai.

Considerazioni operative

Risorse condivise

AEM funziona all’interno di una singola JVM; tutte le applicazioni AEM implementate condividono le stesse risorse, oltre alle risorse già utilizzate nella normale esecuzione di AEM. Nello spazio JVM stesso non vi sarà alcuna separazione logica dei thread e verranno condivise anche le risorse finite disponibili per AEM, come memoria, CPU e i/o disco. Tutte le risorse che consumano tenant influiranno inevitabilmente sugli altri tenant del sistema.

Spettacolo

Se non segui le best practice di AEM, è possibile sviluppare applicazioni che consumano risorse oltre ciò che viene considerato normale. Esempi di questo sono l’attivazione di molte operazioni pesanti del flusso di lavoro (come DAM Update Asset), l’utilizzo di operazioni di push-on-edit MSM su molti nodi o l’utilizzo di query JCR costose per eseguire il rendering del contenuto in tempo reale. Questi avranno inevitabilmente un impatto sulle prestazioni di altre applicazioni tenant.

Registrazione

AEM fornisce interfacce pronte all’uso per una configurazione affidabile del logger che può essere utilizzata a nostro vantaggio in scenari di sviluppo condivisi. Specificando logger separati per ogni marchio, per nome pacchetto, possiamo ottenere un certo grado di separazione dei log. Mentre le operazioni a livello di sistema come la replica e l’autenticazione verranno ancora registrate in una posizione centrale, il codice personalizzato non condiviso può essere registrato separatamente, facilitando le attività di monitoraggio e debug per il team tecnico di ogni marchio.

Backup e ripristino

A causa della natura dell'archivio JCR, i backup tradizionali funzionano nell'intero archivio, anziché su un singolo percorso di contenuto. Non è quindi possibile separare facilmente i backup per tenant. Al contrario, il ripristino da un backup comporta il rollback dei contenuti e dei nodi dell'archivio per tutti gli tenant del sistema. Mentre è possibile eseguire backup di contenuti mirati, utilizzando strumenti come VLT, o per selezionare il contenuto da ripristinare creando un pacchetto in un ambiente separato, questi
gli approcci non includono facilmente le impostazioni di configurazione o la logica dell’applicazione e possono essere ingombranti da gestire.

Considerazioni sulla sicurezza

ACL

È ovviamente possibile utilizzare gli elenchi di controllo accessi (ACL, Access Control List) per controllare chi ha accesso a visualizzare, creare ed eliminare contenuti in base ai percorsi dei contenuti, il che richiede la creazione e la gestione di gruppi di utenti. La difficoltà di mantenere gli ACL e i gruppi dipende dall'enfasi posta sull'importanza di garantire che ogni tenant abbia zero conoscenze degli altri e se le applicazioni distribuite si basano su risorse condivise. Per garantire un'amministrazione efficiente di ACL, utenti e gruppi, si consiglia di disporre di un gruppo centralizzato con la necessaria sorveglianza per garantire che questi controlli di accesso e entità di protezione si sovrappongano (o non si sovrappongano) in un modo che promuova l'efficienza e la sicurezza.

In questa pagina

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now