A l'occasion des TechDays 2015, InfoQ FR a pu rencontrer Samuel Cozannet de Canonical et aborder la roadmap de l'outil d'orchestration cloud Juju, mais aussi sur Ubuntu Snappy, les outils de configuration management open source actuels et Docker.
InfoQ FR : Bonjour Samuel, peux-tu te présenter ?
Samuel : Bonjour, je m'appelle Samuel Cozannet. Je suis Strategic Program Manager chez Canonical. Avant cela, j'ai fait plusieurs startups un peu dans tous les domaines, toujours relativement techniques, au niveau orchestration, configuration management, déploiement de grands parcs. J'ai rejoint Canonical pour m'occuper de l'éco-système de Juju qui est une solution d'orchestration cloud développée depuis trois ans maintenant par Canonical.
InfoQ FR : Justement, concernant Juju, quels sont les buts du projet de façon générale ?
Samuel : On assiste aujourd'hui à la nouvelle représentation d'une application, comme un ensemble de micro-services qui sont déployés sur un mix cloud privé/cloud public. L'objectif de Juju, c'est de mettre en relation ces services, de les orchestrer, sur n'importe quel cloud, voire même sur des substrats bare metal (NdE: directement sur des serveurs physiques non-préinstallés), sur des containers, des VM, etc. Toute l'application, complexe, faite de micro-parties va être orchestrée par Juju (on peut penser Big Data, PaaS... Toute application faite de plus de 2 services distincts est potentiellement juju-phile).
InfoQ FR : Quelle est l'architecture de la solution en elle-même ?
Samuel : C'est une architecture qui est assez classique et que l'on retrouve aussi sur des outils de gestion de configuration. On commence avec un client, on installe ce que l'on appelle un state server (NdE: un serveur d'état), qui peut être soit en stand-alone, soit en haute disponibilité. Ce state server est composé du Juju Core, d'une API de communication sur laquelle on peut plugger un GUI si on veut. C'est backé par un MongoDB. Et ensuite, sur les unités qui sont déployées par Juju, on a un agent qui communique avec ce(s) state server(s).
InfoQ FR : Et dans les cas bare metal, qu'en est-il de cette communication ?
Samuel : Quand on fait du bare metal, on s'appuie sur un ensemble d'autres technologies éditées par Canonical : MAAS (Metal as a Service) et Landscape. L'objectif de MAAS est de prendre une flotte de machines et de la représenter sous la forme d'un cloud pour un outil comme Juju. Du coup, Juju va dire à MAAS "donne-moi des ressources, avec telles contraintes réseau/CPU/RAM/DD" et MAAS va démarrer un serveur correspondant, installer l'OS et les couches de services nécessaires et ensuite le présenter comme une ressource disponible pour Juju. Landscape, c'est un outil de gestion de flotte où on va pouvoir définir un niveau de configuration optimal, de versioning de paquets, etc, et toutes les machines vont montrer une garantie dans cet ensemble là, auditable pour la compliance dans les entreprises.
InfoQ FR : Aujourd'hui, il y a pas mal d'outils de Configuration Management (Chef, Puppet, Ansible et autres). Quels sont les forces, et peut-être faiblesses, de Juju vis-à-vis de ce type de produits ?
Samuel : En fait, il y a une distinction assez claire entre un outil de configuration management et un outil d'orchestration cloud. Les outils comme Ansible, Puppet ou Chef s'intéressent tous à la configuration d'une machine. Le substrat initial c'est une machine, il faut qu'elle existe, il faut qu'il y aie un agent dessus. On va configurer cette machine en lui donnant un objectif, et on essaie de l'atteindre et de le maintenir dans le temps. Ce qui veut dire que lorsque j'ai une infrastructure et que je veux la scaler, que ce soit à la hausse ou à la baisse, j'ai une opération à réaliser potentiellement par un humain, pour créer cette nouvelle ressource et la relier à mon infrastructure. Une solution comme Juju, d'orchestration cloud, crée ces ressources. On lui assigne un objectif qui est une architecture et elle se débrouille pour y arriver. On va lui dire "j'ai besoin de déployer une solution d'analyse sentimentale, composée de 20 unités dont 5 sont déployées dans des containers, 10 dans des VMs, et 5 sous forme de services SaaS, et je veux travailler sur Microsoft Azure, fais en sorte que ça marche". Et là, ça déploie. Voilà, ça c'est l'objectif de Juju. Maintenant, évidemment dans une telle infrastructure, il y a des machines au sein desquelles on va pouvoir déployer un outil de configuration management. Soit on peut déléguer à Juju cette capacité-là, mais ce n'est pas son focus premier de maintenir dans le temps la configuration des utilisateurs ou la sécurité de la machine. Donc en fait, on peut très bien dire à Juju "déploie une machine avec un agent Ansible dessus et je veux qu'Ansible s'occupe de toute la gestion des couches basses. Toi par contre, tu vas créer les relations avec les autres machines. Tu vas faire en sorte d'ouvrir les ports, d'aller dire que tel bloc communique avec tel autre. Tu vas créer l'infrastructure, la couche haute". Et l'outil de gestion de configuration va s'orienter lui sur la garantie de la compliance avec les policies.
Pour revenir à la question, il n'y a pas de force ou faiblesse par rapport à un outil de gestion de configuration. On est dans un rôle très complémentaire, où quand on va vouloir scaler, Juju s'occupe de ça, il va dire le rôle de la machine. On peut soit déléguer à du script le fait de créer ce rôle, ou à une utilisation de configuration. D'ailleurs, Juju permet de créer des Charms, c'est-à-dire la représentation d'une instance de service, au moyen d'outils de gestion de configuration. Donc c'est très ouvert.
InfoQ FR : Bien évidemment, il y a des intégrations avec des clouds (notamment ici aux TechDays où l'on prend connaissance des nouvelles sur l'intégration avec Azure). De façon générale, comment cela fonctionne ?
Samuel : C'est intéressant car ce qu'on annonce là, c'est le fait de pouvoir utiliser Juju très facilement sur Azure. C'est quelque chose qui nous est venu de Microsoft. Ils nous ont dit qu'ils aimaient beaucoup Juju, que c'était un outil intéressant, mais que l'expérience utilisateur pour leurs évangélistes ou même pour leur communauté Azure était relativement complexe. Donc on a cherché un moyen de pouvoir démarrer avec plus rapidement. La première chose qu'on a faite, c'est un template VM Depot où on presse play, on a une interface à laquelle on transmet le fichier Publish Settings d'Azure, et cette machine va créer un environnement Juju, le démarrer, et ensuite on n'a plus qu'à jouer avec. C'est extrêmement rapide. Les raisons de ces synergies avec Azure, c'est que globalement nous pensons que c'est le cloud le plus avancé aujourd'hui dans le monde de l'entreprise, comparé à ses concurrents directs dans le cloud public. Et très clairement, Juju s'exprime bien quand on a des solutions complexes, typiquement du Big Data, des PaaS, des choses comme ça, pas le genre de solution qu'un particulier déploie chez lui. Le focus avec Azure, c'est de renforcer cette relation entreprise, de rendre très simple l'utilisation de ressources via Juju au sein d'Azure. C'est un peu un win-win, c'est la solution Canonical, mais cela génère aussi plus de workloads dans Azure, ce qui est bénéfique aux deux entreprises.
InfoQ FR : Quand il y a un aspect orchestration, utilisation d'un cloud, on va avoir un lock-in de plusieurs services, comme le storage. Comment intégrez-vous ou mettez-vous à disposition ces services ?
Samuel : Il faut considérer que quand on déploie avec Juju, on doit pouvoir déployer sur n'importe quel substrat. Donc, indépendamment du partenariat fort que l'on a avec Microsoft, pour nous il est important que quelque chose déployé sur Azure puisse être porté dans un autre environnement. Ce qui veut dire, qu'en permanence on va chercher à identifier le noyau commun de tous les substrats qu'on va avoir (par exemple le stockage est commun à tous les clouds, il y a besoin d'avoir du blob storage). Sur cette partie là, nous prenons l'action de développer le lien entre Juju et le blob storage. C'est quelque chose qui est aujourd'hui dans la roadmap, qui va arriver très rapidement, mais qui n'est pas encore réalisé. En revanche, tout ce qui est service additionnel, je pense notamment à Azure ML, il va falloir créer un pont avec Juju. Et pour cela, on s'appuie sur le développement du fournisseur de cloud, donc ça va être à Microsoft de s'intégrer dans notre environnement. On va les former, leur apprendre à faire des charms, à les écrire, on les accompagne dans cette démarche de supporter les charms, afin de s'intégrer dans notre éco-système. A quoi cela va ressembler ? Le charm, c'est une représentation d'un service dans Juju. On a un proxy charm, qui est le charm qui permet de consommer un service en SaaS, as-a-Service donc. Du coup, c'est un relai qui va exposer à l'environnement Juju toutes les informations nécessaires pour se connecter à ce service externe (credentials, etc). Ce sont des choses sur lesquelles on discute actuellement avec Microsoft, notamment sur Azure ML, on s'est engagé dans un travail commun sur la Data Science et le Big Data, c'est clairement un sujet d'actualité pour nous.
InfoQ FR : Et concernant les agents supplémentaires que l'on souhaite souvent exécuter sur chaque VM, par exemple le log shipping, comment cela se ferait dans le modèle de charms ?
Samuel : On a trois types de charm. Le proxy charm est de l'enablement pour quelque chose as a service qu'on consomme qui est à l'extérieur de l'environnement. Ensuite, on a un charm classique qui va déployer un workload, disons par exemple un serveur YARN, un noeud Storm. Et enfin, on a ce que l'on appelle les subordinate charms, qui sont dédiés à supporter une application; typiquement du log shipping, du monitoring système ou applicatif, gestion d'identité, des choses comme ça. Lorsqu'on déploie un Subordinate Charm, et qu'on le relie à une instance de service (Storm par exemple), il va être automatiquement déployé sur tous les noeuds de ce service présents sont dans l'environnement. Par la suite, il va pouvoir être configuré pour reporter vers un serveur qui peut être externe, ou lui-même déployé au sein de l'environnement Juju. Un exemple typique serait une entreprise qui dispose d'un service de monitoring historique, Zabbix par exemple, qui est pré-existant à l'arrivée de Juju. On va pouvoir dire à Juju de déployer l'agent Zabbix vers tous les noeuds déployés au sein des environnements de travail, mais pointer le reporting vers le serveur ou proxy préexistant.
InfoQ FR : De la même façon que vous avez une stratégie OpenStack, quelle est votre roadmap vis-à-vis de Docker ?
Samuel : Le principe de Juju est de faire le moins d'hypothèses possibles sur le substrat sur lequel il va être déployé. Donc si un développeur veut développer et déployer avec Docker, c'est supporté par Juju, il pourra le faire, notamment quand il utilise aussi Ubuntu Core/Snappy qui est vraiment dédié à ce genre d'usage. Ubuntu est l'OS principal pour créer des containers Docker, je crois de tête que le numéro 2 doit être six fois moins utilisé que nous, donc c'est très clairement une technologie qu'on supporte, on discute très régulièrement avec eux et c'est intégralement supporté par Juju. On a des charms pour Kubernetes aussi pour aider au déploiement de containers, donc c'est une histoire que l'on est en train de créer, pas finalisée mais qui est sur la roadmap 2015, d'ici Ubuntu 15.10 grosso modo ce sera complètement intégré et déployable n'importe où. Et orchestrable, ce n'est pas seulement de déployer des containers mais l'intérêt de Juju c'est de créer ces relations entre les containers afin qu'ils puissent consommer leurs services respectifs.
InfoQ FR : Mis à part Ubuntu Snappy, sur quels autres types d'OS on peut faire tourner des workloads ?
Samuel : Aujourd'hui, on ne déploie que Ubuntu. Mais il y a une demande de la communauté pour supporter d'autres OS. On a un travail communautaire qui est réalisé sur Windows qui est très proche d'aboutir, également en 2015. On pourra déployer des workloads Windows. On a aussi évidemment une demande pour CentOS/RHEL. On aura grosso modo les distributions majeures. On a aujourd'hui moins de demande pour du SuSE, mais ce n'est pas fermé en soi, il n'y a pas de raison pour qu'ils ne soient pas non plus dans l'écosystème. Et puis, les charms qui sont présents dans le store sont tous open source, même si bien sûr on peut écrire ses charms privés. L'idée est qu'un charm vit parce que la communauté l'améliore sans cesse, donc on a toujours une version de chaque charm qui est recommandée et validée par la communauté comme la meilleure solution à ce jour pour déployer ce workload. Pour les entreprises et les développeurs, il faut comprendre que notre vision est que "charmer" leur application est l'équivalent next-gen de packager en .deb, .rpm ou .msi: la représentation des best practices d'installation du logiciel, at scale.
InfoQ FR : Pour rappeler peut-être un peu le but de Snappy, c'est une distribution minimale orientée VM cloud; on entend en ce moment pas mal parler de CoreOS, quelles différences y-a-t'il ?
Samuel : Oui, c'est une Ubuntu minimale qui tient en 40 Mo de RAM. L'objectif général est le même, c'est d'avoir un OS minimaliste pour déployer des tonnes de machines simplement. Là où Snappy diffère de CoreOS, c'est qu'il est beaucoup plus général. On a la possibilité de supporter tout type de container, et pas forcément uniquement Docker. On a aussi la possibilité de créer des applications qui s'appellent des snaps, qui ne sont pas des containers, mais qui bénéficient aussi d'un sandboxing intransigeant. Chaque application va être versionnée, on a un mécanisme transactionnel et individuel de mise à jour des applications. Du coup c'est extrêmement simple de dire "j'ai une application A, je l'upgrade dans A'", "j'ai un problème, je reviens sur A". Et ça on peut le faire sur tout périmètre applicatif de l'OS. Une autre différence concernant Snappy, c'est qu'il supporte ARM et x86.
InfoQ FR : Tu as commencé à évoquer des points sur la roadmap comme le support d'Azure ML et d'ajout de workloads Windows et CentOS, est-ce qu'il y a d'autres features prévues dès maintenant ?
Samuel : La partie stockage. Il y a aussi une feature autour du stockage long terme avec la capacité de réutiliser des choses qui ont été déployées précédemment dans d'autres environnements. Sur Azure spécifiquement, il y a cette nouvelle machine qui permet de consommer des environnements Juju très rapidement, elle est disponible en alpha dans VM Depot. Juju sera aussi à terme incorporé dans la marketplace Azure, Juju sera donc masqué dans l'interface mais permettra de déployer des workloads directement dans Azure. Pour finaliser ça, il y a deux choses qui arrivent dans Juju, la première c'est le support multi-utilisateurs dans un environnement Juju, et la seconde c'est d'avoir un state server qui soit multi-environnements, n environnements au sein du même cloud.
InfoQ FR : Merci beaucoup Samuel d'avoir répondu à nos questions !
Samuel : Avec plaisir!