Webui on Zwindler's Reflection

Les WebUIs, TUIs, GUIs pour Kubernetes – Episode 03

Mon, 24 Oct 2022 06:00:00 +0200

Note: Cet article fait partie d’une série de 3 articles dans lesquels je fais une liste exhaustive des WebUIs, TUIs et GUIs pour utiliser Kubernetes :

Kubernetes, c’est dur 😭, fin ?

Dans les deux premiers épisodes, j’ai donc présenté les WebUIs puis les Terminal User Interfaces.

Reste maintenant un gros morceau : les Graphical User Interfaces !

Et vous allez voir qu’on a pas mal d’options, de ce côté là (pour l’instant j’en ai 5).

Mirantis Lens (ex-Kontena Lens)

Site : k8slens.dev
Sources : github.com/lensapp/lens

Impossible de parler des GUI pour Kubernetes sans parler de Lens… Après k9s qu’on a vu dans l’article précédent, c’est indubitablement l’outil le plus connu.

Bien que parfois un peu lourde, je pense aussi que c’est l’outil le plus complet et le plus simple pour démarrer dans Kubernetes.

L’outil gère bien entendu les CRDs, permet de naviguer rapidement d’un cluster à l’autre grace à des onglets sur la gauche.

On peut drill down dans les objets en cliquant dessus (Deployment, Pods, etc) et faire des actions spécifiques comme consulter les logs en temps réel, s’attacher sur un container ou faire un port forward en un clic.

L’installation se fait via des packages ou via les snap par exemple

sudo snap install kontena-lens

Alors quel est le hic me demanderez-vous ?

Et bien depuis la version 6, Mirantis impose la création d’un compte sur la plateforme pour pouvoir utiliser l’outil, et depuis peu, a introduit un modèle payant dans l’outil (gratuit pour les individus, payant pour les entreprises, en gros).

Vous ne pouvez donc théoriquement plus l’utiliser dans un contexte pro sans passer à la caisse. Je ne dis pas que c’est mal, mais il faut en être conscient.

OpenLens

Comme le code de Lens est opensource, il est toujours disponible et continue d’évoluer sur leur Github.

En théorie, il suffit juste (“yaka”) de le compiler pour disposer toujours d’une app Lens sans licence.

Un utilisateur de Lens a créé un projet OpenLens (cf cet article plus complet à ce sujet) mettant à disposition des binaires précompilés :

github.com/MuhammedKalkan/OpenLens

Si vous avez la flemme de compiler Lens vous-même et que vous faites confiance à MuhammedKalkan, vous avez donc cette alternative…

Kubenav

Site : kubenav.io
Sources : github.com/kubenav/kubenav

Dans les GUIs pour Kube, je dirais que ce qui différencie Kubenav des autres est le fait qu’il y ait une application iOS et Android (en plus de la version desktop).

What could go wrong?

L’UI est plutôt clean même si je ne suis pas fan des grosses icônes mais c’est acceptable.

Kubevious

Site : kubevious.io
Sources: github.com/kubevious/kubevious

Pas du tout fan de l’UI, très très bizarre je trouve avec des grosses tuiles et plein de couleurs. Mais bon, chacun ses gouts, j’imagine.

A priori, là aussi le modèle éco semble avoir changé récemment… cf kubevious.io/pricing.

Bref… pas convaincu.

aptakube

Site : aptakube.com

A modern and lightweight Kubernetes desktop client to help you operate workloads on multiple clusters.

J’ai hésité à la mettre dans la liste car j’avais vraiment fait un focus sur les outils open source alors qu’aptakube ne l’est pas (c’est une free public preview).

Cependant, je trouve l’outil assez propre, et aussi le fait qu’il y ait des binaires de “petite taille” pour tous les OS et que ce soit une énième application electron.

Ca se sent d’ailleurs dans la réactivité, l’outil est hyper rapide et fluide, c’est très confortable. C’est bien rangé, on peut sélectionner plusieurs clusters à la fois (et on voit les pods de tous nos clusters d’un coup par exemple).

J’ai juste pas envie d’investir trop de temps dessus si l’outil devient au final payant (surtout si c’est cher). Attention donc.

This is the end 🎶

En fait pas vraiment. A la base j’avais prévu de ne parler que des trois catégories qu’on a vues jusqu’à présent, mais j’ai encore une voire deux idées d’articles pour les interfaces pour Kubernetes.

On verra quand j’aurais le temps de rédiger tout ça.

Et en attendant, have fun ;).

Les WebUIs, TUIs, GUIs pour Kubernetes – Episode 02

Thu, 13 Oct 2022 06:00:00 +0200

Note: Cet article fait partie d’une série de 3 articles dans lesquels je fais une liste exhaustive des WebUIs, TUIs et GUIs pour utiliser Kubernetes :

Kubernetes, c’est dur 😭, suite

Dans l’article précédent (en février dernier, mdr), je vous avais présenté les Web UI qu’on pouvait utiliser avec Kubernetes. Vous aviez probablement deviné, aujourd’hui on va parler des TUI, aka les Terminal User Interfaces ou interface pour terminaux en bon français.

Alors on pourrait penser que l’article ne se résume qu’à un seul nom tant il est connu. Car la vraie star des UI dans Kubernetes, c’est bien évidemment k9s.

Mais j’ai réussi à en dégoter une autre, active et utilisée (+2k stars sur Github et une place à part entière dans le repo kubernetes SIG), dont je parlerai après.

k9s 🐶

Who let the Pods out?

WHO?! WHO?! WHO WHO?!

Vous aussi vous avez Baha men dans la tête ?

(Vous êtes vieux/vieilles)

Site: k9scli.io
Sources: github.com/derailed/k9s

Je me répète un peu mais impossible de faire des articles sur les UI dans Kubernetes sans citer k9s (à prononcer k-nine-s, d’où le chien pour ceux qui ne l’avaient pas).

C’est très probablement le tool le plus riche que vous pourrez trouver pour gérer vos clusters Kubernetes, mais aussi celui qui demande un petit apprentissage, notamment parce que 90% de la puissance de l’outil réside dans les raccourcis.

Je ne vais pas mentir, au risque d’en décevoir plus d’un, je ne l’utilise d’ailleurs pas au quotidien, pour cette raison…

J’ai toujours eu la flemme d’apprendre les raccourcis et je préfère “m’embêter” à faire les commandes en CLI, via la WebUI officielle, ou entre via une autre UI dont on parlera dans le prochain article 😏…

Cependant, si vous avez la patience d’apprendre ces fameux raccourcis, c’est sans aucun doute l’outil le plus puissant pour utiliser Kubernetes au quotidien. On peut facilement “drill down” dans notre cluster, filtrer les pods, faire du port-forward facilement, visualiser les CRDs, …

L’outil s’installe grâce à des gestionnaires de paquets (type homebrew, linuxbrew, pacman, chocolatey, …) ou directement en compilant les sources (c’est du go, c’est assez trivial) :

git clone https://github.com/derailed/k9s
make build

A noter, on peut lancer directement d’autres outils depuis k9s comme popeye (un tool pour aider à nettoyer son cluster du même auteur) (avec :popeye).

KUI

KUI KUI KUI 🐦

Site: kui.tools
Sources: github.com/kubernetes-sigs/kui

Deuxième TUI de cet article (et probablement la seule autre), j’ai nommé KUI.

Je l’avais testée en 2018 ou 2019, avant que le projet ne soit déplacé dans le kubernetes-sigs, quand cette UI était encore développée par IBM.

Kui est vraiment une app chelou, hybride entre la CLI, une TUI et une GUI (en fait, c’est une app electron).

Récupérer une release https://github.com/kubernetes-sigs/kui/releases/tag/v13.1.4

unzip kui.zip
export PATH=$PWD/Kui-linux-x64/Kui.app/Contents/Resources:$PATH
kubectl kui get pods

Historiquement, je me souviens l’avoir lancée depuis mon terminal, mais il semblerait que maintenant ce soit lancé dans une fenêtre à part entière…

Toujours est-il qu’une fois lancée, on se retrouve avec un “terminal” permettant de lancer des commandes kubectl soit en les écrivant, soit en cliquant dessus.

Ce que j’avais trouvé intéressant à l’époque avec cette UI (je sais pas trop comment la catégoriser), c’est que toutes les modifs qu’on fait affichent la commande avec kubectl correspondante, et qu’on peut switcher de l’un à l’autre. C’est à la fois terminal et graphique.

J’aime beaucoup cette idée qu’on devrait avoir littéralement dans TOUS les outils qui proposent des CLIs (Google le fait sur certains menus il me semble).

Cependant, c’est un peu bourrin et pas super efficace à l’usage. Mais ça valait je pense quand même le coup d’en parler, au moins pour la culture et les quelques bonnes idées.

Et plus si affinité…

Clairement, cet article n’est pas le plus fourni des 3 de cette série. J’espère rapidement revenir pour le 3ème et dernier épisode, pour parler des interfaces graphiques (les GUIs).

J’espère ne pas mettre 8 mois pour le sortir, cette fois ci ;)

En attendant, have fun !

Les WebUIs, TUIs, GUIs pour Kubernetes – Episode 01

Mon, 21 Feb 2022 06:30:00 +0000

Note: Cet article fait partie d’une série de 3 articles dans lesquels je fais une liste exhaustive des WebUIs, TUIs et GUIs pour utiliser Kubernetes :

Kubernetes, c’est dur 😭

Voilà quelque chose qu’on entend à longueur de journée. J’en ai déjà parlé, Kubernetes est un outil « modérément » complexe. Oui, c’est un outil complet (et pas complexe) avec une terminologie riche qui lui est propre.

Au delà de la fausse promesse que certains lui attribue (permettre aux Dev de s’émanciper totalement des Ops, j’en parle dans l’article « au secours, le métier d’Ops va disparaître« ), il y a un vrai problème de vocabulaire et de concepts qui ne sont pas évidents pour les débutants.

Pour faciliter l’adoption, j’ai remarqué que beaucoup de gens qui débutent dans kube s’aident d’environnement (souvent graphiques, mais pas forcément) permettant d’interagir avec les objets logiques de Kubernetes de manière « simple ».

Car, bizarrement, tout le monde n’aime pas écrire des tonnes de lignes de commandes (ou pire des calls d’API) et des tartines de YAML à longueur de journée… J’comprend pas.

Comme je suis quelqu’un de sympa, j’ai donc testé pour vous tous les outils, graphiques ou non, que j’ai pu trouver, pour vous faire un petit guide et vous donner mes impressions.

Vous êtes prêts ?

Alors c’est parti !

Dans ce premier épisode (qui en comportera 3, je vous laisse deviner les deux autres), je me suis concentré sur les WebUI.

Kubernetes UI (officielle)

Site : kubernetes.io/fr/docs/tasks/access-application-cluster/web-ui-dashboard/
Sources : github.com/kubernetes/dashboard

Franchement au début je voulais prendre le parti de NE PAS parler de la WebUI officielle. Je ne l’aime pas, depuis longtemps.

Je la trouvais limitée, au début elle était buguée, les messages d’erreur étaient tout sauf explicites, … Les CRDs n’étaient pas du tout gérées et même les objets officiels de l’API de Kubernetes n’étaient pas tous représentés, rendant tout diagnostic poussé impossible.

Si c’est pour faire du kubectl de toute façon, autant ne pas perdre de temps à m’authentifier sur la WebUI.

Elle était souvent déployée un peu par défaut dans les débuts de Kubernetes et souvent mal sécurisée (par les utilisateurs) ce qui a conduit à de nombreux piratages. Les cloud providers ne l’activent plus par défaut pour cette raison (voire même, certains le déconseillent).

Cependant, j’ai réessayé la V2 et il faut reconnaître que les choses se sont améliorées. Les CRDs sont correctement prise en charge, notamment.

Octant (VMware)

Site : octant.dev
Sources : github.com/vmware-tanzu/octant

Un projet qui me tient à cœur est la solution de WebUI de VMware.

Je dis WebUI, mais uniquement parce que l’UI est lancée dans un navigateur. Mais ce n’est pas un serveur web à exposer h24 comme l’UI officielle. C’est d’ailleurs pour ça que c’est « plus sécure ». L’UI n’est lancée que localement sur le poste de l’utilisateur, à la demande, avec les privilèges de l’utilisateur (et rien de plus).

Elle sert d’UI pour Tanzu (le Kubernetes à la sauce VMware) mais pas que, ce qui explique je pense l’effort qu’ils y mettent (il faut bien se différencier).

Pour l’avoir pas mal utilisée, c’est fiable et pratique. C’est aussi assez simple à installer, VMware mettant à disposition sur Github des archives et des packages systèmes :

Et voilà à quoi l’UI ressemble. On retrouve des menus où sont regroupés les différentes vues sur la gauche, puis on navigue de ressource en ressource via les liens hypertexte. On peut faire des recherches par filtres, …

Dans les plus que j’y vois, c’est assez intuitif, on est pas perdu. Le principe est relativement similaire à l’UI officielle, même si l’organisation des menus est différentes. Un point noir, le texte est par défaut très petit, et des menus très riches (beaucoup de cadres, beaucoup de texte).

L’UI offre des fonctionnalités supplémentaires par rapport à l’UI officielle, comme l’affichage des logs streamés, le port-forward d’un pod via un click, qui vous lance votre application dans un nouvel onglet de navigateur (hyper pratique). Tout est filtrable, notamment par labels.

Les CRDs sont correctement gérées depuis longtemps (mais c’est aussi le cas dans l’UI officielle maintenant).

Le produit met également en avant son côté extensible avec plusieurs modules complémentaires permettant d’étendre les fonctionnalités de base. Je n’ai pas essayé cette possibilité.

Headlamp

[Edit] J’ajoute aussi Headlamp que je viens de découvrir grâce au seul et unique Seb Moreno :)

Site : Blog de Kinvolk pour présenter headlamp
Sources : github.com/kinvolk/headlamp

Développée par kinvolk (a priori rachetée récemment par Microsoft en 2021) cette nouvelle WebUI se veut simple d’utilisation et multi cluster.

Elle peut être déployée directement dans un cluster, en tant qu’application sur votre laptop/PC/whatever.

Je ne vois pas bien ce qu’elle apporte de plus que les autres à part peut être un look minimaliste qui peut plaire (ou pas).

Ce n’est ni un avis positif, ni un avis négatif, elle n’a juste IMO pas grand chose de vraiment différenciant mais elle a l’air tout à fait acceptable.

Skooner (ex-K8dash) (Indeed)

Développée pour les besoins internes de Indeed, cette WebUI se veut plus simple dans son look que la WebUI officielle.

Site : Blog post sur le tech blog de Indeed Engineering
Sources : github.com/indeedeng/k8dash / github.com/skooner-k8s/skooner
Vidéo démo : www.youtube.com/watch?v=u-1jGAhAHAM

Les fonctionnalités mises en avant sont une installation simple (ça se déploie dans Kubernetes, effectivement c’est pas super complexe), une UI mise à jour en temps réel (pas de reload de la page web) et une authentification OIDC intégrée. Les objets sont filtrables.

Au delà de l’installation simple et de l’intérêt réel pour l’ajout de l’OIDC out of the box, je ne vois pas bien ce qu’elle apporte… Oui, le look est plus léché et il y a un gouvernail qui tourne (youpi). Oui ça se reload tout seul en temps réel.

Mais bon… question de goût, j’imagine ?

Et plus si affinité…

Bon là, niveau WebUI on est déjà bien.

Si jamais vous n’avez toujours pas trouvé votre bonheur, le mieux, c’est certainement d’attendre le prochain épisode (car après les WebUI, on a vraiment du lourd qui arrive pour les prochains épisodes :-p).

Et en attendant, have fun :)

Vulture 2.0.8 : des nouveautés et des impacts sur la WEBUI de Shinken

Fri, 25 Jul 2014 14:14:08 +0000

Fin mai, la version 2.0.8 est sortie et a apporté un lot impressionnant de fonctionnalités supplémentaires (ainsi que quelques bugfixes d’usages)… ainsi que quelques petites surprises pour ma configuration, et notamment pour publier la WebUI de Shinken au travers de Vulture.

Mais le jeu en vaut largement la chandelle, regardez plutôt …

Réécriture de la documentation

OMG ! Vulture dispose ENFIN d’une documentation (relativement complète) pour CHAQUE page de l’interface d’administration. Cela permet de remettre au clair les passages qui n’avaient pas été bien compris lors de mes premières installs et corriger quelques erreurs dues au manque d’information sur les versions précédentes.

A noter, si vous commencez, il faut aller sur ces deux pages, avant de lire la doc en entier, pour ne pas être perdu :

Refonte intégrale du packaging

Refonte intégrale du packaging : Vulture s’installe désormais simplement avec 3 paquets

ENFIN bis ! Et ça fonctionne bien, fini les galères pour installer les dépendances. Par contre la liste des distribs gérées se limite à sont plus simple appareil : CentOS 6.5 et Debian 7.

Mise à jour automatique des configurations

Bon… ça, ça fait un moment qu’on nous le promet, et j’ai du faire une fausse manipulation certainement car comme d’habitude… j’ai tout perdu… Si vous avez des retours positifs, je suis preneur ;)

Support d’une URL par défaut dans les interfaces

En voilà une bonne idée ! Cependant, j’ai eu à l’inverse la mauvaise idée d’en indiquer une pour mon interface, alors que cette appli/URL n’existait pas, et je me suis retrouvé avec de gros soucis sur mon portail, qui ne marchait tout simplement plus.

J’avais des erreurs au niveau des logs des applications, avec des messages d’erreurs faisant état d’une application inconnue depuis le fichier Core::AuthzHandler.

Je le re-testerai une autre fois, pour voir, mais je me demande s’il ne manque peut être des contrôles vu que c’est une nouvelle fonctionnalité. Si vous n’en avez pas besoin, je vous conseille de ne pas l’utiliser.

Plugins – Transhandler

Suite à l’installation de la 2.0.8 de Vulture, je n’arrivais plus à faire fonctionner la WebUI de Shinken. J’arrivais à avoir la mire d’authentification, mais pas les images et le CSS.

Après dépilage des logs, j’ai fini par remarquer que les connexions faisant appels au CSS et aux images (de type static/*) se retrouvaient redirigés sur le serveur où est installé Vulture, et pas sur le serveur Shinken où elles sont situées.

Après vérification, j’ai trouvé avec étonnement que le plugin TransHandler STATIC static/* livré par défaut lors de l’install était appliqué à toute mes applis, alors que cette règle n’est normalement appliqué à AUCUNE application (paramètre positionné à None)**. [Edit] En fait selon l’équipe de Vulture, c’est normal, quand on a la colonne « Application » à « None », ça signifie que ça s’applique à toutes les applications [/Edit]
**

La documentation fait bien état de ce plugin, qui sert effectivement à mettre en local sur le serveur qui héberge Vulture toutes les ressources statiques (ici).

J’ai désactivé ce plugin, et tout est rentré dans l’ordre. [Edit] Il semblerait que cela soit plus compliqué que cela. Ce contournement provoque notamment des effets de bord sur le portail. J’ai ouvert un thread sur le google group de vulture à ce sujet.[/Edit]

Will not rewrite (Rewrite Content) this content-type: application/json

Une fois Shinken de nouveau disponible, ce n’était pas terminé pour autant. Visiblement, depuis la 2.0.8 (peut être avant mais je n’ai pas remarqué en 2.0.4), le plugin de réécriture de contenu de la page à la volée Rewrite Content ne prend plus en charge l’ensemble des contenus par défaut. Cela se traduit par une page web qui n’est simplement pas réécrite (on retrouve les URL privée de PNP dans la page Shinken) et par le message suivant dans le fichier de log

Le log est plutôt explicite, et la doc aussi (vultureproject.org/documentation/configuration/configuration-des-applications-web/composants-plugins/reecriture-de-contenu/) !

Vulture ne pourra altérer que les contenus dont le content-type est l’un des suivants (il est cependant trivial d’en ajouter d’autres, contacter l’équipe de développement pour signaler un type non géré)

Les types sont les suivants :

text/xml
text/html
application/vnd.ogc.wms_xml
text/css
application/x-javascript

J’ai donc signalé ce manque à l’équipe mais en attendant qu’ils publient un patch, vous pouvez simplement ajouter dans l’expression régulière application/json et text/javascript ligne 138 du fichier /opt/vulture/lib/Vulture/Plugin/Plugin_OutputFilterHandler.pm

diff /opt/vulture/lib/Vulture/Plugin/Plugin_OutputFilterHandler.pm*
138c138
< if ($r->content_type ne '' and $r->content_type !~ /(text/xml|text/html|application/vnd.ogc.wms_xml|text/css|application/x-javascript|text/plain|application/json|text/javascript)/){
---
> if ($r->content_type ne '' and $r->content_type !~ /(text/xml|text/html|application/vnd.ogc.wms_xml|text/css|application/x-javascript|text/plain)/){

[En bref] Sortie de Vulture 2.0.6

Thu, 22 Aug 2013 19:38:28 +0000

Sortie de Vulture 2.0.6

Dans le genre news pas très fraîche, je voudrais la sortie Vulture 2.0.6, vieille d’environ 2 mois… Sortie de Vulture 2.0.6

Le changelog fait état de la correction de 3 bugs et l’ajout de quelques petites features sympa. Je ne sais pas si c’est les mises à jours des dépendances (ou les modifications de celles ci?), mais j’avais plusieurs comportements étranges sur mes vulture (Debian et CentOS de test) qui semblent aujourd’hui être de l’histoire ancienne!

Comme d’habitude avec Vulture, mise à jour = suppression de la base de données. Vous aurez donc tous vos paramétrages à refaire, mais personnellement, je trouve que le jeu en vaut la chandelle dans ce cas précis.

Sachez aussi que normalement cela devrait être la dernière fois si l’on en croit la doc d’install de Vulture.

A tester la prochaine fois, j’ai hâte de ne plus avoir besoin de tout refaire à chaque fois !

Activation de django-evolution

Depuis la version 2.0.6, il est possible d’activer l’application django-evolution sur vulture, qui permettra une mise à jour de la base de données lors des mises à jour.

Afin de l’utiliser, il faut d’abord l’installer:

easy_install -U django_evolution

N’hésitez pas à remonter à la dev-list toutes les anomalies que vous pourriez rencontrer. Ils sont assez réactifs.

MàJ : Publier sur le WAN la WebUI de Shinken via Vulture (2.0.4+)

Sat, 17 Nov 2012 17:45:15 +0000

Vulture et Shinken, encore

Petit update de l’article Publier sur le WAN la WebUI de Shinken via Vulture

Depuis la mise à jour de vulture en 2.0.4, il est possible d’avoir des virtuals hosts, qui évitent ainsi le besoin d’avoir deux URLs distinctes du point de vue FQDN pour la WebUI et pour pnp4nagios.

On se retrouve donc avec deux applications comme suit :

Shinken - shinken.vulture.fr - http://@IP_shinken:7767
Shinken pnp4nagios - shinken.vulture.fr/pnp4nagios - http://@IP_shinken/pnp4nagios

ATTENTION : Le « / » à la fin de pnp4nagios dans l’URL privée est très important

Pensez à modifier vos filtres de réécriture d’URL à la volée pour qu’il pointe bien vers cette URL.

C’est beaucoup plus propre avec un FQDN unique

Petite note additionnelle : Attention pour ceux qui sont en 2.0.X avant 2.0.3, la mise à jour doit se faire par un réinstallation. Pour éviter de devoir tout refaire à la main, l’idéal est de désinstaller vulture en ayant préalablement copié la base de données, d’installer la nouvelle version, puis de mettre manuellement à jour la base de données.

La partie « export/import » de la configuration dans vulture fait planter vulture si la base a changé de version entre l’export et l’import (car la base de données n’est pas identiques). Tout sera planté ;-)