Aws-cli: Uma imagem oficial do Docker com o AWS CLI para uso em cenários de CI / CD

Criado em 9 set. 2018  ·  121Comentários  ·  Fonte: aws/aws-cli

Eu li as edições 3529 e 3291 e vi que elas estavam fechadas, com a única reação sugerindo que era 'não tão complicado'. No entanto, o comentário também reconheceu que fazer isso sozinho correria o risco de ficar desatualizado. Além disso, gostaria de salientar que, para usuários comerciais, ter uma imagem oficial da Amazon é extremamente preferencial a "/ aws- cli: mais recente ".

No meu caso, eu estaria usando isso em um Google Cloud Build porque é muito superior ao AWS CodeBuild.

feature-request

Comentários muito úteis

@matti e @nscavell , obrigado por acompanhar este tópico. Parece que há interesse suficiente nesta solicitação de recurso para mantê-lo aberto. Este problema será usado para rastrear uma imagem oficial do Docker para o AWS CLI. Marque com +1 para mostrar interesse e nos ajude a priorizar isso.

Obrigado.

Todos 121 comentários

Estou aqui porque também estou procurando uma imagem oficial do aws-cli docker para usar em meu ambiente de CI / CD. Em vez disso, agora vou criar OUTRO pipeline para construir uma imagem docker que inclui o aws cli quando eu poderia apenas fazer referência ao oficial em meu pipeline original.

Além disso ... outra pessoa também acessa https://hub.docker.com/r/google/cloud-sdk.

@matti e @nscavell , obrigado por acompanhar este tópico. Parece que há interesse suficiente nesta solicitação de recurso para mantê-lo aberto. Este problema será usado para rastrear uma imagem oficial do Docker para o AWS CLI. Marque com +1 para mostrar interesse e nos ajude a priorizar isso.

Obrigado.

+1 não é considerado prejudicial;)

De qualquer forma, este é o terceiro (?) Problema criado sobre isso ...

👍 adicionar meu +1

Tenho que criar minha própria imagem docker para incluir apenas awsCLI em meu CI. Eu preferiria um oficial

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Aqui está uma imagem alpina (pós-correção) com o cli mais recente instalado para qualquer pessoa que esteja procurando por uma versão recente nesse meio tempo.

@justnance o suficiente?

+1

+1

+1

+1

Outro motivo é ao usar um sistema operacional como o coreOS, que não possui gerenciamento de pacotes, a maneira idiomática de executar as coisas é por meio de um contêiner. Estou surpreso que a necessidade disso seja questionada, é uma omissão óbvia. 👍

+1

: +1:

+1

+1

+1

+1

+1

Como o abridor de # 3291 (o mais antigo dos três problemas citados lol), estou feliz em ver que este problema está finalmente ganhando força. Para todos os futuros respondentes, quando @justnance diz "Por favor, curtir no primeiro comentário, essa é a maneira correta de marcar itens com +1 no GitHub para que você não envie spam para as caixas de correio dos mantenedores .

+1 para manter os proprietários do repo notificados

+1

Quando eles dizem +1 um problema, o que eles querem dizer é clicar no botão 👍. Não ajuda os desenvolvedores ter 100 comentários cada um dizendo "+1". Quanto mais você sabe!

@davidham - Obrigado por esclarecer e a todos por responder. Eu concordo. Use as reações do GitHub e clique no botão 👍.

Eu disse a mesma coisa há 2 dias, mas olha que estamos todos do mesmo lado 🙃

+1

+1

+1

+1

+1

+1

+1

Você pode parar o +1? se você quiser marcar com +1, faça no topo.

Você está desperdiçando um valioso tempo de engenheiro. Temos dezenas de inscritos nesta edição ...

Tenho mantido uma imagem aws-cli por mais de dois anos. Sinta-se à vontade para usá-lo se necessário (eu uso várias vezes ao dia). Recebo atualizações sobre lançamentos de novas versões (via IFTT) e envio atualizações rapidamente. Apesar da fama e glória de administrar minha própria imagem (ha!), Irei _gladly_ adiar e forçar as pessoas a usarem uma imagem oficial.

Depois de usar minha imagem por um longo tempo, direi que seria _super_ útil se a imagem oficial incluísse jq (já que a API é pesada em JSON). Isso torna muito conveniente fazer coisas como "pegar a definição de tarefa do ECS mais recente, fazer uma alteração e empurrá-la de volta", tudo em um único estágio de pipeline de CI / CD.

Mais uma solução alternativa para o problema: https://hub.docker.com/r/somedeveloper/aws-cli/

Razões para usar:

  • Mantém a simplicidade.
  • Usa python3.7-stretch oficial como imagem base.
  • Usa a estratégia recomendada da AWS para instalação - python + pip. veja aqui .
  • Inclui aws-sam-cli para os nerds sem servidor 8-).
  • É público e não requer login.
  • Ótimo para pipelines de CI / CD - não o usei para mais nada, então não pesou os prós e os contras.

Ainda esperando por uma imagem oficial. Pense nas pessoas agora

https://hub.docker.com/r/google/cloud-sdk/ . Desculpem rapazes. É uma tarefa tão difícil de fazer para um gigante como a AWS.

+1

+1 não é considerado prejudicial;)

De qualquer forma, este é o terceiro (?) Problema criado sobre isso ...

Quarto, se você considerar https://github.com/aws/amazon-linux-docker-images/issues/10.

Não podemos simplesmente colocá-lo no CircleCI e acabar logo com isso? Fico feliz em ajudar com o Dockerfile ou pipeline.

Eu me pergunto se há alguma restrição interna e / ou trabalho em papel dentro da Amazon que mantém os desenvolvedores longe de realizar este trabalho aparentemente trivial ...

k lol

Existem algumas variantes que seria bom ter em uma imagem "oficial". Por exemplo, atualmente estou procurando obter um contêiner com o aws cli e curl (para verificar o endpoint de metadados IAM) e seria muito útil encontrar um que eu pudesse simplesmente pegar e conectar em minha implantação k8s.

Também existe um motivo de segurança para fornecer imagens oficiais.

Isso torna o modelo de ameaça mais simples, removendo a dependência de uma "pessoa aleatória na Internet" que mantém a imagem que é usada em destinos de alto valor, como pipelines de CI / CD que geralmente fornecem muito acesso aos seus sistemas.

Eu gostaria de uma imagem docker oficial do aws-cli baseada na imagem docker: 18 (atual estável) (https://hub.docker.com/_/docker) - por exemplo. aws-cli-docker-18 porque gostaria de construir minha imagem docker em meu ambiente de CI / CD que atualmente usa a imagem docker:18 e publicá-la no AWS ECR.

+1

+1

Seria ótimo se as pessoas evitassem comentar quando seus comentários não contribuíssem para o problema em questão. Comentários como "+1" apenas introduzem spam para os assinantes e tornam o problema mais demorado do que o necessário. Em vez disso, dê um joinha no primeiro comentário do problema.

Seria ótimo se as pessoas evitassem comentar quando seus comentários não contribuíssem para o problema em questão. Comentários como "+1" apenas introduzem spam para os assinantes e tornam o problema mais demorado do que o necessário. Em vez disso, dê um joinha no primeiro comentário do problema.

Esta edição está aberta desde setembro do ano passado. Acho que precisamos pedir à AWS para dar uma olhada neste problema novamente, uma vez que obviamente há interesse nisso. Devemos ser informados de quanto juros são "suficientes".

uma vez que há obviamente interesse nisso

Não apenas interesse, mas o problema aberto com mais : +1: reações :

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

A 2ª com mais reações foi aberta em 2014 e a 3ª em 2015, enquanto esta edição foi aberta em setembro de 2018 (há menos de um ano ).

+1000

Tenho em minha máquina local o tempo todo problemas com a configuração das dependências certas para fazer o aws-cli funcionar. Portanto, decidi mudar para o aws-cli dentro do docker. Encontrei várias imagens publicamente disponíveis no docker-hub MAS porque não são oficiais, não confio nelas por padrão, então sempre que houver uma versão atualizada disponível, tenho que pesquisar e encontrar novamente uma imagem confiável. e é seguro para uso. A AWS constrói, mantém e fornece uma imagem segura do aws-cli docker por meio do hub do docker. desde já, obrigado

Há uma grande fragmentação das imagens aws-cli fornecidas pela comunidade. Mas, como mencionado anteriormente: as pessoas preferem um que seja oficialmente mantido e suportado pela Amazon. Vários motivos:

1) Não ficará obsoleto - as imagens da comunidade são notórias por eventualmente ficarem obsoletas;
2) Mais seguro - é de um recurso confiável, não importa o quão confiável um membro da comunidade possa ser, eles não representam oficialmente a Amazon, portanto, "todas as garantias são nulas";
3) Suporte oficial significa suporte oficial em caso de bugs, conflitos de versão, compatibilidade com versões anteriores, etc.
4) A AWS pode atualizar sua imagem à medida que atualiza aws cli, incluindo tags históricas.

+1

1 É realmente uma pena que a Amazon não forneça este

Desde então, adicionei outra imagem que foi útil. Ele combina o Docker no Docker com o AWS e o SAM CLI, o que contribui para uma integração ECR perfeita.

dind-aws-cli

+1

Embora existam muitas imagens não oficiais por aí que são bem mantidas, o que os impedirá de um dia dizer "Pfft, não adianta mais atualizar isso. Este é o trabalho da Amazon!"

+1

+1

Quando se trata de ajudar as pessoas a automatizarem seu trabalho com a AWS Amazon, estão falhando muito, esse é um dos motivos pelos quais pensamos em deixá-los.

Existe uma resposta oficial dos mantenedores sobre se isso já está ou não em um road map? Como muitos outros, prefiro usar uma imagem oficial também ...

+1

Se houvesse uma imagem oficial para o AWS CLI, seria um executável dentro de um contêiner de rascunho. Porque isso não seria extremamente útil para os indivíduos, o que poderia ser melhor é:

  • Use um contêiner python oficial para construir a CLI a partir da fonte
  • Copie o binário AWS CLI resultante em um busybox ou contêiner de rascunho

Qualquer coisa além disso seria um excesso de engenharia, apesar de quaisquer debates ocorrendo aqui.

A AWS adora demonstrar todos os seus serviços ECR e CodeDeploy. Por que eles não apontam todo esse poder de fogo para sua própria CLI em contêineres?

Porque a oferta sobre a mesa parece ser para alguém da comunidade mantê-la.

@balibebas alguém da comunidade já está fazendo isso. Há uma tonelada de imagens por aí - mas a questão aqui é que haveria uma da AWS, porque não quero executar randomguy/aws-cli:canbechangedanytime em meu ambiente de CI com todos os segredos abertos.

O que você diria sobre F-Droid então?

é tão relevante para este problema quanto este gato:

Você parece um cliente pagante.

bem, talvez seja porque _I_ _am_

Pregando para o coro. De qualquer forma, a fórmula de Brew teve uma chance melhor porque foi rastreada por mais tempo, ainda sem movimento. Portanto, as fotos de gatos tornam-se imediatamente contraproducentes quando não há nenhum caso de uso geral fora de um contêiner de scratch ou busybox, como mencionei antes. Qual é a sua proposta de design?

eu e muitos outros estamos atualmente fazendo "containers busybox", por exemplo, para executá-lo com docker para obter credenciais de autenticação ECR. dada a quantidade de dockers que o aws possui, não faz sentido que não exista um pacote oficial.

Talvez eles estejam apenas em outra coisa. ;)

Estou feliz por termos resolvido isso agora. Voltar para comentários de +1:

+1 para Dockerless

@matti @balibebas Lembre-se de que no momento existem 64 pessoas apenas na conversa deste problema, e cada resposta dispara um e-mail e uma notificação inúteis que potencialmente são enviados para cada uma das 64 pessoas e mais que estão inscritas. Esta mensagem fará o mesmo e peço desculpas por isso.

Mas realmente, por favor, mantenha as coisas profissionais. Embora as fotos de gatos sejam legais, quanto mais esse tópico sai dos trilhos eu acho menos provável que seja levado a sério pelos mantenedores. Infelizmente, spam é spam.

Isso é o que o botão de cancelamento de inscrição faz, aquele que acabei de clicar.

Isso seria uma coisa boa de se ter. Estou apenas surpreso que nenhuma ação está sendo tomada ou que isso está sendo mantido (incluindo ser dito NÃO).
De qualquer forma, as pessoas acima indicaram corretamente a importância de uma imagem oficial do aws cli.
Acho que as pessoas já estão usando os seus próprios em particular ou por meio da rota de gerenciadores de imagens / pacotes de outra pessoa, etc.
Mais um script de exemplo para o mesmo

Mas o problema mais simples e não evitável permanece o mesmo.

  • A lista interminável de dependências e incertezas que surgem se depender dos desenvolvedores para integrar as coisas por conta própria. Eventualmente levará a mais problemas no repo, já que as pessoas começarão instalando uma coisa, depois outra e depois algumas outras para realizar o trabalho de contaminação do ambiente, o que anula o propósito do CI / CD ou trabalhos semelhantes de serem isolados e intocados.
  • É difícil confiar para implementar e rastrear a imagem docker de outra pessoa para o seu trabalho. Isso leva à criação de outro pipeline e adição de entrada no registro do docker para a nova imagem awscli, outro repositório, ou seja, outra coisa para manter.
  • Em CI / CD, minha preferência é usar apenas a imagem (nossa interna ou oficial) e evitar linhas de scripting para adicionar coisas o máximo possível.
  • Problema com build & libs como imagem oficial pode ser compilado imediatamente a partir de lançamentos de código-fonte e ter menos dependências dinâmicas gerenciador de pacotes wrt e quais não.

senão
=> Todo mundo acaba fazendo o seu.

mesmo aqui, atualmente eu uso uma imagem de auto-construção, mas preferiria uma imagem oficial sob o

namespace. Eu o uso para construir outras imagens do docker e enviá-las ao ECR, onde o awscli é necessário para obter as credenciais.

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

Não deveria ser grande coisa adicionar isso ao pipeline de construção do awscli ... :)

-

Eu atualizei o Dockerfile de acordo com a sugestão de @ mikesir87 ,

Desculpe por enviar spam a todos, mas gostaria de salientar (no caso de alguém querer usar o snippet de @ jens-meiss) que você deve _realmente_ considerar encadear suas três RUN declarações em uma única declaração. Caso contrário, você ainda estará enviando o conteúdo de py-pip e os caches apk nas camadas intermediárias, mesmo que seu contêiner final não possa acessá-los.

Em outra nota, o comentário traz outro caso de uso válido ... quando você está usando o aws-cli apenas para obter credenciais de ECR para enviar imagens. Isso soa como a necessidade de empacotar o auxiliar de credencial ECR em uma imagem também. Isso certamente tornaria mais fácil construir e enviar imagens sem a necessidade do aws-cli completo.

Olá a todos, mantenedor aqui. Só queria esclarecer, isso está acontecendo, estamos fazendo isso.

Estamos no processo de construção de uma infraestrutura de lançamento melhor internamente para poder construir / testar / suportar mais tipos de artefatos de lançamento, especialmente porque estaremos enviando mais artefatos de lançamento para cli v2.

Não temos um cronograma exato no momento, mas está acontecendo.

Coisa fácil de fazer de acordo com os desenvolvedores da Amazon e muitos outros, mas ainda espera depois de 2 anos e sem ETA 😂

+1

Infraestrutura de lançamento interno (quarto trimestre de 2019)
avaliação da equipe jurídica (2020 Q1)
beta público em aws / cli-dev-test (2º trimestre de 2020)
versão final (Q3 2020)

Nesta linha do tempo otimista, você obterá o que deseja em menos de 10 meses. 🥇

esperando a postagem do blog de jeff barrs

Estou esperando por isso.

Podemos pelo menos obter um anúncio oficial ou compromisso. Talvez um lançamento alvo?

@bhmckendrick é um compromisso não exatamente o que este comentário não muito acima do seu é?

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

mais de um ano e sem atualizações? Imagem?

Ei @jamesls , você consideraria bloquear este tópico até que você tenha algo para compartilhar?

o número de pessoas que não querem ler ( dica dica ) e, em vez disso, escolhem enviar spam para mais de 70 observadores sobre como eles _especificamente_ estão irritados, tenho certeza, reduzindo drasticamente o interesse de todos em seguir este tópico.

Além disso, obrigado pelo seu trabalho para fazer isso acontecer!

Como o autor original desta edição (bem, eu tive a coragem de copiar / colar os anteriormente fechados "wontfix"), já cancelei a inscrição nesta edição por causa do grande spam +1 e brigas ocasionais com fotos de gatos (desculpe) .

Basta ajustar as configurações de notificação para receber notificações apenas se o problema for encerrado.

Gostaria apenas de salientar que, além de CI / CD, alguns desenvolvedores (consulte @LongLiveCHIEF), preferem ter ambientes de desenvolvimento encaixados e não gostam de instalar as coisas nativamente, ou ter que lidar com os gerenciadores de versão subsequentes para o línguas nativas das quais essas ferramentas CLI inevitavelmente dependem.

É mais fácil docker pull aws-cli que quaisquer que sejam as etapas de instalação existentes ... sem mencionar que se você não for um desenvolvedor de python, terá a sobrecarga de configurar uma boa versão e ambiente de python para seu usuário, ou talvez até mesmo cada projeto.

Escale isso para todas as diferentes ferramentas que um desenvolvedor pode usar (cli baseado em ruby, CLI baseado em nó), e você tem que aprender configurações de ambiente para linguagens que você talvez nunca tenha codificado.

O que quero dizer aqui é que a execução do docker é onipresente, elimina qualquer configuração / configuração de idioma nativo e facilita as coisas para os usuários.

Mesmo que os usuários criem suas próprias imagens do docker, eles ainda terão que se esforçar para executar essas tarefas de configuração.

Eu não codifico em python, mas fui forçado a aprender os meandros dos ambientes virtuais e suas melhores práticas em várias versões de python, simplesmente porque os fornecedores de ferramentas consideram isso "trivial".

Nem todos os desenvolvedores têm o mesmo plano de fundo que aqueles que criaram a ferramenta, e fornecer uma imagem do docker é um sinal de respeito. Os fornecedores de ferramentas podem assumir a sobrecarga de peculiaridades de ambiente específicas do idioma nativo com muita rapidez e facilidade, enquanto os adotantes precisam gastar muito mais tempo para gerenciar essa sobrecarga por meio dos vários estágios do ciclo de vida de desenvolvimento do seu produto.

Comida, entretanto.

@jamesls Obrigado por ouvir os comentários da comunidade aqui. Enquanto espera pelas imagens oficiais do docker hospedadas, uma etapa intermediária útil pode ser postar recomendações de instalação para algumas imagens base populares do docker aqui (por exemplo, node, alpine, ubuntu, amazon2, python). Isso seria imediatamente valioso para nós.

Como trabalho para uma grande empresa, deixe-me atendê-lo com isto:
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

Isso não parece bem conservado, mas aqui está outro

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

Acabei de descobrir isso: https://hub.docker.com/r/amazon/aws-cli

Parece que finalmente chegou :)

@pablosjv não é uma imagem oficial ou certificada. Esteja ciente disso.

@anjakammer Parece que é uma imagem oficial da amazon , embora não seja uma imagem oficial publicada pelo Docker .

Não sei se é difícil para a produção, porque ainda não disseram nada nesta edição.

Curioso como esta imagem da AWS tem 98,42 MB, enquanto outras (por exemplo, atlassian / pipelines-awscli ) são muito menores.

Membro da equipe CLI aqui. Sim, posso confirmar que lançamos oficialmente uma imagem Docker para o AWS CLI v2! Recomendo a leitura do seguinte:

Vou encerrar esse problema. Se você tiver comentários ou perguntas sobre a imagem, abra outro problema do GitHub neste repositório.

Para abrir a edição original nº 3291, muitos anos atrás, minha dor ❤️ se encheu de alegria ao ver minhas preocupações finalmente validadas e uma imagem oficial do Docker agora disponível. Fotos rápidas sobre o tempo que levou para deixar essa imagem de lado, tenho certeza de que foi muito mais fácil falar do que fazer, então, um grande obrigado aos desenvolvedores da Amazon que fizeram isso acontecer. Todos vocês fazem um excelente trabalho. 👏🎉👏

_Ok Alexa, agradeci a eles, por favor, deixem minha família ir agora._

O Dockerfile disponível em algum lugar?

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

Acho que eles finalmente estão conseguindo, mas não consegui fazer com que rodasse no Gitlab CI https://hub.docker.com/r/amazon/aws-cli

Em vez disso, estou usando a imagem da janela de encaixe AWS CLI do Gitlab e ela funciona perfeitamente. Apenas use

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

ATUALIZAR:

A imagem acima está obsoleta, use a nova em seu lugar.

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

Observe que para usar a imagem no GitLab CI, você precisará definir manualmente um ponto de entrada vazio, pois a imagem amazon/aws-cli define o ponto de entrada como /usr/local/bin/aws . Um exemplo...

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

@ mikesir87 por que isso?

@pSnehanshu Acho que é porque você executa a imagem como se fosse o próprio cli, como docker run --rm amazon/aws-cli <<command>> , que seria semelhante a executar o cli com aws <<command>> , em vez de docker run --rm amazon/aws-cli aws <<command>> . Existem prós e contras em cada abordagem, dependendo da sua preferência e da maneira como você executa a imagem, mas substituir o ponto de entrada deve resolver o problema de qualquer maneira.

@lucasbasquerotto Eu me conformei com a imagem do Gitlab de qualquer maneira. De qualquer forma, obrigado pela explicação.

Caso alguém ainda esteja interessado em fazer o AWS CLI v2 funcionar no Alpine Linux, aqui está um exemplo 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/

O problema era que o AWS CLI v2 usa GLIBC, mas Alpine Linux tem suporte GLIBC limitado (ele usa 'musl', uma alternativa leve). O Dockerfile acima instala as bibliotecas glibc ausentes e usa um Dockerfile de vários estágios para manter a imagem final pequena. Com um pouco de esforço, provavelmente podemos reduzir o tamanho da imagem ainda mais, incluindo apenas os arquivos de / usr / lib que são realmente necessários.

Depois de algumas refatorações, consegui reduzir ainda mais o tamanho da imagem:

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

O índice de autocompletar e os arquivos de exemplo são removidos, e também 'groff' é removido (estou assumindo que as pessoas não precisam de páginas de ajuda em suas imagens do Docker)

Isso é muito simples, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile e faz o trabalho, mas me avise por meio de meus problemas no github se algo mais for necessário na imagem (caso de uso válido).

Isso é muito simples, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile e faz o trabalho, mas me avise por meio de meus problemas no github se algo mais for necessário na imagem (caso de uso válido).

O APK acima é baseado no AWS-CLI 1.18, não no v2 CLI.

Alguma chance da Amazon considerar a criação de uma imagem com a versão 1 da CLI?

@keeganwitt Você deve abrir um novo problema para essa solicitação. : +1:

Esta página foi útil?
0 / 5 - 0 avaliações