Почему моя сборка aws-cli работает с промежуточным контейнером во время сборки, но не с конечным контейнером?

#amazon-web-services #docker #aws-cli #alpine

#amazon-web-services #docker #aws-cli #alpine-linux

Вопрос:

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

После копирования двоичного каталога aws в пункт назначения все файлы передаются, но исполняемый файл aws больше не работает. Я пытаюсь сделать это либо из CMD, либо из docker exec, и я просто получаю сообщение об ошибке, что файл не существует: введите описание изображения здесь

У кого-нибудь есть какие-либо идеи, что происходит?

Это репозиторий docker, с которого я начал:https://hub.docker.com/r/alfg/nginx-rtmp /. Я просто вставляю приведенный ниже код сборки aws cli после блока ffmpeg FROM и добавляю COPY --from=2 строку ниже в этом вопросе.

Вот раздел сборки для aws cli:

 FROM alpine:3.11

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk --no-cache add 
        binutils 
        curl 
    amp;amp; curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub 
    amp;amp; curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk 
    amp;amp; curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk 
    amp;amp; apk add --no-cache 
        glibc-${GLIBC_VER}.apk 
        glibc-bin-${GLIBC_VER}.apk 
    amp;amp; curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip 
    amp;amp; unzip awscliv2.zip 
    amp;amp; aws/install 
    amp;amp; 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 
    amp;amp; apk --no-cache del 
        binutils 
        curl 
    amp;amp; rm glibc-${GLIBC_VER}.apk 
    amp;amp; rm glibc-bin-${GLIBC_VER}.apk 
    amp;amp; rm -rf /var/cache/apk/*
  

И вот заключительные шаги моего Dockerfile, которые копируют файлы и обновляют ПУТЬ:

 COPY --from=0 /usr/local/nginx /usr/local/nginx
COPY --from=0 /etc/nginx /etc/nginx
COPY --from=1 /usr/local /usr/local
COPY --from=1 /usr/lib/libfdk-aac.so.2 /usr/lib/libfdk-aac.so.2
COPY --from=2 /usr/local/aws-cli /usr/local/aws-cli

# Add NGINX path, AWS-CLI path, config and static files.
ENV PATH "${PATH}:/usr/local/nginx/sbin:/usr/local/aws-cli/v2/current/bin"
ADD nginx.conf /etc/nginx/nginx.conf.template
RUN mkdir -p /opt/data amp;amp; mkdir /www
ADD static /www/static

EXPOSE 1935
EXPOSE 80

CMD envsubst "$(env | sed -e 's/=.*//' -e 's/^/$/g')" < 
  /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf amp;amp; 
  nginx
  

Сборка docker выполняется успешно, и я могу запускать контейнеры из образа. Я также поместил такие вещи, как aws s3 ls s3://my-public-bucket в Dockerfile в конце блока aws-cli, и во время сборки они выполняются успешно и могут извлекаться из s3.

Единственное, что я вижу неправильного в сборке, это на изображении ниже — это происходит во время сборки glibc / aws, но сборка все равно успешно завершается, и двоичный файл после этого становится функциональным:

 /usr/glibc-compat/sbin/ldconfig: /usr/glibc-compat/lib/ld-linux-x86-64.so.2 is not a symbolic link
  

/usr/glibc-compat/ sbin/ldconfig: /usr/ glibc-compat/ lib / ld-linux-x86-64.so.2 не является символической ссылкой

Комментарии:

1. Я бы посоветовал сделать пару вещей. во-первых, убедитесь, что вы показываете ошибку, которую вы получаете, и, во-вторых, чтобы было немного более четко указано, что происходит сбой и когда. То, что вы указали, не дает большого представления о том, в чем заключается ваша проблема.

2. Да, извините за это — меня прервали, и я просто нажал отправить, когда я не закончил собирать всю информацию вместе. Теперь я обновил вопрос.

3. Почему бы просто не установить Python, а затем pip install awscli ? Кроме того, вы уверены, что скопировали все библиотеки glibc в конечный образ? Похоже, вы только что скопировали aws-cli без библиотек. Вы уверены, что она скомпилирована статистически? И последнее, но не менее важное: запустите ldd двоичный файл, чтобы увидеть, какие библиотеки отсутствуют.

4. @kichik Я специально хотел поддержку aws-cli v2, которая еще не построена на pip. Похоже, вы правы, что мне не удалось скопировать библиотеки. ldd показывает, что пара отсутствует.