Subprocess.Popen выдает «Нет такого файла» при запуске внутри контейнера Docker - PullRequest
Новая
       6

Subprocess.Popen выдает «Нет такого файла» при запуске внутри контейнера Docker

0 голосов
/ 02 апреля 2019

Я запускаю приложение на Python из док-контейнера. Приложение представляет собой сценарий, который последовательно вызывает набор исполняемых файлов с использованием подпроцесса.

Сценарий запускался нормально, когда я тестировал его как таковой на моей машине Centos, но завершается неудачно с «файлом не найден» (предположительно для исполняемого файла), когда подпроцесс, вызывающий исполняемый файл, вызывается внутри контейнера Docker

Я пробовал это использовать Python 2.7 и Centos7 в качестве базового контейнера, но проблема сохраняется.

Код Python, который выдает ошибку: 

def __CallCommand(self, program, command):
        """ Allows execution of a simple command. """
        out = ""
        err = ""
        p = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        out,err = p.communicate()

ошибка: OSError: [Errno 2] Нет такого файла или каталога

вот мой докер-файл 

FROM python:2.7-alpine


RUN mkdir -p /input
RUN mkdir -p /output
RUN mkdir -p /executables

COPY config.yml        .
COPY executables       /executables
COPY pipeline.py       .
COPY input             /input

ENTRYPOINT ["python", "pipeline.py", "-i", "/input/inputFile.txt", "-o", "output"]

Ответы [ 2 ]

0 голосов
/ 03 апреля 2019

Спасибо @DazWilkin! Интерактивная оболочка в контейнере очень помогла!

Первым исполняемым файлом был файл JRE, а в моем контейнере не было java (интересно, о чем я думал :), запустив его без Java). Добавил Java и Python в контейнер Centos, и теперь я могу его запустить.

0 голосов
/ 02 апреля 2019

Из вашего резюме не совсем понятно, как работает ваше решение, но при условии, что вы перебираете /executables и помещаете их в __CallCommand, возможно, что ваши исполняемые файлы не будут работать на Alpine, если они собраны (связаны)в CentOS.

Я могу создать и запустить воспроизведение вашего кода, но с помощью исполняемых файлов Alpine (busybox) и не пытаться копировать двоичные файлы. Затем я скопировал echo моего локального дистрибутива, это не получается (как и ожидалось)

Вы можете попробовать запустить исполняемые файлы, скопированные в контейнер: 

docker run --interactive --tty --entrypoint ash [[your-image]]`
/ # cd executables/
/executables # ls -l
total 32
-rw-r--r--    1 root     root             0 Apr  1 23:13 1
-rw-r--r--    1 root     root             0 Apr  1 23:13 2
-rwxr-xr-x    1 root     root         31464 Apr  1 23:38 echo
/executables # ldd echo
        /lib64/ld-linux-x86-64.so.2 (0x7f405d498000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f405d498000)
Error relocating echo: __printf_chk: symbol not found
Error relocating echo: error: symbol not found
Error relocating echo: __fprintf_chk: symbol not found
/executables # ./echo Hello
ash: ./echo: not found

Вам следует:

  • использовать не-Alpine FROM image
  • сборка бинарных файлов для Alpine
  • установка glibc на Alpine

Дополнительная информация

На Alpine (с использованием собственного |busybox) echo команда: 

ldd /bin/echo
        /lib/ld-musl-x86_64.so.1 (0x7ff4f8848000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7ff4f8848000)

Вы видите, что используется musl (Alpine использует эту версию libc)

Мой локальный хост имеет Debian ион использует библиотеку GNU C (glibc): 

ldd /bin/echo
        linux-vdso.so.1 (0x00007ffc88ff6000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6933af1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6934098000)

Вы можете увидеть libc.so ссылки наgnu/libc

...