Migrazione tra le versioni principali della piattaforma server Windows di Elastic Beanstalk - AWS Elastic Beanstalk

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à.

Migrazione tra le versioni principali della piattaforma server Windows di Elastic Beanstalk

AWS Elastic Beanstalk ha avuto diverse versioni principali della sua piattaforma Windows Server. Questa pagina descrive i miglioramenti più significativi per ogni versione principale e cosa occorre considerare prima di eseguire la migrazione a una versione più recente.

La versione corrente della piattaforma Windows Server è la versione 2 (v2). Se l'applicazione usa qualsiasi versione della piattaforma Windows Server precedente a v2, ti consigliamo di eseguire la migrazione a v2.

Novità delle versioni principali della piattaforma Windows Server

Piattaforma Windows Server V2

La versione 2 (v2) della piattaforma Windows Server di Elastic Beanstalk è stata resa disponibile a febbraio 2019. La versione V2 avvicina il funzionamento della piattaforma Windows Server a quello delle piattaforme basate su Linux di Elastic Beanstalk in molti modi importanti. La versione V2 è completamente compatibile con la versione v1 e questo semplifica la migrazione dalla versione v1.

La piattaforma Windows Server ora supporta quanto segue:

Nota

Le nuove caratteristiche di distribuzione e aggiornamento dipendono dallo stato avanzato. Abilita stato avanzato per utilizzarle. Per informazioni dettagliate, consulta Abilitazione del reporting dello stato avanzato Elastic Beanstalk.

Piattaforma Windows Server V1

La versione 1.0.0 (v1) della piattaforma Windows Server di Elastic Beanstalk è stata resa disponibile a ottobre 2015. Questa versione cambia l'ordine in cui Elastic Beanstalk elabora i comandi nei file di configurazione durante la creazione dell'ambiente e gli aggiornamenti.

Le versioni precedenti della piattaforma non dispongono di un numero di versione nel nome dello stack della soluzione:

  • Windows Server 2012 R2 (64 bit) con IIS 8.5 in esecuzione

  • Windows Server Core 2012 R2 (64 bit) con IIS 8.5 in esecuzione

  • Windows Server 2012 (64 bit) con IIS 8 in esecuzione

  • Windows Server 2008 R2 (64 bit) con IIS 7.5 in esecuzione

Nelle versioni precedenti l'ordine di elaborazione per i file di configurazione è incoerente. Durante la creazione dell'ambiente, Container Commands viene eseguito dopo che il codice sorgente dell'applicazione viene distribuito su IIS. Durante una distribuzione in un ambiente di esecuzione, i comandi del container vengono eseguiti prima della distribuzione della nuova versione. Durante un aumento del dimensionamento, i file di configurazione non vengono elaborati.

Oltre a questo, IIS viene avviato prima dell'esecuzione dei comandi del container. Questo comportamento ha portato alcuni clienti a implementare soluzioni alternative nei comandi dei container, con una pausa del server IIS prima dell'esecuzione dei comandi e con un avvio successivo al completamento.

La versione 1 corregge l'incoerenza e avvicina il comportamento della piattaforma Windows Server a quello delle piattaforme basate su Linux di Elastic Beanstalk. Nella piattaforma v1, Elastic Beanstalk esegue sempre i comandi dei container prima di avviare il server IIS.

La soluzione della piattaforma v1 specifica v1 dopo la versione di Windows Server:

  • Windows Server 2012 R2 (64 bit) v1.1.0 con IIS 8.5 in esecuzione

  • Windows Server Core 2012 R2 (64 bit) v1.1.0 con IIS 8.5 in esecuzione

  • Windows Server 2012 (64 bit) v1.1.0 con IIS 8 in esecuzione

  • Windows Server 2008 R2 (64 bit) v1.1.0 con IIS 7.5 in esecuzione

Inoltre, la piattaforma v1 estrae il contenuto del bundle di origine dell'applicazione in C:\staging\ prima dell'esecuzione dei comandi dei container. Quando i comandi container hanno completato l'operazione, i contenuti di questa cartella vengono compressi in un file .zip e distribuiti in IIS. Questo flusso di lavoro consente di modificare i contenuti del tuo bundle di origine dell'applicazione con comandi o con uno script prima della distribuzione.

Migrazione da versioni principali della piattaforma Windows Server

Questa sezione contiene alcune considerazioni sulla migrazione di cui tenere conto prima di aggiornare l'ambiente. Per aggiornare la piattaforma dell'ambiente a una versione più recente, consulta Aggiornamento della versione della piattaforma dell'ambiente Elastic Beanstalk.

Da V1 verso V2

La piattaforma Windows Server v2 non supporta .NET Core 1.x e 2.0. Se esegui la migrazione dell'applicazione da Windows Server v1 a v2 e l'applicazione utilizza una di queste versioni .NET Core, aggiorna l'applicazione a una versione .NET Core supportata da v2. Per un elenco delle versioni supportate, consulta .NET su Windows Server con IIS in Piattaforme AWS Elastic Beanstalk .

Se l'applicazione utilizza una Amazon Machine Image (AMI) personalizzata, crea una nuova AMI personalizzata in base all’AMI della piattaforma di Windows Server v2. Per ulteriori informazioni, vedi Utilizzo di un'immagine Amazon Machine Image (AMI) personalizzata nell'ambiente Elastic Beanstalk.

Nota

Le caratteristiche di distribuzione e aggiornamento che sono nuove per Windows Server v2 dipendono dallo stato avanzato. Quando si esegue la migrazione di un ambiente a v2, lo stato avanzato è disabilitato. Abilitarlo per utilizzare queste caratteristiche. Per informazioni dettagliate, consulta Abilitazione del reporting dello stato avanzato Elastic Beanstalk.

Da versioni precedenti alla versione V1

Oltre alle considerazioni sulla migrazione da v1, se esegui la migrazione dell'applicazione da uno stack di soluzioni Windows Server che è precedente alla versione v1 e usi attualmente comandi dei container, rimuovi tutti i comandi aggiunti per risolvere le incoerenze di elaborazione quando esegui la migrazione a una versione più recente. A partire da v1, i comandi del container vengono sicuramente eseguiti completamente prima dell'origine dell'applicazione che viene distribuita e prima dell'avvio di IIS. Questo consente di apportare eventuali modifiche all'origine in C:\staging e modificare i file di configurazione IIS durante questa fase senza problemi.

Ad esempio, puoi utilizzare per AWS CLI scaricare un file DLL nella sorgente dell'applicazione da Amazon S3:

.ebextensions\copy-dll.config

container_commands: copy-dll: command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\

Per ulteriori informazioni sull'utilizzo dei file di configurazione, consulta Personalizzazione avanzata dell'ambiente con i file di configurazione (.ebextensions).