ARG ou ENV, lequel utiliser dans ce cas?

Cela pourrait être peut-être une question triviale, mais la lecture de documents pour ARG et ENV ne me clarifie pas les choses.

Je construis un conteneur PHP-FPM et je souhaite donner la possibilité d'activer / désactiver certaines extensions en fonction des besoins des utilisateurs.

Ce serait formidable si cela pouvait être fait dans le Dockerfile en ajoutant des conditions et en passant des indicateurs sur la commande de construction peut-être, mais AFAIK n'est pas pris en charge.

Dans mon cas et mon approche personnelle est d'exécuter un petit script au démarrage du conteneur, quelque chose comme ce qui suit:

#!/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 "$@"

Voici à quoi Dockerfileressemble mon :

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

Voici le référentiel complet si vous avez besoin de regarder en profondeur pour comprendre comment je fais les choses

Actuellement, cela fonctionne mais ... Si je veux ajouter, disons, 20 (un nombre aléatoire) d'extensions ou toute autre fonctionnalité qui peut être activée | désactiver, je ENVfinirai par 20 non nécessaires (car Dockerfile ne prend pas en charge .env files) définition dont le seul but serait de définir cet indicateur pour que le script sache quoi faire alors ...

• Est-ce que c'est la bonne façon de le faire?
• Dois-je utiliser ENVà cette fin?

Je suis ouvert aux idées si vous avez une approche différente pour y parvenir s'il vous plaît laissez-moi savoir

À partir de la référence Dockerfile :

• L' ARGinstruction définit une variable que les utilisateurs peuvent transmettre au générateur au moment de la construction avec la commande docker build à l'aide de l' --build-arg <varname>=<value>indicateur.

• L' ENVinstruction définit la variable d'environnement <key>sur la valeur <value>.
  Les variables d'environnement définies à l'aide de ENVpersisteront lorsqu'un conteneur est exécuté à partir de l'image résultante.

Donc, si vous avez besoin d'une personnalisation au moment de la construction , ARGc'est votre meilleur choix.
Si vous avez besoin d'une personnalisation au moment de l'exécution (pour exécuter la même image avec des paramètres différents), ENVc'est bien adapté.

Si je veux ajouter, disons 20 (un nombre aléatoire) d'extensions ou toute autre fonctionnalité qui peut être activée | désactivée

Compte tenu du nombre de combinaisons impliquées, il ENVest préférable d' utiliser pour définir ces fonctionnalités au moment de l'exécution.

Mais vous pouvez combiner les deux en:

• construire une image avec un ARG
• en utilisant cela ARGcomme unENV

Autrement dit, avec un Dockerfile comprenant:

ARG var
ENV var=${var}

Vous pouvez ensuite soit créer une image avec une varvaleur spécifique au moment de la construction ( docker build --build-arg var=xxx), soit exécuter un conteneur avec une valeur d'exécution spécifique ( docker run -e var=yyy)

Donc, si vous souhaitez définir la valeur d'une variable d'environnement sur quelque chose de différent pour chaque construction, nous pouvons transmettre ces valeurs pendant la construction et nous n'avons pas besoin de changer notre fichier docker à chaque fois.

Alors ENVqu'une fois défini, il ne peut pas être écrasé par les valeurs de ligne de commande. Donc, si nous voulons que notre variable d'environnement ait des valeurs différentes pour différentes versions, nous pourrions utiliser ARGet définir des valeurs par défaut dans notre fichier docker. Et lorsque nous voulons écraser ces valeurs, nous pouvons le faire --build-argsà chaque build sans changer notre fichier docker.

Pour plus de détails, vous pouvez vous référer à ceci .