Aws-cli: CI/CD 시나리오에서 사용하기 위한 AWS CLI가 있는 공식 Docker 이미지

저도 CI/CD 환경에서 사용할 공식 aws-cli 도커 이미지를 찾고 있기 때문에 여기 있습니다. 대신 원래 파이프라인에서 공식 파일을 참조할 수 있을 때 aws cli를 포함하는 도커 이미지를 빌드하기 위해 이제 다른 파이프라인을 만들 것입니다.

또한 ... 다른 사람도 https://hub.docker.com/r/google/cloud-sdk를 얻습니다

@matti 및 @nscavell , 이 주제에 대한 후속 조치에 감사드립니다. 이 기능 요청에 관심이 있어 계속 열어 두는 것 같습니다. 이 문제는 AWS CLI의 공식 Docker 이미지를 추적하는 데 사용됩니다. 관심을 표시하고 우선 순위를 정하는 데 도움이 되도록 +1하세요.

감사 해요.

+1은 유해한 것으로 간주되지 않습니다 ;)

어쨌든 이것은 이것에 대해 생성 된 세 번째 (?) 문제입니다 ...

👍 내 +1 추가

내 CI에 awsCLI만 포함하려면 고유한 도커 이미지를 만들어야 합니다. 나는 공식 것을 선호한다.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Heres는 다른 사람이 그 동안의 최신 버전을 찾고에 대한 설치 가장 최근의 CLI와 고산 (게시물 수정) 이미지.

@저스트넌스 충분해?

+1

+1

+1

+1

또 다른 이유는 패키지 관리가 없는 coreOS와 같은 OS를 사용하는 경우 관용적인 실행 방식이 컨테이너를 통하는 것입니다. 나는 이것에 대한 필요성이 의심되는 것에 놀랐습니다. 명백한 누락입니다. 👍

+1

:+1:

+1

+1

+1

+1

+1

#3291(3개의 인용된 문제 중 가장 이른 것)의 시작자로서, 이 문제가 마침내 주목을 받고 있다는 것을 알게 되어 기쁩니다. 미래의 모든 응답자에게 @justnance 가 "관심을 나타내려면 +1을 해주세요"라고 말하면 첫 번째 댓글에 좋아요를 추가한다는 의미입니다. 이는 GitHub에서 +1하는 적절한 방법이므로 관리자의 사서함에 스팸을 보내지 않도록 해야 합니다. .

리포지토리 소유자에게 알림을 유지하려면 +1

+1

+1 문제 라고 하면 👍 버튼을 누르

@davidham - 명확히 해 주셔서 감사하고 응답해

2일 전에도 똑같은 말을 했지만 헐 우리는 다 같은 편이다 🙃

+1

+1

+1

+1

+1

+1

+1

+1을 멈출 수 있습니까? +1하고 싶다면 상단에서 하세요.

귀중한 엔지니어 시간을 낭비하고 있습니다. 우리는 이 문제를 구독했습니다...

저는 2년 넘게 aws-cli 이미지를 유지하고 있습니다. 필요한 경우 자유롭게 사용하십시오(저는 하루에 여러 번 사용합니다). (IFTT를 통해) 새 버전 릴리스에 대한 업데이트를 수신하고 업데이트를 상당히 빠르게 푸시합니다. 내 자신의 이미지를 운영하는 명성과 영광에도 불구하고(하!) 공식 이미지를 사용하도록 사람들을 _기쁘게_ 연기할 것입니다.

• GitHub 리포지토리
• 도커 허브

오랫동안 제 이미지를 사용한 후, 공식 이미지에 jq (API가 JSON이 무겁기 때문에)가 포함되어 있으면 _매우_ 도움이 된다고 말씀드리고 싶습니다. 단일 CI/CD 파이프라인 단계에서 "최신 ECS 작업 정의 가져오기, 변경 및 푸시백"과 같은 작업을 모두 수행하는 것이 매우 편리합니다.

문제에 대한 또 다른 대안 솔루션: 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 파이프라인과 같은 고가치 대상에 사용되는 이미지를 유지 관리하는 "인터넷 상의 임의의 사람"에 대한 종속성을 제거하여 위협 모델을 더 단순하게 만듭니다.

docker:18 (현재 안정적인) 이미지(https://hub.docker.com/_/docker)를 기반으로 하는 공식 aws-cli docker 이미지를 원합니다. aws-cli-docker-18은 현재 docker:18 이미지를 사용하는 CI/CD 환경에서 도커 이미지를 빌드하고 AWS ECR에 게시하고 싶기 때문입니다.

+1

+1

사람들이 자신의 논평이 당면한 문제에 기여하지 않을 때 논평을 자제한다면 좋을 것입니다. "+1"과 같은 댓글은 구독자에게 스팸을 제공하고 문제를 필요 이상으로 길게 만듭니다. 대신, 문제의 첫 번째 댓글에 엄지손가락을 치켜듭니다.

사람들이 자신의 논평이 당면한 문제에 기여하지 않을 때 논평을 자제한다면 좋을 것입니다. "+1"과 같은 댓글은 구독자에게 스팸을 제공하고 문제를 필요 이상으로 길게 만듭니다. 대신, 문제의 첫 번째 댓글에 엄지손가락을 치켜듭니다.

이 문제는 작년 9월부터 공개되었습니다. 분명히 관심이 있기 때문에 AWS에 이 문제를 다시 검토해 달라고 요청해야 한다고 생각합니다. 우리는 얼마나 많은 관심이 "충분한지" 말해야 합니다.

분명히 관심이 있기 때문에

관심뿐만 아니라 더 많은 :+1: 반응 이 있는 열린 문제입니다.

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

2호는 2014년, 3호는 2015년에 열렸고, 이번 호는 2018년 9월(1년 미만) 에 열렸습니다.

+1000

aws-cli가 작동하도록 올바른 종속성을 설정하는 데 항상 로컬 컴퓨터에 문제가 있습니다. 따라서 docker 내부에서 aws-cli로 전환하기로 결정했습니다. docker-hub에서 공개적으로 사용 가능한 여러 이미지를 찾았지만 공식이 아니기 때문에 기본적으로 신뢰하지 않으므로 사용 가능한 업데이트된 버전이 있을 때마다 신뢰할 수 있는 이미지를 검색하고 다시 찾아야 합니다. 사용하기에 안전합니다. AWS에서 도커 허브를 통해 안전한 aws-cli 도커 이미지를 구축, 유지 관리 및 제공하십시오. 미리 감사드립니다

커뮤니티에서 제공한 aws-cli 이미지의 거대한 조각화가 있습니다. 그러나 앞서 언급했듯이 사람들은 공식적으로 Amazon에서 유지 관리하고 지원하는 것을 선호합니다. 몇 가지 이유:

1) 오래되지 않을 것입니다. 커뮤니티 이미지는 결국 오래 가지 않는 것으로 유명합니다.
2) 더 안전함 -- 커뮤니티 구성원이 아무리 신뢰할 수 있더라도 공식적으로 Amazon을 대표하지 않으므로 "모든 보증이 무효"인 신뢰할 수 있는 리소스에서 제공됩니다.
3) 공식 지원은 버그, 버전 충돌, 하위 호환성 등의 경우 공식 지원을 의미합니다.
4) AWS는 기록 태그를 포함하여 aws cli를 업데이트할 때 이미지를 업데이트할 수 있습니다.

+1

+1 아마존이 이것을 제공하지 않는 것은 정말 유감입니다

그 이후 로 편리한 다른 이미지를 추가했습니다. Docker의 Docker를 AWS 및 SAM CLI와 결합하여 완벽한 ECR 통합을 구현합니다.

dind-aws-cli

+1

관리가 잘 된 비공식 이미지가 많이 있지만 언젠가는 "아, 이걸 더 이상 업데이트해야 하는 이유가 무엇입니까. 이것이 Amazon의 일입니다!"라고 말하는 것을 막을 수 있는 방법은 무엇입니까?

+1

+1

사람들이 AWS를 사용하여 작업을 자동화하도록 돕는 것과 관련하여 Amazon은 큰 실패를 겪고 있습니다. 이것이 우리가 Amazon을 떠나려고 생각하는 이유 중 하나입니다.

이것이 아직 로드맵에 있는지 여부에 대한 유지 관리자의 공식 응답이 있습니까? 다른 많은 사람들과 마찬가지로 나도 공식 이미지를 사용하는 것을 선호합니다...

+1

AWS CLI에 대한 공식 이미지가 있는 경우 스크래치 컨테이너 내부에 있는 실행 파일이 될 것입니다. 개인에게 매우 유용하지 않기 때문에 가장 좋은 방법은 다음과 같습니다.

• 공식 Python 컨테이너를 사용하여 소스에서 CLI 빌드
• 결과 AWS CLI 바이너리를 busybox 또는 스크래치 컨테이너에 복사합니다.

여기서 일어나는 논쟁에도 불구하고 더 많은 것은 과잉 엔지니어링 될 것입니다.

AWS는 모든 ECR 및 CodeDeploy 서비스를 시연하는 것을 좋아합니다. 왜 그들은 자신의 컨테이너화된 CLI에서 모든 화력을 가리키지 않습니까?

테이블에 있는 제안은 커뮤니티의 누군가가 이를 유지 관리하기 위한 것처럼 보이기 때문입니다.

@balibebas 커뮤니티의 누군가가 이미 하고 있습니다. 엄청난 양의 이미지가 있지만 여기에서 요점은 AWS에서 제공하는 이미지가 있다는 것입니다. 모든 비밀이 열린 상태로 CI 환경에서 randomguy/aws-cli:canbechangedanytime 를 실행하고 싶지 않기 때문입니다.

그렇다면 F-Droid에 대해 어떻게 말씀하시겠습니까?

이 고양이만큼 이 문제와 관련이 있습니다.

당신은 유료 고객처럼 들립니다.

글쎄 아마도 그것은 _I_ _am_ 때문일 것입니다.

합창단에 설교. 어쨌든 Brew 공식은 더 오래 트롤링되었지만 여전히 움직임이 없기 때문에 더 나은 기회를 얻었습니다. 따라서 고양이 사진은 앞서 지적했듯이 스크래치나 바쁜 상자 컨테이너 외부에 일반적인 사용 사례가 없을 때 즉시 역효과를 낳습니다. 당신의 디자인 제안은 무엇입니까?

나와 다른 많은 사람들은 현재 "busybox 컨테이너"를 수행하여 ECR 인증 자격 증명을 얻기 위해 도커로 실행하고 있습니다. aws가 가지고 있는 docker things의 수를 감안할 때 공식 패키징이 존재하지 않는다는 것은 말이 되지 않습니다.

어쩌면 그들은 다른 것에 관심이 있습니다. ;)

이제 문제가 해결되어 기쁩니다. +1 댓글로 돌아가기:

Dockerless의 경우 +1

@matti @balibebas 현재 이 문제의 대화에만 64명이 있으며 모든 응답은 잠재적으로 구독 중인 64명 이상의 모든 사람에게 전송될 도움이 되지 않는 이메일 및 알림을 트리거합니다. 이 메시지도 마찬가지이며 이에 대해 사과드립니다.

그러나 정말로, 일을 전문적으로 유지하십시오. 고양이 사진은 좋지만 이 실이 레일에서 멀어질수록 관리자가 심각하게 받아들이지 않을 것 같습니다. 안타깝게도 스팸은 스팸입니다.

내가 방금 클릭한 구독 취소 버튼이 하는 일입니다.

그것은 좋은 것입니다. 나는 아무 조치도 취하지 않거나 이것이 유지되고 있다는 사실에 놀랐습니다(NO라고 말하는 것을 포함).
어쨌든 위의 사람들은 공식 aws cli 이미지의 중요성을 올바르게 지적했습니다.
나는 사람들이 이미 개인적으로 또는 다른 사람이 만든 이미지/패키지 관리자 경로 등을 통해 자신의 것을 사용하고 있다고 생각합니다.
같은 것에 대한 또 다른 예제 스크립트

그러나 가장 간단하고 피할 수 없는 문제는 그대로입니다.

• 개발자가 자체적으로 통합해야 하는 경우 홉핑되는 종속성 및 불확실성의 끝없는 목록입니다. 사람들이 CI/CD 또는 격리되고 깨끗한 상태의 유사한 작업의 목적을 무효화하는 환경 오염 작업을 수행하기 위해 한 가지를 설치한 다음 다른 것을 설치하기 시작하기 때문에 결국 저장소에서 더 많은 문제로 이어질 것입니다.
• 귀하의 작업에 대해 다른 사람의 도커 이미지를 구현하고 추적하는 것을 신뢰하기 어렵습니다. 이것은 새로운 awscli 이미지에 대한 도커 레지스트리에 다른 파이프라인 및 항목 추가, 즉 유지해야 할 또 다른 저장소를 만듭니다.
• CI/CD에서 내가 선호 하는 것은 이미지(내부 또는 공식)를 사용하고 가능한 한 많은 것을 추가하기 위해 스크립팅 라인을 피하는 것입니다.
• 공식 이미지로서의 빌드 및 라이브러리 문제는 소스 릴리스 자체에서 즉시 빌드할 수 있으며 패키지 관리자 및 그렇지 않은 경우 동적 종속성이 적습니다.

또 다른
=> 모두가 결국 자신의 것을 만듭니다.

여기에서도 마찬가지입니다. 현재 자체 빌드 이미지를 사용하고 있지만 아래의 공식 이미지를 선호합니다.

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

네임스페이스. 이를 사용하여 다른 도커 이미지를 빌드하고 자격 증명을 얻기 위해 awscli가 필요한 ECR로 푸시합니다.

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에 대해 더 많은 릴리스 아티팩트를 출시할 예정이기 때문입니다.

현재 정확한 일정은 없지만 진행 중입니다.

amazon devs 및 다른 많은 사람들에 따르면 하기 쉬운 일이지만 2년이 지난 후에도 여전히 대기 중이며 ETA가 없습니다 😂

+1

내부 출시 인프라(2019년 4분기)
법무팀 평가(2020년 1분기)
aws/cli-dev-test의 공개 베타(2020년 2분기)
최종 릴리스(2020년 3분기)

이 낙관적인 일정에서 10개월 이내에 원하는 것을 얻을 수 있습니다. 🥇

제프 바 블로그 포스트를 기다립니다

젠장 기다리고 있어.

최소한 공식 발표나 약속을 받을 수 있습니까? 아마도 대상 릴리스 ?

@bhmckendrick 은 이 댓글이 당신보다 훨씬 높지 않은 것과 정확히 일치하지 않는 약속입니까?

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

1년이 넘었는데 업데이트가 없습니까? 영상?

@jamesls 님 , 공유할 내용이 있을 때까지 이 스레드를 잠그는 것을 고려하시겠습니까?

읽기를 완전히 꺼리고( 힌트 힌트 ) 대신 70명 이상의 관찰자들에게 스팸 메일을 보내 그들이 _구체적으로_ 짜증나게 하는 방식을 선택하는 사람들의 수는 확신합니다. 이 스레드를 팔로우하는 모든 사람들의 관심이 크게 감소하고 있습니다.

또한 이러한 일이 일어나도록 노력해 주셔서 감사합니다!

이 문제의 원저자로서(글쎄요, 저는 이전에 닫은 "wontfix" 항목을 복사/붙여넣기할 만큼 충분히 용감했습니다) 엄청난 +1 스팸과 고양이 사진과의 가끔 싸움 때문에 이미 이 문제의 구독을 취소했습니다(죄송합니다) .

이 문제가 해결된 경우에만 알림을 받도록 알림 설정을 조정하세요.

CI/CD를 제외하고 일부 개발자(@LongLiveCHIEF 참조)는 도킹된 개발 환경을 선호하며 기본적으로 설치하거나 후속 버전 관리자를 처리하는 것을 좋아하지 않는다는 점을 지적하고 싶습니다. cli 도구가 필연적으로 의존하는 모국어.

기존 설치 단계보다 docker pull aws-cli 것이 더 쉽습니다... python 개발자가 아닌 경우 사용자를 위해 좋은 python 버전과 환경을 설정하는 오버헤드가 있거나 아마도 심지어 각 프로젝트.

개발자가 사용할 수 있는 모든 다양한 도구(루비 기반 cli, 노드 기반 cli)로 확장하고 코딩하지 않은 언어에 대한 환경 설정을 배워야 합니다.

내가 여기서 말하고 있는 요점은 도커 실행이 유비쿼터스이며 모든 모국어 설정/구성을 제거하고 사용자가 작업을 쉽게 수행할 수 있도록 한다는 것입니다.

사용자가 자신의 도커 이미지를 빌드하더라도 여전히 이러한 설정 작업과 씨름해야 합니다.

저는 파이썬으로 코딩하지 않지만, 순수하게 도구 공급자가 그것을 "사소한" 것으로 간주하기 때문에 다양한 버전의 파이썬에서 가상 환경의 내용과 모범 사례를 배우지 않을 수 없었습니다.

모든 개발자가 도구를 만든 사람과 동일한 배경을 가진 것은 아니며 도커 이미지를 제공하는 것은 존경의 표시입니다. 도구 제공업체는 모국어 특정 환경 문제의 오버헤드를 매우 빠르고 쉽게 처리할 수 있지만 채택자는 제품 개발의 다양한 라이프사이클 단계를 통해 이 오버헤드를 관리하는 데 훨씬 더 많은 시간을 소비해야 합니다.

그래도 음식.

@jamesls 여기에서 커뮤니티 피드백을 들어주셔서 감사합니다. 공식 호스팅 도커 이미지를 기다리는 동안 유용한 중간 단계는 여기에 몇 가지 인기 있는 기본 도커 이미지(예: 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://hub.docker.com/r/amazon/aws-cli

드디어 온 것 같습니다 :)

@pablosjv 공식 또는 인증된 이미지가 아닙니다. 알아두세요.

@anjakammer 도커에서 공개한 공식 이미지 는 아니지만 아마존 공식 이미지 인 것 같습니다.

그들이 아직 이 문제에 대해 아무 말도 하지 않았기 때문에 힘든 생산 준비가 되었는지 모르겠습니다.

이 AWS 이미지가 98.42MB인 반면 다른 이미지(예: atlassian/pipelines-awscli )는 훨씬 작은지

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

CLI 팀원이 여기에 있습니다. 예, AWS CLI v2용 Docker 이미지를 공식적으로 출시했음을 확인할 수 있습니다! 다음을 읽는 것이 좋습니다.

• 블로그 게시물 소개: https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/
• 사용 설명서 항목: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html
• DockerHub 리포지토리: https://hub.docker.com/r/amazon/aws-cli

이 문제를 마무리하겠습니다. 이미지에 대한 피드백이나 질문이 있는 경우 이 리포지토리에서 다른 GitHub 문제를 여십시오.

원호 #3291의 개막작인 몇 년 전, 내 고민이 마침내 확인되고 이제 공식 Docker 이미지를 사용할 수 있게 된 것을 보는 기쁨으로 가슴이 뭉클합니다. 이 이미지를 만드는 데 시간이 얼마나 걸렸는지에 대한 포트 샷, 나는 이것이 말보다 훨씬 쉬웠을 것이라고 확신합니다. 그래서 이것을 가능하게 한 Amazon 개발자들에게 큰 감사를 드립니다. 여러분 모두 훌륭한 일을 하고 있습니다. 👏🎉👏

_알렉사, 감사합니다. 이제 가족을 보내주세요._

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 도커 이미지를 사용하고 있으며 완벽하게 작동합니다. 그냥 사용

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 docker run --rm amazon/aws-cli <<command>> 처럼 docker run --rm amazon/aws-cli aws <<command>> 대신 aws <<command>> cli를 실행하는 것과 유사한 cli 자체인 것처럼 이미지를 실행하기 때문이라고 생각합니다 docker run --rm amazon/aws-cli <<command>> . 선호하는 것과 이미지를 실행하는 방식에 따라 각 접근 방식에는 장단점이 있지만 어쨌든 진입점을 재정의하면 트릭을 수행해야 합니다.

@lucasbasquerotto 어쨌든 Gitlab의 이미지로 정착했습니다. 어쨌든 설명 감사합니다.

Alpine Linux에서 AWS CLI v2가 작동하도록 하는 데 여전히 관심이 있는 사람이 있는 경우 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는 v2 CLI가 아닌 AWS-CLI 1.18 기반입니다.

Amazon이 CLI 버전 1로 이미지 생성을 고려할 가능성이 있습니까?

@keeganwitt 해당 요청에 대한 새 문제를 열어야 합니다. :+1: