Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Domini tecnici
Questa sezione offre una panoramica dei principali domini tecnologici per la containerizzazione. Il diagramma seguente mostra l'architettura di un'applicazione Java EE tradizionale.
Il diagramma seguente mostra l'architettura di un'applicazione Java EE containerizzata.
1. Stato della sessione
Nella maggior parte dei casi, le applicazioni Java EE archiviano i dati della sessione associati alle richieste degli utenti, come i cookie per i servlet e le sessioni di stato di Enterprise Java Beans (EJB). Ti consigliamo di evitare di archiviare informazioni sullo stato nella memoria della macchina virtuale Java (JVM) perché il container deve essere mantenuto stateless. Per ulteriori informazioni sul principio di disponibilità, consulta la sezione Principi di progettazione di applicazioni basate su container
Il meccanismo di replica della memoria presuppone che nel cluster esista sempre un determinato set di server oppure che un numero limitato di server si unisca o esca dal cluster. Questo non è compatibile con un ambiente container, pertanto ti consigliamo di eliminare il meccanismo di replica della memoria. In un ambiente container, i server delle applicazioni vengono ridistribuiti quando viene creata una nuova versione dell'immagine container. In altre parole, vengono cancellati anche tutti i dati di memoria replicati.
2. Agenti
Esistono più processi agente in esecuzione su un singolo server fisico o virtuale che in genere eseguono attività di automazione e utilità, come le seguenti:
-
Monitoraggio: gli ambienti applicativi Java EE tradizionali utilizzano spesso agenti dedicati per il monitoraggio. Questi agenti sono responsabili del monitoraggio della CPU del server, della memoria, dell'utilizzo del disco, dell'utilizzo della memoria all'interno della JVM, dei messaggi di registro e altro ancora. Tuttavia, non è possibile eseguire direttamente gli agenti di monitoraggio in un ambiente container. È necessario sostituire gli agenti di monitoraggio con il meccanismo di monitoraggio fornito dalla piattaforma container, come Amazon CloudWatch e Amazon CloudWatch Logs.
-
Lavori (attività pianificate): negli ambienti applicativi Java EE tradizionali, l'ambiente di esecuzione dei process risiede spesso sullo stesso server del server delle applicazioni ed è responsabile dei processi batch a esecuzione prolungata, oltre alle richieste degli utenti. Ad esempio, il processo batch controllato dal controller di processo accede al database per recuperare dati e creare un report. Poiché questi carichi di lavoro multipli non possono coesistere in un ambiente container, è necessario creare l'ambiente di esecuzione dei lavori e dei batch separatamente dall'ambiente container.
-
Trasferimento file: gli agenti di trasferimento file in genere non sono così comuni negli ambienti applicativi Java EE, ma a volte vengono eseguiti sullo stesso sistema operativo con l'applicazione Java come processo indipendente per lo scambio di file da o verso applicazioni esterne. Ad esempio, i dati utilizzati da altre applicazioni vengono trasferiti su un file ogni giorno e riportati nel database. Gli agenti di trasferimento file non possono funzionare separatamente dai container, ma devono essere in esecuzione su un altro server che abbia accesso al database e ai file.
3. Server delle applicazioni
La sfida più importante nella containerizzazione è la modifica dei server delle applicazioni. I server delle applicazioni tradizionali conformi a Java EE presuppongono un ambiente di calcolo statico, quindi potrebbero non essere adatti per l'esecuzione in un ambiente container. In altre parole, si presuppone che i server fisici o virtuali siano l'entità dell'ambiente di calcolo per le applicazioni Java EE. Ad esempio, i server applicativi Java EE proprietari, come un tradizionale IBM WebSphere Application Server (TWAS) e Oracle WebLogic Server, dispongono di un proprio meccanismo di distribuzione delle applicazioni.
La situazione è diversa in un ambiente container. In questo ambiente, i container includono un server delle applicazioni e un runtime con pacchetti di compilazione dell'applicazione (ad esempio file .war e .jar) e vengono distribuiti su piattaforme container come Amazon ECS o Amazon EKS. Ti consigliamo di utilizzare un meccanismo di piattaforma container per distribuire le applicazioni negli ambienti. I server delle applicazioni vengono spesso distribuiti con container, quindi devono essere di piccole dimensioni (inferiori a 500 MB) e veloci da avviare. Per soddisfare questo requisito, potrebbe essere necessario modificare il server delle applicazioni tradizionale ed eseguire la migrazione a un server delle applicazioni più adatto ai container. Ciò potrebbe richiedere una migrazione da IBM WebSphere Application Server a IBM WebSphere Liberty o JBoss Enterprise Application Platform (EAP) a. WildFly
Ti consigliamo di prendere in considerazione i seguenti impatti che possono derivare dalla modifica di un server delle applicazioni:
-
Inserimento della configurazione tramite variabili ambiente (a differenza delle tradizionali applicazioni Java EE che memorizzano le configurazioni in un file, come web.xml)
-
Compatibilità con le funzionalità di Java EE
-
Versioni JVM
4. Archivio di file
L'archivio di file più comunemente utilizzato per le applicazioni Java EE tradizionali è il file system locale. I casi d'uso più comuni includono i file di log delle applicazioni, i file generati dall'applicazione come i report aziendali e i contenuti caricati dagli utenti. Ti consigliamo di evitare di archiviare i file all'interno dei container perché questi sono stateless, il che significa che gli archivi di file devono essere esternalizzati per la containerizzazione.
Ti consigliamo di prendere in considerazione le opzioni di containerizzazione seguenti:
-
Amazon Elastic File System (Amazon EFS): Amazon EFS è un servizio NFS gestito accessibile dai container. Amazon EFS è integrato con Amazon ECS e Amazon EKS. Se usi Amazon EFS, non è necessario scrivere script personalizzati per montare volumi EFS nei tuoi container. Il primo passaggio di questa opzione consiste nell'elencare tutti i percorsi del file system dell'applicazione utilizzati per la lettura o la scrittura. Dopo aver identificato il percorso del file system da rendere persistente, puoi mappare il percorso del file system a un percorso del file system EFS. Per ulteriori informazioni, consulta la sezione Tutorial: utilizzo dei file system Amazon EFS con Amazon ECS nella documentazione di Amazon ECS. Non è necessario che tutti i percorsi siano resi persistenti, in particolare i file di log delle applicazioni. La maggior parte delle applicazioni aziendali scrive i file di log in un file system locale. Come parte del processo di containerizzazione, ti consigliamo di prendere in considerazione la possibilità di modificare la destinazione di registrazione utilizzando Standard Out e Standard Error. Ciò consente di acquisire tutto l'output in CloudWatch Logs senza gestire le dimensioni e le prestazioni dello storage dei log. Per ulteriori informazioni sulla registrazione in Amazon ECS, consulta la sezione Utilizzo del driver di log awslogs nella documentazione di Amazon ECS.
-
Amazon Simple Storage Service (Amazon S3): Amazon S3 è meno costoso di Amazon EFS e supporta una larghezza di banda più ampia rispetto ad Amazon EFS, ma Amazon S3 richiede una modifica del codice dell'applicazione più ampia rispetto ad Amazon EFS. Questo perché Amazon S3 non è un file system.
5. Processo di creazione e implementazione
Il processo di containerizzazione prevede la modifica e l'estensione del processo di implementazione delle applicazioni. Negli ambienti tradizionali, il processo di implementazioni delle applicazioni coinvolge principalmente artefatti Java (ad esempio, file .war e .ear). In un ambiente container, l'immagine del container è l'unità di distribuzione. Oltre al processo per la creazione di artefatti Java esistenti, è necessario creare un processo per la creazione e la distribuzione di container Docker. Per ulteriori informazioni sul processo di pipeline, consulta Creare e distribuire automaticamente un'applicazione Java in Amazon EKS utilizzando una pipeline CI/CD nella documentazione Prescriptive Guidance. AWS
6. Accesso al database
Le containerizzazioni delle applicazioni tradizionali sono spesso accompagnate dalla migrazione del database. Per ridurre il rischio di migrazione, consigliamo di seguire la strategia di migrazione per i database relazionali (Prescriptive Guidance).AWS Gli ambienti containerizzati richiedono una configurazione esternalizzata, comprese le stringhe di connessione al database. È possibile utilizzare strumenti come Spring Cloud Config
