У меня есть Dockerfile, который я собираю для установки среды vanilla python (в которую я буду устанавливать приложение, но позже).

FROM ubuntu:12.04

# required to build certain python libraries
RUN apt-get install python-dev -y

# install pip - canonical installation instructions from pip-installer.org
# http://www.pip-installer.org/en/latest/installing.html
ADD https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py /tmp/ez_setup.py
ADD https://raw.github.com/pypa/pip/master/contrib/get-pip.py /tmp/get-pip.py
RUN python /tmp/ez_setup.py
RUN python /tmp/get-pip.py
RUN pip install --upgrade pip 

# install and configure virtualenv
RUN pip install virtualenv 
RUN pip install virtualenvwrapper
ENV WORKON_HOME ~/.virtualenvs
RUN mkdir -p $WORKON_HOME
RUN source /usr/local/bin/virtualenvwrapper.sh

Сборка работает нормально до последней строки, где я получаю следующее исключение:

[previous steps 1-9 removed for clarity]
...
Successfully installed virtualenvwrapper virtualenv-clone stevedore
Cleaning up...
 ---> 1fc253a8f860
Step 10 : ENV WORKON_HOME ~/.virtualenvs
 ---> Running in 8b0145d2c80d
 ---> 0f91a5d96013
Step 11 : RUN mkdir -p $WORKON_HOME
 ---> Running in 9d2552712ddf
 ---> 3a87364c7b45
Step 12 : RUN source /usr/local/bin/virtualenvwrapper.sh
 ---> Running in c13a187261ec
/bin/sh: 1: source: not found

Если я lsпопаду в этот каталог (просто чтобы проверить, что предыдущие шаги были зафиксированы), я вижу, что файлы существуют, как и ожидалось:

$ docker run 3a87 ls /usr/local/bin
easy_install
easy_install-2.7
pip
pip-2.7
virtualenv
virtualenv-2.7
virtualenv-clone
virtualenvwrapper.sh
virtualenvwrapper_lazy.sh

Если я пытаюсь sourceвыполнить команду, я получаю ту же ошибку «not found», что и выше. Однако, если я запускаю сеанс интерактивной оболочки, источник работает:

$ docker run 3a87 bash
source
bash: line 1: source: filename argument required
source: usage: source filename [arguments]

Я могу запустить скрипт отсюда, а затем с радостью получить доступ workonи mkvirtualenvт. Д.

Я сделал некоторое рытье, и первоначально это выглядело так , как будто эта проблема может лежать в различии между Башем как Ubuntu шелл и тиром в качестве Ubuntu системы оболочки , тир не поддерживает sourceкоманду.

Тем не менее, ответом на этот вопрос является использование «.» вместо этого source, но это только приводит к тому, что среда исполнения Docker взрывается с исключением из-за паники.

Как лучше всего запустить сценарий оболочки из инструкции Dockerfile RUN, чтобы обойти это (я запускаю базовый образ по умолчанию для Ubuntu 12.04 LTS).

RUN /bin/bash -c "source /usr/local/bin/virtualenvwrapper.sh"

Оригинальный ответ

FROM ubuntu:14.04
RUN rm /bin/sh && ln -s /bin/bash /bin/sh

Это должно работать для каждого базового образа докера Ubuntu. Я обычно добавляю эту строку для каждого Dockerfile, который я пишу.

Редактировать заинтересованным свидетелем

Если вы хотите получить эффект «использовать bashвместо shвсего этого Dockerfile», не изменяя и не повреждая * ОС внутри контейнера, вы можете просто сообщить Docker о своем намерении . Это делается так:

SHELL ["/bin/bash", "-c"]

* Возможный ущерб состоит в том, что многие скрипты в Linux (при новой установке Ubuntu grep -rHInE '/bin/sh' /возвращают более 2700 результатов) ожидают полностью POSIX-оболочку в /bin/sh. Оболочка bash - это не просто POSIX плюс дополнительные встроенные функции. Есть встроенные функции (и даже больше), которые ведут себя совершенно иначе, чем в POSIX. Я ПОЛНОСТЬЮ поддерживаю избегать POSIX (и заблуждение, что любой скрипт, который вы не тестировали в другой оболочке, сработает, потому что вы думаете, что вы избежали басмизм), и просто использовать bashism. Но вы делаете это с правильным шебангом в вашем сценарии. Не вытаскивая оболочку POSIX из-под всей ОС. (Если у вас нет времени, чтобы проверить все 2700+ сценариев, поставляемых с Linux, плюс все те, которые есть в любых установленных вами пакетах.)

Более подробно в этом ответе ниже. https://stackoverflow.com/a/45087082/117471

Оболочка по умолчанию для RUNобучения является ["/bin/sh", "-c"].

RUN "source file"      # translates to: RUN /bin/sh -c "source file"

Используя инструкцию SHELL , вы можете изменить оболочку по умолчанию для последующих RUNинструкций в Dockerfile:

SHELL ["/bin/bash", "-c"] 

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

RUN "source file"    # now translates to: RUN /bin/bash -c "source file"

Дополнительное примечание : Вы также можете добавить --loginопцию, которая запускает оболочку входа в систему. Это означает, ~/.bachrcчто, например, будет прочитано, и вам не нужно явно указывать его перед вашей командой

У меня была такая же проблема, и для выполнения установки pip внутри virtualenv мне пришлось использовать эту команду:

RUN pip install virtualenv virtualenvwrapper
RUN mkdir -p /opt/virtualenvs
ENV WORKON_HOME /opt/virtualenvs
RUN /bin/bash -c "source /usr/local/bin/virtualenvwrapper.sh \
    && mkvirtualenv myapp \
    && workon myapp \
    && pip install -r /mycode/myapp/requirements.txt"

Я надеюсь, что это помогает.

Самый простой способ - использовать оператор точки вместо источника, который является эквивалентом команды bash source:

Вместо того:

RUN source /usr/local/bin/virtualenvwrapper.sh

Использование:

RUN . /usr/local/bin/virtualenvwrapper.sh

Если вы используете Docker 1.12 или новее, просто используйте SHELL!

Короткий ответ:

Общее:

SHELL ["/bin/bash", "-c"] 

для питона vituralenv:

SHELL ["/bin/bash", "-c", "source /usr/local/bin/virtualenvwrapper.sh"]

Длинный ответ:

со страницы https://docs.docker.com/engine/reference/builder/#/shell

SHELL ["executable", "parameters"]

Инструкция SHELL позволяет переопределить оболочку по умолчанию, используемую для команд оболочки. Оболочкой по умолчанию в Linux является ["/ bin / sh", "-c"], а в Windows - ["cmd", "/ S", "/ C"]. Инструкция SHELL должна быть написана в форме JSON в Dockerfile.

Инструкция SHELL особенно полезна в Windows, где есть две обычно используемые и совершенно разные собственные оболочки: cmd и powershell, а также доступны альтернативные оболочки, включая sh.

Инструкция SHELL может появляться несколько раз. Каждая инструкция SHELL переопределяет все предыдущие инструкции SHELL и влияет на все последующие инструкции. Например:

FROM microsoft/windowsservercore

# Executed as cmd /S /C echo default
RUN echo default

# Executed as cmd /S /C powershell -command Write-Host default
RUN powershell -command Write-Host default

# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]
RUN Write-Host hello

# Executed as cmd /S /C echo hello
SHELL ["cmd", "/S"", "/C"]
RUN echo hello

На инструкции SHELL могут повлиять следующие инструкции, если их форма оболочки используется в Dockerfile: RUN, CMD и ENTRYPOINT.

В следующем примере приведен общий шаблон, который можно найти в Windows и который можно упростить с помощью инструкции SHELL:

...
RUN powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"
...

Команда, вызываемая Docker, будет:

cmd /S /C powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"

Это неэффективно по двум причинам. Во-первых, вызывается ненужный командный процессор cmd.exe (он же оболочка). Во-вторых, каждая инструкция RUN в форме оболочки требует дополнительной команды powershell, префикс команды.

Чтобы сделать это более эффективным, можно использовать один из двух механизмов. Одним из них является использование JSON-формы команды RUN, например:

...
RUN ["powershell", "-command", "Execute-MyCmdlet", "-param1 \"c:\\foo.txt\""]
...

Хотя форма JSON однозначна и не использует ненужный cmd.exe, она требует большей детализации благодаря двойным кавычкам и экранированию. Альтернативный механизм заключается в использовании инструкции SHELL и формы оболочки, что делает более естественным синтаксис для пользователей Windows, особенно в сочетании с директивой escape-анализатора:

# escape=`

FROM microsoft/nanoserver
SHELL ["powershell","-command"]
RUN New-Item -ItemType Directory C:\Example
ADD Execute-MyCmdlet.ps1 c:\example\
RUN c:\example\Execute-MyCmdlet -sample 'hello world'

В результате чего:

PS E:\docker\build\shell> docker build -t shell .
Sending build context to Docker daemon 4.096 kB
Step 1/5 : FROM microsoft/nanoserver
 ---> 22738ff49c6d
Step 2/5 : SHELL powershell -command
 ---> Running in 6fcdb6855ae2
 ---> 6331462d4300
Removing intermediate container 6fcdb6855ae2
Step 3/5 : RUN New-Item -ItemType Directory C:\Example
 ---> Running in d0eef8386e97


    Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       10/28/2016  11:26 AM                Example


 ---> 3f2fbf1395d9
Removing intermediate container d0eef8386e97
Step 4/5 : ADD Execute-MyCmdlet.ps1 c:\example\
 ---> a955b2621c31
Removing intermediate container b825593d39fc
Step 5/5 : RUN c:\example\Execute-MyCmdlet 'hello world'
 ---> Running in be6d8e63fe75
hello world
 ---> 8e559e9bf424
Removing intermediate container be6d8e63fe75
Successfully built 8e559e9bf424
PS E:\docker\build\shell>

Инструкция SHELL также может быть использована для изменения способа работы оболочки. Например, используя команду SHELL cmd / S / C / V: ON | OFF в Windows, можно изменить семантику расширения переменной среды с задержкой.

Инструкция SHELL также может использоваться в Linux, если потребуется альтернативная оболочка, такая как zsh, csh, tcsh и другие.

Функция SHELL была добавлена ​​в Docker 1.12.

Основываясь на ответах на этой странице, я хотел бы добавить, что вы должны знать, что каждое утверждение RUN выполняется независимо от других с /bin/sh -c и, следовательно, не получит никаких переменных среды, которые обычно были бы получены в оболочках входа в систему.

Наилучший способ, который я нашел на данный момент, - добавить скрипт /etc/bash.bashrcи затем вызвать каждую команду как bash login.

RUN echo "source /usr/local/bin/virtualenvwrapper.sh" >> /etc/bash.bashrc
RUN /bin/bash --login -c "your command"

Например, вы можете установить и настроить virtualenvwrapper, создать виртуальную среду, активировать ее при использовании входа в систему bash, а затем установить модули python в эту среду:

RUN pip install virtualenv virtualenvwrapper
RUN mkdir -p /opt/virtualenvs
ENV WORKON_HOME /opt/virtualenvs
RUN echo "source /usr/local/bin/virtualenvwrapper.sh" >> /etc/bash.bashrc
RUN /bin/bash --login -c "mkvirtualenv myapp"
RUN echo "workon mpyapp" >> /etc/bash.bashrc
RUN /bin/bash --login -c "pip install ..."

Чтение руководства по загрузочным файлам bash помогает понять, когда это происходит.

Согласно https://docs.docker.com/engine/reference/builder/#run оболочка [Linux] по умолчанию для RUNis /bin/sh -c. Вы, кажется, ожидаете bashisms, поэтому вы должны использовать "exec форму", RUNчтобы указать вашу оболочку.

RUN ["/bin/bash", "-c", "source /usr/local/bin/virtualenvwrapper.sh"]

В противном случае использование «формы оболочки» RUN и указание другой оболочки приводит к появлению вложенных оболочек.

# don't do this...
RUN /bin/bash -c "source /usr/local/bin/virtualenvwrapper.sh"
# because it is the same as this...
RUN ["/bin/sh", "-c", "/bin/bash" "-c" "source /usr/local/bin/virtualenvwrapper.sh"]

Если у вас более одной команды, для которой требуется другая оболочка, вам следует прочитать https://docs.docker.com/engine/reference/builder/#shell и изменить оболочку по умолчанию, поместив ее перед командами RUN:

SHELL ["/bin/bash", "-c"]

Наконец, если вы поместили в .bashrcфайл пользователя root что-то, что вам нужно, вы можете добавить -lфлаг к команде SHELLor, RUNчтобы сделать его оболочкой входа в систему и убедиться, что он получен.

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

Согласно документации Docker

Чтобы использовать другую оболочку, отличную от '/ bin / sh', используйте форму exec, передающую нужную оболочку. Например,

RUN ["/bin/bash", "-c", "echo hello"]

См. Https://docs.docker.com/engine/reference/builder/#run.

Если у вас есть SHELLдоступ, вы должны пойти с этим ответом - не используйте принятый ответ , который заставляет вас поместить остальную часть файла docker в одну команду для каждого комментария .

Если вы используете старую версию Docker и не имеете доступа SHELL, это будет работать до тех пор, пока вам ничего не понадобится .bashrc(что является редким случаем в Dockerfiles):

ENTRYPOINT ["bash", "--rcfile", "/usr/local/bin/virtualenvwrapper.sh", "-ci"]

Обратите внимание, что -ibash необходим для чтения rcfile.

Вы могли бы хотеть бежать bash -v чтобы увидеть, что происходит.

Я бы сделал следующее вместо того, чтобы играть с символическими ссылками:

RUN echo "source /usr/local/bin/virtualenvwrapper.sh" >> /etc/bash.bashrc

У меня тоже были проблемы с бегом source в Dockerfile

Это прекрасно работает для построения контейнера CentOS 6.6 Docker, но вызывает проблемы в контейнерах Debian

RUN cd ansible && source ./hacking/env-setup

Это то, как я решил, может быть, это не элегантный способ, но это то, что сработало для меня

RUN echo "source /ansible/hacking/env-setup" >> /tmp/setup
RUN /bin/bash -C "/tmp/setup"
RUN rm -f /tmp/setup

Это может произойти, потому что sourceэто встроенный в bash, а не двоичный файл где-то в файловой системе. Вы планируете использовать сценарий для изменения контейнера позже?

Я закончил тем, что положил свои вещи в env .profileи SHELLчто-то вроде

SHELL ["/bin/bash", "-c", "-l"]

# Install ruby version specified in .ruby-version
RUN rvm install $(<.ruby-version)

# Install deps
RUN rvm use $(<.ruby-version) && gem install bundler && bundle install

CMD rvm use $(<.ruby-version) && ./myscript.rb

Если вы просто пытаетесь использовать pip для установки чего-либо в virtualenv, вы можете изменить окружение PATH, чтобы сначала просмотреть папку bin в virtualenv.

ENV PATH="/path/to/venv/bin:${PATH}"

Затем любые pip installкоманды, которые следуют в Dockerfile, сначала найдут / path / to / venv / bin / pip и будут использовать его, что установит в этот virtualenv, а не в системный питон.