TRANSFORM'IT
MENU

Retour au début de millénaire

Dans les années 2000, la plupart d’entre nous utilisaient un numéro ICQ pour communiquer ou faire de nouvelles connaissances à travers le monde. Je ne me souviens plus de mon numéro ICQ ; pourtant, ce système de messagerie existe toujours et de nombreuses solutions alternatives sont apparues depuis, chacune avec ses propres protocoles et clients. Il en a résulté une initiative permettant de créer un protocole ouvert sur la base de Jabber. Appelé XMPP (Extensible Messaging and Presence Protocol), il est pris en charge à titre de protocole intermédiaire pour échanger des messages avec d’autres réseaux : Jabber, AIM, Google Talk, ICQ, etc.

Durant cette période, le protocole de communication textuelle par Internet (IRC, ou Internet Relay Chat) était également un moyen populaire de discuter et rencontrer des gens partageant des points communs : hobbies, ville, pays, lieu, école, etc. Étant donné que l’IRC est un protocole client/serveur, il suffisait d’avoir un client IRC pour se connecter à un serveur ou un réseau, et rejoindre une salle de chat ou un canal : c’était aussi simple que ça. Il y avait également la possibilité de créer son propre canal ou sa salle de chat, ou de devenir l’opérateur de l’un de ceux qui existaient déjà. Différents réseaux étaient disponibles, mais je ne les comparerai pas dans cet article car je ne veux pas déclencher de Flame war comme à l’époque 🙂

Automatisation du chat IRC

Afin d’assurer sa popularité, un canal devait proposer des rubriques divertissantes, des publicités, et disposer d’opérateurs dédiés pour contrôler les salles de chat. Il était donc devenu fréquent, pour automatiser ces activités, d’utiliser des robots. Certaines entreprises ont alors commencé à se développer autour de cette activité spécifique : exécuter des robots IRC. Il pouvait s’agir de scripts dans un ordinateur individuel ou dans des serveurs dédiés, connectés à Internet en permanence pour exécuter ces robots. N’oublions pas que nous parlons de la fin des années 90 et du début des années 2000 ; il était très rare qu’un particulier soit connecté à Internet toute la journée. En résumé, le robot restait connecté aux canaux et automatisait les tâches suivantes :

  1. censurer/bannir les propos inappropriés (termes offensants) ;
  2. fournir des services tels que !Download, !Radio, !etc ;
  3. diffuser de la publicité dans le canal ;
  4. maintenir la salle de chat en cas de netsplit.
FloodBot-IRC
Un “Floodbot” en action sur IRC

Mon histoire avec les robots

À cette époque, j’avais le projet de m’appuyer sur les mécaniques de salles de chat pour utiliser l’IRC comme plan de commande de serveurs. Puppet a été créé autour de 2005, mais certains concepts s’appliquent toujours, même avec Puppet.

Détection de serveurs

À partir d’un serveur IRC privé et de différents canaux définis en fonction du client, de la distribution Linux et du rôle du serveur. J’ai donc développé un script Perl que j’ai déployé sur chaque serveur comme un service robotisé. Sa mission : détecter les serveurs dès qu’ils se connectaient à l’ensemble initial des salles de chat. La liste des salles de chat et des canaux était conçue sur la base d’une distribution Linux et des packages installés. Dans le cas d’un serveur LAMP, il pouvait s’agir de : #world, #debian, #slackware, #redhat, #conectiva, #apache, #mysql, #php, etc. Dès que le serveur apparaissait dans le canal, je pouvais exécuter des commandes via le service robot/IRC afin de regrouper des serveurs dans des canaux supplémentaires : #customerX, #siteX, etc.

Le référentiel de configurations

Aujourd’hui, Git est bien connu et largement adopté ; mais dans les années 2000, le référentiel commun était CVS. Donc, l’idée était d’utiliser un CVS privé avec des serveurs agissant comme des clients, pour extraire et mettre à jour des fichiers du référentiel et pour sauvegarder et valider son contenu local à l’intérieur. Ces référentiels contenaient plusieurs serveurs et configurations de services qui, suite à l’exécution de commandes, étaient introduits dans le plan de commande (IRC). Utiliser CVS présentait plusieurs avantages : réduire la liste des commandes disponibles via l’interface des robots, suivre qui avait changé quoi et quand, et effectuer des retours en arrière pour analyser la configuration centrale.

L’exécution en masse

Lorsque je devais procéder à l’exécution en masse d’une commande, il me suffisait de rejoindre le canal approprié et de spécifier la commande de la liste blanche à faire exécuter par les bots. Par exemple, cela pouvait être quelque chose comme :

  1. join #debian chatroom
  2. Backup, !cvs update
  3. !exec apt-get -y update

Où ces concepts sont-ils appliqués aujourd’hui ?

De nos jours le protocole XMPP est encore utilisé pour les échanges de messages, mais sous des formes complètement différentes comme, par exemple, dans le cadre d’une architecture réseau SDN (Software Defined Networking). En deux mots, le XMPP agit comme un protocole de plan de commande permettant d’échanger des messages entre les contrôleurs et les nœuds. Génial, non ?

De nombreux concepts de l’IRC se retrouvent dans Slack, où vous pouvez créer votre propre réseau ou projet, inviter des amis et collègues et regrouper des conversations dans des canaux. Slack intègre en natif la capacité de développer des bots, comme dans cet exemple (ici), où il fait office de pont entre votre canal Slack et l’IRC. Il est également fréquent d’avoir des robots qui envoient les résultats d’une tâche Jenkins ou d’interagir avec eux par le biais de macros texte envoyées dans le canal. Pour plus d’informations, je vous invite à découvrir Hubot, la plateforme dédiée aux robots développée par GitHub.

Hubot-automatisation

L’idée de se fonder sur des référentiels est largement admise, mais certains types d’utilisation ont évolué avec l’expansion des conteneurs. Par exemple, citons OSTree, adopté dans Project Atomic et dans Photon de VMware pour procéder à l’installation et aux mises à jour des packages, ou encore Docker Hub, où sont stockées des tonnes de conteneurs.

Who let the bots out ?

Si l’on considère que, dans les deux scénarios, la communication entre les systèmes s’effectue via des canaux et des salles de chat, des éléments autorisés pourraient les rejoindre afin de participer ou, tout simplement, de s’inspirer de ce qui se passe dans l’environnement. Cela permettrait un échange de messages ouvert entre les systèmes de différents fournisseurs afin de créer un écosystème où des logiciels supplémentaires pourraient se raccorder et imiter des comportements observés chez les robots IRC.

Automatisation 1.0 : Laisser le bot provisionner

Les bots pourraient constituer une façon originale d’interagir avec l’infrastructure : au lieu de recourir à des portails, on pourrait demander des ressources à provisionner avec une interface beaucoup plus simple. Cela reviendrait à avoir une conversation avec quelqu’un pour demander les ressources dont vous avez besoin, au lieu de naviguer pour trouver le menu correct sur lequel cliquer.

Si l’on considère le niveau actuel d’automatisation auquel sont parvenus CoprHD (stockage), Openstack (cloud), OpenDayLight (réseaux), Cloud Foundry (application) et Jenkins (intégration continue), pour ne nommer que certains d’entre eux, on peut en déduire que que de nombreuses innnovations pour le provisionnement et la consommation de ressources existent déjà. Le chaînon manquant est une interface standard simple pour interagir avec tous ces éléments. Maintenant, imaginez un instant que, pour provisionner un espace de stockage, il suffise de démarrer une discussion avec votre robot de stockage et de lui demander ce dont vous avez besoin. Après vous avoir authentifié, le robot communiquerait alors avec tous les systèmes d’automatisation appropriés pour fournir les ressources concernées. On touche à la science fiction… Mais en vérité, nous n’en sommes pas si loin.

Automatisation 2.0 : Laisser le bot piloter

Essayons d’aller encore un peu plus loin : Que se passerait-il si l’on remplaçait l’être humain opérant derrière ces différents canaux de communication, avec des robots de différents fournisseurs ? Nous pourrions créer un écosystème de robots capable de faire ce que nous, les humains, ne sommes pas en mesure de réaliser, à savoir : consolider, analyser, interagir, déclencher des actions/workflows, alerter, etc.

Imaginez des bots effectuant des analyses en ligne ou du deep learning, tout en communiquant entre eux ! Nous pourrions en programmer autant que nécessaire et créer un écosystème de robots basé sur un plan de commande d’évènements commun. Nous pourrions alors :

  • identifier les comportements anormaux ;
  • détecter les menaces de sécurité ;
  • analyser les ressources ;
  • apprendre des mesures correctives mises en œuvre pour itérer.

Encore une fois, certaines initiatives très similaires existent déjà : les travaux de RSA dans le domaine de la sécurité et ceux d’ITOA en matière d’analyse des opérations informatiques, pour ne citer qu’eux. Ce qui manque encore, de mon point de vue, c’est une interface commune où l’ensemble des différents éléments pourraient voir le flux d’informations qui circulent.

Et demain ?

Notre mode d’interaction avec les systèmes va radicalement changer. La reconnaissance vocale évolue très rapidement. La simple curiosité de tester Shazam et de découvrir comment il fonctionne, même dans des environnements bruyants, a évolué pour donner des assistants personnels disposant d’une précision stupéfiante en matière de reconnaissance vocale.

Je ne serais pas surpris si, dans quelques années, le chat évoluait vers le contrôle vocal et l’intelligence artificielle personnalisée, un peu à l’image du système d’exploitation OS1 (ou Samantha), avec lequel Joaquin Phoenix entretient une relation dans le film Her.

Her-Movie-Automatisation

Comment cela serait-il appliqué au monde de l’entreprise ? Les robots sont-ils l’avenir de l’automatisation des infrastructures ? Une chose est sûre : l’automatisation des infrastructures, le Deep Learning et les Chatbots (robots conversationnels) sont autant de briques élémentaires pour évoluer dans cette direction. Reste désormais à savoir quand ces infrastructures de nouvelle génération arriveront dans nos Datacenters.



Victor da Costa

Technophile de nature, la passion pour le monde Open Source et communautaire de Victor a commencé dans les salles IRC Freenode/Efnet au début des années 2000, alors qu’il était utilisateur et développeur de systèmes basés sur Linux. Pendant les 10 prochaines années il développera son expertise en systèmes et infrastructures de Data Center en évoluant comme Avant-vente et Expert Technique au sein de sociétés comme Equinix, Petrobras, Cisco et Unisys. Après un passage au sein de l'équipe Software Defined de Dell EMC France, Victor fait aujourd'hui partie de l'équipe spécialiste Core Technologies. Sur son temps libre, il contribue aux projets Opensource chez Dell EMC (DellEMCCODE/DellEMCDOJO) et publie le fruit de son travail sur https://github.com/victorock.

COMMENTAIRES