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.

Nouvelles fonctionnalités et modifications de la AWS CLI version 2

Cette rubrique décrit les nouvelles fonctionnalités et les changements de comportement entre les AWS CLI versions 1 et AWS CLI 2. Ces modifications peuvent vous obliger à mettre à jour vos scripts ou commandes afin d'obtenir le même comportement dans la version 2 que dans la version 1.

AWS CLI nouvelles fonctionnalités de la version 2

La AWS CLI version 2 est la version majeure la plus récente AWS CLI et prend en charge toutes les dernières fonctionnalités. Certaines fonctionnalités introduites dans la version 2 ne sont pas rétroportées vers la version 1 et vous devez effectuer une mise à niveau pour accéder à ces fonctionnalités. Les principales fonctions sont notamment :

Changements majeurs entre AWS CLI la version 1 et AWS CLI la version 2

Cette section décrit tous les changements de comportement entre la AWS CLI version 1 et AWS CLI la version 2. Ces modifications peuvent vous obliger à mettre à jour vos scripts ou commandes afin d'obtenir le même comportement dans la version 2 que dans la version 1.

Variable d'environnement ajoutée pour définir le codage du fichier texte

Par défaut, les fichiers texte BLOB utilisent le même encodage que les paramètres régionaux installés. Comme la AWS CLI version 2 utilise une version intégrée de Python, les variables d'PYTHONIOENCODINGenvironnement PYTHONUTF8 et ne sont pas prises en charge. Pour définir un encodage de fichier texte différent de celui des paramètres régionaux, utilisez la variable d'environnement AWS_CLI_FILE_ENCODING. L'exemple suivant montre comment AWS CLI ouvrir des fichiers texte UTF-8 sous Windows.

AWS_CLI_FILE_ENCODING=UTF-8

Pour plus d'informations, consultez Configuration des variables d'environnement pour AWS CLI.

Les paramètres binaires sont transmis sous forme de chaînes codées en base64 par défaut

Dans le AWS CLI, certaines commandes nécessitaient des chaînes codées en base64, tandis que d'autres nécessitaient des chaînes d'octets codées en UTF -8. Dans la AWS CLI version 1, le transfert de données entre deux types de chaînes codées nécessitait souvent un traitement intermédiaire. La AWS CLI version 2 rend la gestion des paramètres binaires plus cohérente, ce qui permet de transmettre les valeurs d'une commande à l'autre de manière plus fiable.

Par défaut, la AWS CLI version 2 transmet tous les paramètres binaires d'entrée et de sortie binaires sous forme de chaîne codée en base64 blobs (gros objet binaire). Pour de plus amples informations, veuillez consulter BLOB.

Pour revenir au comportement de la AWS CLI version 1, utilisez la configuration du cli_binary_format fichier ou le --cli-binary-format paramètre.

Amélioration de la gestion par Amazon S3 des propriétés des fichiers et des balises pour les copies partitionnées

Lorsque vous utilisez les commandes de la AWS CLI version 1 dans l'aws s3espace de noms pour copier un fichier d'un emplacement de compartiment S3 vers un autre, et que cette opération utilise une copie en plusieurs parties, aucune propriété de fichier de l'objet source n'est copiée vers l'objet de destination.

Par défaut, les commandes correspondantes de la AWS CLI version 2 transfèrent toutes les balises et certaines propriétés de la copie source vers la copie de destination. Par rapport à la AWS CLI version 1, cela peut entraîner un plus grand nombre d' AWS APIappels vers le point de terminaison Amazon S3. Pour modifier le comportement par défaut des s3 commandes de AWS CLI la version 2, utilisez le --copy-props paramètre.

Pour de plus amples informations, veuillez consulter Propriétés des fichiers et balises dans les copies en plusieurs parties.

Aucune récupération automatique de http:// ou https:// URLs pour les paramètres

La AWS CLI version 2 n'effectue aucune GET opération lorsqu'une valeur de paramètre commence par http:// ouhttps://, et n'utilise pas le contenu renvoyé comme valeur de paramètre. Par conséquent, l'option de ligne de commande associée cli_follow_urlparam est supprimée de la AWS CLI version 2.

Si vous devez récupérer un URL et en transmettre le URL contenu dans une valeur de paramètre, nous vous recommandons curl d'utiliser un outil similaire pour télécharger le contenu du dans URL un fichier local. Utilisez ensuite la file:// syntaxe pour lire le contenu de ce fichier et utilisez-le comme valeur de paramètre.

Par exemple, la commande suivante n'essaie plus de récupérer le contenu de la page se trouvant dans http://www.example.com et de le transmettre en tant que paramètre. Au lieu de cela, elle transmet la chaîne de texte littéral https://example.com en tant que paramètre.

$ aws ssm put-parameter \
    --value http://www.example.com \
    --name prod.microservice1.db.secret \
    --type String 2

Si vous devez récupérer et utiliser le contenu d'un site Web URL en tant que paramètre, vous pouvez effectuer les opérations suivantes dans la version 2.

$ curl https://my.example.com/mypolicyfile.json -o mypolicyfile.json
$ aws iam put-role-policy \
    --policy-document file://./mypolicyfile.json \
    --role-name MyRole \
    --policy-name MyReadOnlyPolicy

Dans l'exemple précédent, le -o paramètre indique curl d'enregistrer le fichier dans le dossier actuel sous le même nom que le fichier source. La deuxième commande récupère le contenu de ce fichier téléchargé et le transmet en tant que valeur de --policy-document.

Pager utilisé pour toutes les sorties par défaut

Par défaut, la AWS CLI version 2 renvoie toutes les sorties via le programme de téléavertisseur par défaut de votre système d'exploitation. Ce programme est le lessprogramme sous Linux ou macOS, et le moreprogramme sous Windows. Cela peut vous aider à parcourir une grande quantité de résultats d'un service en affichant ces résultats page par page.

Vous pouvez configurer la AWS CLI version 2 pour utiliser un programme de pagination différent ou aucun programme de pagination du tout. Pour de plus amples informations, veuillez consulter Téléavertisseur côté client.

Les valeurs de sortie de l'horodatage sont normalisées au format 8601 ISO

Par défaut, la AWS CLI version 2 renvoie toutes les valeurs de réponse d'horodatage au format ISO8601. Dans AWS CLI la version 1, les commandes renvoyaient des valeurs d'horodatage quel que soit le format renvoyé par la HTTP API réponse, qui pouvait varier d'un service à l'autre.

Pour voir les horodatages au format renvoyé par la HTTP API réponse, utilisez la wire valeur de votre config fichier. Pour de plus amples informations, veuillez consulter cli_timestamp_format.

Gestion améliorée des CloudFormation déploiements qui n'entraînent aucune modification

Par défaut, dans la AWS CLI version 1, si vous déployez un AWS CloudFormation modèle qui n'entraîne aucune modification, un code d'erreur d'échec est renvoyé. AWS CLI Cela pose des problèmes si vous ne considérez pas qu'il s'agit d'une erreur et que vous souhaitez que votre script continue. Vous pouvez contourner ce problème dans la AWS CLI version 1 en ajoutant le drapeau-–no-fail-on-empty-changeset, qui revient0.

Comme il s'agit d'un cas d'utilisation courant, la AWS CLI version 2 renvoie par défaut un code de sortie réussi 0 lorsqu'aucun changement n'est causé par un déploiement et que l'opération renvoie un ensemble de modifications vide.

Pour revenir au comportement d'origine, ajoutez le drapeau--fail-on-empty-changeset.

Comportement par défaut modifié pour le point de terminaison Amazon S3 régional pour us-east-1 la région

Lorsque vous configurez la AWS CLI version 1 pour utiliser la us-east-1 région, elle AWS CLI utilise le point de s3.amazonaws.com terminaison global qui est physiquement hébergé dans la us-east-1 région. La AWS CLI version 2 utilise le véritable point de terminaison régional s3.us-east-1.amazonaws.com lorsque cette région est spécifiée. Pour forcer la AWS CLI version 2 à utiliser le point de terminaison global, vous pouvez définir la région d'une commande suraws-global.

Comportement par défaut modifié pour les points de AWS STS terminaison régionaux

Par défaut, la AWS CLI version 2 envoie toutes les AWS Security Token Service (AWS STS) API demandes au point de terminaison régional pour le système actuellement configuré Région AWS.

Par défaut, la AWS CLI version 1 envoie des AWS STS demandes au point de AWS STS terminaison global. Vous pouvez contrôler ce comportement par défaut dans la version 1 à l'aide du sts_regional_endpointsparamètre.

ecr get-loginretiré et remplacé par ecr get-login-password

La AWS CLI version 2 remplace la commande aws ecr get-login par la aws ecr get-login-password commande qui améliore l'intégration automatisée avec l'authentification des conteneurs.

La commande aws ecr get-login-password réduit le risque d'exposer vos informations d'identification dans la liste des processus, l'historique du shell ou d'autres fichiers journaux. Il améliore également la compatibilité avec la docker login commande pour une meilleure automatisation.

La aws ecr get-login-password commande est disponible dans les AWS CLI versions 1.17.10 et ultérieures, ainsi que dans la AWS CLI version 2. La aws ecr get-login commande précédente est toujours disponible dans la AWS CLI version 1 pour des raisons de rétrocompatibilité.

Avec la aws ecr get-login-password commande, vous pouvez remplacer le code suivant qui permet de récupérer un mot de passe.

$ (aws ecr get-login --no-include-email)

Pour réduire le risque d'exposer le mot de passe à l'historique ou aux journaux du shell, utilisez plutôt l'exemple de commande suivant. Dans cet exemple, le mot de passe est transféré directement à la commande docker login, où il est affecté au paramètre password par l'option --password-stdin.

$ aws ecr get-login-password | docker login --username AWS --password-stdin MY-REGISTRY-URL

Pour plus d'informations, consultez aws ecr get-login-passwordle guide de référence de la AWS CLI version 2.

AWS CLI le support de la version 2 pour les plugins est en train de changer

La prise en charge des plugins dans la AWS CLI version 2 est entièrement provisoire et vise à aider les utilisateurs à migrer depuis la AWS CLI version 1 jusqu'à ce qu'une interface de plugin stable et mise à jour soit publiée. Rien ne garantit qu'un plugin particulier ou même l'interface du AWS CLI plugin seront pris en charge dans les futures versions de la AWS CLI version 2. Si vous utilisez des plugins, assurez-vous de vous connecter à une version spécifique de votre plugin AWS CLI et de tester ses fonctionnalités lors de la mise à niveau.

Pour activer la prise en charge du plug-in, créez une section [plugins] dans votre ~/.aws/config.

[plugins]
cli_legacy_plugin_path = <path-to-plugins>/python3.7/site-packages
<plugin-name> = <plugin-module>

Dans [plugins] cette section, définissez la cli_legacy_plugin_path variable et définissez sa valeur sur le chemin des packages du site Python où se trouve votre module de plugin. Vous pouvez ensuite configurer un plugin en fournissant un nom pour le plugin (plugin-name) et le nom de fichier du module Python (plugin-module) qui contient le code source de votre plugin. AWS CLI Charge chaque plugin en l'important plugin-module et en appelant sa awscli_initialize fonction.

Suppression du support des alias masqués

AWS CLI la version 2 ne prend plus en charge les alias cachés suivants qui étaient pris en charge dans la version 1.

Dans le tableau suivant, la première colonne affiche le service, la commande et le paramètre qui fonctionnent dans toutes les versions, y compris la AWS CLI version 2. La deuxième colonne affiche l'alias qui ne fonctionne plus dans la AWS CLI version 2.

Le paramètre du fichier api_versions de configuration n'est pas pris en charge

La AWS CLI version 2 ne prend pas en charge l'appel de versions antérieures du AWS service à APIs l'aide du paramètre du fichier de api_versions configuration. Toutes les AWS CLI commandes appellent désormais la dernière version du service APIs actuellement prise en charge par le point de terminaison.

AWS CLI la version 2 utilise uniquement Signature v4 pour authentifier les demandes Amazon S3

La AWS CLI version 2 ne prend pas en charge les algorithmes de signature antérieurs pour authentifier de manière cryptographique les demandes de service envoyées aux points de terminaison Amazon S3. Cette signature s'effectue automatiquement à chaque demande Amazon S3 et seul le processus de signature Signature version 4 est pris en charge. Vous ne pouvez pas configurer la version de signature. Tous les compartiments Amazon S3 présignés utilisent URLs désormais uniquement le protocole SigV4 et ont une durée d'expiration maximale d'une semaine.

AWS CLI la version 2 est plus cohérente avec les paramètres de pagination

Dans la AWS CLI version 1, si vous spécifiez les paramètres de pagination sur la ligne de commande, la pagination automatique est désactivée comme prévu. Toutefois, lorsque vous spécifiez des paramètres de pagination à l'aide d'un fichier contenant le ‐‐cli-input-json paramètre, la pagination automatique n'était pas désactivée, ce qui pouvait entraîner une sortie inattendue. La AWS CLI version 2 désactive la pagination automatique, quelle que soit la manière dont vous fournissez les paramètres.

AWS CLI la version 2 fournit des codes de retour plus cohérents pour toutes les commandes

La AWS CLI version 2 est plus cohérente dans toutes les commandes et renvoie correctement un code de sortie approprié par rapport à la AWS CLI version 1. Nous avons également ajouté les codes de sortie 252, 253 et 254. Pour plus d'informations sur les codes de sortie, consultezCodes de retour de ligne de commande dans le AWS CLI.

Si vous êtes tributaire de la façon dont la AWS CLI version 1 utilise les valeurs des codes de retour, nous vous recommandons de vérifier les codes de sortie pour vous assurer que vous obtenez les valeurs que vous attendez.