Aws-cli: Ein offizielles Docker-Image mit der AWS CLI zur Verwendung in CI/CD-Szenarien

Erstellt am 9. Sept. 2018  ·  121Kommentare  ·  Quelle: aws/aws-cli

Ich las die Ausgaben #3529 und #3291 und sah, dass diese geschlossen waren, mit der einzigen Reaktion, die darauf hindeutete, dass es "nicht so kompliziert" war. Der Kommentar räumte jedoch auch ein, dass dies selbst die Gefahr birgt, veraltet zu sein. Abgesehen von genau diesem Punkt möchte ich auch darauf hinweisen, dass für kommerzielle Nutzer ein offizielles Amazon-Image gegenüber „/aws- cli:latest “ enorm bevorzugt wird.

In meinem Fall würde ich dies in einem Google Cloud Build verwenden, da es AWS CodeBuild weit überlegen ist.

feature-request

Hilfreichster Kommentar

@matti und @nscavell , Vielen Dank, dass Sie dieses Thema

Danke.

Alle 121 Kommentare

Ich bin hier, weil auch ich nach einem offiziellen aws-cli-Docker-Image suche, das ich in meiner CI/CD-Umgebung verwenden kann. Stattdessen werde ich jetzt eine ANDERE Pipeline erstellen, um ein Docker-Image zu erstellen, das die AWS-Cli enthält, während ich nur auf die offizielle in meiner ursprünglichen Pipeline verweisen könnte.

Außerdem ... jemand anderes bekommt es auch https://hub.docker.com/r/google/cloud-sdk.

@matti und @nscavell , Vielen Dank, dass Sie dieses Thema

Danke.

Gilt +1 nicht als schädlich ;)

Wie auch immer, dies ist das dritte (?) Problem, das zu diesem Thema erstellt wurde ...

👍 füge meine +1 hinzu

Ich muss mein eigenes Docker-Image erstellen, um nur awsCLI in mein CI aufzunehmen. Ich würde einen offiziellen bevorzugen

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Hier ist ein alpines (postfix) Image mit der neuesten cli installiert für alle anderen, die in der Zwischenzeit nach einer neueren Version suchen.

@justnance genug?

+1

+1

+1

+1

Ein weiterer Grund ist, dass bei der Verwendung eines Betriebssystems wie coreOS ohne Paketverwaltung die idiomatische Art und Weise, Dinge über einen Container auszuführen. Ich bin überrascht, dass die Notwendigkeit dafür überhaupt in Frage gestellt würde, ist eine offensichtliche Unterlassung. 👍

+1

:+1:

+1

+1

+1

+1

+1

Als Opener von #3291 (der frühesten der drei zitierten Ausgaben lol) bin ich froh zu sehen, dass diese Ausgabe endlich an Fahrt gewinnt. An alle zukünftigen Responder, wenn @justnance sagt "Bitte geben Sie +1, um Interesse zu zeigen", bedeutet er, dem ersten Kommentar ein "

+1, um Repo-Inhaber auf dem Laufenden zu halten

+1

Wenn sie +1 ein Problem sagen, meinen sie, dass sie auf die Schaltfläche 👍 klicken. Es hilft den Entwicklern nicht, 100 Kommentare zu haben, die jeweils "+1" sagen. Je mehr du weisst!

@davidham - Danke für die Klarstellung und alle für die Antwort. Ich unterstütze das. Bitte verwenden Sie die GitHub-Reaktionen und klicken Sie auf die Schaltfläche 👍.

Ich habe vor 2 Tagen dasselbe gesagt, aber hey, wir sind alle auf der gleichen Seite 🙃

+1

+1

+1

+1

+1

+1

+1

Können Sie +1 stoppen? Wenn Sie +1 geben möchten, tun Sie dies oben.

Sie verschwenden wertvolle Ingenieurzeit. Wir haben diese Ausgabe zu Dutzenden abonniert...

Ich pflege seit über zwei Jahren ein aws-cli-Image. Fühlen Sie sich frei, es bei Bedarf zu verwenden (ich benutze es mehrmals täglich). Ich erhalte Updates zu neuen Versionsreleases (über IFTT) und pushe Updates ziemlich schnell. Trotz des Ruhms und Ruhmes, mein eigenes Image zu führen (ha!), werde ich _gerne_ aufschieben und die Leute dazu drängen, ein offizielles Image zu verwenden.

Nachdem ich mein Bild längere Zeit verwendet habe, werde ich sagen, dass es _super_ hilfreich wäre, wenn das offizielle Bild jq (da die API JSON-lastig ist). Es macht es sehr bequem, Dinge wie "die neueste ECS-Aufgabendefinition abrufen, eine Änderung vornehmen und sie zurückschieben" alles in einer einzigen CI/CD-Pipeline-Phase durchzuführen.

Noch eine andere alternative Lösung für das Problem: https://hub.docker.com/r/somedeveloper/aws-cli/

Gründe für die Verwendung:

  • Hält es einfach.
  • Verwendet offizielles Python3.7-Stretch als Basis-Image.
  • Verwendet die von AWS empfohlene Strategie für die Installation – python + pip. siehe hier .
  • Enthält aws-sam-cli für diese serverlosen Nerds 8-).
  • Es ist öffentlich und erfordert keine Anmeldung.
  • Großartig für CI/CD-Pipelines - habe es für nichts anderes verwendet, also habe die Vor- und Nachteile nicht abgewogen.

Hoffe immer noch auf ein offizielles Bild. Denk jetzt an die Leute

https://hub.docker.com/r/google/cloud-sdk/ . Tut mir leid, Leute. Für einen Giganten wie AWS ist das eine so schwere Aufgabe.

+1

Gilt +1 nicht als schädlich ;)

Wie auch immer, dies ist das dritte (?) Problem, das zu diesem Thema erstellt wurde ...

Viertens, wenn Sie https://github.com/aws/amazon-linux-docker-images/issues/10 berücksichtigen

Können wir es nicht einfach in CircleCI einfügen und fertig? Helfen Sie gerne mit dem Dockerfile oder der Pipeline.

Ich frage mich, ob es innerhalb von Amazon interne Einschränkungen und/oder Papierkram gibt, die die Entwickler davon abhalten, diese scheinbar triviale Arbeit zu erledigen ...

k lol

Es gibt ein paar Varianten, die in einem "offiziellen" Image schön wären. Zum Beispiel suche ich derzeit nach einem Container mit aws cli und curl (um den IAM-Metadatenendpunkt zu überprüfen) und es wäre wirklich praktisch, einen zu finden, den ich einfach greifen und in meine k8s-Bereitstellung einstecken könnte.

Es gibt auch einen Sicherheitsgrund für die Bereitstellung offizieller Bilder.

Es vereinfacht das Bedrohungsmodell, indem es eine Abhängigkeit von einer "zufälligen Person im Internet" beseitigt, die das Image verwaltet, das in hochwertigen Zielen wie CI/CD-Pipelines verwendet wird, die normalerweise viel Zugriff auf Ihre Systeme gewähren.

Ich möchte ein offizielles aws-cli Docker-Image basierend auf dem docker:18 (aktuell stabil) Image (https://hub.docker.com/_/docker) - zB. aws-cli-docker-18, weil ich mein Docker-Image in meiner CI/CD-Umgebung erstellen möchte, die derzeit das docker:18 Image verwendet, und es in AWS ECR veröffentlichen möchte.

+1

+1

Es wäre toll, wenn Leute auf Kommentare verzichten würden, wenn ihr Kommentar nicht zum vorliegenden Thema beiträgt. Kommentare wie "+1" führen nur zu Spam für Abonnenten und machen das Problem länger als nötig. Geben Sie stattdessen dem ersten Kommentar des Problems einen Daumen nach oben.

Es wäre toll, wenn Leute auf Kommentare verzichten würden, wenn ihr Kommentar nicht zum vorliegenden Thema beiträgt. Kommentare wie "+1" führen nur zu Spam für Abonnenten und machen das Problem länger als nötig. Geben Sie stattdessen dem ersten Kommentar des Problems einen Daumen nach oben.

Diese Ausgabe ist seit September letzten Jahres geöffnet. Ich denke, wir müssen AWS bitten, sich dieses Thema noch einmal anzusehen, da offensichtlich Interesse daran besteht. Uns sollte gesagt werden, wie viel Interesse "genug" ist.

da offensichtlich Interesse daran besteht

Nicht nur Interesse, sondern das eröffnete Thema mit mehr :+1: Reaktionen :

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

Die zweite mit den meisten Reaktionen wurde 2014 und die dritte 2015 eröffnet, während diese Ausgabe im September 2018 ( vor weniger als einem Jahr ) eröffnet wurde.

+1000

Ich habe auf meinem lokalen Computer ständig Probleme mit der Einrichtung der richtigen Abhängigkeiten, damit aws-cli funktioniert. Daher habe ich mich entschieden, innerhalb von Docker zu aws-cli zu wechseln. Ich habe mehrere öffentlich verfügbare Bilder auf Docker-Hub gefunden, ABER da sie nicht offiziell sind, vertraue ich ihnen standardmäßig nicht, also muss ich jedes Mal, wenn eine aktualisierte Version verfügbar ist, suchen und ein Bild finden, dem man vertrauen kann. und ist sicher in der Anwendung. AWS erstellt, wartet und stellt ein sicheres aws-cli-Docker-Image über Docker-Hub bereit. Vielen Dank im Voraus

Es gibt eine große Fragmentierung der von der Community bereitgestellten aws-cli-Bilder. Aber wie bereits erwähnt: Die Leute würden eines bevorzugen, das offiziell von Amazon gewartet und unterstützt wird. Mehrere Gründe dafür:

1) Wird nicht veralten – Community-Bilder sind dafür bekannt, dass sie irgendwann veralten;
2) Sicherer – es stammt von einer vertrauenswürdigen Quelle, egal wie vertrauenswürdig ein Community-Mitglied sein mag, es repräsentiert Amazon nicht offiziell, daher „alle Garantien ungültig“;
3) Offizieller Support bedeutet offizieller Support bei Bugs, Versionskonflikten, Abwärtskompatibilitäten etc.
4) AWS kann sein Image aktualisieren, wenn es die aws Cli aktualisiert, einschließlich historischer Tags.

+1

+1 Schade, dass Amazon das nicht anbietet

Ich habe seitdem ein weiteres Bild hinzugefügt, das praktisch war. Es kombiniert Docker in Docker mit der AWS- und SAM-CLI, was für eine perfekte ECR-Integration sorgt.

dind-aws-cli

+1

Es gibt zwar jede Menge inoffizielle Bilder, die gut gepflegt sind, aber was hält sie davon ab, eines Tages zu sagen: "Pfft, was bringt es noch, das zu aktualisieren. Das ist Amazons Job!"

+1

+1

Wenn es darum geht, Menschen dabei zu helfen, ihre Arbeit mit AWS zu automatisieren, scheitert Amazon stark. Dies ist einer der Gründe, warum wir daran denken, sie zu verlassen.

Gibt es eine offizielle Antwort von den Betreuern, ob dies bereits auf einer Roadmap steht oder nicht? Wie viele andere würde ich auch lieber ein offizielles Bild verwenden...

+1

Wenn es ein offizielles Image für die AWS CLI gäbe, wäre es eine ausführbare Datei in einem Scratch-Container. Da dies für Einzelpersonen nicht unglaublich nützlich wäre, ist es am besten:

  • Verwenden Sie einen offiziellen Python-Container, um die CLI aus dem Quellcode zu erstellen
  • Kopieren Sie die resultierende AWS CLI-Binärdatei in eine Busybox oder einen Scratch-Container

Alles andere wäre Over-Engineering, trotz aller Debatten, die hier stattfinden.

AWS liebt es, alle seine ECR- und CodeDeploy-Services zu demonstrieren. Warum werden sie nicht all diese Feuerkraft auf ihre eigene containerisierte CLI richten?

Denn das Angebot, das auf dem Tisch liegt, scheint jemand aus der Community zu haben, um es aufrechtzuerhalten.

@balibebas jemand aus der Community macht es bereits. Es gibt eine Menge Bilder da draußen - aber der Punkt hier ist, dass es eines von AWS geben würde, weil ich randomguy/aws-cli:canbechangedanytime in meiner CI-Umgebung nicht mit all den Geheimnissen weit offen ausführen möchte.

Was würdest du dann zu F-Droid sagen?

es ist für dieses Thema genauso relevant wie diese Katze:

Sie klingen wie ein zahlender Kunde.

Nun, vielleicht liegt das daran, dass _ich_ _am_

Predigt im Chor. Jedenfalls hatte die Brew-Formel eine bessere Chance, weil sie länger getrollt wurde, immer noch ohne Bewegung. Katzenfotos werden also sofort kontraproduktiv, wenn es keinen allgemeinen Anwendungsfall außerhalb eines Scratch- oder Busybox-Containers gibt, wie ich bereits erwähnt habe. Was ist Ihr Designvorschlag?

Ich und viele andere verwenden derzeit "Busybox-Container", um sie beispielsweise mit Docker auszuführen, um ECR-Authentifizierungsdaten zu erhalten. wenn man bedenkt, wie viele Docker Things aws hat, macht es keinen Sinn, dass es keine offizielle Verpackung gibt.

Vielleicht sind sie nur auf etwas anderes gefasst. ;)

Ich bin froh, dass wir das jetzt geklärt haben. Zurück zu +1 Kommentaren:

+1 für Dockerless

@matti @balibebas Denken Sie daran, dass derzeit allein 64 Personen an der Konversation dieser Ausgabe teilnehmen und jede Antwort eine nicht hilfreiche E-Mail und Benachrichtigung auslöst, die möglicherweise an jede dieser 64 und mehr Personen gesendet wird, die abonniert sind. Diese Nachricht wird dasselbe tun, und ich entschuldige mich dafür.

Aber wirklich, bitte halten Sie die Dinge professionell. Katzenbilder sind zwar nett, aber je weiter dieser Thread aus der Bahn gerät, desto weniger wahrscheinlich ist es, dass er von den Betreuern ernst genommen wird. Leider ist Spam Spam ist Spam.

Das ist, was der Abmelden-Button tut, den ich gerade angeklickt habe.

Das wäre gut zu haben. Ich bin nur überrascht, dass keine Maßnahmen ergriffen werden oder dies beibehalten wird (einschließlich NEIN gesagt wird).
Wie auch immer, die oben genannten Personen haben zu Recht auf die Bedeutung eines offiziellen aws-cli-Images hingewiesen.
Ich denke, die Leute verwenden bereits ihre eigenen privat oder über die von jemand anderem erstellte Image- / Paketmanagerroute usw.
Noch ein weiteres Beispielskript dafür

Aber das einfachste und unvermeidbare Problem bleibt dasselbe.

  • Die endlose Liste von Abhängigkeiten und Unsicherheiten, die auftaucht, wenn es von den Entwicklern abhängt, Dinge selbst zu integrieren. Wird schließlich zu mehr Problemen im Repo führen, da die Leute damit beginnen werden, eine Sache dann eine andere und dann ein paar andere zu installieren, um Arbeit zu erledigen, die die Umgebung kontaminiert, was den Zweck von CI/CD oder ähnlichen Werken, isoliert und makellos zu sein, zunichte macht.
  • Es ist schwer zu vertrauen, das Docker-Image anderer für Ihre Arbeit zu implementieren und zu verfolgen. Dies führt dazu, dass eine weitere Pipeline und ein weiterer Eintrag in der Docker-Registrierung für ein neues awscli-Image hinzugefügt werden, ein weiteres Repository, dh eine andere Sache, die gewartet werden muss.
  • In CI/CD bevorzuge ich es, nur das Bild (unser internes oder offizielles) zu verwenden und Skriptzeilen zu vermeiden, um so viel wie möglich hinzuzufügen.
  • Problem mit Build & Libs, da das offizielle Image sofort aus den Quellversionen selbst erstellt werden kann und weniger dynamische Abhängigkeiten bezüglich des Paketmanagers hat und was nicht.

anders
=> Am Ende macht jeder seine eigenen.

Das gleiche hier, derzeit verwende ich ein selbstgebautes Image, würde aber ein offizielles Image unter dem bevorzugen

Namensraum. Ich verwende es, um andere Docker-Images zu erstellen und sie an ECR zu übertragen, wo die awscli benötigt wird, um die Anmeldeinformationen abzurufen.

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/*

Es sollte nicht so schlimm sein, dies zu Ihrer awscli-Build-Pipeline hinzuzufügen ... :)

--

Ich habe das Dockerfile gemäß @mikesir87- Vorschlag aktualisiert, danke dafür (das ist ein weiterer Grund, ein Standard-Image mit Beiträgen der Community zu haben, um das kleinste Image zu erhalten)

Es tut mir leid, dass ich alle spamme, aber ich wollte darauf hinweisen (falls jemand anderes das Snippet von @jens-meiss verwenden möchte), dass Sie _wirklich_ erwägen sollten, Ihre drei RUN Anweisungen zu einer einzigen Anweisung zu verketten. Andernfalls versenden Sie immer noch den Inhalt von py-pip und die APK-Caches in den Zwischenschichten, obwohl Ihr endgültiger Container nicht darauf zugreifen kann.

In einer anderen Anmerkung bringt der Kommentar einen weiteren gültigen Anwendungsfall hervor ... wenn Sie die aws-cli nur verwenden, um Anmeldeinformationen für ECR zum Pushen von Bildern abzurufen. Dies klingt nach der Notwendigkeit, den ECR-Anmeldeinformationshelfer auch in einem Bild zu verpacken. Es würde es sicherlich leicht machen, Bilder zu erstellen und zu übertragen, ohne die vollständige aws-cli zu benötigen.

Hallo zusammen, Betreuer hier. Wollte nur klarstellen, das passiert gerade, wir machen das.

Wir sind dabei, intern eine bessere Release-Infrastruktur aufzubauen, um mehr Arten von Release-Artefakten erstellen/testen/unterstützen zu können, insbesondere da wir mehr Release-Artefakte für cli v2 ausliefern werden.

Wir haben im Moment keinen genauen Zeitplan, aber es passiert.

Laut Amazon-Entwicklern und vielen anderen einfach zu machen, aber nach 2 Jahren und ohne ETA immer noch warten

+1

Interne Freigabeinfrastruktur (2019 Q4)
Bewertung des Rechtsteams (2020 Q1)
öffentliche Beta unter aws/cli-dev-test (2020 Q2)
endgültige Veröffentlichung (2020 Q3)

In diesem optimistischen Zeitplan werden Sie in weniger als 10 Monaten das bekommen, was Sie wollen. 🥇

Warten auf Jeff Barrs Blogbeitrag

Darauf warte ich verdammt noch mal.

Können wir wenigstens eine offizielle Ankündigung oder Zusage bekommen? Vielleicht eine Zielfreigabe?

@bhmckendrick ist eine Verpflichtung nicht genau das, was dieser Kommentar nicht zu weit über deinem steht?

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

über ein Jahr alt und keine Updates? Bild?

hey @jamesls , würdest du in Erwägung

Die Anzahl der Leute, die völlig nicht bereit sind zu lesen ( Hinweis Hinweis ) und sich stattdessen dafür entscheiden, mehr als 70 Zuschauer zu spammen, weil sie _speziell_ verärgert sind, verringert sicherlich das Interesse aller, diesem Thread zu folgen, drastisch.

Vielen Dank auch für Ihre Arbeit, um dies zu ermöglichen!

Als der ursprüngliche Autor dieser Ausgabe (nun, ich war gerade mutig genug, die zuvor geschlossenen "wontfix"-Dateien zu kopieren / einzufügen) habe ich diese Ausgabe bereits wegen des massiven +1-Spams und gelegentlicher Kämpfe mit Katzenbildern abgemeldet (sorry) .

Passen Sie einfach die Benachrichtigungseinstellungen an, damit Sie nur Benachrichtigungen erhalten, wenn dieses Problem geschlossen ist.

Ich möchte nur darauf hinweisen, dass abgesehen von CI/CD einige Entwickler (siehe @LongLiveCHIEF) lieber dockerisierte Entwicklungsumgebungen haben und Dinge nicht gerne nativ installieren oder sich mit den daraus resultierenden Versionsmanagern für die Muttersprachen, auf die diese CLI-Tools unweigerlich angewiesen sind.

Es ist einfacher zu docker pull aws-cli als die bestehenden Installationsschritte ... ganz zu schweigen davon, dass Sie, wenn Sie kein Python-Entwickler sind, den Aufwand haben, eine gute Python-Version und -Umgebung für Ihren Benutzer einzurichten, oder vielleicht sogar jedes Projekt.

Skalieren Sie dies auf all die verschiedenen Tools, die ein Entwickler verwenden könnte (rubybasierte clis, knotenbasierte clis), und Sie müssen Umgebungskonfigurationen für Sprachen lernen, in denen Sie möglicherweise nie codieren.

Der Punkt, den ich hier anspreche, ist, dass Docker Run allgegenwärtig ist und alle muttersprachlichen Setups/Konfigurationen beseitigt und die Dinge für Benutzer einfach macht.

Selbst wenn Benutzer ihre eigenen Docker-Images erstellen, müssen sie sich dennoch mit diesen Setup-Aufgaben herumschlagen.

Ich programmiere nicht in Python, aber ich war gezwungen, die Vor- und Nachteile virtueller Umgebungen und deren Best Practices aus verschiedenen Python-Versionen zu lernen, nur weil Toolanbieter dies für "trivial" halten.

Nicht alle Entwickler haben den gleichen Hintergrund wie die Entwickler des Tools, und die Bereitstellung eines Docker-Images ist ein Zeichen des Respekts. Die Tool-Anbieter können den Overhead muttersprachlicher spezifischer Umgebungseigenheiten sehr schnell und einfach übernehmen, während die Anwender viel mehr Zeit aufwenden müssen, um diesen Overhead während der verschiedenen Lebenszyklusphasen der Entwicklung Ihres Produkts zu verwalten.

Essen dafür.

@jamesls Danke, dass hast . Während Sie auf die offiziell gehosteten Docker-Images warten, kann ein hilfreicher Zwischenschritt darin bestehen, hier Installationsempfehlungen für einige beliebte Basis-Docker-Images zu posten (z. B. node, alpine, ubuntu, amazon2, python). Dies wäre für uns sofort wertvoll.

Da ich für ein großes Unternehmen arbeite, möchte ich Ihnen Folgendes anbieten:
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

Das sieht nicht gut gepflegt aus, aber hier ist noch eins

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

Ich habe das gerade in freier Wildbahn entdeckt: https://hub.docker.com/r/amazon/aws-cli

Es scheint, dass es endlich da ist :)

@pablosjv Es ist kein offizielles oder zertifiziertes Bild. Seien Sie sich dessen bewusst.

@anjakammer Es scheint ein offizielles Amazon-Image zu sein , obwohl es kein offizielles Image ist, das von Docker veröffentlicht wurde .

Ich weiß nicht, ob es produktionsreif ist, weil sie in dieser Ausgabe noch nichts gesagt haben.

Neugierig, wie dieses AWS-Image 98,42 MB groß ist, während andere (zB atlassian/pipelines-awscli ) viel kleiner sind.

CLI-Teammitglied hier. Ja, ich kann bestätigen, dass wir offiziell ein Docker-Image für die AWS CLI v2 veröffentlicht haben! Ich empfehle folgendes zu lesen:

Ich werde dieses Thema abschließen. Wenn Sie Feedback oder Fragen zum Image haben, öffnen Sie bitte ein weiteres GitHub-Problem in diesem Repository.

Als Öffner der ursprünglichen Ausgabe #3291 vor vielen Jahren ist mein schmerzendes ❤️ mit solcher Freude erfüllt, dass meine Bedenken endlich bestätigt werden und ein offizielles Docker-Image jetzt verfügbar ist. Pot Shots darüber, wie lange es gedauert hat, dieses Bild zu erstellen, beiseite, ich bin sicher, das war viel leichter gesagt als getan, also ein großes Dankeschön an die Amazon-Entwickler, die dies ermöglicht haben. Sie alle leisten hervorragende Arbeit. 👏🎉👏

_Okay Alexa, ich habe ihnen gedankt, bitte lass meine Familie jetzt gehen._

Ist das Dockerfile überall verfügbar?

@zerkms Aha, habe es im v2 Zweig gefunden:
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

Ich denke, sie tun es endlich, aber ich konnte es nicht auf Gitlab CI https://hub.docker.com/r/amazon/aws-cli . zum Laufen bringen

Ich verwende stattdessen das AWS CLI-Docker-Image von Gitlab, und es funktioniert perfekt. Benutz einfach

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

AKTUALISIEREN:

Das obige Bild ist veraltet, verwenden Sie stattdessen das neue.

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

Beachten Sie, dass Sie zur Verwendung des Bilds in GitLab CI manuell einen leeren Einstiegspunkt setzen müssen, da das amazon/aws-cli Bild den Einstiegspunkt auf /usr/local/bin/aws . Ein Beispiel...

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

@ mikesir87 warum ist das so?

@pSnehanshu Ich denke, das liegt daran, dass Sie das Image so ausführen, als wäre es die Cli selbst, wie docker run --rm amazon/aws-cli <<command>> , was der Ausführung der Cli mit aws <<command>> ähneln würde, anstelle von docker run --rm amazon/aws-cli aws <<command>> . Jeder Ansatz hat Vor- und Nachteile, je nachdem, was Sie bevorzugen und wie Sie das Image ausführen, aber das Überschreiben des Einstiegspunkts sollte trotzdem ausreichen.

@lucasbasquerotto Ich habe mich sowieso mit dem Image von Gitlab zufrieden gegeben. Danke jedenfalls für die Erklärung.

Falls jemand immer noch daran interessiert ist, AWS CLI v2 unter Alpine Linux zum Laufen zu bringen, hier ist ein Beispiel-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/

Das Problem war, dass AWS CLI v2 GLIBC verwendet, Alpine Linux jedoch nur begrenzte GLIBC-Unterstützung bietet (es verwendet "musl", eine leichte Alternative). Das obige Dockerfile installiert die fehlenden glibc-Bibliotheken und verwendet ein mehrstufiges Dockerfile, um das endgültige Image klein zu halten. Mit etwas Aufwand können wir die Bildgröße wahrscheinlich noch weiter reduzieren, indem wir nur die wirklich benötigten Dateien aus /usr/lib einbinden.

Nach einigen Refactorings ist es mir gelungen, die Bildgröße noch weiter zu reduzieren:

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/*

Der Autovervollständigungsindex und die Beispieldateien werden entfernt, und auch 'groff' wird entfernt (ich gehe davon aus, dass die Leute keine Hilfeseiten in ihren Docker-Images benötigen)

Dies ist sehr einfach, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile und erledigt den Job, aber lassen Sie mich über meine Github-Probleme wissen, wenn im Image noch etwas benötigt wird (gültiger Anwendungsfall).

Dies ist sehr einfach, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile und erledigt den Job, aber lassen Sie mich über meine Github-Probleme wissen, wenn im Image noch etwas benötigt wird (gültiger Anwendungsfall).

Das obige APK basiert auf AWS-CLI 1.18, nicht auf der v2-CLI.

Besteht die Möglichkeit, dass Amazon in Betracht zieht, ein Image mit Version 1 der CLI zu erstellen?

@keeganwitt Sie sollten eine neue Ausgabe für diese Anfrage öffnen. :+1:

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen