Tengo un Dockerfile que estoy armando para instalar un entorno de python vainilla (en el que instalaré una aplicación, pero en una fecha posterior).

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

La compilación funciona bien hasta la última línea, donde obtengo la siguiente excepción:

[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

Si entro lsen ese directorio (solo para probar que se confirmaron los pasos anteriores) puedo ver que los archivos existen como se esperaba:

$ 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

Si intento simplemente ejecutar el sourcecomando, obtengo el mismo error 'no encontrado' que el anterior. Sin embargo, si EJECUTO una sesión de shell interactiva, la fuente funciona:

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

Puedo ejecutar el script desde aquí, y luego acceder felizmente workon, mkvirtualenvetc.

He cavado un poco, e inicialmente parecía que el problema podría estar en la diferencia entre bash como el shell de inicio de sesión de Ubuntu y dash como el shell del sistema de Ubuntu , el dash no admite el sourcecomando.

Sin embargo, la respuesta a esto parece ser usar '.' en lugar de source, pero esto solo hace que el tiempo de ejecución de Docker explote con una excepción de pánico.

¿Cuál es la mejor manera de ejecutar un script de shell desde una instrucción Dockerfile RUN para evitar esto (estoy ejecutando la imagen base predeterminada para Ubuntu 12.04 LTS)?

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

Respuesta original

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

Esto debería funcionar para cada imagen base de Docker de Ubuntu. Generalmente agrego esta línea para cada Dockerfile que escribo.

Editar por un espectador preocupado

Si desea obtener el efecto de "usar en bashlugar de en shtodo este Dockerfile", sin alterar y posiblemente dañar * el sistema operativo dentro del contenedor, puede decirle a Docker su intención . Eso se hace así:

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

* El posible daño es que muchos scripts en Linux (en una nueva instalación de Ubuntu grep -rHInE '/bin/sh' /devuelve más de 2700 resultados) esperan un shell POSIX completo en /bin/sh. El bash shell no es solo POSIX más componentes adicionales. Hay incorporados (y más) que se comportan completamente diferentes a los de POSIX. APOYO TOTALMENTE evitar POSIX (y la falacia de que cualquier script que no haya probado en otro shell funcionará porque cree que evitó los basmismos) y simplemente usar el bashismo. Pero lo haces con un shebang adecuado en tu guión. No extrayendo el shell POSIX de todo el sistema operativo. (A menos que tenga tiempo para verificar todos los scripts 2700 plus que vienen con Linux más todos los paquetes que instale).

Más detalles en esta respuesta a continuación. https://stackoverflow.com/a/45087082/117471

El shell predeterminado para la RUNinstrucción es ["/bin/sh", "-c"].

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

Con la instrucción SHELL , puede cambiar el shell predeterminado para las RUNinstrucciones posteriores en Dockerfile:

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

Ahora, el shell predeterminado ha cambiado y no necesita definirlo explícitamente en cada instrucción RUN

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

Nota adicional : También puede agregar la --loginopción que iniciaría un shell de inicio de sesión. Esto significa que, ~/.bachrcpor ejemplo, se leería y no necesita obtenerlo explícitamente antes de su comando

Tuve el mismo problema y para ejecutar pip install dentro de virtualenv tuve 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 ayude.

La manera más simple es usar el operador de punto en lugar de la fuente, que es el equivalente sh del sourcecomando bash :

En vez de:

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

Utilizar:

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

Si está utilizando Docker 1.12 o más reciente, ¡simplemente utilícelo SHELL!

Respuesta corta:

general:

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

para python vituralenv:

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

Respuesta larga:

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

SHELL ["executable", "parameters"]

La instrucción SHELL permite anular el shell predeterminado utilizado para la forma de shell de los comandos. El shell predeterminado en Linux es ["/ bin / sh", "-c"], y en Windows es ["cmd", "/ S", "/ C"]. La instrucción SHELL debe escribirse en forma JSON en un Dockerfile.

La instrucción SHELL es particularmente útil en Windows donde hay dos shells nativos de uso común y bastante diferentes: cmd y powershell, así como shells alternativos disponibles, incluido sh.

La instrucción SHELL puede aparecer varias veces. Cada instrucción SHELL anula todas las instrucciones SHELL anteriores y afecta a todas las instrucciones posteriores. Por ejemplo:

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

Las siguientes instrucciones pueden verse afectadas por la instrucción SHELL cuando su forma de shell se utiliza en un Dockerfile: RUN, CMD y ENTRYPOINT.

El siguiente ejemplo es un patrón común que se encuentra en Windows que se puede simplificar mediante el uso de la instrucción SHELL:

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

El comando invocado por docker será:

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

Esto es ineficiente por dos razones. Primero, se invoca un procesador de comandos cmd.exe innecesario (también conocido como shell). En segundo lugar, cada instrucción RUN en la forma de shell requiere un comando extra de PowerShell que prefija el comando.

Para hacer esto más eficiente, se puede emplear uno de dos mecanismos. Una es usar la forma JSON del comando EJECUTAR como:

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

Si bien el formulario JSON es inequívoco y no utiliza el cmd.exe innecesario, sí requiere más verbosidad mediante comillas dobles y escape. El mecanismo alternativo es utilizar la instrucción SHELL y la forma de shell, creando una sintaxis más natural para los usuarios de Windows, especialmente cuando se combina con la directiva del analizador de 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'

Resultando en:

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>

La instrucción SHELL también podría usarse para modificar la forma en que opera un shell. Por ejemplo, usando SHELL cmd / S / C / V: ON | OFF en Windows, la semántica de expansión variable de entorno retrasada podría modificarse.

La instrucción SHELL también se puede usar en Linux si se requiere un shell alternativo como zsh, csh, tcsh y otros.

La función SHELL se agregó en Docker 1.12.

Sobre la base de las respuestas en esta página, agregaría que debe tener en cuenta que cada instrucción RUN se ejecuta independientemente de las demás /bin/sh -cy, por lo tanto, no obtendrá ningún valor de entorno que normalmente se obtenga en shells de inicio de sesión.

La mejor manera que he encontrado hasta ahora es agregar el script /etc/bash.bashrcy luego invocar cada comando como inicio de sesión bash.

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

Por ejemplo, puede instalar y configurar virtualenvwrapper, crear el entorno virtual, activarlo cuando use un inicio de sesión bash y luego instalar sus módulos de Python en este entorno:

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

Leer el manual sobre los archivos de inicio de bash ayuda a comprender de qué se origina cuándo.

De acuerdo con https://docs.docker.com/engine/reference/builder/#run, el shell predeterminado [Linux] RUNes /bin/sh -c. Parece que espera bashismos, por lo que debe utilizar la "forma ejecutiva" de RUNpara especificar su shell.

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

De lo contrario, usar la "forma de shell" de RUN y especificar un shell diferente da como resultado shells anidados.

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

Si tiene más de 1 comando que necesita un shell diferente, debe leer https://docs.docker.com/engine/reference/builder/#shell y cambiar su shell predeterminado colocando esto antes de sus comandos RUN:

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

Finalmente, si ha colocado algo en el .bashrcarchivo del usuario raíz que necesita, puede agregar el -lindicador al comando SHELLo RUNpara convertirlo en un shell de inicio de sesión y asegurarse de que se obtenga.

Nota: He ignorado intencionalmente el hecho de que no tiene sentido obtener un script como único comando en un EJECUTAR.

De acuerdo con la documentación de Docker

Para usar un shell diferente, que no sea '/ bin / sh', use la forma ejecutiva que pasa en el shell deseado. Por ejemplo,

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

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

Si tiene SHELLdisponible, debe ir con esta respuesta : no use la aceptada, lo que lo obliga a colocar el resto del dockerfile en un comando por este comentario .

Si está utilizando una versión antigua de Docker y no tiene acceso a ella SHELL, esto funcionará siempre que no necesite nada .bashrc(que es un caso raro en Dockerfiles):

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

Tenga en cuenta que -ise necesita para que bash lea el archivo rc en absoluto.

Es posible que desee correr bash -vpara ver qué se obtiene.

Haría lo siguiente en lugar de jugar con enlaces simbólicos:

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

También tuve problemas para ejecutar sourceen un Dockerfile

Esto funciona perfectamente bien para construir el contenedor CentOS 6.6 Docker, pero dio problemas en los contenedores Debian

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

Así es como lo aborde, puede que no sea una forma elegante, pero esto es lo que funcionó para mí

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

Esto podría estar sucediendo porque sourceestá integrado en bash en lugar de un binario en algún lugar del sistema de archivos. ¿Su intención para el script que está buscando para alterar el contenedor después?

Terminé poniendo mis cosas env .profiley 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

Si solo está tratando de usar pip para instalar algo en virtualenv, puede modificar el PATH env para buscar primero en la carpeta bin de virtualenv

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

Luego, cualquier pip installcomando que siga en el Dockerfile encontrará primero / path / to / venv / bin / pip y lo usará, lo que se instalará en ese virtualenv y no en el sistema python.