Migration entre les principales versions de la plateforme Windows Server pour Elastic Beanstalk - AWS Elastic Beanstalk

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migration entre les principales versions de la plateforme Windows Server pour Elastic Beanstalk

AWS Elastic Beanstalk dispose de plusieurs versions majeures de sa plateforme Windows Server. Cette page couvre les améliorations principales de chaque version majeure et les éléments que vous devez prendre en compte avant de migrer vers une version ultérieure.

La plateforme Windows Server est actuellement à la version 2 (v2). Si votre application utilise une version de plateforme Windows Server antérieure à v2, nous vous recommandons de migrer vers v2.

Nouveautés des versions majeures de la plateforme Windows Server

Plateforme Windows Server V2

La version 2 (v2) de la plateforme Windows Server pour Elastic Beanstalk a été publiée en février 2019. La V2 aligne le comportement de la plateforme Windows Server sur celui des plateformes Linux Elastic Beanstalk pour plusieurs aspects importants. Le V2 est entièrement rétrocompatible avec la V1, ce qui facilite la migration à partir de la V1.

La plateforme Windows Server prend désormais en charge les fonctionnalités suivantes :

Note

Les nouvelles fonctionnalités de déploiement et de mise à jour dépendent des rapports améliorés sur l'état de santé. Activez la fonctionnalité correspondante pour les utiliser. Pour plus d'informations, consultez Activation des rapports améliorés sur l'état Elastic Beanstalk.

Plateforme Windows Server V1

La version 1.0.0 (v1) de la plateforme Windows Server pour Elastic Beanstalk a été publiée en octobre 2015. Cette version modifie l'ordre dans lequel Elastic Beanstalk traite les commandes dans les fichiers de configuration lors de la création et des mises à jour d'un environnement.

Les versions antérieures de la plateforme ne comportent pas de numéro dans le nom de pile de solutions :

  • Windows Server 64 bits 2012 R2 exécutant IIS 8.5

  • Windows Server Core 64 bits 2012 R2 exécutant IIS 8.5

  • Windows Server 64 bits 2012 exécutant IIS 8

  • Windows Server 64 bits 2008 R2 exécutant IIS 7.5

Dans les versions antérieures, l'ordre de traitement des fichiers de configuration n'est pas cohérent. Pendant la création de l'environnement, les commandes Container Commands sont exécutées une fois que la source de l'application est déployée dans IIS. Lors d'un déploiement dans un environnement en cours d'exécution, les commandes de conteneur sont exécutées avant le déploiement de la nouvelle version. Lors d'un ajustement à la hausse, les fichiers de configuration ne sont pas traités du tout.

En outre, IIS démarre avant l'exécution des commandes de conteneur. Ce comportement a conduit certains clients à mettre en place des solutions de contournement dans les commandes de conteneur. Elles consistent à mettre en veille le serveur IIS avant l'exécution des commandes et à le redémarrer une fois l'exécution terminée.

La version 1 corrige le problème d'incohérence et aligne le comportement de la plateforme Windows Server sur celui des plateformes Linux Elastic Beanstalk. Sur la plateforme v1, Elastic Beanstalk exécute toujours les commandes de conteneur avant de démarrer le serveur IIS.

Les piles de solutions de la plateforme v1 comportent la mention v1 après la version de Windows Server :

  • Windows Server 64 bits 2012 R2 v1.1.0 exécutant IIS 8.5

  • Windows Server Core 64 bits 2012 R2 v1.1.0 exécutant IIS 8.5

  • Windows Server 64 bits 2012 v1.1.0 exécutant IIS 8

  • Windows Server 64 bits 2008 R2 v1.1.0 exécutant IIS 7.5

En outre, la plateforme v1 extrait le contenu du bundle de fichiers source de votre application dans C:\staging\ avant d'exécuter les commandes de conteneur. Une fois que l'exécution des commandes de conteneur est terminée, le contenu de ce dossier est compressé en fichier .zip et déployé dans IIS. Ce processus vous permet de modifier le contenu du bundle source de votre application à l'aide des commandes ou d'un script avant le déploiement.

Migration à partir de versions majeures antérieures de la plateforme Windows Server

Consultez cette section pour prendre connaissance des considérations relatives à la migration avant de mettre à jour votre environnement. Pour mettre à jour votre plateforme d'environnement vers une version plus récente, consultez Mise à jour de la version de la plateforme de votre environnement Elastic Beanstalk.

De V1 vers V2

La plateforme Windows Server v2 ne prend pas en charge .NET Core 1.x et 2.0. Si vous migrez votre application à partir de Windows Server v1 vers v2 et que votre application utilise l'une de ces versions .NET Core, mettez à jour votre application vers une version .NET Core prise en charge par la v2. Pour obtenir la liste des versions prises en charge, consultez .NET sur Windows Server avec IIS dans les Plateformes AWS Elastic Beanstalk .

Si votre application utilise une Amazon Machine Image (AMI) personnalisée, créez une AMI personnalisée basée sur une AMI de plate-forme Windows Server v2. Pour en savoir plus, consultez la section Utilisation d'une Amazon Machine Image (AMI) personnalisée.

Note

Les fonctionnalités de déploiement et de mise à jour qui sont nouvelles dans Windows Server v2 dépendent des rapports améliorés sur l'état de santé. Lorsque vous migrez un environnement vers v2, les rapports améliorés sur l'état de santé sont désactivés. Activez-les pour utiliser ces fonctionnalités. Pour plus d'informations, consultez Activation des rapports améliorés sur l'état Elastic Beanstalk.

À partir de versions antérieures à la V1

Outre les considérations concernant la migration à partir de la v1, si vous migrez votre application à partir d'une pile de solutions Windows Server antérieure à la v1 et que vous utilisez actuellement des commandes de conteneur, supprimez toutes les commandes que vous avez ajoutées pour contourner les incohérences de traitement lors de la migration vers une version plus récente. Depuis la v1, l'exécution complète des commandes de conteneur est garantie avant l'application source qui est déployée et avant le démarrage d'IIS. Vous pouvez ainsi apporter des modifications à la source dans C:\staging et modifier sans problème les fichiers de configuration IIS au cours de cette étape.

Par exemple, vous pouvez utiliser le AWS CLI pour télécharger un fichier DLL vers la source de votre application depuis Amazon S3 :

.ebextensions\copy-dll.config

container_commands: copy-dll: command: aws s3 cp s3://DOC-EXAMPLE-BUCKET/dlls/large-dll.dll .\lib\

Pour de plus amples informations sur l'utilisation des fichiers de configuration, veuillez consulter Personnalisation d'environnement avancée avec fichiers de configuration (.ebextensions).