Backlog Courrier

Bonjour,

Ce ticket a pour vocation d'entamer une discussion sur l'opportunité qu'il y aurait à éliminer, dans Maarch Courrier, un test au niveau du code qui se révèle particulièrement ennuyeux dans des situations de production sur une infrastructure moderne.
Ce bout de code est présent depuis les premières versions de Maarch Courrier et l'est toujours dans le code de la 20.03.7 par exemple. Il se situe au niveau du fichier class_core_tools.php, en particulier dans la fonction suivante (lignes 1656 à 1692) :

public function get_custom_id()
{
    if (!file_exists($_SESSION['config']['corepath'].'custom'.DIRECTORY_SEPARATOR.'custom.xml')) {
        return '';
    }
    $linkToApps = false;
    $arr = explode('/', $_SERVER['SCRIPT_NAME']);
    if ($key = array_search('rest', $arr)) {
        unset($arr[$key]);
    }
    $arr = array_values($arr);
    for ($cptArr = 0; $cptArr < count($arr); ++$cptArr) {
        if ($arr[$cptArr] == 'apps') {
            $linkToApps = true;
        }
    }
    if ($linkToApps) {
        $path = $arr[count($arr) - 4];
    } else {
        $path = $arr[count($arr) - 2];
    }

    $xml = simplexml_load_file($_SESSION['config']['corepath'].'custom'.DIRECTORY_SEPARATOR.'custom.xml');
    foreach ($xml->custom as $custom) {
        if (trim($path) != '' && isset($custom->path) && $custom->path == trim($path)) {
            return (string) $custom->custom_id;
        }
        if ($custom->ip == $_SERVER['SERVER_ADDR']) {
            return (string) $custom->custom_id;
        }
        if ($custom->external_domain == $_SERVER['HTTP_HOST'] xor $custom->domain == $_SERVER['HTTP_HOST']) {
            return (string) $custom->custom_id;
        }
    }

    return '';
}

En effet, afin de charger le custom à prendre en compte (le cas échéant) il teste la correspondance entre l'ip (à renseigner manuellement) dans le fichier custom.xml et l'ip du serveur renvoyée par la variable de serveur $_SERVER dans $_SERVER['SERVER_ADDR']

Je n'ai jamais vraiment compris l'intérêt de ce test, peut-être a-t-il eu une utilité dans la prise en compte de customs multiples sur une même instance comme semble le suggérer la boucle for dans lequel le test s'inscrit ?
En tous cas je ne suis pas bien sûr qu'il y ait un cas pratique et courant qui justifient les ennuis que causent ce test.

Les ennuis en question ne devaient pas se manifester il y a quelques années avec les premières versions de Maarch Courrier étant donné que la norme d'alors était plutôt un serveur applicatif bare metal et dédié ayant vocation à tourner plusieurs années, les mises à jour étant effectuées itérativement.
L'ip du serveur Apache ne devait donc théoriquement pas changer et était à renseigner une fois à l'installation dans le fichier custom.xml.

Il est difficile d'ignorer qu'aujourd'hui le contexte d'exploitation a changé : les infrastructures sont de plus en plus virtualisées et particulier l'état de l'art tend à faire de la containérisation et de l'organisation en micro-services le mode d'exploitation principal.
Le MTES, pour de multiples raisons, a fait le choix d'une infrastructure containérisée pour l'exploitation de Maarch Courrier. Dans ce contexte les containers des diverses instances de l'application peuvent être amenés à être redemarrés, migrés de machine physiques par un load balancer, etc.
Ces opérations réalisées soit automatiquement selon les règles d'orchestration de l'infrastructure containérisée, soit volontairement (mise en place d'un environnement type dév pour des tests de paramétrage technique, instance de recette à très courte durée de vie, etc) ont vocation a être transparentes pour les utilisateurs mais le fait que chaque nouveau container se voit attribué une ip différente au sein réseau virtuel de l'orchestrateur de containerisation pose problème vis-à-vis du code mentionné ci-dessus.

Nous nous retrouvons donc avec des interruptions de service sur des environnements de production, aléa sévère, ou avec des opérations manuelles de mise à jour des fichiers custom.xml sans plus-value évidente sur les autres environnements.
Il n'est pas évident de "tourner autour" du problème : une approche via un script lancé automatiquement à l'exécution du container applicatif qui essaye de récupérer l'ip du serveur a été tentée mais il ne fonctionne pas systématiquement (pas forcément la même interface réseau montée à chaque fois selon le réseau hôte). De même il est possible de rendre le fichier custom.xml un peu moins pénible à éditer dans un contexte containérisé en montant le fichier sur le système hôte afin d'y accéder facilement mais ça nécessite toujours une intervention manuelle et s'oppose aux bonnes pratiques en matière de containérisation.

En bref nous en sommes venus à considérer cet irritant comme une vraie anomalie, surtout au regard du peu d'utilité apparente de ce test et des impacts très négatif que cela a en production.
Il sera possible d'opposer que Maarch n'offre aucune compatibilité particulière a priori pour les infrastructures containérisées mais il serait opportun de prendre ce problème en compte pour l'avenir du produit afin que ce dernier ne se retrouve pas à contre-courant de ce qui est une tendance générale de l'état de l'art.
Par ailleurs ce problème se pose pour tout type d'infrastructure à courte durée de vie, pas uniquement pour la containérisation : c'est le cas par exemple pour des instances de tests déployées par Ansible sur des VPS "jetables".

En vous remerciant d'avance pour votre retour sur ce sujet.