Aws-cli: 带有 AWS CLI 的官方 Docker 映像，用于 CI/CD 场景

我来这里是因为我也在寻找官方的 aws-cli docker 映像以在我的 CI/CD 环境中使用。 相反，我现在将创建另一个管道来构建一个包含 aws cli 的 docker 映像，当我可以在我的原始管道中引用官方的时候。

另外……其他人也得到了https://hub.docker.com/r/google/cloud-sdk。

@matti和@nscavell ，感谢您跟进此主题。 听起来对这个功能请求有足够的兴趣来保持它的开放。 此问题将用于跟踪 AWS CLI 的官方 Docker 映像。 请为它 +1 以表示感兴趣并帮助我们优先考虑它。

谢谢。

+1 被认为是有害的吗 ;)

无论如何，这是为此创建的第三个（？）问题......

👍 添加我的 +1

我必须创建我自己的 docker 镜像，以便在我的 CI 中只包含 awsCLI。 我更喜欢官方的

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

这是一个 alpine（后修复）图像，其中安装了最新的 cli，供其他同时寻找最新版本的人使用。

@justnance够了吗？

+1

+1

+1

+1

另一个原因是，当使用像 coreOS 这样没有包管理的操作系统时，运行事物的惯用方式是通过容器。 我很惊讶甚至会质疑这种必要性，这是一个明显的遗漏。 👍

+1

：+1：

+1

+1

+1

+1

+1

作为#3291（三个引用问题中最早的一个，哈哈）的开场白，我很高兴看到这个问题终于获得了关注。 对于所有未来的响应者，当@justnance说“请为它+1 以表示感兴趣”时，他的意思是在第一条评论上添加一个

+1 通知回购所有者

+1

当他们对+1一个问题时，他们的意思是单击 👍 按钮。 有 100 条评论每条都说“+1”，这对开发人员没有帮助。 你懂得越多！

@davidham - 感谢您的澄清和每个人的回应。 我同意那个。 请使用 GitHub 反应并单击 👍 按钮。

2 天前我说了同样的话，但嘿，我们都站在同一边 🙃

+1

+1

+1

+1

+1

+1

+1

你能停止+1吗？ 如果您想 +1，请在顶部进行。

您正在浪费宝贵的工程师时间。 我们有十几个订阅了这个问题......

两年多以来，我一直在维护 aws-cli 映像。 如果需要，请随意使用它（我每天使用它几次）。 我收到有关新版本发布的更新（通过 IFTT）并很快推送更新。 尽管运行我自己的形象（哈！）享有盛誉和荣耀，但我会_很高兴_推迟并推动人们使用官方形象。

• GitHub 仓库
• 码头工人中心

使用我的图像很长时间后，我会说如果官方图像包含jq （因为 API 是 JSON 重的），那将是 _super_ 有帮助的。 它确实让在单个 CI/CD 管道阶段执行诸如“获取最新的 ECS 任务定义、进行更改并将其推回”之类的操作变得非常方便。

该问题的另一种替代解决方案： https :

使用理由：

• 保持简单。
• 使用官方 python3.7-stretch 作为基础镜像。
• 使用 AWS 推荐的安装策略——python + pip。 看到这里。
• 包括那些无服务器书呆子的 aws-sam-cli 8-)。
• 它是公开的，不需要登录。
• 非常适合 CI/CD 管道——没有将它用于其他任何事情，所以没有权衡利弊。

还是希望官方形象。 想想现在的人

https://hub.docker.com/r/google/cloud-sdk/ 。 对不起大家。 对于像 AWS 这样的巨头来说，这是一项艰巨的任务。

+1

+1 被认为是有害的吗 ;)

无论如何，这是为此创建的第三个（？）问题......

第四，如果你考虑https://github.com/aws/amazon-linux-docker-images/issues/10。

我们不能把它放在 CircleCI 中并完成它吗？ 很高兴为 Dockerfile 或管道提供帮助。

我想知道亚马逊内部是否有任何内部限制和/或文书工作使开发人员无法完成这项看似微不足道的工作......

哈哈

有一些变体可以很好地出现在“官方”图像中。 例如，我目前正在寻找一个带有 aws cli 和 curl 的容器（以检查 IAM 元数据端点），找到一个我可以抓取并插入到我的 k8s 部署中的容器会非常方便。

提供官方图像还有一个安全原因。

它通过消除对“互联网上的随机人员”的依赖来简化威胁模型，该图像维护用于高价值目标（例如 CI/CD 管道）通常可以对您的系统进行大量访问。

我想要一个基于docker:18 （当前稳定）图像（https://hub.docker.com/_/docker）的官方 aws-cli docker 图像 - 例如。 aws-cli-docker-18，因为我想在当前使用docker:18图像的 CI/CD 环境中构建我的 docker 图像并将其发布到 AWS ECR。

+1

+1

如果人们在他们的评论对手头的问题没有贡献时不发表评论，那就太好了。 诸如“+1”之类的评论只会为订阅者带来垃圾邮件，并使问题变得比必要的时间更长。 相反，请对问题的第一条评论竖起大拇指。

如果人们在他们的评论对手头的问题没有贡献时不发表评论，那就太好了。 诸如“+1”之类的评论只会为订阅者带来垃圾邮件，并使问题变得比必要的时间更长。 相反，请对问题的第一条评论竖起大拇指。

这个问题是从去年九月开始的。 我认为我们需要请 AWS 再次研究这个问题，因为显然人们对此很感兴趣。 我们应该被告知多少利息是“足够”的。

因为显然有兴趣

不仅仅是兴趣，而且是有更多:+1:反应的未解决问题：

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

反应最多的第二期是 2014 年，第三期是 2015 年，而本期是 2018 年 9 月（不到一年前）。

+1000

我一直在我的本地机器上设置正确的依赖项以使 aws-cli 工作。 因此我决定在 docker 中切换到 aws-cli。 我在 docker-hub 上找到了几个公开可用的图像，但是因为它们不是官方的，我默认不信任它们，所以每次有可用的更新版本时，我都必须再次搜索并找到一个可以信任的图像。 并且可以安全使用。 请 AWS 通过 docker hub 构建、维护和提供安全的 aws-cli docker 镜像。 提前致谢

社区提供的 aws-cli 图像非常分散。 但是，如前所述：人们更喜欢亚马逊官方维护和支持的产品。 几个原因：

1) 不会过时——社区形象因最终会过时而臭名昭著；
2) 更安全——来自可信赖的资源，无论社区成员多么受信任，他们都不正式代表亚马逊，因此“所有保修均无效”；
3) 官方支持是指在出现bug、版本冲突、向后兼容等情况下的官方支持。
4) AWS 可以在更新aws cli 时更新他们的图像，包括历史标签。

+1

+1 真的很遗憾亚马逊不提供这个

从那以后，我添加了另一个方便的图像。 它将 Docker 中的 Docker 与 AWS 和 SAM CLI 相结合，从而实现了完美的 ECR 集成。

dind-aws-cli

+1

虽然有大量维护良好的非官方图片，但有什么办法阻止他们有一天说“噗，再更新这个有什么意义。这是亚马逊的工作！”

+1

+1

当谈到帮助人们使用 AWS 实现工作自动化时，亚马逊在很大程度上失败了，这是我们考虑离开他们的原因之一。

维护者是否有官方回应关于这是否在路线图上？ 像许多其他人一样，我也更愿意使用官方图片......

+1

如果 AWS CLI 有官方镜像，它将是一个位于临时容器内的可执行文件。 因为这对个人来说不会非常有用，最好的方法是：

• 使用官方 python 容器从源代码构建 CLI
• 将生成的 AWS CLI 二进制文件复制到一个 busybox 或临时容器

尽管这里发生了任何辩论，但任何更多的事情都会过度设计。

AWS 喜欢演示它的所有 ECR 和 CodeDeploy 服务。 他们为什么不把所有的火力都指向自己的容器化 CLI？

因为桌面上的提议似乎是由社区中的某个人维护的。

@balibebas社区中的某个人已经在这样做了。 那里有大量的图像 - 但这里的重点是 AWS 会有一个图像，因为我不想在我的 CI 环境中运行randomguy/aws-cli:canbechangedanytime并且所有的秘密都是敞开的。

那么你对 F-Droid 有什么看法呢？

它和这只猫一样与这个问题相关：

你听起来像一个付费客户。

好吧，也许那是因为_I_ _am_

向合唱团宣讲。 无论如何，Brew 配方有更好的机会，因为它已经被拖得更久了，仍然没有移动。 因此，正如我之前指出的那样，当在 Scratch 或 busybox 容器之外没有一般用例时，猫照片会立即产生反作用。 你的设计方案是什么？

我和许多其他人目前正在做“busybox 容器”，例如使用 docker 运行它以获得 ECR 身份验证凭据。 鉴于 aws 有多少 docker 东西，官方包装不存在是没有意义的。

也许他们只是在做别的事情。 ;)

我很高兴我们现在解决了这个问题。 回到 +1 评论：

+1 无 Docker

@matti @balibebas请记住，截至目前，仅此问题的对话中就有 64 人，每个回复都会触发无用的电子邮件和通知，这些电子邮件和通知可能会发送给这 64 人中的每一个人以及更多订阅者。 此消息将执行相同的操作，对此我深表歉意。

但真的，请保持专业。 虽然猫的照片很好，但是这个线程越是偏离轨道，我觉得它就越不可能被维护者认真对待。 不幸的是，垃圾邮件就是垃圾邮件。

这就是取消订阅按钮的作用，我刚刚点击的那个。

这将是一件好事。 我只是惊讶于没有采取任何行动或维持这一点（包括被拒绝）。
无论如何，上面的人已经正确地指出了官方 aws cli 图像的重要性。
我认为人们已经在私下或通过其他人的构建图像/包管理器路线等使用自己的。
同样的另一个示例脚本

但最简单和不可避免的问题仍然是一样的。

• 如果依赖于开发人员自己集成东西，就会出现永无止境的依赖项和不确定性列表。 最终会导致 repo 中出现更多问题，因为人们会先安装一个东西然后再安装一些东西，以完成污染环境的工作，这违背了 CI/CD 或类似的隔离和原始工作的目的。
• 很难相信为您的工作实施和跟踪任何其他人的 docker 镜像。 这导致在 docker 注册表中为新的 awscli 映像创建另一个管道和条目，另一个存储库，即需要维护的另一件事。
• 在 CI/CD 中，我的偏好是只使用图像（我们的内部或官方）& 避免脚本行尽可能多地添加东西。
• 构建和库作为官方映像的问题可以立即从源版本本身构建，并且具有较少的动态依赖项 wrt 包管理器等等。

别的
=> 每个人最终都会制作自己的。

同样在这里，目前我使用的是自建镜像，但更喜欢下面的官方镜像

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

命名空间。 我用它来构建其他 docker 镜像并将它们推送到 ECR，在那里需要 awscli 来获取凭据。

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

将它添加到您的 awscli 构建管道应该没什么大不了的...... :)

——

我已经根据@mikesir87 的建议更新了 Dockerfile，谢谢（这是拥有标准图像的另一个原因，社区的贡献以获得最小的图像）

抱歉给大家发垃圾邮件，但想指出（以防其他人想使用来自@jens-meiss 的片段）您应该_真的_考虑将您的三个RUN语句链接到一个语句中。 否则，您仍然在传送py-pip以及中间层中的 apk 缓存，即使您的最终容器无法访问它们。

另一方面，该评论提出了另一个有效用例……当您仅使用 aws-cli 获取 ECR 的凭据以推送图像时。 这听起来也需要在图像中打包ECR 凭证助手。 它肯定会使构建和推送图像变得容易，而无需完整的 aws-cli。

大家好，这里的维护者。 只是想澄清一下，这正在发生，我们正在这样做。

我们正在内部构建更好的发布基础设施，以便能够构建/测试/支持更多类型的发布工件，特别是当我们将为 cli v2 发布更多发布工件时。

我们目前没有确切的时间表，但它正在发生。

根据亚马逊开发人员和许多其他人的说法，这很容易做到，但仍然在等待 2 年后没有 ETA 😂

+1

内部发布基础设施（2019 Q4）
法律团队评估（2020 年第一季度）
aws/cli-dev-test 下的公开测试版（2020 年第二季度）
最终版本（2020 年第三季度）

在这个乐观的时间表中，您将在不到 10 个月的时间内得到您想要的东西。 🥇

等待杰夫·巴尔斯的博文

我他妈在等这个。

我们能不能至少得到一个正式的公告或承诺。 也许是目标版本？

@bhmckendrick是一种承诺，不完全是这条评论并没有超出你的评论？

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

一年多了还没有更新？ 图片？

嘿@jamesls ，你会考虑硬锁定这个线程，直到你有东西要分享吗？

我敢肯定，完全不愿意阅读（提示提示）而是选择向 70 多个观察者发送垃圾邮件，告诉他们他们是如何_特别_感到恼火的人数，我敢肯定，这大大降低了每个人关注此线程的兴趣。

另外，感谢您为实现这一目标所做的努力！

作为这个问题的原作者（好吧，我只是勇敢地复制/粘贴以前关闭的“wontfix”）我已经取消订阅这个问题，因为大量+1垃圾邮件和偶尔与猫图片打架（对不起） .

只需调整通知设置，以便您仅在此问题关闭时收到通知。

我只想指出，除了 CI/CD，一些开发人员（参见 @LongLiveCHIEF）更喜欢使用 dockerized 开发环境，并且不喜欢在本地安装东西，或者不得不处理随后的版本管理器cli 工具不可避免地依赖的母语。

docker pull aws-cli比现有的安装步骤更容易......更不用说如果您不是python开发人员，您有为您的用户设置一个好的python版本和环境的开销，或者也许甚至每个项目。

将其扩展到开发人员可能使用的所有不同工具（基于 ruby​​ 的 cli、基于节点的 cli），并且您必须学习可能永远不会编码的语言的环境设置。

我在这里提出的观点是 docker run 无处不在，并且摆脱了任何本地语言设置/配置，并使用户的工作变得容易。

即使用户构建了自己的 docker 镜像，他们仍然不得不为这些设置任务而苦苦挣扎。

我不使用 python 编写代码，但我被迫从各种版本的 python 中学习虚拟环境的来龙去脉及其最佳实践，纯粹是因为工具提供商认为它“微不足道”。

并非所有开发人员都具有与构建该工具的人员相同的背景，提供 docker 映像是一种尊重。 工具提供者可以非常快速和轻松地承担本地语言特定环境怪癖的开销，而采用者必须花费更多的时间来管理产品开发的各个生命周期阶段的开销。

食物虽然。

@jamesls感谢您在这里听取社区反馈。 在等待官方托管的 docker 镜像时，一个有用的中间步骤可能是在此处发布一些流行的基本 docker 镜像的安装建议（例如 node、alpine、ubuntu、amazon2、python）。 这将立即对我们有价值。

当我为大企业工作时，让我为您服务：
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

这看起来维护得不好，但这是另一个

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

我刚刚发现了这个： https :

好像终于来了：）

@pablosjv它不是官方或经过认证的图像。 请注意这一点。

@anjakammer它似乎是亚马逊的Docker 发布的

我不知道它是否准备好生产，因为他们在这个问题上什么也没说。

很好奇这个 AWS 镜像是 98.42 MB，而其他镜像（例如atlassian/pipelines-awscli ）要小得多。

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

CLI 团队成员在这里。 是的，我可以确认我们已经正式启动了 AWS CLI v2 的 Docker 镜像！ 我建议阅读以下内容：

• 介绍它的博客文章： https :
• 用户指南入口： https :
• DockerHub 存储库： https ://hub.docker.com/r/amazon/aws-cli

我要结束这个问题。 如果您对图像有反馈或问题，请在此存储库中打开另一个 GitHub 问题。

作为多年前原始问题#3291 的开场白，看到我的担忧终于得到证实，官方 Docker 映像现已可用，我的心痛❤️ 充满了喜悦。 关于制作这张图片需要多长时间的拍摄，我相信这说起来容易做起来难，所以非常感谢让这一切发生的亚马逊开发人员。 你们都做得很好。 👏🎉👏

_好的 Alexa，我感谢他们，现在请让我的家人离开。_

Dockerfile可以在任何地方使用吗？

@zerkms Aha，在v2分支中找到它：
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

我猜他们终于做到了，但我无法让它在 Gitlab CI 上运行https://hub.docker.com/r/amazon/aws-cli

我改为使用 Gitlab 的 AWS CLI docker 映像，它运行良好。 只需使用

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

更新：

上图已弃用，请改用新图。

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

请注意，要在 GitLab CI 上使用图像，您需要手动设置一个空入口点，因为amazon/aws-cli图像将入口点设置为/usr/local/bin/aws 。 一个例子...

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

@ mikesir87为什么？

@pSnehanshu我认为这是因为您运行图像就像它是 cli 本身一样，例如docker run --rm amazon/aws-cli <<command>> ，这类似于使用aws <<command>>而不是docker run --rm amazon/aws-cli aws <<command>>运行 cli . 每种方法都有优点和缺点，这取决于你喜欢什么，以及你运行图像的方式，但无论如何覆盖入口点应该可以解决问题。

@lucasbasquerotto 无论如何我已经选择了 Gitlab 的图像。 无论如何，谢谢你的解释。

如果有人仍然有兴趣让 AWS CLI v2 在 Alpine Linux 上运行，这里有一个 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/

问题在于 AWS CLI v2 使用 GLIBC，但 Alpine Linux 对 GLIBC 的支持有限（它使用“musl”，一种轻量级的替代方案）。 上面的 Dockerfile 安装了缺少的 glibc 库，并使用多阶段 Dockerfile 来保持最终的镜像很小。 通过一些努力，我们可能可以通过仅包含来自 /usr/lib 的真正需要的文件来进一步减小图像大小。

经过一些重构，我设法进一步减小了图像大小：

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

自动完成索引和示例文件被删除，“groff”也被删除（我假设人们不需要他们的 Docker 镜像中的帮助页面）

这非常简单， https://github.com/flaccid/docker-awscli/blob/master/Dockerfile并完成这项工作，但如果图像中需要其他任何内容（有效用例），

这非常简单， https://github.com/flaccid/docker-awscli/blob/master/Dockerfile并完成这项工作，但如果图像中需要其他任何内容（有效用例），

上述 APK 基于 AWS-CLI 1.18，而非 v2 CLI。

亚马逊是否有可能考虑使用 CLI 的第 1 版创建映像？

@keeganwitt您应该为该请求打开一个新问题。 ：+1：