Passer des arguments et variables d'environnement aux conteneurs

Configuration directe : les bases pour influencer vos conteneurs

Avant même d'aborder les objets dédiés comme les ConfigMaps et les Secrets, Kubernetes offre des moyens directs pour influencer le comportement des conteneurs au moment de leur lancement, directement depuis la définition du Pod (ou du template de Pod dans un Deployment, StatefulSet, etc.). Ces méthodes sont fondamentales pour contrôler comment le processus principal de votre conteneur démarre et pour lui fournir des paramètres simples.

Nous allons explorer ici deux mécanismes intégrés à la spécification du conteneur (`spec.containers[]`) :

1. La définition des arguments de ligne de commande que le conteneur doit exécuter, via les champs `command` et `args`.
2. La définition des variables d'environnement qui seront disponibles pour le processus à l'intérieur du conteneur, via le champ `env`.

Ces méthodes sont idéales pour les paramètres d'exécution simples, les flags de configuration non sensibles, ou pour remplacer le comportement par défaut de l'image du conteneur.

Contrôler l'exécution : `command` et `args`

Chaque image de conteneur Docker (ou OCI) définit généralement un `ENTRYPOINT` (le programme à exécuter par défaut) et/ou un `CMD` (les arguments par défaut passés à l'entrypoint). Kubernetes vous permet de remplacer ces valeurs par défaut via les champs `command` et `args` dans la définition du conteneur.

• `command` : Ce champ remplace l'`ENTRYPOINT` défini dans l'image du conteneur. Si vous définissez `command`, l'`ENTRYPOINT` de l'image est ignoré. La valeur de `command` doit être un tableau de chaînes de caractères, où chaque élément représente une partie de la commande (ex: `["/bin/sh", "-c", "mon_script.sh"]`).
• `args` : Ce champ remplace le `CMD` défini dans l'image du conteneur. Si vous définissez `args` mais *pas* `command`, alors les `args` sont passés comme arguments à l'`ENTRYPOINT` par défaut de l'image. Si vous définissez *à la fois* `command` et `args`, alors les `args` sont passés comme arguments à votre `command` spécifiée (et l'`ENTRYPOINT` et le `CMD` de l'image sont tous deux ignorés). La valeur de `args` est également un tableau de chaînes.

Scénarios courants :

• Passer des arguments à l'entrypoint par défaut : Ne définissez que `args`.

  # Supposons que l'image a ENTRYPOINT ["python", "app.py"]
  spec:
    containers:
    - name: mon-app
      image: mon-image-app
      args: ["--mode=production", "--port=8080"] # Remplace le CMD de l'image

  Le conteneur exécutera `python app.py --mode=production --port=8080`.
• Remplacer l'entrypoint et passer des arguments : Définissez `command` et `args`.

  spec:
    containers:
    - name: busybox-shell
      image: busybox
      command: ["/bin/sleep"]
      args: ["3600"] # Exécute sleep 3600

• Remplacer uniquement l'entrypoint (sans arguments spécifiques) : Définissez `command` mais pas `args`.

  spec:
    containers:
    - name: run-script
      image: mon-image-avec-outils
      command: ["/opt/mon_script_init.sh"] # Ignore l'ENTRYPOINT/CMD de l'image

L'utilisation de `command` et `args` est très utile pour configurer finement le processus qui s'exécute dans votre conteneur, passer des flags ou des paramètres d'exécution spécifiques.

Injecter des variables d'environnement avec `env`

Une autre méthode très courante pour passer des informations de configuration est d'utiliser les variables d'environnement. Kubernetes vous permet de définir ces variables directement dans la spécification du conteneur via le champ `env`.

Le champ `env` est une liste d'objets, où chaque objet définit une variable d'environnement avec au minimum un `name` et une source pour sa `value`.

Définition directe de la valeur : La méthode la plus simple consiste à fournir la valeur directement dans le manifeste.

spec:
  containers:
  - name: mon-app-conteneur
    image: mon-image-app
    env:
    - name: LOG_LEVEL # Nom de la variable d'environnement
      value: "info"    # Valeur directe
    - name: API_TIMEOUT
      value: "30"
    - name: FEATURE_FLAG_X
      value: "true"

A l'intérieur du conteneur `mon-app-conteneur`, le processus pourra accéder à ces variables comme n'importe quelle variable d'environnement standard (par exemple, `getenv("LOG_LEVEL")` en C, `os.environ.get('LOG_LEVEL')` en Python, `$LOG_LEVEL` dans un script shell).

Cette méthode est pratique pour des valeurs simples et non sensibles. Nous verrons dans les sections suivantes comment utiliser `env` pour injecter des valeurs provenant de sources externes comme les ConfigMaps (`valueFrom: configMapKeyRef`) et les Secrets (`valueFrom: secretKeyRef`), ce qui est beaucoup plus flexible et sécurisé.

Quand utiliser ces méthodes directes (et leurs limites)

Passer des arguments via `command`/`args` ou des variables d'environnement via `env` avec des valeurs directes est utile pour :

• Définir le point d'entrée ou les arguments d'exécution du conteneur.
• Passer des paramètres simples et statiques qui ne changent pas souvent.
• Fournir des configurations non sensibles qui peuvent être versionnées avec le manifeste du Pod/Deployment.

Cependant, ces méthodes présentent des limitations importantes :

• Manque de flexibilité : Toute modification de la configuration nécessite de modifier le fichier YAML du Pod/Deployment et de déclencher un redéploiement (rollout).
• Couplage : La configuration est directement liée à la définition du Pod.
• Gestion difficile pour de grandes configurations : Le manifeste peut devenir très volumineux et difficile à lire si de nombreuses variables ou arguments sont définis.
• Insécurité pour les données sensibles : Les valeurs sont stockées en clair dans le manifeste YAML, ce qui est inacceptable pour les mots de passe, tokens ou clés API.

Ces limitations nous amènent naturellement au besoin de solutions plus robustes pour externaliser la configuration : les ConfigMaps pour les données non sensibles et les Secrets pour les données sensibles, que nous allons explorer maintenant.