BlueBanquise est une pile de logiciels libres pour déployer et maintenir aisément un parc de serveurs ou de stations de travail sous GNU/Linux.
La pile de logiciels, bien que générique, est fortement orientée vers l’informatique à haute performance — HPC (High Performance Computing) —, et repose entièrement sur Ansible, un outil de gestion de configuration.
BlueBanquise est compatible RHEL/CentOS 7 et 8, et couvre l’installation et la configuration de l’ensemble des briques de base d’une grappe de serveurs de calcul. L’outil se veut totalement modulaire, pour permettre aux utilisateurs d’écrire leurs propres composants ou d’aisément dupliquer puis modifier ceux existants.
Parmi les fonctionnalités présentes figurent :
- le déploiement de serveurs via PXE ;
- la gestion de serveurs de calcul sans disque dur (diskless) ;
- la gestion des tâches de calcul via Slurm ;
- la supervision via Prometheus et Grafana ;
- la gestion des grappes de serveurs multi‑ilots.
La pile de logiciels possède une documentation complète, avec une partie (Ansible) sous forme de tutoriel.
Aller plus loin
- Site du projet (565 clics)
- Projet GitHub (121 clics)
# Encore de l'Ansible...
Posté par SuperPommeDeTerre . Évalué à -2. Dernière modification le 29 septembre 2020 à 16:05.
Je vais sûrement à l'encontre des convictions de pas mal de personnes, mais pourquoi utiliser encore Ansible, alors que des alternatives viables aussi bien techniquement qu'éthiquement existent ?
[^] # Re: Encore de l'Ansible...
Posté par Moonz . Évalué à 6. Dernière modification le 29 septembre 2020 à 16:34.
Quelles sont ces alternatives ? Ça m’intéresse vraiment, parce que techniquement je déteste ansible, mais j’ai l’impression d’avoir fait le tour des alternatives (Chef, Salt et Puppet) et c’est au final le moins pire.
Quel est le problème éthique d’Ansible ?
[^] # Re: Encore de l'Ansible...
Posté par Anonyme . Évalué à 2.
Dans tout ce que j’ai pu testé, Salt est de loin le pire. Le code est dégueulasse (des fonctions de 3000 linges avec des boucles et des conditions imbriquées), la config en YAML et Jinja est horrible, les mises à jour sont toutes plus foireuses les unes que les autres, leur gestion de versions est complètement pété, tu n’es jamais sûr qu’un patch va pas être oublié au moment de la release et tu dois une PR par version pour les hotfix (ça, ça a changé un peu apparemment). J’ai vu beaucoup de bug avec Salt ou il fallait aller sur un syndic ou master pour
rm -rfdes fichiers, genre le cache des pillars qui se met pas à jour pour ta branche de dev (ou inversement qui se propage de ta branche de dev vers ta branche de prod), le dépôt qui se synchronise pas, etc.Côté Chef, j’ai pas trop jouer avec, mais j’ai jamais vraiment apprécier et comme il est quand même moins répandu que Puppet, j’ai jamais ressenti le besoin de le tester outre mesure. Aussi, depuis qu’ils ont signé un contrat avec l’ICE, ils peuvent m’oublier.
J’utilise énormément Puppet et je suis probablement biaisé en sa faveur, je suis curieux de connaître ce qui te fait le rejeter.
[^] # Re: Encore de l'Ansible...
Posté par claudex . Évalué à 7.
Ah ça explique pourquoi ils se sont fait racheté par VMWare.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Encore de l'Ansible...
Posté par Moonz . Évalué à 2.
C’est que, globalement et contrairement à toi, je préfère la philosophie push et le procédural. Ansible est certes déclaratif, mais tu as des choses comme
with_itemsouinclude_rolesqui sont vraiment pratiques. Écrire (et déployer/utiliser) ses propres modules est également assez simple.[^] # Re: Encore de l'Ansible...
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Je ne suis pas un grand connaisseur mais pour moi le push c'est plus simple pour une petites grappes de serveurs (moins d'une centaine et plutôt la dizaine) dans un réseau assez simple (interne). Mais quand tu n'a pas accès en direct au serveurs par sécurité (les serveurs peuvent toujours avoir accès a plus que ce qu'ils acceptent en entrant) et qu'en plus tu a beaucoup de serveur, c'est plus léger de ne pas avoir du push.
C'est en tout cas ce que j'ai lu et que je trouve justifié. Dites moi si je me trompe.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Encore de l'Ansible...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 06 octobre 2020 à 22:24.
Tu as toujours accès, en SSH, aux serveurs que tu gères non ? Alors tu peux utiliser Ansible sur ces serveurs ; c'est pas plus compliqué ni plus lourd que ça. Et cela n'a rien à voir avec le nombre de serveur ; c'est un choix KISS.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encore de l'Ansible...
Posté par Anonyme . Évalué à 2.
Non, le but c’est justement de ne plus avoir accès en SSH au serveur.
[^] # Re: Encore de l'Ansible...
Posté par flan (site web personnel) . Évalué à 2.
Si tu as beaucoup de serveurs, le mode centralisé (SaltStack/Chef/Puppet/…) doit certainement s'imposer de lui-même. Cela permet d'avoir des configurations qui sont appliquées plus fréquemment (si le démon tourne en permanence sur chaque machine).
En revanche, quand on regarde la sécurité, le principe d'Ansible peut être meilleur, vu que tu supprimes un point de faiblesse (si ton serveur maître est compromis, tu perds tout ton réseau instantanément).
[^] # Re: Encore de l'Ansible...
Posté par Anonyme . Évalué à 2.
Mouais, on pourrait arguer que la machine d’un admin est probablement plus facile à corrompre qu’une machine dont le seul point d’entré est un serveur HTTPs qui vérifie les certificats clients.
[^] # Re: Encore de l'Ansible...
Posté par flan (site web personnel) . Évalué à 1.
De toute façon, si ton poste d'admin est corrompu, c'est mort, dans tous les cas. Avec un serveur de conf', la situation devient « si ton poste d'admin OU ton serveur de conf est corrompu, c'est mort ».
Si tu suis les bonnes pratiques de l'ANSSI, le poste d'admin est censé être plutôt bien protégé (on évite la bureautique, les mails extérieurs, le web, les ports ouverts, etc.)
[^] # Re: Encore de l'Ansible...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Bonjour,
Je fais de l'Ansible en amateur, mon point de vue de Lead Java Architecte Urbaniste Jardinier Devops:
Bref ça fait le boulot, mais c'est pas terrible.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Encore de l'Ansible...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Objection votre honneur
(:Si tu veux comparer à du scripting, une tâche/action (task) est plutôt une fonction, et le rôle serait un/une module/classe/etc. Perso, j'ai tendance à voir Ansible comme un cadriciel pour orchestrer des déploiements de configuration (à ne pas confondre avec du maintien de configuration que ça peut faire aussi mais où ce n'est pas mieux que d'autres.)
Pour la syntaxe, malgré ton aversion, YAML est le choix le plus judicieux plutôt que de devoir inventer un nouveau langage de balisage et réinventer la roue (pardon, tous les outils pour faire le boulot)
Je crois qu'il y a une confusion parce-que ce n'est pas de l'impératif mais du déclaratif. Comme en SQL où tu indiques dans ton
SELECTquoi requête et où sans te préoccuper de programmer toutes les opérations sous-jacentes, chaque tâche Ansible est un appel de module (dans le jargon —ou le vocabulaire dégueu si ça te fait plaisir) auquel tu indique que tu souhaites par exemple qu'un compte soit présent ou basent sans te préoccuper des opérations relatives auuser(franchement ça fait le boulot beaucoup mieux que lesadduseret compagnie dans tout ce que j'ai pu voir comme script shell, et cerise sur le gâteau : ça s'adapte bien mieux à un parc hétérogène car on n'a pas que des RHEL 8 par exemple.)Maintenant, si tu lui reproche son côté séquentiel (une tâche après l'autre aulieu de vouloir faire de la magie de Poupée) —est-ce de là que vient la confusion avec un langage impératif ?— il se trouve que c'est ce qui fait sa simplicité et sa force : on sait/suit point par point ce qui est fait et n'impose pas de vision (avec bémol car il y a toujours des limites, mais je me casse moins la tête pour y adapter mes idées là où d'autres outils font une forte résistance)
Le côté descriptif vient juste de ce YAML qui t'insupporte, et c'est un bénéfice indéniable car on n'a pas à se farcir une longue documentation à côté (il en faut quand même mais beaucoup moins et du coup on a moins de souci de ce côté là.)
Bah justement, ça ne prétend pas faire de magie ou te faire de gamin dans le dos. Ça ne prétend pas non plus remplacer des fonctionnalités existantes mais veut juste les exploiter proprement et prévisiblement (raison pour laquelle j'ai comparé Ansible à cadriciel) Pour reprendre le cas de la gestion des comptes, ça s'appuie sur les bibliothèques/commandes système qui font le job au lieu de prétendre vouloir réinventer l'eau chaude. La base de la solution veille aussi à réduire les dépendances, donc je suis étonné que tu ais besoin d'installer « souvent pleins de paquets juste pour faire marcher un module » Ceci dit, tu peux écrire tes propres modules facilement ou améliorer ceux existant…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encore de l'Ansible...
Posté par Anonyme . Évalué à 4.
Tu joues sur les mots, mais personnellement je comprends le ressentit de devnewton.
Y a pas de magie dans Puppet, à moins de considérer l’ordonnancement comme de la magie.
Puppet ne fait rien de différent de ce que, par exemple, systemd peut faire au démarrage d’une machine (exécuté les tâche dans l’ordre de leur dépendance).
Parmi les plus répandus (Puppet, Chef et Salt), j’en connais aucun qui réinvente l’eau chaude.
Moi, je ne lui reproche rien, mais je regarde Ansible pour ce qu’il est : un moyen facile d’exécuter des tâches récurrentes. Par contre je ne le considèrerai probablement jamais Ansible comme de l’IaC par exemple et surtout, il me viendrait pas à l’idée de gérer une infrastructure avec, au delà d’un administrateur unique et/ou d’une dizaines serveur (on l’utilise au taf, et je comprends honnêtement pas comment ils en sont arrivé là).
Pour mon usage personnel par exemple (une quinzaine de machines), tout est géré par Puppet et j’utilise Ansible pour des tâches comme la mise à jour de Kubernetes1, mais je pense que quand j’aurai pris le temps d’apprendre Bolt, j’abandonnerai complètement Ansible.
il faut drain le nœud, le mettre à jour, éventuellement le redémarré puis l’uncordon, c’est plus rapide d’écrire un playbook que de le faire à la main. ↩
[^] # Re: Encore de l'Ansible...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
Je n'ai pas encore connu de cas où tu n'es pas obligé de lancer l'agent plusieurs fois pour arriver à l'état souhaité. La raison en est sa tentative d'automagiquement ordonnancer comme tu dis ; du coup il se retrouve à faire les actions dans un ordre qu'on ne sait pas prévoir.
Oui, je sais qu'on peut imposer une sorte de chaîne de dépendance mais il faut s'arracher les cheveux pour arriver à mettre ça en place.
Maintenant ce n'était pas un reproche et je ne faisais que souligner la différence de fonctionnement des deux solutions (et il faut toujours faire des choix en connaissance de cause et ne pas croire qu'il y a du meilleur dans l'absolu car tout a ses avantages et ses inconvénients)
En tout cas systemd a l'air de mieux s'en sortir…
Je peux comprendre : je suis dans un taf où l'infra est géré avec et où c'est pas top.
J'ai aussi connu, paradoxalement, une plus grande infrastructure entièrement pilotée par Ansible et c'était un bonheur. On peut l'utiliser à plusieurs administrateurs sur des centaines d'hôtes ; mais il faut une organisation qui ne s'improvise pas.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encore de l'Ansible...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ils auraient pu prendre un bon langage existant, c'est pas ce qui manque. Même du xml est plus agréable à écrire que du YAML.
Derniers exemples sur lesquels je suis tombé :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Encore de l'Ansible...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Ah ha, tu es l'exception qui confirme la règle car la majorité autour de moi semble trouver plus facile d'écrire du YAML que du XML, et c'est je crois ce constat qui a poussé au choix. Bon, pour mes prochains jours de repos, je vais écrire un convertisseur pour faire des playbooks en XML.
Mouais. Cela rejoins mes remarques du peu de dépendance pour les modules de base (là ce sont des modules communautaires) d'une part et du fait de s'appuyer sur des outils tiers qui font le boulot d'autre part.
Il serait intéressant de voir comment gérer les artéfacts Maven par script sans rien installer… Ce sera une piste pour proposer un module alternatif.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encore de l'Ansible...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ansible est plus proche d'un langage de programmation que d'un simple fichier de configuration, une syntaxe dédiée aurait été plus pertinente.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Encore de l'Ansible...
Posté par ff9097 . Évalué à 0.
Là tu dis vraiment n'importe quoi
[^] # Re: Encore de l'Ansible...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Attention, sa formulation est bien une appréciation personnelle. Et je peux comprendre car je passe beaucoup moins de temps pour pondre un document en XHTML qu'avec un traitement de texte ; l'habitude et la bonne maîtrise de la chose aidant probablement.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encore de l'Ansible...
Posté par Anonyme . Évalué à 2.
Je n’aime pas non plus Ansible techniquement (le code est pas fou, je n’aime pas la philosophie « push » et je préfère le « déclaratif » au « procédural »), mais je veux bien une explication de ce que tu entends par « éthiquement » ?
[^] # Re: Encore de l'Ansible...
Posté par SuperPommeDeTerre . Évalué à 1.
Personnellement, j'ai une préférence pour Salt. Pas pour sa base de code, mais plutôt pour ses principes sous-jacents (notamment le système de bus et d'évènements qui te permette de monter des choses vraiment cool).
Pour l'éthique, c'est juste que Ansible monopolise depuis un moment (et de plus en plus) ce marché. Et depuis le rachat de Redhat, j'ai un peu peur de la suite…
[^] # Re: Encore de l'Ansible...
Posté par remyd1 . Évalué à 2.
La précédente mouture "Banquise" était une version SaltStack; l'auteur avait d'ailleurs fait un billet sur celle-ci à l'époque : https://linuxfr.org/news/outil-de-deploiement-et-de-configuration-d-un-cluster-hpc-ou-d-un-reseau-de-machines-banquise
Je pense que la version Ansible était nécessaire mais pas nécessairement souhaitée.
[^] # Re: Encore de l'Ansible...
Posté par zaft . Évalué à 5.
Oui, remyd1 a raison, la première version de ce projet reposait sur Salt Stack. J'utilise Salt, Puppet et Ansible dans mon emploi, sans réelle préférence. Chacun a ses avantages et inconvénients.
Mais je me suis heurté à deux gros soucis avec la première monture:
La grande majorité des utilisateurs qui avaient testé la stack se heurtaient à la difficulté de Slack. Bien que je trouve Slack puissant et flexible, il semble que cet outils soit plus complexe de premier abord pour des néophytes.
Le support. J'ai tenté plusieurs fois de proposer la stack sur Slack à des professionnels, et à chaque fois le retour était : "Pas de support RedHat, pas intéressant". RedHat est particulièrement bien implanté dans le HPC.
Souhaitant pouvoir faire usage de Banquise dans mon emploi aussi, j'ai donc migré vers Ansible, qui semble plus simple (mais plus limité, on a rien sans rien) et qui bénéficie du support RedHat.
J'ai donc ré-implémenté Banquise, ce qui a donné BlueBanquise. Voilà pour la raison du choix d'Ansible.
Ces outils sont des tentatives de proposer des alternatives aux lourdes stacks existantes dans le monde du HPC. Ce sont (je l'espère, on s'y efforce) des micro stacks, sans surcouches, et très modulaires.
[^] # Re: Encore de l'Ansible...
Posté par remyd1 . Évalué à 2.
s/Slack/SaltStack/g
[^] # Re: Encore de l'Ansible...
Posté par zaft . Évalué à 1.
Oups, merci :)
# ah tien ça fait comme GLPI ?
Posté par BAud (site web personnel) . Évalué à 2.
comment cela se balade via GLPI qui permet le même genre de déploiement (et beaucoup d'autres choses en plus, pas que de la gestion de parc) ?
BlueBanquise gère-t-il une CMDB ?
pourquoi cette orientation affichée pour le hpc ? Je n'ai pas trop compris ce qui y est spécifique (je ne suis pas du domaine, on va dire).
[^] # Re: ah tien ça fait comme GLPI ?
Posté par zaft . Évalué à 2.
J'avoue mal connaître GLPI, impossible de répondre avec certitude.
BlueBanquise ne gère pas de CMDB. C'est a design, et aussi par rejet des databases overkill que l'on croise dans le HPC. L'ensemble des données sont stockées dans l'inventaire Ansible (~= pillars Salt), au format text (YAML). Cela donne des inventaires certes lourds, mais qui ont le mérite de rester éditables par des néophytes.
BlueBanquise me sert aussi de base pour la formation de jeunes admin système. Ils peuvent démanteler les différents roles, et comprendre comment se déploient un DHCP, un DNS, comment fonctionne le PXE, etc. Tout doit donc être "lisible" via un coup de cat/vi. Nous tentons de tout garder au plus simple et de nous conformer aux standards.
Le HPC ressemble un peu au cloud : des centaines de serveurs clones, et surtout des soucis de réseau et de hardware. La particularité va aussi résider dans la présence d'un ordonnanceur (le job scheduler, ici Slurm (Linux mag 185, super article dessus)) qui va dispatcher les "jobs" (des scripts à executer, des programmes à executer, etc) des utilisateurs sur les différentes ressources disponibles et permettre un usage partagé et si possible équitable du calculateur.
[^] # Re: ah tien ça fait comme GLPI ?
Posté par BAud (site web personnel) . Évalué à 3.
ok merci de ta réponse :-)
j'ai un peu la même approche du hpc que toi (= cloud, potentiellement 200 serveurs… donc faut automatiser), ce pour quoi un pilotage par GLPI pourrait être intéressant, autant comparer les 2 solutions.
[^] # Re: ah tien ça fait comme GLPI ?
Posté par zaft . Évalué à 1.
Merci pour le tuyau :-)
Je vais aller regarder du coté de GLPI et fouiller dans leur documentation.
[^] # Re: ah tien ça fait comme GLPI ?
Posté par Anonyme . Évalué à 3.
Si tu regarde à t’interfacer avec une CMDB, tu peux regarder du côté de Netbox également.
[^] # Re: ah tien ça fait comme GLPI ?
Posté par zaft . Évalué à 1.
Merci de l'info ! Je vais regarder du coté de NetBox aussi.
Je me demande par contre comment, sans avoir 2 inventories Ansible empilés, ce qui est faisable mais peu ergonomique, comment mettre des variables à des groupes d'équipements (types) du coté de NetBox.
[^] # Re: ah tien ça fait comme GLPI ?
Posté par actatux . Évalué à 0.
NetBox pourrait répondre à un besoin dont nous discutions récemment. :-)
Je viens de faire un tour sur le site du projet, dans la doc et sur le site de démonstration. Il est possible de définir des Custom Fields par objet, incluant les Device Types. Il est peut-être possible de récupérer ces informations dans les playbooks via le plugin de lookup netbox.netbox.nb_lookup_lookup ?
# pourquoi BlueBanquise ?
Posté par thamieu . Évalué à 4.
De ce que j'ai compris, BlueBanquise n'est jamais qu'un ensemble de rôles et modules pour Ansible, pour le HPC. Du coup je me demande pourquoi ce nom, ce logo et ce site web ? J'ai l'impression qu'une couche de marketing-bullshist a été rajoutée sur une solution technique qui n'en avait pas besoin.
Techniquement l'approche me paraît bien, ça s'intègre à ansible, et c'est pas une surcouche propriétaire à la mords-moi-le-nœud qui casse tous les outils sur lesquels elle s'appuie (j'ai bossé pour une fameuse entreprise française qui pour son HPC prenait soin de faire des surcouches à Yum et Puppet pour rendre le truc moins efficace et déposer du brevet).
Sinon, je trouve dommage l'approche documentée consistant à installer le premier nœud de management « à la main », pour ensuite déployer le cluster depuis celui-ci. Avez-vous envisagé déployer ce premier nœud via Ansible aussi ?
[^] # Re: pourquoi BlueBanquise ?
Posté par zaft . Évalué à 3.
Oui, c'est un ensemble cohérent de roles Ansible. On peut donc y brancher d'autres roles ou modifier les existants.
Le nom, le site web, et le logo… Fantaisie de concepteur, par "amour" pour sa création, rien de plus.
Il y a comme premier objectif derrière cette stack le besoin de faire tourner le calculateur d'un FabLab en Bretagne, surtout pas d'en faire du business. Donc si le site fait bullshit marketing, alors le coup est raté et je dois le reprendre. Des suggestions ?
Le concept est effectivement de ne pas faire de surcouche, pour permettre d'utiliser les documentations en ligne, ou trouver facilement sur le web en cas de bug / soucis / besoin de développement. Et aussi pour des raisons de maintenance : surcouche = besoin de maintenance à chaque mise à jours des outils sous la surcouche.
Concernant le déploiement du premier noeud, il faut déposer les répos "vitaux" (OS + BlueBanquise), les configurer en mode file:///, et monter l'interface réseau principale afin que Ansible puisse ssh vers la bonne ip. Ensuite, tout se fait via Ansible.
Donc étape 1, effectivement manuelle: https://bluebanquise.com/documentation/install_first_management.html
Puis étape 2, cette fois via Ansible: https://bluebanquise.com/documentation/deploy_bluebanquise.html#management-configuration
Tu suggérerais de remplacer aussi l'étape 1 par un bootstrap via Ansible ?
[^] # Re: pourquoi BlueBanquise ?
Posté par BAud (site web personnel) . Évalué à 2.
Lannion ? Brest ?
pour l'instant je reste à St Quay en télétravail ;-)
[^] # Re: pourquoi BlueBanquise ?
Posté par zaft . Évalué à 3.
A Auray :-)
On tente une approche différente : en tant que FabLab, on ne croule pas sous l'or, donc on a pris le parti de recycler des calculateurs usagés, souvent retirés de production faute de maintenance / support.
Nous leur donnons une seconde vie en mode "on fait ce qu'on peut", et partant du principe que lorsqu'un serveur tombe en panne, il devient pièces détachées pour les autres. La machine sert aussi à chauffer nos locaux.
Pour notre premier calculateur, le CINES de Montpellier nous a fait don d’une machine en Sandy Bridge (si vous lisez ceci, merci encore !!!!). Ce n’est pas de toute jeunesse, mais largement suffisant comme calculateur d’échelle locale.
La machine a vocation à être accessible aux universités, aux PME, et aux autres FabLabs. Pour le moment, elle a surtout fait du rendu Blender et des calculs durant le confinement (https://www.ouest-france.fr/sante/virus/coronavirus/algoric-un-supercalculateur-breton-contre-le-covid-19-6811820), mais on monte en charge. L'idée est aussi de former au calcul parallèle et à l’administration système Linux de base.
[^] # Re: pourquoi BlueBanquise ?
Posté par thamieu . Évalué à 4.
Si j'avais eu ce genre de truc à l'époque où je déployais des (tout petits) clusters HPC, ça m'aurait épargné les procédures de 400 pages qui permettaient même pas d'aboutir =D
Ha ben non, si c'est l'âme de poète qui parle faut laisser. Ce qui me fait user de ces mots sévères, c'est :
- la présentation sur le site web semble attribuer des qualités (la modularité, la flexibilité) à BlueBanquise, alors qu'elles me semblent plutôt inhérentes à ansible.
- le fait que ça me fait penser à la tendance qu'on observe par exemple en sécurité, où dès qu'une faille est trouvée, on y consacre un nom de domaine, un site web et un logo…
Présenter explicitement BlueBanquise comme une collection pour Ansible, et publier cette collection1 sur ansible-galaxy. En recherchant viteuf y a quelques roles slurm qui remontent, mais pas de collection complète hpc, donc il se pourrait que blue banquise trouve des adoptants via ce canal.
Oui, je me dis que l'admin devrait pouvoir déployer l'intégralité du cluster depuis son PC :
- si le pc n'est pas sous linux, on peut y palier par exemple en installant des sous-systèmes comme ubuntu
- installer ansible et git sur le poste de l'admin
- récupérer le(s) dépôt(s) git blue banquise
- lancer un playbook pour mettre en place toutes les ressources nécessaires et déployer le premier nœud
[^] # Re: pourquoi BlueBanquise ?
Posté par actatux . Évalué à 3.
Salut,
C'est quelque chose que j'ai en tête depuis un moment, mais il y a pas mal de travail à faire pour ça. Pour le moment on en est encore à implémenter les tests de CI manquants. (j'aide zaft sur ce projet)
J'aime beaucoup ce cas d'usage. Dans les idées d'évolution que j'ai pour ce projet, il y a la possibilité d'utiliser un nœud quelconque de la grappe comme serveur d'installation (bootstrap server) qui installera le premier nœud de gestion, l'idée étant d'avoir une installation complète par la pile logicielle, plutôt qu'un premier nœud déployé manuellement avec des modifications non suivies. (ce nœud qu'on n'ose jamais redéployer par la suite…)
J'ai comme l'impression qu'on a été collègues à une époque. :-)
[^] # Re: pourquoi BlueBanquise ?
Posté par zaft . Évalué à 2.
Merci beaucoup !
Je vais reprendre le site web avec ces commentaires. Effectivement, après relecture, le site n'est pas assez précis sur ces points, et sur l'aspect collection de roles Ansible.
Et puis je venais de découvrir le framework css Bulma au moment de coder ce site, et je me suis un peu lâché…
Idem ici, on est tous passé par là j'ai l'impression ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.