Eu tenho um Dockerfile que estou montando para instalar um ambiente vanilla python (no qual instalarei um aplicativo, mas posteriormente).

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

A compilação funciona bem até a última linha, onde recebo a seguinte exceção:

[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

Se eu lsentrar nesse diretório (apenas para testar se as etapas anteriores foram confirmadas), posso ver que os arquivos existem conforme o esperado:

$ 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

Se eu tentar apenas executar o sourcecomando, recebo o mesmo erro 'não encontrado' como acima. Se eu executar uma sessão de shell interativa, no entanto, a fonte funcionará:

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

Eu posso executar o script a partir daqui e acessar com prazer workon, mkvirtualenvetc.

Eu fiz algumas pesquisas e, inicialmente, parecia que o problema poderia estar na diferença entre o bash como o shell de login do Ubuntu e o dash como o shell do sistema Ubuntu , o dash não suportando o sourcecomando.

No entanto, a resposta para isso parece ser usar '.' em vez de source, mas isso apenas faz com que o tempo de execução do Docker exploda com uma exceção de pânico.

Qual é a melhor maneira de executar um shell script a partir de uma instrução RUN do Dockerfile para contornar isso (estou executando a imagem base padrão do Ubuntu 12.04 LTS).

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

Resposta original

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

Isso deve funcionar para todas as imagens base do docker do Ubuntu. Geralmente, adiciono essa linha a todos os Dockerfiles que escrevo.

Editar por um espectador preocupado

Se você deseja obter o efeito de "usar em bashvez de shtodo esse arquivo Dockerfile", sem alterar e possivelmente danificar * o sistema operacional dentro do contêiner, basta dizer à Docker sua intenção . Isso é feito assim:

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

* O possível dano é que muitos scripts no Linux (em uma nova instalação do Ubuntu grep -rHInE '/bin/sh' /retornam mais de 2700 resultados) esperam um shell totalmente POSIX em /bin/sh. O shell bash não é apenas o POSIX mais os recursos extras. Existem componentes internos (e mais) que se comportam totalmente diferentes dos do POSIX. Eu apoio totalmente a evitar o POSIX (e a falácia de que qualquer script que você não testou em outro shell funcionará porque você acha que evitou basmismos) e apenas usando o bashism. Mas você faz isso com um shebang adequado em seu script. Não puxando o shell POSIX para fora de todo o sistema operacional. (A menos que você tenha tempo para verificar todos os scripts 2700 plus que acompanham o Linux e todos os pacotes instalados).

Mais detalhes nesta resposta abaixo. https://stackoverflow.com/a/45087082/117471

O shell padrão para a RUNinstrução é ["/bin/sh", "-c"].

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

Usando a instrução SHELL , você pode alterar o shell padrão para RUNinstruções subsequentes no Dockerfile:

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

Agora, o shell padrão mudou e você não precisa defini-lo explicitamente em todas as instruções RUN

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

Nota adicional : Você também pode adicionar a --loginopção que iniciaria um shell de login. Isso significa que, ~/.bachrcpor exemplo, seria lido e você não precisa fornecê-lo explicitamente antes do seu comando

Eu tive o mesmo problema e, para executar a instalação do pip dentro do virtualenv, tive que usar este comando:

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"

Espero que ajude.

A maneira mais simples é usar o operador de ponto no lugar da fonte, que é o equivalente sh do sourcecomando bash :

Ao invés de:

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

Usar:

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

Se você estiver usando o Docker 1.12 ou mais recente, basta usar SHELL!

Resposta curta:

geral:

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

para python vituralenv:

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

Resposta longa:

de https://docs.docker.com/engine/reference/builder/#/shell

SHELL ["executable", "parameters"]

A instrução SHELL permite que o shell padrão usado para a forma de comandos do shell seja substituída. O shell padrão no Linux é ["/ bin / sh", "-c"] e no Windows é ["cmd", "/ S", "/ C"]. A instrução SHELL deve ser escrita no formato JSON em um Dockerfile.

A instrução SHELL é particularmente útil no Windows, onde existem dois shells nativos comumente usados ​​e bastante diferentes: cmd e powershell, além de shells alternativos disponíveis, incluindo sh.

A instrução SHELL pode aparecer várias vezes. Cada instrução SHELL substitui todas as instruções SHELL anteriores e afeta todas as instruções subseqüentes. Por exemplo:

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

As instruções a seguir podem ser afetadas pela instrução SHELL quando a forma do shell delas é usada em um Dockerfile: RUN, CMD e ENTRYPOINT.

O exemplo a seguir é um padrão comum encontrado no Windows que pode ser simplificado usando a instrução SHELL:

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

O comando chamado pelo docker será:

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

Isso é ineficiente por duas razões. Primeiro, há um processador de comando cmd.exe desnecessário (também conhecido como shell) sendo invocado. Segundo, cada instrução RUN na forma de shell requer um comando extra do powershell que prefixa o comando.

Para tornar isso mais eficiente, um dos dois mecanismos pode ser empregado. Uma é usar o formulário JSON do comando RUN, como:

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

Embora o formulário JSON seja inequívoco e não use o cmd.exe desnecessário, ele exige mais detalhamento por meio de aspas duplas e escape. O mecanismo alternativo é usar a instrução SHELL e a forma do shell, criando uma sintaxe mais natural para usuários do Windows, especialmente quando combinada com a diretiva de escape parser:

# 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'

Resultando em:

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>

A instrução SHELL também pode ser usada para modificar a maneira como um shell opera. Por exemplo, usando SHELL cmd / S / C / V: ON | OFF no Windows, a semântica de expansão da variável de ambiente atrasada pode ser modificada.

A instrução SHELL também pode ser usada no Linux, caso seja necessário um shell alternativo, como zsh, csh, tcsh e outros.

O recurso SHELL foi adicionado no Docker 1.12.

Com base nas respostas desta página, eu acrescentaria que você deve estar ciente de que cada instrução RUN é executada independentemente das outras /bin/sh -ce, portanto, não obterá nenhum ambiente de variáveis ​​que normalmente seriam originadas em shells de login.

A melhor maneira que encontrei até agora é adicionar o script /etc/bash.bashrce, em seguida, chamar cada comando como login do bash.

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

Você pode, por exemplo, instalar e configurar o virtualenvwrapper, criar o ambiente virtual, ativá-lo quando você usa um login bash e, em seguida, instalar seus módulos python nesse ambiente:

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 ..."

A leitura do manual nos arquivos de inicialização do bash ajuda a entender o que é originado quando.

De acordo com https://docs.docker.com/engine/reference/builder/#run, o shell [Linux] padrão para RUNé /bin/sh -c. Você parece estar esperando basismos, então você deve usar o "exec form" de RUNpara especificar seu shell.

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

Caso contrário, usar o "formulário de shell" do RUN e especificar um shell diferente resulta em shells aninhados.

# 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"]

Se você possui mais de um comando que precisa de um shell diferente, leia https://docs.docker.com/engine/reference/builder/#shell e altere o shell padrão colocando-o antes dos comandos RUN:

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

Por fim, se você colocou algo no .bashrcarquivo do usuário raiz que precisa, pode adicionar o -lsinalizador ao comando SHELLou RUNpara torná-lo um shell de logon e garantir que ele seja originado.

Nota: Ignorei intencionalmente o fato de que não faz sentido originar um script como o único comando em um RUN.

De acordo com a documentação do Docker

Para usar um shell diferente, diferente de '/ bin / sh', use o formulário exec que passa no shell desejado. Por exemplo,

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

Consulte https://docs.docker.com/engine/reference/builder/#run

Se você tiver SHELLdisponível, siga esta resposta - não use a aceita, o que força você a colocar o restante do arquivo docker em um comando por esse comentário .

Se você estiver usando uma versão antiga do Docker e não tiver acesso SHELL, isso funcionará desde que você não precise de nada .bashrc(o que é um caso raro no Dockerfiles):

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

Observe que -ié necessário fazer com que o bash leia o rcfile.

Você pode querer correr bash -v para ver o que está sendo adquirido.

Eu faria o seguinte em vez de jogar com links simbólicos:

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

Eu também tive problemas na execução source em um Dockerfile

Isso funciona perfeitamente para criar contêineres CentOS 6.6 Docker, mas deu problemas em contêineres Debian

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

É assim que eu lidei com isso, pode não ser uma maneira elegante, mas é isso que funcionou para mim

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

Isso pode estar acontecendo porque sourceé um built-in para bash em vez de um binário em algum lugar do sistema de arquivos. Sua intenção para o script que você está contratando é alterar o contêiner posteriormente?

Acabei colocando minhas coisas env .profilee mutado SHELLalgo como

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

Se você está apenas tentando usar o pip para instalar algo no virtualenv, pode modificar o env PATH para procurar primeiro na pasta bin do virtualenv

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

Em seguida, quaisquer pip installcomandos que seguem na Dockerfile vai encontrar / path / to / venv / bin / pip primeiro e usar isso, que irá instalar em que virtualenv e não o sistema de python.