Aws-cli: [v2] alpine / musllibcのバイナリを配布する

問題をデバッグしようとしましたが、失敗する理由がわかりませんでした。 インストールスクリプトは少し不安定なようです。 v2ラベルも追加してみました。

公開するバイナリは、glibcに対してコンパイルしているため、 alpine基づくDockerイメージでは機能しません。 sh: aws2: not foundは、このバイナリを実行しようとしたときに発生することです。 ubuntu:latestのような画像で試してみると、インストーラーが機能します。

さらに、一般的なLinuxバイナリの場合のように、アルパイン互換のバイナリをリリースすることはないと思います。 アルパイン上に構築されたバイナリに付属するDockerイメージをリリースする傾向があると思います。

ご回答有難うございます。 https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.htmlの「Linuxの前提条件」の下にそれを文書化すること、または高山ベースでエラーをよりユーザーフレンドリーにすることは可能ですか？イメージケース？

これはユーザーガイドで必ず更新されます。 この場合、よりユーザーフレンドリーなエラーメッセージを作成するというアイデアも気に入っています。

@joguSD残念、アルパインはDockerイメージの標準です。 特に、自動化を望んでいて、非常に大きなDockerイメージを継続的にダウンロードしたくないビルド/ ciシステムの場合。

ただし、マルチステージビルドで公式のアルパインドッカーイメージを使用して、バイナリを別のドッカーイメージにコピーできます。

@ chadgrant-多段階のdockerfileの例を挙げていただけますか？

@ BarakBD-Globality私は持っていませんが、aws-alpineイメージが作成された場合は、次のようにすることができます。

FROM aws_alpine_image:latest as aws
FROM alpine:latest
COPY --from=aws /usr/local/bin/binary /usr/local/bin/binary

残念ながら、彼らは高山をサポートしていません。 標準画像です。

さらに、一般的なLinuxバイナリの場合のように、アルパイン互換のバイナリをリリースすることはないと思います。 アルパイン上に構築されたバイナリに付属するDockerイメージをリリースする傾向があると思います。

@joguSDこれについて何か議論や動きはありましたか？ 高山の蔓延を考えると、かなり大したことのようです。 私のような人々は、cicdやその他の自動化でawsを使用しているため、高山ベースの画像で使用できない場合、バージョン2を使用することは、多大な労力がなければオプションではありません。 ありがとう。

busyboxもインストールできません

興味深いことに、これをベースイメージとして使用すると、AWS cliがインストールされ、正しく機能します。

からadoptopenjdk / openjdk11：alpine

次のDockerfileを使用してこれを行うことができました

FROM adoptopenjdk/openjdk11:alpine

RUN apk add --no-cache \
        ca-certificates \
        unzip \
        curl \
        groff \
        less  \
        bash  \
        openssh-client

WORKDIR /home
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" \
    && unzip awscliv2.zip \
    && ./aws/install \
    && rm awscliv2.zip \
    && rm -R aws

Adaptopenjdkイメージが機能する理由は、欠落しているglibcライブラリが含まれているためです。 Alphine linuxは、本格的なglibcの軽量な代替手段である「muslglibc」に基づいています。 aws cli v2バイナリはmuslでは機能しません。機能するには、さらにいくつかのライブラリが必要です。

Javaイメージを使用する代わりに、AlpineLinuxでAWSCLIv2を実行する方法の例として以下のDockerfileを使用することもできます。

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

上記では、glibcライブラリをダウンロードし、AWS CLI v2をダウンロードしてインストールし、オートコンプリートなど、おそらく不要なものをいくつか削除します。 結果の画像のサイズは約100MBです

では、Dockerコンテナ内でaws ecr get-login-password … | docker login …を実行するための最短パスは何ですか？ （これは、 docker:dindを意味します）？

docker:dindサポートする独自のdocker:stableイメージを作成することは避けたいと思います。 少なくとも、 https： //github.com/aws/aws-cli/issues/4685#issuecomment-615872019ソリューションに感謝することができ

@bentolor docker:dindもアルパインを使用しているので、あなたがしなければならないのは、上記のDockerfileの最初の行を変更することだけだと思います。 代わりにFROM alpine:3.11あなたが使用する必要がありますFROM docker:dind 。 しかし、それはあなたがあなた自身のイメージを構築していることを意味します。

ありがとう@blagerweijは本当にうまく機能します

また、 @ blagerweijに感謝します。ソリューションをコピーして貼り付けることで、イラクサを把握し、パブリックなカスタムDockerイメージを作成しました： https ：

@bentolor私はあなたのDockerfileが使用するあなたのレポに気づいFROM docker:stableの代わりにFROM docker:dind 。 肝心なのは、AWSをサポートするDockerでDockerのイメージを作成することだと思いましたか？

@blagerweij説明については、公式のDockerイメージから以下のイメージを参照してください。

一般的な使用法は次のとおりです。

1. 1つ（またはあなたのci）がdocker:dindインスタンスを開始してから
2. 開始されたdocker:dindコンテナにリンクされている別のdocker:stableインスタンスを開始します
3. 2番目のコンテナー内でdockerコマンドの実行を開始します。これにより、ソケット接続を介して、最初のdocker:dindコンテナー内で実行されているdockerデーモンにコマンドがリダイレクトされます。

したがって、 docker:dindインスタンスが最終的にDockerコマンドを実行するのは事実ですが、CLIフロントエンドは実際にはdocker:stableインスタンスに存在します。 そして、それは1つがAWSにログインする必要がある場所です;-)

少なくともこれは私が知っている使用パターンです（つまり、 Gitlab CIを使用してdocker:dind使用シナリオもありますか？

https://hub.docker.com/r/frolvlad/alpine-glibc/のglibcで高山の画像を使用できます
そして、awsドキュメントの手順に従ってawscliをインストールします。 私のために働いた。

@blagerweijDockerイメージのdockerでスクリプトを使用しました。 awscliは正常に機能します。 ビルドでエラーが発生しました：
/usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-x86-64.so.2 is not a symbolic link

@amiramはい、そのメッセージも受け取ります。これは、単に無視できる警告です。シンボリックリンクが必要ですが、存在するファイルは通常のファイルです。 https://github.com/envoyproxy/envoy/issues/9078#issuecomment-576837432を参照して

誰かがこの問題の名前を「alpine / muslのバイナリを配布する」のような名前に変更できますか？

@joguSD @ jordanst3wart

ええ、「alpine / musllibcのバイナリを配布する」に満足しています。 問題があれば教えてください

パッションプロジェクトにはawss3 cpのみが必要なので、pipを使用してawscliV1をインストールしました。

FROM alpine:3.12
RUN pip install awscli        
RUN aws s3 ..

Adaptopenjdkイメージが機能する理由は、欠落しているglibcライブラリが含まれているためです。 Alphine linuxは、本格的なglibcの軽量な代替手段である「muslglibc」に基づいています。 aws cli v2バイナリはmuslでは機能しません。機能するには、さらにいくつかのライブラリが必要です。

Javaイメージを使用する代わりに、AlpineLinuxでAWSCLIv2を実行する方法の例として以下のDockerfileを使用することもできます。

をちょきちょきと切る

上記では、glibcライブラリをダウンロードし、AWS CLI v2をダウンロードしてインストールし、オートコンプリートなど、おそらく不要なものをいくつか削除します。 結果の画像のサイズは約100MBです

glibcバージョンをハードコーディングしたくない場合、この調整により最新バージョンが自動的にフェッチされます。

FROM alpine

# install glibc compatibility for alpine
RUN apk --no-cache add \
    binutils \
    curl \
    && GLIBC_VER=$(curl -s https://api.github.com/repos/sgerrand/alpine-pkg-glibc/releases/latest | grep tag_name | cut -d : -f 2,3 | tr -d \",' ') \
    && 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/*

AlpineLinuxでAWSCLI v2を実行する方法の例として、以下のDockerfileを使用することもできます。

提供されたDockerfile / scriptは機能しますが、このエラーが表示されます。これにより、機能が妨げられることはないようです。

aws/install: line 78: /aws/dist/aws: not found

不思議なことに、 apk add mandoc直前にaws/installを実行すると、このエラーが表示されなくなり、インストール後にそのパッケージを削除しても悪影響はありません。 ランダムな他のパッケージには、この保護効果がないようです。

何かご意見は？

PS apk add lessは、 aws helpが正しく機能するために必要です（そうでない場合は、パッケージgroffないことについて文句を言います）。