Aws-cli: Une image Docker officielle avec l'AWS CLI à utiliser dans les scénarios CI/CD

Je suis ici parce que je recherche moi aussi une image officielle du docker aws-cli à utiliser dans mon environnement CI/CD. Au lieu de cela, je vais maintenant créer un AUTRE pipeline pour créer une image docker qui inclut le aws cli alors que je pouvais simplement référencer l'officiel dans mon pipeline d'origine.

Aussi... quelqu'un d'autre l'obtient aussi https://hub.docker.com/r/google/cloud-sdk.

@matti et @nscavell , Merci d'avoir suivi ce sujet. On dirait que cette demande de fonctionnalité suscite suffisamment d'intérêt pour la garder ouverte. Ce problème sera utilisé pour suivre une image Docker officielle pour l'AWS CLI. Veuillez lui attribuer +1 pour montrer votre intérêt et nous aider à prioriser cela.

Merci.

Le +1 n'est-il pas considéré comme nuisible ;)

Quoi qu'il en soit, c'est le troisième (?) numéro créé à ce sujet...

ajouter mon +1

Je dois créer ma propre image docker pour inclure uniquement awsCLI dans mon CI. je préférerais un officiel

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Voici une image alpine (post fix) avec le cli le plus récent installé pour toute autre personne à la recherche d'une version récente entre-temps.

@justnance assez ?

+1

+1

+1

+1

Une autre raison est que lorsque vous utilisez un système d'exploitation comme coreOS qui n'a pas de gestion de packages, la manière idiomatique de faire fonctionner les choses se fait via un conteneur. Je suis surpris que la nécessité de cela soit même remise en question, c'est une omission évidente. ??

+1

:+1:

+1

+1

+1

+1

+1

En tant qu'ouvreur de #3291 (le plus ancien des trois numéros cités lol), je suis heureux de voir que ce numéro gagne enfin du terrain. À tous les futurs répondeurs, lorsque @justnance dit "S'il vous plaît, +1 pour montrer votre intérêt", il veut dire ajouter un j'aime sur le premier commentaire, c'est la bonne façon de +1 choses sur GitHub afin que vous ne spammiez pas les boîtes aux lettres des responsables .

+1 pour tenir les propriétaires de pension informés

+1

Quand ils disent à +1 un problème, ce qu'ils veulent dire c'est de cliquer sur le bouton 👍. Cela n'aide pas les développeurs d'avoir 100 commentaires qui disent chacun "+1". Plus vous en savez!

@davidham - Merci d'avoir clarifié et à tous d'avoir répondu. Je suis d'accord. Veuillez utiliser les réactions GitHub et cliquez sur le bouton 👍.

J'ai dit la même chose il y a 2 jours mais bon on est tous du même côté 🙃

+1

+1

+1

+1

+1

+1

+1

Pouvez-vous arrêter +1 ? si vous voulez +1, faites-le en haut.

Vous perdez un temps précieux d'ingénieur. Nous sommes une dizaine d'abonnés à ce numéro...

Je maintiens une image aws-cli depuis plus de deux ans maintenant. N'hésitez pas à l'utiliser si besoin (je l'utilise plusieurs fois par jour). Je reçois des mises à jour sur les nouvelles versions (via IFTT) et les mises à jour push assez rapidement. Malgré la renommée et la gloire de gérer ma propre image (ha!), Je vais _avec plaisir_ différer et pousser les gens à utiliser une image officielle.

• Dépôt GitHub
• Docker Hub

Après avoir utilisé mon image pendant longtemps, je dirai qu'il serait _super_ utile si l'image officielle incluait jq (car l'API est lourde en JSON). Cela rend très pratique de faire des choses telles que "saisir la dernière définition de tâche ECS, apporter une modification et la repousser" le tout dans une seule étape de pipeline CI/CD.

Encore une autre solution alternative au problème : https://hub.docker.com/r/somedeveloper/aws-cli/

Raisons d'utiliser:

• Cela reste simple.
• Utilise python3.7-stretch officiel comme image de base.
• Utilise la stratégie d'installation recommandée par AWS : python + pip. voir ici .
• Comprend aws-sam-cli pour les nerds sans serveur 8-).
• Son public et ne nécessite pas de connexion.
• Idéal pour les pipelines CI/CD - je ne l'ai utilisé pour rien d'autre, donc je n'ai pas pesé le pour et le contre.

J'espère toujours une image officielle. Pense aux gens maintenant

https://hub.docker.com/r/google/cloud-sdk/ . Désolé les gars. C'est une tâche si difficile à faire pour un géant comme AWS.

+1

Le +1 n'est-il pas considéré comme nuisible ;)

Quoi qu'il en soit, c'est le troisième (?) numéro créé à ce sujet...

Quatrièmement, si vous considérez https://github.com/aws/amazon-linux-docker-images/issues/10.

Ne pouvons-nous pas simplement le mettre dans CircleCI et en finir avec ? Heureux de vous aider avec le Dockerfile ou le pipeline.

Je me demande s'il existe des restrictions internes et/ou des formalités administratives à l'intérieur d'Amazon qui empêchent les développeurs d'accomplir ce travail apparemment trivial...

k lol

Il y a quelques variantes qu'il serait bien d'avoir dans une image "officielle". Par exemple, je cherche actuellement à récupérer un conteneur avec les aws cli et curl (pour vérifier le point de terminaison des métadonnées IAM) et il serait vraiment pratique d'en trouver un que je pourrais simplement saisir et brancher sur mon déploiement k8s.

Il y a aussi une raison de sécurité pour fournir des images officielles.

Cela simplifie le modèle de menace en supprimant une dépendance à l'égard d'une "personne aléatoire sur Internet" en maintenant l'image utilisée dans les cibles de grande valeur telles que les pipelines CI/CD qui donnent généralement beaucoup d'accès à vos systèmes.

Je voudrais une image officielle du docker aws-cli basée sur l'image docker:18 (actuellement stable) (https://hub.docker.com/_/docker) - par exemple. aws-cli-docker-18 car je souhaite créer mon image Docker dans mon environnement CI/CD qui utilise actuellement l'image docker:18 et la publier sur AWS ECR.

+1

+1

Ce serait formidable si les gens s'abstenaient de commenter lorsque leur commentaire ne contribue pas au problème en question. Des commentaires tels que « +1 » introduisent simplement du spam pour les abonnés et allongent le problème plus que nécessaire. Au lieu de cela, donnez un coup de pouce au premier commentaire du problème.

Ce serait formidable si les gens s'abstenaient de commenter lorsque leur commentaire ne contribue pas au problème en question. Des commentaires tels que « +1 » introduisent simplement du spam pour les abonnés et allongent le problème plus que nécessaire. Au lieu de cela, donnez un coup de pouce au premier commentaire du problème.

Cette question est ouverte depuis septembre de l'année dernière. Je pense que nous devons demander à AWS de se pencher à nouveau sur cette question, car elle suscite évidemment un intérêt. On devrait nous dire à quel point l'intérêt est « suffisant ».

car il y a manifestement de l'intérêt

Pas seulement de l'intérêt, mais c'est le problème ouvert avec plus :+1: réactions :

https://github.com/aws/aws-cli/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Le 2e avec le plus de réactions a été ouvert en 2014 et le 3e en 2015, tandis que ce numéro a été ouvert en septembre 2018 (il y a moins d'un an ).

+1000

J'ai sur ma machine locale tout le temps des problèmes avec la configuration des bonnes dépendances pour faire fonctionner aws-cli. Par conséquent, j'ai décidé de passer à aws-cli dans docker. J'ai trouvé plusieurs images accessibles au public sur docker-hub MAIS parce qu'elles ne sont pas officielles, je ne leur fais pas confiance par défaut, donc chaque fois qu'une version mise à jour est disponible, je dois rechercher et retrouver une image de confiance. et est sûr à utiliser. Veuillez créer, maintenir et fournir une image docker aws-cli sécurisée via le hub docker. Merci d'avance

Il y a une énorme fragmentation des images aws-cli fournies par la communauté. Mais, comme mentionné précédemment : les gens préféreraient un qui est officiellement maintenu et pris en charge par Amazon. Plusieurs raisons pour lesquelles :

1) Ne s'éteindra pas - les images de la communauté sont connues pour finir par devenir périmées ;
2) Plus sécurisé - il provient d'une ressource de confiance, quelle que soit la confiance d'un membre de la communauté, il ne représente pas officiellement Amazon, donc "toutes les garanties sont annulées" ;
3) Support officiel signifie support officiel en cas de bugs, conflits de versions, rétrocompatibilités, etc.
4) AWS peut mettre à jour son image à mesure qu'il met à jour le aws cli, y compris les balises historiques.

+1

+1 C'est vraiment dommage qu'Amazon ne fournisse pas cela

J'ai depuis ajouté une autre image qui a été pratique. Il combine Docker dans Docker avec AWS et SAM CLI, ce qui permet une intégration ECR parfaite.

dind-aws-cli

+1

Bien qu'il existe des tas d'images non officielles qui sont bien entretenues, qu'est-ce qui les empêchera un jour de dire "Pfft, à quoi bon mettre à jour ça maintenant. C'est le travail d'Amazon !"

+1

+1

Lorsqu'il s'agit d'aider les gens à automatiser leur travail avec AWS, Amazon échoue énormément, c'est l'une des raisons pour lesquelles nous pensons les quitter.

Y a-t-il une réponse officielle des responsables quant à savoir si cela figure ou non sur une feuille de route ? Comme beaucoup d'autres, je préférerais aussi utiliser une image officielle...

+1

S'il existait une image officielle pour l'AWS CLI, il s'agirait d'un exécutable placé dans un conteneur de travail. Parce que cela ne serait pas incroyablement utile pour les individus, ce qui pourrait être le mieux est de :

• Utilisez un conteneur python officiel pour créer l'interface de ligne de commande à partir des sources
• Copiez le binaire AWS CLI résultant dans un conteneur busybox ou scratch

Rien de plus serait de la sur-ingénierie malgré les débats qui se produisent ici.

AWS adore faire la démonstration de tous ses services ECR et CodeDeploy. Pourquoi ne pointent-ils pas toute cette puissance de feu vers leur propre CLI conteneurisée ?

Parce que l'offre sur la table semble être que quelqu'un de la communauté la maintienne.

@balibebas quelqu'un de la communauté le fait déjà. Il y a une tonne d'images là-bas - mais le fait est qu'il y en aurait une par AWS, car je ne veux pas exécuter randomguy/aws-cli:canbechangedanytime dans mon environnement CI avec tous les secrets grands ouverts.

Que diriez-vous alors de F-Droid ?

il est aussi pertinent pour ce problème que ce chat :

Vous avez l'air d'un client payant.

eh bien, c'est peut-être parce que _je_ _am_

La prédication à la chorale. Quoi qu'il en soit, la formule Brew a eu une meilleure chance car elle a été traînée plus longtemps, toujours sans mouvement. Ainsi, les photos de chats deviennent immédiatement contre-productives lorsqu'il n'y a pas de cas d'utilisation générale en dehors d'un conteneur à gratter ou occupé, comme je l'ai souligné plus tôt. Quelle est votre proposition de conception?

moi et beaucoup d'autres faisons actuellement des "conteneurs occupés", par exemple pour l'exécuter avec docker pour obtenir les informations d'authentification ECR. étant donné le nombre de docker things aws, cela n'a aucun sens qu'un emballage officiel n'existe pas.

Peut-être qu'ils sont juste sur autre chose. ;)

Je suis content que nous ayons réglé ça maintenant. Retour aux commentaires +1 :

+1 pour Dockerless

@matti @balibebas Gardez à l'esprit qu'à l'heure actuelle, il y a 64 personnes dans la seule conversation de ce problème, et chaque réponse déclenche un e-mail et une notification inutiles qui sont potentiellement envoyés à chacune de ces 64 personnes et plus qui sont abonnées. Ce message fera la même chose, et je m'en excuse.

Mais vraiment, s'il vous plaît, restez professionnel. Bien que les images de chats soient belles, plus ce fil déraille, moins il est probable qu'il soit pris au sérieux par les responsables. Malheureusement, le spam reste du spam.

C'est ce que fait le bouton de désinscription, celui sur lequel je viens de cliquer.

Ce serait une bonne chose à avoir. Je suis seulement surpris qu'aucune mesure ne soit prise ou que cela soit maintenu (y compris le fait de dire NON).
Quoi qu'il en soit, les personnes ci-dessus ont souligné à juste titre l'importance d'une image officielle d'aws cli.
Je pense que les gens utilisent déjà le leur en privé ou via la route des gestionnaires d'images / de packages construits par quelqu'un d'autre, etc.
Encore un autre exemple de script pour le même

Mais le problème le plus simple et inévitable reste le même.

• La liste interminable de dépendances et d'incertitudes qui saute si cela dépend des développeurs d'intégrer les choses par eux-mêmes. Cela finira par entraîner plus de problèmes dans le référentiel, car les gens commenceront par installer une chose, puis une autre, puis quelques autres pour accomplir le travail en contaminant l'environnement, ce qui va à l'encontre du but de CI/CD ou de travaux similaires d'être isolés et vierges.
• Il est difficile de faire confiance pour implémenter et suivre l'image Docker de quelqu'un d'autre pour votre travail. Cela conduit à créer un autre ajout de pipeline et d'entrée dans le registre Docker pour la nouvelle image awscli, un autre référentiel, c'est-à-dire une autre chose à maintenir.
• En CI/CD, ma préférence est d' utiliser simplement l'image (notre interne ou officielle) & d'éviter les lignes de script pour ajouter autant de choses que possible.
• Le problème avec la construction et les bibliothèques en tant qu'image officielle peut être immédiatement construit à partir des versions source elle-même et avoir des dépendances moins dynamiques par rapport au gestionnaire de packages et ainsi de suite.

autre
=> Chacun finit par fabriquer le sien.

même chose ici, actuellement j'utilise une image auto-construite, mais je préférerais une image officielle sous le

• https://hub.docker.com/_/awscli

espace de noms. Je l'utilise pour créer d'autres images Docker et les envoyer vers ECR, où l'awscli est nécessaire pour obtenir les informations d'identification.

FROM docker:18.06

RUN apk update && \
apk -Uuv add python py-pip && \
pip install awscli && \
apk --purge -v del py-pip && \
rm /var/cache/apk/*

Cela ne devrait pas être si grave d'ajouter ceci à votre pipeline de construction awscli ... :)

--

j'ai mis à jour le Dockerfile selon la suggestion de @ mikesir87 , merci pour cela (c'est une autre raison d'avoir une image standard avec des contributions de la communauté pour obtenir la plus petite image)

Désolé de spammer tout le monde, mais je voulais souligner (au cas où quelqu'un d'autre voudrait utiliser l'extrait de @jens-meiss) que vous devriez _vraiment_ envisager d'enchaîner vos trois déclarations RUN en une seule déclaration. Sinon, vous expédiez toujours le contenu de py-pip et les caches apk dans les couches intermédiaires, même si votre conteneur final ne peut pas y accéder.

Sur une autre note, le commentaire fait apparaître un autre cas d'utilisation valide... lorsque vous utilisez aws-cli uniquement pour obtenir des informations d'identification pour ECR afin de transmettre des images. Cela ressemble à un besoin d'emballer l' assistant d'identification ECR dans une image également. Cela faciliterait certainement la création et la diffusion d'images sans avoir besoin de l'aws-cli complet.

Salut à tous, mainteneur ici. Je voulais juste clarifier, ce qui se passe, nous le faisons.

Nous sommes en train de créer une meilleure infrastructure de version en interne pour pouvoir créer/tester/prendre en charge plus de types d'artefacts de version, d'autant plus que nous expédierons plus d'artefacts de version pour cli v2.

Nous n'avons pas de calendrier précis pour le moment, mais c'est en train de se produire.

Chose facile à faire selon les développeurs d'Amazon et bien d'autres, mais toujours en attente après 2 ans et pas d'ETA 😂

+1

Infrastructure de diffusion interne (T4 2019)
évaluation de l'équipe juridique (2020 Q1)
bêta publique sous aws/cli-dev-test (2020 Q2)
version finale (2020 Q3)

Dans ce calendrier optimiste, vous obtiendrez ce que vous voulez en moins de 10 mois. ??

en attente d'un article sur le blog de jeff barrs

J'attends ça.

Pouvons-nous au moins obtenir une annonce officielle ou un engagement. Peut-être une version cible ?

@bhmckendrick est un engagement pas exactement ce qu'est ce commentaire pas trop au-dessus du vôtre ?

https://github.com/aws/aws-cli/issues/3553#issuecomment -519280276

plus d'un an et aucune mise à jour? Image?

salut @jamesls , envisageriez-vous de verrouiller ce fil jusqu'à ce que vous ayez quelque chose à partager ?

le nombre de personnes totalement réticentes à lire ( indice indice ) et choisissant plutôt de spammer plus de 70 observateurs sur la façon dont ils sont _spécifiquement_ agacés réduit considérablement, j'en suis sûr, l'intérêt de tout le monde à suivre ce fil.

aussi, merci pour votre travail pour que cela se produise !

En tant qu'auteur original de ce numéro (enfin, j'ai juste eu le courage de copier/coller les "wontfix" précédemment fermés), je me suis déjà désabonné de ce numéro à cause du spam massif +1 et des combats occasionnels avec des images de chat (désolé) .

Ajustez simplement les paramètres de notification afin que vous ne receviez des notifications que si ce problème est résolu.

Je voudrais juste souligner qu'à part CI/CD, certains développeurs (voir @LongLiveCHIEF), préfèrent avoir des environnements de développement dockerisés, et n'aiment pas installer des choses nativement, ou avoir à traiter avec les gestionnaires de versions qui en découlent pour le langues natives sur lesquelles ces outils CLI s'appuient inévitablement.

Il est plus facile de docker pull aws-cli que quelles que soient les étapes d'installation existantes... sans compter que si vous n'êtes pas un développeur python, vous devez configurer une bonne version et un bon environnement python pour votre utilisateur, ou même chaque projet.

Adaptez cela à tous les différents outils qu'un développeur peut utiliser (clis basés sur Ruby, CLI basés sur des nœuds), et vous devez apprendre les configurations d'environnement pour les langages dans lesquels vous ne codez peut-être jamais.

Ce que je veux dire ici, c'est que docker run est omniprésent et se débarrasse de toute configuration/configuration de langue maternelle et facilite les choses pour les utilisateurs.

Même si les utilisateurs créent leurs propres images Docker, ils doivent toujours lutter avec ces tâches de configuration.

Je ne code pas en python, mais j'ai été obligé d'apprendre les tenants et les aboutissants des environnements virtuels et leurs meilleures pratiques à partir de différentes versions de python, simplement parce que les fournisseurs d'outils le considèrent comme "trivial".

Tous les développeurs n'ont pas la même expérience que ceux qui ont construit l'outil, et fournir une image docker est un signe de respect. Les fournisseurs d'outils peuvent prendre en charge très rapidement et facilement les bizarreries de l'environnement spécifique à la langue maternelle, tandis que les utilisateurs doivent passer beaucoup plus de temps à gérer cette surcharge à travers les différentes étapes du cycle de vie du développement avec votre produit.

Nourriture pour cependant.

@jamesls Merci d'avoir écouté les commentaires de la communauté ici. En attendant les images docker hébergées officielles, une étape intermédiaire utile pourrait être de publier des recommandations d'installation pour quelques images docker de base populaires ici (par exemple, node, alpine, ubuntu, amazon2, python). Cela nous serait immédiatement précieux.

Comme je travaille pour une entreprise à gros cul, permettez-moi de vous servir ceci :
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

Cela n'a pas l'air bien entretenu, mais en voici un autre

https://hub.docker.com/r/amazon/lambda-build-node10.x

Je viens de le repérer dans la nature : https://hub.docker.com/r/amazon/aws-cli

Il semble qu'il soit enfin là :)

@pablosjv ce n'est pas une image officielle ou certifiée. Soyez conscient de cela.

@anjakammer Il semble que ce soit une image officielle d'Amazon , même si ce n'est pas une image officielle publiée par Docker .

Je ne sais pas si la production est prête, car ils n'ont encore rien dit dans ce numéro.

Curieux de savoir comment cette image AWS fait 98,42 Mo alors que d'autres (par exemple atlassian/pipelines-awscli ) sont beaucoup plus petites.

https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/

Membre de l'équipe CLI ici. Oui, je peux confirmer que nous avons officiellement lancé une image Docker pour l'AWS CLI v2 ! Je recommande de lire ce qui suit :

• Article de blog le présentant : https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/
• Entrée du guide de l'utilisateur : https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html
• Référentiel DockerHub : https://hub.docker.com/r/amazon/aws-cli

Je vais clore ce sujet. Si vous avez des commentaires ou des questions sur l'image, veuillez ouvrir un autre problème GitHub dans ce référentiel.

En tant qu'ouvreur du numéro original #3291, il y a de nombreuses années, mon ️ douloureux est rempli d'une telle joie de voir mes préoccupations enfin validées, et une image officielle Docker maintenant disponible. Des photos de pot sur le temps qu'il a fallu pour faire cette image de côté, je suis sûr que c'était beaucoup plus facile à dire qu'à faire, donc un grand merci aux développeurs d'Amazon qui ont rendu cela possible. Vous faites tous un excellent travail. ??

_D'accord Alexa, je les ai remerciés, s'il vous plaît laissez ma famille partir maintenant._

Le Dockerfile disponible n'importe où ?

@zerkms Aha, v2 :
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

Je suppose qu'ils le font enfin, mais je n'ai pas pu le faire fonctionner sur Gitlab CI https://hub.docker.com/r/amazon/aws-cli

J'utilise plutôt l'image docker AWS CLI de Gitlab, et cela fonctionne parfaitement. Utilisez simplement

image: registry.gitlab.com/gitlab-org/cloud-deploy:latest

METTRE À JOUR:

L'image ci-dessus est obsolète, utilisez la nouvelle à la place.

image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest

Notez que pour utiliser l'image sur GitLab CI, vous devrez définir manuellement un point d'entrée vide, car l'image amazon/aws-cli définit le point d'entrée sur /usr/local/bin/aws . Un exemple...

image:
    name: amazon/aws-cli
    entrypoint: [""]

@ mikesir87 pourquoi est-ce?

@pSnehanshu Je pense que c'est parce que vous exécutez l'image comme si c'était le cli lui-même, comme docker run --rm amazon/aws-cli <<command>> , ce qui serait similaire à l'exécution du cli avec aws <<command>> , au lieu de docker run --rm amazon/aws-cli aws <<command>> . Il y a des avantages et des inconvénients avec chaque approche, selon ce que vous préférez et la façon dont vous exécutez l'image, mais le remplacement du point d'entrée devrait faire l'affaire de toute façon.

@lucasbasquerotto J'ai quand même opté pour l'image de Gitlab. En tout cas merci pour l'explication.

Au cas où quelqu'un serait toujours intéressé à faire fonctionner AWS CLI v2 sur Alpine Linux, voici un exemple de Dockerfile :

FROM alpine:3.11 AS builder

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk add --no-cache --virtual .build-deps \
        binutils \
        curl
RUN curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub
RUN curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk
RUN curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk
RUN apk add --no-cache \
        glibc-${GLIBC_VER}.apk \
        glibc-bin-${GLIBC_VER}.apk

# install AWS CLI
RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip
RUN unzip awscliv2.zip
RUN aws/install

FROM alpine:3.11
MAINTAINER Barry Lagerweij
RUN apk --update --no-cache --virtual .build-deps add \
    groff \
    && rm -rf /var/cache/apk/*
COPY --from=builder /usr/local/aws-cli/ /usr/local/aws-cli/
COPY --from=builder /usr/local/bin/ /usr/local/bin/
COPY --from=builder /usr/lib/ /usr/lib/
COPY --from=builder /lib64 /lib64
COPY --from=builder /usr/glibc-compat/ /usr/glibc-compat/
COPY --from=builder /lib/ld-linux-x86-64.so.2 /lib/

Le problème était qu'AWS CLI v2 utilise GLIBC, mais Alpine Linux a une prise en charge limitée de GLIBC (il utilise 'musl', une alternative légère). Le Dockerfile ci-dessus installe les bibliothèques glibc manquantes et utilise un Dockerfile à plusieurs étapes pour garder l'image finale petite. Avec un peu d'effort, nous pouvons probablement réduire encore plus la taille de l'image en n'incluant que les fichiers de /usr/lib qui sont vraiment nécessaires.

Après quelques refactorisations, j'ai réussi à réduire encore plus la taille de l'image :

FROM alpine:3.11

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk --no-cache add \
        binutils \
        curl \
    && curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub \
    && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk \
    && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk \
    && apk add --no-cache \
        glibc-${GLIBC_VER}.apk \
        glibc-bin-${GLIBC_VER}.apk \
    && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip \
    && unzip awscliv2.zip \
    && aws/install \
    && rm -rf \
        awscliv2.zip \
        aws \
        /usr/local/aws-cli/v2/*/dist/aws_completer \
        /usr/local/aws-cli/v2/*/dist/awscli/data/ac.index \
        /usr/local/aws-cli/v2/*/dist/awscli/examples \
    && apk --no-cache del \
        binutils \
        curl \
    && rm glibc-${GLIBC_VER}.apk \
    && rm glibc-bin-${GLIBC_VER}.apk \
    && rm -rf /var/cache/apk/*

L'index de saisie semi-automatique et les fichiers d'exemple sont supprimés, ainsi que 'groff' est supprimé (je suppose que les gens n'ont pas besoin de pages d'aide dans leurs images Docker)

C'est très simple, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile et fait le travail mais faites-moi savoir via mes problèmes github si quelque chose d'autre est nécessaire dans l'image (cas d'utilisation valide).

C'est très simple, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile et fait le travail mais faites-moi savoir via mes problèmes github si quelque chose d'autre est nécessaire dans l'image (cas d'utilisation valide).

L'APK ci-dessus est basé sur AWS-CLI 1.18, pas sur la CLI v2.

Amazon envisage-t-il de créer une image avec la version 1 de la CLI ?

@keeganwitt Vous devriez ouvrir un nouveau problème pour cette demande. :+1: