Aws-cli: Una imagen de Docker oficial con la AWS CLI para usar en escenarios de CI / CD

Estoy aquí porque yo también estoy buscando una imagen de docker oficial aws-cli para usar en mi entorno CI / CD. En su lugar, ahora voy a crear OTRA canalización para crear una imagen de la ventana acoplable que incluye el aws cli cuando podría hacer referencia a la oficial en mi canalización original.

Además ... alguien más también lo entiende https://hub.docker.com/r/google/cloud-sdk.

@matti y @nscavell , Gracias por dar seguimiento a este tema. Parece que hay suficiente interés en esta solicitud de función para mantener esto abierto. Este problema se utilizará para rastrear una imagen oficial de Docker para la AWS CLI. Haz +1 en él para mostrar interés y ayudarnos a priorizar esto.

Gracias.

No se considera +1 dañino;)

De todos modos, este es el tercer (?) Problema creado sobre esto ...

👍 agregar mi +1

Tengo que crear mi propia imagen de la ventana acoplable para incluir solo awsCLI en mi CI. Preferiría una oficial

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Aquí hay una imagen alpina (posterior a la corrección) con el cli más reciente instalado para cualquier otra persona que busque una versión reciente mientras tanto.

@justnance suficiente?

+1

+1

+1

+1

Otra razón es que cuando se usa un sistema operativo como coreOS que no tiene administración de paquetes, la forma idiomática de ejecutar las cosas es a través de un contenedor. Me sorprende que incluso se cuestione la necesidad de esto, es una omisión obvia. 👍

+1

: +1:

+1

+1

+1

+1

+1

Como abridor de # 3291 (el primero de los tres problemas citados jajaja), me alegra ver que este problema finalmente está ganando terreno. Para todos los que respondan en el futuro, cuando @justnance dice "Por favor,

+1 para mantener notificados a los propietarios de repositorios

+1

Cuando le dicen a +1 un problema, lo que quieren decir es hacer clic en el botón 👍. No ayuda a los desarrolladores tener 100 comentarios en los que cada uno diga "+1". ¡Cuanto más sepas!

@davidham - Gracias por aclarar y a todos por responder. Secundo que. Utilice las reacciones de GitHub y haga clic en el botón 👍.

Dije lo mismo hace 2 días pero oye, todos estamos del mismo lado 🙃

+1

+1

+1

+1

+1

+1

+1

¿Puedes dejar de hacer +1? si quieres hacer +1, hazlo en la parte superior.

Está perdiendo un valioso tiempo de ingeniería. Somos una docena de suscriptos a este número ...

He mantenido una imagen aws-cli durante más de dos años. Siéntase libre de usarlo si es necesario (lo uso varias veces al día). Recibo actualizaciones sobre lanzamientos de nuevas versiones (a través de IFTT) y envío actualizaciones con bastante rapidez. A pesar de la fama y la gloria de ejecutar mi propia imagen (¡ja!), _Con gusto_ aplazaré y presionaré a la gente para que use una imagen oficial.

• Repositorio de GitHub
• Docker Hub

Después de haber usado mi imagen durante mucho tiempo, diré que sería _super_ útil si la imagen oficial incluyera jq (ya que la API es JSON pesada). Hace que sea muy conveniente hacer cosas como "tomar la última definición de tarea de ECS, hacer un cambio y retroceder", todo en una sola etapa de canalización de CI / CD.

Otra solución alternativa al problema: https://hub.docker.com/r/somedeveloper/aws-cli/

Razones para usar:

• Lo mantiene simple.
• Utiliza python3.7-stretch oficial como imagen base.
• Utiliza la estrategia recomendada por AWS para la instalación: python + pip. ver aquí .
• Incluye aws-sam-cli para aquellos nerds sin servidor 8-).
• Es público y no requiere inicio de sesión.
• Excelente para canalizaciones de CI / CD: no lo he usado para nada más, por lo que no he sopesado los pros y los contras.

Todavía esperando una imagen oficial. Piensa en la gente ahora

https://hub.docker.com/r/google/cloud-sdk/ . Lo siento chicos. Es una tarea muy difícil para un gigante como AWS.

+1

No se considera +1 dañino;)

De todos modos, este es el tercer (?) Problema creado sobre esto ...

Cuarto, si considera https://github.com/aws/amazon-linux-docker-images/issues/10.

¿No podemos simplemente ponerlo en CircleCI y terminar con él? Feliz de ayudar con Dockerfile o pipeline.

Me pregunto si hay restricciones internas y / o papeleo dentro de Amazon que evite que los desarrolladores realicen este trabajo aparentemente trivial ...

k lol

Hay algunas variantes que sería bueno tener en una imagen "oficial". Por ejemplo, actualmente estoy buscando tomar un contenedor con aws cli y curl (para verificar el punto final de metadatos de IAM) y sería muy útil encontrar uno que pudiera simplemente tomar y conectar en mi implementación de k8s.

También existe una razón de seguridad para proporcionar imágenes oficiales.

Simplifica el modelo de amenazas al eliminar la dependencia de una "persona aleatoria en Internet", manteniendo la imagen que se usa en objetivos de alto valor como las canalizaciones de CI / CD que generalmente brindan mucho acceso a sus sistemas.

Me gustaría una imagen de la ventana acoplable aws-cli oficial basada en la imagen de la ventana acoplable: 18 (estable actual) (https://hub.docker.com/_/docker), por ejemplo. aws-cli-docker-18 porque me gustaría crear mi imagen de Docker en mi entorno CI / CD que actualmente usa la imagen docker:18 y publicarla en AWS ECR.

+1

+1

Sería fantástico que las personas se abstuvieran de comentar cuando su comentario no contribuya al problema en cuestión. Los comentarios como "+1" simplemente introducen spam para los suscriptores y hacen que el problema sea más extenso de lo necesario. En su lugar, apruebe el primer comentario del problema.

Sería fantástico que las personas se abstuvieran de comentar cuando su comentario no contribuya al problema en cuestión. Los comentarios como "+1" simplemente introducen spam para los suscriptores y hacen que el problema sea más extenso de lo necesario. En su lugar, apruebe el primer comentario del problema.

Esta edición está abierta desde septiembre del año pasado. Creo que debemos pedirle a AWS que analice este tema nuevamente, ya que obviamente hay interés en él. Deberíamos decirnos cuánto interés es "suficiente".

ya que obviamente hay interés en él

No solo interés, sino que es el tema abierto con más : +1: reacciones :

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

El segundo con más reacciones se abrió en 2014 y el tercero en 2015, mientras que este número se abrió en septiembre de 2018 (hace menos de un año ).

+1000

Tengo problemas en mi máquina local todo el tiempo para configurar las dependencias correctas para que aws-cli funcione. Por lo tanto, decidí cambiar a aws-cli dentro de la ventana acoplable. Encontré varias imágenes disponibles públicamente en docker-hub PERO porque no son oficiales, no confío en ellas de forma predeterminada, por lo que cada vez que hay una versión actualizada disponible tengo que buscar y encontrar nuevamente una imagen en la que se pueda confiar. y es seguro de usar. AWS cree, mantenga y proporcione una imagen de la ventana acoplable aws-cli segura mediante el concentrador de la ventana acoplable. Gracias por adelantado

Hay una gran fragmentación de imágenes aws-cli proporcionadas por la comunidad. Pero, como se mencionó anteriormente: la gente preferiría uno que sea mantenido y respaldado oficialmente por Amazon. Varias razones por las que:

1) No se quedará obsoleto: las imágenes de la comunidad son conocidas por volverse obsoletas con el tiempo;
2) Más seguro: proviene de un recurso confiable, no importa cuán confiable pueda ser un miembro de la comunidad, no representan oficialmente a Amazon, por lo tanto, "todas las garantías se anulan";
3) Soporte oficial significa soporte oficial en caso de errores, conflictos de versiones, compatibilidades con versiones anteriores, etc.
4) AWS puede actualizar su imagen a medida que actualiza el aws cli, incluidas las etiquetas históricas.

+1

+1 Es realmente lamentable que Amazon no proporcione este

Desde entonces he añadido otra imagen que ha sido útil. Combina Docker en Docker con AWS y SAM CLI, lo que lo convierte en una perfecta integración de ECR.

dind-aws-cli

+1

Si bien hay un montón de imágenes no oficiales que están bien mantenidas, ¿qué les impedirá algún día decir "Pfft, cuál es el punto de actualizar esto más? ¡Este es el trabajo de Amazon!"

+1

+1

Cuando se trata de ayudar a las personas a automatizar su trabajo con AWS, Amazon está fallando a lo grande, esta es una de las razones por las que estamos pensando en dejarlos.

¿Existe una respuesta oficial de los mantenedores con respecto a si esto está o no en una hoja de ruta todavía? Como muchos otros, preferiría usar una imagen oficial también ...

+1

Si hubiera una imagen oficial para la AWS CLI, sería un ejecutable dentro de un contenedor temporal. Porque eso no sería increíblemente útil para las personas, lo mejor sería:

• Use un contenedor de Python oficial para construir la CLI desde la fuente
• Copie el binario resultante de la AWS CLI en un contenedor busybox o temporal

Cualquier otra cosa sería un exceso de ingeniería a pesar de los debates que se produzcan aquí.

A AWS le encanta hacer demostraciones de todos sus servicios ECR y CodeDeploy. ¿Por qué no dirigen toda esa potencia de fuego a su propia CLI en contenedores?

Porque la oferta sobre la mesa parece que es para que alguien de la comunidad la mantenga.

@balibebas alguien de la comunidad ya lo está haciendo. Hay un montón de imágenes por ahí, pero el punto aquí es que habría una de AWS, porque no quiero ejecutar randomguy/aws-cli:canbechangedanytime en mi entorno de CI con todos los secretos abiertos.

¿Qué dirías entonces de F-Droid?

es tan relevante para este problema como este gato:

Suenas como un cliente que paga.

bueno tal vez sea porque _ yo_ _am_

Predicando al coro. De todos modos, la fórmula de Brew tenía más posibilidades porque ha sido trolleada por más tiempo, todavía sin movimiento. Entonces, las fotos de gatos se vuelven inmediatamente contraproducentes cuando no hay un caso de uso general fuera, tal vez un contenedor de scratch o busybox, como señalé anteriormente. ¿Cuál es tu propuesta de diseño?

Yo y muchos otros estamos haciendo "contenedores de busybox", por ejemplo, para ejecutarlo con Docker para obtener las credenciales de autenticación de ECR. Dada la cantidad de cosas de Docker que tiene AWS, no tiene sentido que no exista un empaque oficial.

Tal vez solo estén en otra cosa. ;)

Me alegro de que hayamos solucionado esto ahora. Volver a los comentarios +1:

+1 para Dockerless

@matti @balibebas Tenga en cuenta que en este momento hay 64 personas solo en la conversación de este número, y cada respuesta genera un correo electrónico y una notificación inútiles que potencialmente se envía a cada una de esas 64 personas y más que están suscritas. Este mensaje hará lo mismo, y me disculpo por eso.

Pero en serio, mantén las cosas profesionales. Si bien las imágenes de gatos son agradables, cuanto más se descarrila este hilo, creo que es menos probable que los mantenedores lo tomen en serio. Desafortunadamente, el spam es spam.

Eso es lo que hace el botón para cancelar la suscripción, el que acabo de hacer clic.

Sería bueno tenerlo. Solo me sorprende que no se esté tomando ninguna medida o que esto se mantenga (incluye que se diga NO).
De todos modos, las personas de arriba han señalado con razón la importancia de una imagen oficial de aws cli.
Creo que las personas ya están usando las suyas de forma privada o a través de la ruta de gestión de paquetes / imágenes de otra persona, etc.
Otro ejemplo de guión para el mismo

Pero el problema más simple e inevitable sigue siendo el mismo.

• La lista interminable de dependencias e incertidumbres que aparece si depende de que los desarrolladores integren las cosas por su cuenta. Eventualmente conducirá a más problemas en el repositorio, ya que la gente comenzará instalando una cosa, luego otra y luego algunas otras para hacer el trabajo contaminando el entorno, lo que frustra el propósito de CI / CD o trabajos similares de estar aislado y prístino.
• Es difícil de confiar para implementar y rastrear la imagen de Docker de otra persona para su trabajo. Esto lleva a realizar otra adición de canalización y entrada en el registro de la ventana acoplable para la nueva imagen awscli, otro repositorio, es decir, otra cosa que mantener.
• En CI / CD, mi preferencia es simplemente usar la imagen (nuestra interna u oficial) y evitar las líneas de scripting para agregar cosas tanto como sea posible.
• El problema con la compilación y las bibliotecas como imagen oficial se puede compilar de inmediato a partir de las versiones de origen y tener menos dependencias dinámicas con el administrador de paquetes y otras cosas.

demás
=> Todos terminan haciendo los suyos.

Lo mismo aquí, actualmente uso una imagen de autoconstrucción, pero preferiría una imagen oficial debajo de la

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

espacio de nombres. Lo uso para crear otras imágenes de la ventana acoplable y enviarlas a ECR, donde se necesita awscli para obtener las credenciales.

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

No debería ser tan importante agregar esto a su tubería de compilación awscli ... :)

-

He actualizado el Dockerfile de acuerdo con la sugerencia de @ mikesir87 , gracias por eso (esa es otra razón para tener una imagen estándar con contribuciones de la comunidad para obtener la imagen más pequeña)

Perdón por enviar spam a todos, pero quería señalar (en caso de que alguien más quiera usar el fragmento de @ jens-meiss) que deberías _realmente_ considerar encadenar tus tres declaraciones RUN en una sola declaración. De lo contrario, todavía está enviando el contenido de py-pip y los cachés de apk en las capas intermedias, aunque su contenedor final no pueda acceder a ellos.

En otra nota, el comentario muestra otro caso de uso válido ... cuando está usando aws-cli solo para obtener credenciales para que ECR envíe imágenes. Esto suena como una necesidad de empaquetar el asistente de credenciales ECR en una imagen también. Sin duda, facilitaría la creación y el envío de imágenes sin necesidad de aws-cli completo.

Hola a todos, mantenedor. Solo quería aclarar, esto está sucediendo, lo estamos haciendo.

Estamos en el proceso de desarrollar una mejor infraestructura de lanzamiento internamente para poder construir / probar / admitir más tipos de artefactos de lanzamiento, especialmente porque enviaremos más artefactos de lanzamiento para cli v2.

No tenemos una línea de tiempo exacta en este momento, pero está sucediendo.

Algo fácil de hacer según los desarrolladores de Amazon y muchos otros, pero todavía esperando después de 2 años y sin ETA 😂

+1

Infraestructura de liberación interna (cuarto trimestre de 2019)
evaluación del equipo legal (2020 Q1)
beta pública bajo aws / cli-dev-test (2020 Q2)
versión final (2020 Q3)

En esta línea de tiempo optimista, obtendrá lo que desea en menos de 10 meses. 🥇

esperando la entrada del blog de jeff barrs

Estoy esperando esto.

¿Podemos al menos conseguir un anuncio o compromiso oficial? ¿Quizás un lanzamiento objetivo?

@bhmckendrick es un compromiso, ¿no es exactamente lo que es este comentario no muy por encima del tuyo?

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

¿Tiene más de un año y no hay actualizaciones? ¿Imagen?

Hola @jamesls , ¿considerarías bloquear este hilo hasta que tengas algo para compartir?

la cantidad de personas que no están dispuestas a leer ( sugerencia ) y, en su lugar, optar por enviar spam a más de 70 espectadores sobre cómo ellos _específicamente_ están molestos, estoy seguro, está disminuyendo drásticamente el interés de todos en seguir este hilo.

también, ¡gracias por su trabajo para que esto suceda!

Como autor original de este número (bueno, fui lo suficientemente valiente como para copiar / pegar los "wontfix" previamente cerrados) ya me he dado de baja de este número debido al spam +1 masivo y las peleas ocasionales con imágenes de gatos (lo siento) .

Simplemente ajuste la configuración de notificaciones para que solo reciba notificaciones si este problema está cerrado.

Solo me gustaría señalar que, aparte de CI / CD, algunos desarrolladores (consulte @LongLiveCHIEF) prefieren tener entornos de desarrollo acoplados y no les gusta instalar cosas de forma nativa o tener que lidiar con los administradores de versiones subsiguientes para el idiomas nativos en los que inevitablemente se basan esas herramientas cli.

Es más fácil docker pull aws-cli que cualesquiera que sean los pasos de instalación existentes ... sin mencionar que si no es un desarrollador de Python, tiene la sobrecarga de configurar una buena versión y entorno de Python para su usuario, o quizás incluso cada proyecto.

Escale eso a todas las diferentes herramientas que un desarrollador podría usar (cli basado en ruby, cli basado en nodo), y debe aprender configuraciones de entorno para lenguajes en los que quizás nunca codifique.

El punto que estoy diciendo aquí es que la ejecución de la ventana acoplable es ubicua y elimina cualquier configuración / configuración del idioma nativo, y facilita las cosas a los usuarios.

Incluso si los usuarios crean sus propias imágenes de la ventana acoplable, todavía tienen que luchar con esas tareas de configuración.

No codifico en Python, pero me he visto obligado a aprender los entresijos de los entornos virtuales y sus mejores prácticas de varias versiones de Python, simplemente porque los proveedores de herramientas lo consideran "trivial".

No todos los desarrolladores tienen los mismos antecedentes que los que crearon la herramienta, y proporcionar una imagen de la ventana acoplable es una señal de respeto. Los proveedores de herramientas pueden asumir la sobrecarga de las peculiaridades del entorno específico del idioma nativo de forma muy rápida y sencilla, mientras que los adoptantes tienen que dedicar mucho más tiempo a gestionar esta sobrecarga a través de las diversas etapas del ciclo de vida del desarrollo de su producto.

Sin embargo, comida.

@jamesls Gracias por escuchar los comentarios de la comunidad aquí. Mientras espera las imágenes de la ventana acoplable alojadas oficiales, un paso intermedio útil podría ser publicar recomendaciones de instalación para algunas imágenes populares de la ventana acoplable base aquí (por ejemplo, node, alpine, ubuntu, amazon2, python). Esto sería inmediatamente valioso para nosotros.

Mientras trabajo para una gran empresa, déjame servirte con esto:
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

Esto no parece estar bien mantenido, pero aquí hay otro

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

Acabo de ver esto en la naturaleza: https://hub.docker.com/r/amazon/aws-cli

Parece que finalmente está aquí :)

@pablosjv no es una imagen oficial ni certificada. Sea consciente de eso.

@anjakammer Parece que es una imagen oficial de Amazon , aunque no es una imagen oficial publicada por Docker .

No sé si está listo para la producción, porque todavía no dijeron nada en este número.

Es curioso cómo esta imagen de AWS tiene 98,42 MB, mientras que otras (por ejemplo, atlassian / pipelines-awscli ) son mucho más pequeñas.

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

Miembro del equipo CLI aquí. Sí, puedo confirmar que hemos lanzado oficialmente una imagen de Docker para AWS CLI v2. Recomiendo leer lo siguiente:

• Publicación de blog que lo presenta: https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/
• Entrada de la guía del usuario: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html
• Repositorio de DockerHub: https://hub.docker.com/r/amazon/aws-cli

Voy a cerrar este problema. Si tiene comentarios o preguntas sobre la imagen, abra otro problema de GitHub en este repositorio.

Como abridor del número original # 3291, hace muchos años, mi dolor ❤️ está lleno de alegría al ver mis inquietudes finalmente validadas y una imagen oficial de Docker ahora disponible. Fotos de bote sobre cuánto tiempo tomó hacer esta imagen a un lado, estoy seguro de que fue mucho más fácil decirlo que hacerlo, así que muchas gracias a los desarrolladores de Amazon que hicieron que esto sucediera. Todos ustedes hacen un trabajo excelente. 👏🎉👏

_Está bien Alexa, les di las gracias, por favor dejen ir a mi familia ahora.

¿El Dockerfile disponible en algún lugar?

@zerkms Aha, lo encontré en la rama v2 :
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

Supongo que finalmente lo están haciendo, pero no pude hacer que se ejecutara en Gitlab CI https://hub.docker.com/r/amazon/aws-cli

En cambio, estoy usando la imagen de la ventana acoplable AWS CLI de Gitlab y funciona perfectamente. Solo usa

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

ACTUALIZAR:

La imagen de arriba está obsoleta, use la nueva en su lugar.

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

Tenga en cuenta que para usar la imagen en GitLab CI, deberá establecer manualmente un punto de entrada vacío, ya que la imagen amazon/aws-cli establece el punto de entrada en /usr/local/bin/aws . Un ejemplo...

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

@ mikesir87 ¿por qué?

@pSnehanshu Creo que es porque ejecutas la imagen como si fuera el cli en sí, como docker run --rm amazon/aws-cli <<command>> , que sería similar a ejecutar el cli con aws <<command>> , en lugar de docker run --rm amazon/aws-cli aws <<command>> . Hay pros y contras con cada enfoque, según lo que prefiera y la forma en que ejecuta la imagen, pero anular el punto de entrada debería funcionar de todos modos.

@lucasbasquerotto Me he conformado con la imagen de Gitlab de todos modos. De todos modos, gracias por la explicación.

En caso de que alguien todavía esté interesado en que AWS CLI v2 funcione en Alpine Linux, aquí hay un Dockerfile de ejemplo:

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/

El problema fue que AWS CLI v2 usa GLIBC, pero Alpine Linux tiene soporte GLIBC limitado (usa 'musl', una alternativa liviana). El Dockerfile anterior instala las bibliotecas glibc que faltan y usa un Dockerfile de múltiples etapas para mantener pequeña la imagen final. Con un poco de esfuerzo, probablemente podamos reducir el tamaño de la imagen aún más incluyendo solo los archivos de / usr / lib que realmente son necesarios.

Después de algunas refactorizaciones, logré reducir aún más el tamaño de la imagen:

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

El índice de autocompletar y los archivos de ejemplo se eliminan, y también se elimina 'groff' (supongo que las personas no necesitan páginas de ayuda en sus imágenes de Docker)

Esto es muy simple, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile y hace el trabajo, pero avíseme a través de mis problemas de github si se necesita algo más en la imagen (caso de uso válido).

Esto es muy simple, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile y hace el trabajo, pero avíseme a través de mis problemas de github si se necesita algo más en la imagen (caso de uso válido).

El APK anterior se basa en AWS-CLI 1.18, no en la CLI v2.

¿Alguna posibilidad de que Amazon considere crear una imagen con la versión 1 de la CLI?

@keeganwitt Debes abrir un nuevo problema para esa solicitud. : +1: