Aws-cli: Официальный образ Docker с интерфейсом командной строки AWS для использования в сценариях CI / CD.

Созданный на 9 сент. 2018  ·  121Комментарии  ·  Источник: aws/aws-cli

Я прочитал выпуски №3529 и №3291 и увидел, что они закрыты, и единственная реакция намекнула, что это «не так уж сложно». Тем не менее, в комментарии также признается, что, делая это самостоятельно, вы рискуете устареть. Помимо этого, я также хотел бы отметить, что для коммерческих пользователей наличие официального образа Amazon намного предпочтительнее, чем "/ awscli : latest ".

В моем случае я бы использовал это в Google Cloud Build, потому что он намного превосходит AWS CodeBuild.

feature-request

Самый полезный комментарий

@matti и @nscavell , Спасибо за

Спасибо.

Все 121 Комментарий

Я здесь, потому что я тоже ищу официальный образ докера aws-cli для использования в моей среде CI / CD. Вместо этого я сейчас собираюсь создать ДРУГОЙ конвейер для создания образа докера, который включает aws cli, когда я мог бы просто сослаться на официальный конвейер в моем исходном конвейере.

Также ... кто-то другой тоже это понимает https://hub.docker.com/r/google/cloud-sdk.

@matti и @nscavell , Спасибо за

Спасибо.

+1 не считается вредным;)

В любом случае это третья (?) Проблема, созданная по этому поводу ...

👍 добавить мой +1

Мне нужно создать свой собственный образ докера, чтобы включить только awsCLI в мой CI. Я бы предпочел официальный

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Вот образ alpine (post fix) с самым последним установленным кликом для всех, кто тем временем ищет последнюю версию.

@ Достаточно

+1

+1

+1

+1

Другая причина заключается в том, что при использовании такой ОС, как coreOS, в которой нет управления пакетами, идиоматический способ запуска вещей - через контейнер. Я удивлен, что необходимость в этом даже может быть поставлена ​​под сомнение, это очевидное упущение. 👍

+1

: +1:

+1

+1

+1

+1

+1

Как открывающий № 3291 (самый ранний из трех процитированных вопросов, смеется), я рад видеть, что эта проблема наконец набирает обороты. Для всех будущих респондентов, когда @justnance говорит: «Пожалуйста,

+1, чтобы держать владельцев репо в курсе

+1

Когда они говорят +1 о проблеме, они имеют в виду нажать кнопку 👍. Разработчикам не помогает наличие 100 комментариев, в каждом из которых написано «+1». Чем больше ты знаешь!

@davidham - Спасибо за разъяснения и всем за ответы. Я поддерживаю это. Воспользуйтесь реакциями GitHub и нажмите кнопку 👍.

Я сказал то же самое 2 дня назад, но мы все на одной стороне 🙃

+1

+1

+1

+1

+1

+1

+1

Вы можете остановить +1? если хотите +1, делайте это сверху.

Вы тратите драгоценное время инженера. Нас десяток подписались на этот выпуск ...

Я поддерживаю имидж aws-cli уже более двух лет. Не стесняйтесь использовать его при необходимости (я использую его несколько раз в день). Я получаю обновления о выпусках новых версий (через IFTT) и довольно быстро отправляю обновления. Несмотря на известность и славу использования моего собственного имиджа (ха!), Я _ рад_ отсрочить и подтолкнуть людей к использованию официального изображения.

После долгого использования своего изображения я скажу, что было бы _супер_ полезно, если бы официальное изображение включало jq (так как API тяжелый JSON). Это действительно делает очень удобным выполнение таких вещей, как «захватить последнее определение задачи ECS, внести изменение и отправить его обратно» за один этап конвейера CI / CD.

Еще одно альтернативное решение проблемы: https://hub.docker.com/r/somedeveloper/aws-cli/

Причины использования:

  • Все просто.
  • В качестве базового образа используется официальный 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 или конвейером.

Интересно, есть ли внутри Amazon какие-либо внутренние ограничения и / или бумажная волокита, которая удерживает разработчиков от выполнения этой, казалось бы, тривиальной работы ...

к лол

Есть несколько вариантов, которые хотелось бы иметь в «официальном» образе. Например, сейчас я хочу взять контейнер с aws cli и curl (чтобы проверить конечную точку метаданных IAM), и было бы очень удобно найти тот, который я мог бы просто захватить и подключить к моему развертыванию k8s.

Также существует причина безопасности для предоставления официальных изображений.

Это упрощает модель угроз, устраняя зависимость от «случайного человека в Интернете», поддерживающего образ, который используется в важных целях, таких как конвейеры CI / CD, которые обычно предоставляют широкий доступ к вашим системам.

Мне нужен официальный образ докера aws-cli на основе образа docker: 18 (текущий стабильный) (https://hub.docker.com/_/docker) - например. aws-cli-docker-18, потому что я хотел бы создать свой образ докера в своей среде CI / CD, которая в настоящее время использует изображение docker:18 и опубликовать его в 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 года ( менее года назад ).

+1000

У меня на локальном компьютере все время возникают проблемы с настройкой правильных зависимостей для работы aws-cli. Поэтому я решил перейти на aws-cli внутри докера. Я нашел несколько общедоступных изображений на docker-hub, НО, поскольку они не являются официальными, я не доверяю им по умолчанию, поэтому каждый раз, когда появляется обновленная версия, мне приходится искать и снова находить изображение, которому можно доверять. и безопасен в использовании. Пожалуйста, создайте, поддержите и предоставьте AWS безопасный образ докера aws-cli через концентратор докеров. заранее спасибо

Существует огромная фрагментация сообщества, предоставляющего изображения aws-cli. Но, как упоминалось ранее: люди предпочли бы тот, который официально поддерживается и поддерживается Amazon. Несколько причин, почему:

1) Не устареет - изображения сообщества печально известны тем, что в конечном итоге устаревают;
2) Более безопасный - это от надежного ресурса, независимо от того, насколько доверяют члену сообщества, он официально не представляет Amazon, поэтому «все гарантии аннулируются»;
3) Официальная поддержка означает официальную поддержку в случае ошибок, конфликтов версий, обратной совместимости и т. Д.
4) AWS может обновлять свое изображение по мере обновления aws cli, включая исторические теги.

+1

+1 Очень жаль, что Amazon не предоставляет этого

С тех пор я добавил еще одно изображение, которое мне пригодилось. Он объединяет Docker в Docker с AWS и SAM CLI, что обеспечивает идеальную интеграцию ECR.

dind-aws-cli

+1

Несмотря на то, что существует множество неофициальных изображений, которые поддерживаются в хорошем состоянии, что может помешать им однажды сказать: «Пфф, какой смысл обновлять это больше. Это работа Amazon!»

+1

+1

Когда дело доходит до помощи людям в автоматизации их работы с AWS, Amazon терпит большие неудачи, это одна из причин, по которой мы думаем о том, чтобы уйти от них.

Есть ли официальный ответ от сопровождающих относительно того, есть ли это еще в дорожной карте? Как и многие другие, я бы предпочел использовать официальное изображение ...

+1

Если бы существовал официальный образ для интерфейса командной строки AWS, это был бы исполняемый файл, находящийся внутри временного контейнера. Поскольку это не будет очень полезно для людей, лучше всего будет:

  • Используйте официальный контейнер Python для создания интерфейса командной строки из исходного кода.
  • Скопируйте полученный двоичный файл AWS CLI в busybox или рабочий контейнер.

Что-либо еще было бы чрезмерной инженерией, несмотря на любые дебаты, происходящие здесь.

AWS любит демонстрировать все свои сервисы ECR и CodeDeploy. Почему бы им не направить всю свою огневую мощь на собственный контейнерный интерфейс командной строки?

Поскольку предложение на столе, кажется, для кого-то из сообщества поддержать его.

@balibebas кто-то из сообщества уже этим занимается. Есть масса изображений, но дело в том, что одно будет от AWS, потому что я не хочу запускать randomguy/aws-cli:canbechangedanytime в своей среде CI с широко открытыми секретами.

Что бы вы тогда сказали о F-Droid?

это так же актуально для этого вопроса, как и этот кот:

Вы похожи на платящего покупателя.

ну может это потому что _I_ _am_

Проповедь хору. Как бы то ни было, у формулы Brew было больше шансов, потому что ее троллили дольше, а движения все еще не было. Таким образом, фотографии кошек сразу же становятся контрпродуктивными, когда нет универсального варианта использования, кроме контейнера для царапин или занятого ящика, как я указывал ранее. Какое у вас дизайнерское предложение?

я и многие другие в настоящее время занимаюсь «контейнерами busybox», например, чтобы запустить его с помощью докера, чтобы получить учетные данные для авторизации ECR. учитывая, сколько у aws docker-вещей, нет никакого смысла в том, что официальной упаковки не существует.

Может, они просто на чем-то другом. ;)

Я рад, что мы сейчас с этим разобрались. Вернуться к комментариям +1:

+1 за Dockerless

@matti @balibebas Имейте в виду, что на данный момент в разговоре только с этим вопросом

Но на самом деле, пожалуйста, сохраняйте профессионализм. Хотя картинки с кошками хороши, чем дальше эта ветка сходит с рельсов, тем меньше вероятность того, что разработчики отнесутся к ней серьезно. К сожалению, спам есть спам.

Это то, что делает кнопка отказа от подписки, которую я только что нажал.

Было бы хорошо, если бы это было. Я только удивлен, что никаких действий не предпринимается или поддерживается (включая ответ НЕТ).
Во всяком случае, люди выше правильно указали на важность официального изображения aws cli.
Я думаю, что люди уже используют свои собственные в частном порядке или через чьи-то созданные менеджеры изображений / пакетов и т. Д.
Еще один пример сценария для того же

Но самая простая проблема, которую нельзя избежать, остается прежней.

  • Бесконечный список зависимостей и неопределенностей, который возникает, если разработчикам нужно интегрировать что-то самостоятельно. В конечном итоге приведет к большему количеству проблем в репозитории, так как люди начнут устанавливать одну вещь, затем другую, а затем несколько других, чтобы выполнить работу, загрязняющую среду, которая сводит на нет цель CI / CD или аналогичных работ по изолированности и первозданности.
  • Трудно доверять реализации и отслеживанию чужого образа докера для вашей работы. Это приводит к созданию еще одного конвейера и добавления записи в реестр докеров для нового образа awscli, другого репозитория, то есть еще одной вещи, которую нужно поддерживать.
  • В CI / CD я предпочитаю просто использовать изображение (наше внутреннее или официальное) и избегать строк сценария, чтобы добавить что-то как можно больше.
  • Проблема со сборкой и библиотеками в качестве официального образа может быть сразу собрана из исходных выпусков и имеет менее динамические зависимости от диспетчера пакетов и прочего.

еще
=> Каждый делает свое собственное.

то же самое здесь, в настоящее время я использую образ самостоятельной сборки, но предпочел бы официальный образ под

пространство имен. Я использую его для создания других образов докеров и отправки их в 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 не должно быть большой проблемой ... :)

-

Я обновил Dockerfile в соответствии с предложением @ mikesir87 ,

Приносим извинения за спам, но хотел указать (на случай, если кто-то еще захочет использовать фрагмент из @ jens-meiss), что вам действительно нужно _ действительно_ рассмотреть возможность объединения трех ваших RUN операторов в один оператор. В противном случае вы по-прежнему отправляете содержимое py-pip и кеши apk на промежуточных уровнях, даже если ваш последний контейнер не может получить к ним доступ.

С другой стороны, комментарий вызывает еще один допустимый вариант использования ... когда вы используете aws-cli только для получения учетных данных для ECR для отправки изображений. Это похоже на необходимость упаковки помощника по ECR в образ. Это, безусловно, упростило бы создание и отправку образов без необходимости использования полного aws-cli.

Всем привет, сопровождающий. Просто хотел уточнить, это происходит, мы это делаем.

Мы находимся в процессе создания более совершенной инфраструктуры выпуска внутри компании, чтобы иметь возможность создавать / тестировать / поддерживать больше типов артефактов выпуска, тем более что мы будем поставлять больше артефактов выпуска для cli v2.

На данный момент у нас нет точных сроков, но это происходит.

Разработчики Amazon и многие другие утверждают, что это легко сделать, но все еще ждем через 2 года и без ETA 😂

+1

Внутренняя инфраструктура выпуска (4 квартал 2019 г.)
оценка юридической группы (I квартал 2020 г.)
публичная бета-версия под aws / cli-dev-test (2 квартал 2020 г.)
финальный выпуск (3 квартал 2020 г.)

В этом оптимистичном графике вы получите желаемое менее чем за 10 месяцев. 🥇

жду поста в блоге Джеффа Баррса

Я чертовски жду этого.

Можем ли мы получить хотя бы официальное объявление или обязательство. Может целевой релиз?

@bhmckendrick - это обязательство, не совсем то, что этот комментарий не намного выше вашего?

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

старше года и без обновлений? Изображение?

Привет , ветку , пока у вас не будет чем поделиться?

количество людей, которые полностью не желают читать ( подсказка ) и вместо этого решают спамить более 70 наблюдателей о том, как они _ конкретно_ раздражены, я уверен, что резко снижает интерес всех к отслеживанию этой темы.

Кроме того, спасибо за вашу работу, направленную на то, чтобы это произошло!

Как первоначальный автор этого выпуска (ну, я был достаточно храбрым, чтобы скопировать / вставить ранее закрытые "wontfix"), я уже отказался от подписки на этот выпуск из-за массового спама +1 и периодических драк с изображениями кошек (извините) .

Просто настройте параметры уведомлений, чтобы получать уведомления только в том случае, если проблема закрыта.

Я просто хотел бы указать на то, что помимо CI / CD, некоторые разработчики (см. @LongLiveCHIEF) предпочитают иметь dockerized среды разработки и не любят устанавливать что-то изначально или иметь дело с последующими менеджерами версий для родные языки, на которые неизбежно полагаются эти инструменты cli.

docker pull aws-cli проще, чем любые существующие шаги установки ... не говоря уже о том, что если вы не разработчик Python, у вас есть накладные расходы на настройку хорошей версии Python и среды для вашего пользователя, или, возможно, даже каждый проект.

Масштабируйте это для всех различных инструментов, которые может использовать разработчик (cli на основе Ruby, cli на основе узлов), и вам нужно изучить настройки среды для языков, на которых вы, возможно, никогда не кодируете.

Я хочу сказать, что docker run является повсеместным и избавляет от любых настроек / конфигов на родном языке и упрощает работу для пользователей.

Даже если пользователи создают свои собственные образы докеров, им все равно придется бороться с этими задачами настройки.

Я не пишу код на python, но я был вынужден изучать все тонкости виртуальных сред и их лучшие практики из различных версий python просто потому, что поставщики инструментов считают это «тривиальным».

Не все разработчики имеют тот же опыт, что и те, кто создал этот инструмент, и предоставление образа докера является признаком уважения. Поставщики инструментов могут очень быстро и легко взять на себя накладные расходы, связанные с особенностями среды, специфичными для родного языка, в то время как последователи должны тратить гораздо больше времени на управление этими накладными расходами на различных этапах жизненного цикла разработки вашего продукта.

Пища для хотя.

@jamesls Спасибо, что

Поскольку я работаю на крупном предприятии, позвольте мне помочь вам:
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://hub.docker.com/r/amazon/aws-cli

Вроде наконец-то здесь :)

@pablosjv это не официальное или сертифицированное изображение. Помните об этом.

@anjakammer Похоже, это официальный образ Amazon , хотя это не официальный образ, опубликованный Docker .

Не знаю, готов ли он к продакшну, потому что в этом номере еще ничего не сказано.

Любопытно, насколько этот образ AWS составляет 98,42 МБ, тогда как другие (например, atlassian / pipelines-awscli ) намного меньше.

Член команды CLI здесь. Да, я могу подтвердить, что мы официально запустили образ Docker для AWS CLI v2! Я рекомендую прочитать следующее:

Я собираюсь закрыть этот вопрос. Если у вас есть отзывы или вопросы об изображении, откройте другой выпуск GitHub в этом репозитории.

Как открывший исходный выпуск № 3291 много лет назад, я испытываю такую ​​радость, что мои опасения наконец подтвердились и теперь доступен официальный образ Docker. Снимки горшка о том, сколько времени потребовалось для создания этого изображения, я уверен, что это было намного легче сказать, чем сделать, поэтому большое спасибо разработчикам Amazon, которые сделали это возможным. Вы все делаете отличную работу. 👏🎉👏

_Хорошо, Алекса, я поблагодарил их, пожалуйста, отпустите мою семью.

Доступен ли где-нибудь Dockerfile ?

@zerkms Ага, нашел в ветке v2 :
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

Думаю, они наконец-то это делают, но мне не удалось запустить его на Gitlab CI https://hub.docker.com/r/amazon/aws-cli

Вместо этого я использую образ докера Gitlab AWS CLI, и он отлично работает. Просто используйте

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>> , что было бы похоже на запуск cli с aws <<command>> вместо docker run --rm amazon/aws-cli aws <<command>> . У каждого подхода есть свои плюсы и минусы, в зависимости от того, что вы предпочитаете, и от того, как вы запускаете изображение, но переопределение точки входа в любом случае должно помочь.

@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 и выполняет свою работу, но дайте мне знать через мои проблемы с github, если что-то еще требуется в образе (допустимый вариант использования).

Это очень просто, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile и выполняет свою работу, но дайте мне знать через мои проблемы с github, если что-то еще требуется в образе (допустимый вариант использования).

Вышеупомянутый APK основан на AWS-CLI 1.18, а не на интерфейсе командной строки v2.

Есть ли шанс, что Amazon рассмотрит возможность создания образа с версией 1 интерфейса командной строки?

@keeganwitt Вы должны открыть новую

Была ли эта страница полезной?
0 / 5 - 0 рейтинги