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 :

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 :

Dans les versions antérieures, l'ordre de traitement des fichiers de configuration n'est pas cohérent. Lors de la création de l'environnement, Container Commands exécutez-le une fois que la source de l'application a été déployée surIIS. 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, il IIS démarre avant l'exécution des commandes du conteneur. Ce comportement a amené certains clients à implémenter des solutions de contournement dans les commandes de conteneur, en interrompant le IIS serveur avant l'exécution des commandes, puis en le redémarrant une fois celles-ci terminées.

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 :

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 les commandes du conteneur terminées, le contenu de ce dossier est compressé dans un 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 n'est pas prise en charge. NETCore 1.x et 2.0. Si vous migrez votre application de Windows Server v1 vers la version v2 et que votre application utilise l'un de ces outils. NETVersions de base, mettez à jour votre application vers un. NETVersion de base prise en charge par la v2. Pour obtenir la liste des versions prises en charge, consultez. NETsur Windows Server avec IIS les AWS Elastic Beanstalk plateformes.

Si votre application utilise une Amazon Machine Image personnalisée (AMI), créez-en une nouvelle personnalisée AMI basée sur une plate-forme Windows Server v2AMI. Pour en savoir plus, consultez Utilisation d'une image de machine Amazon personnalisée (AMI) dans votre environnement 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. À partir de la version 1, l'exécution complète des commandes de conteneur est garantie avant le déploiement de la source d'application et avant le IIS démarrage. Cela vous permet d'apporter des modifications à la source C:\staging et de modifier les fichiers IIS de configuration au cours de cette étape sans problème.

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

.ebextensions\copy-dll.config

container_commands:
  copy-dll:
    command: aws s3 cp s3://amzn-s3-demo-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).