Bonjour, Pierre Malard a écrit : > Il y a aussi un point négatif sur les déploiements intégrés : > * Le fait qu’on ne peut suivre raisonnablement les N sources > d’émission (FlatPack, Snap, AppImage, Docker, …) en fonction des > outils utilisés sur chaque serveur. Cela alourdi conséquemment le > suivit des serveurs sans en garantir l’intégrité.
Je comprends donc qu'il s'agit d'un point négatif pour les déploiements autoportants, et non intégrés. > Quant à l’argument de bibliothèques « ante-dilluviennes » présentes > sur les distributions LTS, vous me permettrez de douter de celui-ci. Si cela ne vaut bien entendu pas vérité universelle et intemporelle, je vais me permettre de m'en référer à mon expérience personnelle. Je travaille dans le spatial, monde où deux logiques cohabitent : * Sur les centres de contrôle, centres de missions et autres systèmes opérationnels critiques, nous avons besoin de système stables, qualifiés et maintenus sur le très long terme (plusieurs années peuvent s'écouler entre le lancement d'une sonde et son activation en vue de remplir la mission qui lui a été assignée). Les agences spatiales optent donc pour des distributions adossées à des acteurs commerciaux qui s'engagent contractuellement à ce support à très long terme. Pendant longtemps, Sun a régné en maitre, avec son système Solaris. Depuis dix ans, il a peu ou prou disparu au profit de systèmes RHEL ou Suse. * Sur les missions scientifiques, mais aussi sur les plateformes opérationnelles de traitement et de distribution de données, nous utilisons souvent des technologies, algorithmes, formats et protocoles représentant l'état de l'art dans leur domaine. Certains d'entre eux sont même développés pour les besoins de ces missions et sont implantés dans des outils libres pour en favoriser l'adoption et la dissémination. Les versions des bibliothèques fournies par une RHEL ou même une Debian stable sont, à cette aune, antédiluviennes. Ce faisant, le système de prédilection dans ce domaine est Ubuntu, non à cause du système en lui-même et des bibliothèques fournies dans les dépôts officiels de la distribution (les mêmes que dans Debian), mais à cause des PPA, dans lesquels les mainteneurs de ces bibliothèques et outils publient au plus tôt les dernières versions stables, voire les versions « edge » de leur projet. La quasi-totalité de mes collègues travaillant dans la télédétection, le traitement d'images optiques ou radar ou la distribution des produits satellitaires dans leur forme complexe, ont donc pour système de référence – imposé par leur client – le système Ubuntu. L'outil doit fonctionner sur Ubuntu. Quant aux autres plateformes, ça va du « hors-sujet » au « ce serait bien que ce soit supporté, mais ce n'est pas une priorité ». Et je parle bien là d'outils utilisés, pour certains, de manière opérationnelle, sur des volumes de données colossaux et avec une criticité assez élevée. Bien sûr, comme partout ailleurs, cette logique est en train d'être balayée par les déploiements autoportants que proposent les conteneurs et les clusters Kubernetes. Ceci étant, l'image de base des conteneurs utilisés dans ces domaines est souvent une Ubuntu. > Pour un responsable de sécurité, lire comme un argument positif que > les containers peuvent être la solution car phagocytées; lire que > « S'il est strict et propre, l'application n'a qu'un accès limité au > système » hérisse le poil. Le concept de cloisonnement, d'isolation, de partionnement, n'a pourtant rien de neuf et il est prôné de longue date par les experts en sécurité. La première forme historique de ce cloisonnement, très imparfaite, était le « chroot », puis sont venues des technologies plus avancées (cgroups, LXC, machines virtuelles, conteneurs Docker…). Partant du principe que nous n'éliminerons jamais les bogues et failles de sécurité, l'isolation est le sens de l'histoire. > Toutes ces réflexions viennent finalement de la faiblesse des > ressources humaines disponibles à tous les étages de la construction, > du suivit des applications proposées. Ce n'est pas qu'un problème de ressources humaines, même si le manque de personnes qualifiées l'accentue. Une fois encore, se coltiner toutes les spécificités de chaque distribution, de chaque plateforme, n'a rien de plaisant quand on est développeur et cela consomme un temps et une énergie qui pourraient être bien mieux utilisées si la diversité de ces plateformes était drastiquement réduite (sans qu'il soit souhaitable, pour d'autres raisons, de ne disposer que d'un seul et unique système d'exploitation). Même dans un contexte professionnel, il arrive qu'un client revienne sur ses exigences initiales et nous demande de laisser tomber le support de macOS ou d'une distribution GNU/Linux quelconque. Au niveau des systèmes GNU/Linux, les efforts de standardisation que sont la LSB et le FHS vont dans le bon sens, mais ces initiatives sont une goutte d'eau dans l'océan de diversité qu'est le libre (pour ne parler que de lui, car les systèmes d'exploitation propriétaires ont bien d'autres tares). Sébastien -- Sébastien Dinot, [email protected] https://www.palabritudes.net/ Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
