hub - que es docker file

ARG o ENV, ¿cuál usar en este caso?

Question

Esta podría ser una pregunta trivial, pero leer documentos para ARG y ENV no me deja las cosas claras.

Estoy construyendo un contenedor PHP-FPM y quiero dar la posibilidad de habilitar / deshabilitar algunas extensiones según las necesidades del usuario.

Sería genial si esto se pudiera hacer en el Dockerfile agregando condicionales y pasando banderas en el comando de compilación tal vez, pero AFAIK no es compatible.

En mi caso y mi enfoque personal es ejecutar un pequeño script cuando se inicia el contenedor, algo como lo siguiente:

#!/bin/sh   
set -e

RESTART="false"

# This script will be placed in /config/init/ and run when container starts.
if  [ "$INSTALL_XDEBUG" == "true" ]; then
    printf "/nInstalling Xdebug .../n"
    yum install -y  php71-php-pecl-xdebug
    RESTART="true"
fi
...   
if  [ "$RESTART" == "true" ]; then
    printf "/nRestarting php-fpm .../n"
    supervisorctl restart php-fpm
fi

exec "$@"

Así es como se ve mi Dockerfile :

FROM reynierpm/centos7-supervisor
ENV TERM=xterm /
    PATH="/root/.composer/vendor/bin:${PATH}" /
    INSTALL_COMPOSER="false" /
    COMPOSER_ALLOW_SUPERUSER=1 /
    COMPOSER_ALLOW_XDEBUG=1 /
    COMPOSER_DISABLE_XDEBUG_WARN=1 /
    COMPOSER_HOME="/root/.composer" /
    COMPOSER_CACHE_DIR="/root/.composer/cache" /
    SYMFONY_INSTALLER="false" /
    SYMFONY_PROJECT="false" /
    INSTALL_XDEBUG="false" /
    INSTALL_MONGO="false" /
    INSTALL_REDIS="false" /
    INSTALL_HTTP_REQUEST="false" /
    INSTALL_UPLOAD_PROGRESS="false" /
    INSTALL_XATTR="false"

RUN yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm /
                   https://rpms.remirepo.net/enterprise/remi-release-7.rpm
RUN yum install -y  /
        yum-utils /
        git /
        zip /
        unzip /
        nano /
        wget /
        php71-php-fpm /
        php71-php-cli /
        php71-php-common /
        php71-php-gd /
        php71-php-intl /
        php71-php-json /
        php71-php-mbstring /
        php71-php-mcrypt /
        php71-php-mysqlnd /
        php71-php-pdo /
        php71-php-pear /
        php71-php-xml /
        php71-pecl-apcu /
        php71-php-pecl-apfd /
        php71-php-pecl-memcache /
        php71-php-pecl-memcached /
        php71-php-pecl-zip && /
        yum clean all && rm -rf /tmp/yum*

RUN ln -sfF /opt/remi/php71/enable /etc/profile.d/php71-paths.sh && /
    ln -sfF /opt/remi/php71/root/usr/bin/{pear,pecl,phar,php,php-cgi,phpize} /usr/local/bin/. && /
    mv -f /etc/opt/remi/php71/php.ini /etc/php.ini && /
    ln -s /etc/php.ini /etc/opt/remi/php71/php.ini && /
    rm -rf /etc/php.d && /
    mv /etc/opt/remi/php71/php.d /etc/. && /
    ln -s /etc/php.d /etc/opt/remi/php71/php.d

COPY container-files /
RUN chmod +x /config/bootstrap.sh
WORKDIR /data/www
EXPOSE 9001

Here está todo el repositorio si necesita echar un vistazo profundo para comprender cómo estoy haciendo las cosas

Actualmente esto está funcionando pero ... Si quiero agregar digamos 20 (un número aleatorio) de extensiones o cualquier otra característica que se pueda habilitar | deshabilitar, terminaré con 20 ENV no necesarios (porque Dockerfile no es compatible. definición de archivos env) cuyo único propósito sería establecer este indicador para que el script sepa qué hacer entonces ...

• ¿Esta es la manera correcta de hacerlo?
• ¿Debo usar ENV para este propósito?

Estoy abierto a ideas si tiene un enfoque diferente para lograr esto, hágamelo saber

Answer 1

De la referencia de Dockerfile :

• La instrucción ARG define una variable que los usuarios pueden pasar en el momento de la compilación al constructor con el comando de compilación de la --build-arg <varname>=<value> acoplable utilizando el --build-arg <varname>=<value>

• La instrucción ENV establece la variable de entorno <key> en el valor <value> .
  Las variables de entorno establecidas mediante ENV persistirán cuando se ejecute un contenedor desde la imagen resultante.

Entonces, si necesita personalización en tiempo de construcción , ARG es su mejor opción.
Si necesita personalización en tiempo de ejecución (para ejecutar la misma imagen con diferentes configuraciones), ENV es muy adecuado.

Si quiero agregar digamos 20 (un número aleatorio) de extensiones o cualquier otra característica que se pueda habilitar | deshabilitar

Dado el número de combinaciones involucradas, usar ENV para establecer esas características en tiempo de ejecución es mejor aquí.

Pero puedes combinar ambos por:

• construir una imagen con un ARG específico
• usando ese ARG como un ENV

Es decir, con un Dockerfile que incluye:

ARG var
ENV var=${var}

Luego, puede crear una imagen con un valor var específico en el momento de la compilación ( docker build --build-arg var=xxx ), o ejecutar un contenedor con un valor de tiempo de ejecución específico ( docker run -e var=yyy )