Bonjour,
J'ai en gestion 800 postes clients sous Ubuntu, j'ai dans l'idée depuis quelques temps de concevoir un systeme de deploiement/maintenance des machines basé sur bittorrent.
Je lance la discussion pour voir si l'on pourrait me conseiller des outils ou me prevenir de problème que je pourrais rencontrer.
Selon moi, le système idéal permettrait de :
- Redescendre quasi aussi rapidement un poste que le parc complet.
- Permettre à l’utilisateur de redéployer complètement son poste lui même en cas de pb. (via boot PXE)
- Que le système redéployé soit automatiquement et systématiquement le dernier à l’image d'un poster maître.
- Qu’une machine n'étant pas en état de recevoir l’instruction de redéploiement le face au prochain redémarrage ou démarrage.
- Que les machines se synchronise à chaque demarrage (créé un service)
- Prendre en charge une machine neuve avec un premier deploiement ou donc pouvoir pusher à chaud les modifications d'un poste master à une machine up.
- Comme il s'agit d'un outils qui serait utilisé dans une université, pouvoir gerer des salles indépendamment les unes des autres (plusieurs tracker en indiquant aux clients d'une même salle sur lequel prendre les données)
Voila le fonctionnement que j'imagine :
Et ici l'algo (deja en place avec une solution unicast de deploiement Clonezilla) pour ne pouvoir geré les deploiements sans intervention sur la machine.
J'ai deja posé la question sur syncthing qui semblait être un outils interressant, mais l'idée à vite capoté : https://forum.syncthing.net/t/sync-800-computers/6629
Reste bittorrent-sync, mais le côté fermé me rebute. J'ai pas encore regardé ce qu'il etait possible de faire avec un tracker classique.
Voila, dites moi si l'idée vous semble bonne, realisable ou si vous avez des conseils ou autre.
Bonne soirée.
# en quoi ce serait mieux
Posté par NeoX . Évalué à 2.
en quoi ce serait mieux qu'une solution reinstall automatique (kickstart pour centos/redhat, preseed pour debian) +puppet/chef/cfengine pour les paquets maisons ?
voir simplement un OS chargé via PXE puis executer en local comme avec AbulEdu/LTSP
[^] # Re: en quoi ce serait mieux
Posté par ptit_poulet . Évalué à 1.
Pareil j'allais te proposer LTSP. Tu vas pouvoir gérer plusieurs "images" en fonction de tes salles et/ou machines.
Pour déployer un package rien de plus simple tu mets à jour l'image et le client l'obtient en live.
Rien d'installer sur les postes, sécurité accrue, faciliter de maintenance.
Par contre faut que tu es un bon voir plusieurs serveurs et surtout un bon réseau.
[^] # Re: en quoi ce serait mieux
Posté par eoli3n (site web personnel) . Évalué à 2. Dernière modification le 28 janvier 2016 à 08:17.
Pour LTSP, imagines le serveur qu'il faut pour pouvoir deservir 800 machines.
Je vais quand même explorer cette solution mais je parle ici de "déploiement".
[^] # Re: en quoi ce serait mieux
Posté par NeoX . Évalué à 2.
LTSP ne fait que des terminaux graphiques (client normal)
il peut aussi lancés les OS au travers du reseaux, mais ils sont executés localement (fat client)
[^] # Re: en quoi ce serait mieux
Posté par eoli3n (site web personnel) . Évalué à 1. Dernière modification le 28 janvier 2016 à 09:06.
La partition linux fait 30Go dont 20 d'utilisé. Même si elle est compressée (pour exemple clonezilla compressse l'image pour un fichier de 6Go), ca fait quand même bien lourd à demarrer. Pas une bonne solution.
Et imagines une coupure de courant, tous les postes se relancent d'un coup, ne serait-ce que toute une salle :
6Go x 24 postes, moi qui voulait economiser de la bande passante, pas top
[^] # Re: en quoi ce serait mieux
Posté par NeoX . Évalué à 2.
parce qu'avec ton "deploiement" en bittorrent tu economises ta bande passante ?
ton torrent il est sur le serveur central
les autres machines n'ont pas encore le torrent,
elles vont donc toutes aller chercher le torrent sur le serveur central.
et les machines une fois installées, contiennent aussi le media d'installation ? pour pouvoir fournir le torrent aux machines qui redemarrent ?
[^] # Re: en quoi ce serait mieux
Posté par eoli3n (site web personnel) . Évalué à 0. Dernière modification le 28 janvier 2016 à 09:31.
Je voudrais un fonctionnement torrent type Rsync, comme le font Syncthing ou Bittorrent-sync, et à ce compte là, je deploie que le diff, et pas tout le systeme. (voir mon shema plus haut, et les lignes "paquets X Y Z")
Et donc oui parce que les machines ne chargent pas TOUT le systeme à chaque démarrage. Juste le diff (3mo par exemple pour un paquet quelconque), et juste une fois (la synchro suivante après l'installation sur le poste master).
De toute facon, je n'ai pas l'infra pour faire en sorte d'offrir une qualité de service satisfaisante avec un LTSP.
Je vais explorer cette piste là, ca devrait t'en dire plus sur ce que je vise :
Murder, outils utilisé par twitter : https://vimeo.com/11280885
# apt et xget
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Il y a eu un début de version apt avec prise en charge du pair à pair. Si stagiaire ou ressource dev, ce pourrait être sympa de finaliser ?
Sinon, cela fait pas mal de temps que je me dis que je devrais tester xget même si c'est mort…
https://www.researchgate.net/publication/253121932_XGet_a_highly_scalable_and_efficient_file_transfer_tool_for_clusters
On le trouve dans le projet xcpu (http://xcpu.sourceforge.net/) : http://sourceforge.net/projects/xget/
[^] # Re: apt et xget
Posté par eoli3n (site web personnel) . Évalué à 2.
Pour apt, on utilise un proxy qui cache les paquets, donc bon au final.
Mais je veux bien un lien de ce dont tu parles.
Xget oui je suis tombé dessus, c'est une des pistes que j'ai à explorer, mais je crois qu'il n'y a quasi pas de documentation et qu'on sait pas trop comment ca tourne derrière.
[^] # Re: apt et xget
Posté par eoli3n (site web personnel) . Évalué à 1. Dernière modification le 28 janvier 2016 à 22:39.
Ah ben elle y est la doc là. A voir si je ne m'en sors pas avec bokor, ou s'il y a trop à adapter.
Parce qu'en soit si xget permet de diffuser de pair à pair un dossier sans tracker ni client autre que lui même, ca pourrait etre la soluce bien plus simple, je remplace juste mon rsync par xget et zou
"The Bittorrent protocol was created for the purpose of
transferring multi-media files over the Internet. Due to
its scalable properties, it is also being used for trans-
ferring files over LANs. Bittorrent and XGet are quite
similar; they both create a peer-to-peer network and
generate an ad-hoc tree. Bittorrent usually requires at
least three items in order to transfer files: a torrent file,
the tracker, and the client. To use Bittorrent, one needs
to first create a metainfo file (or .torrent file) that in-
cludes: the tracker’s URL, file size, suggested file name,
and other data about the file(s) being shared [16]. Next,
a tracker needs to be started before any of the clients
can begin transferring data. The tracker is a lightweight
server that provides routing information to each of the
clients in the network. After the tracker is running, a
client with a completed version of the file(s) being served
needs to start. This client then “seeds” the file(s) for
the other clients. Once other clients have started, they
connect to the tracker, which redirects them to the ap-
propriate client to download from. The main differences
between Bittorrent and XGet are: XGet does not require
clients to load small files informing them of the files be-
ing transferred, and Bittorrent clients receive portions
of files from many clients, rather than being assigned to
a single secondary server as in XGet."
Ca me semble même plus adapté que bittorrent… je test ca demain
[^] # Re: apt et xget
Posté par eoli3n (site web personnel) . Évalué à 1.
Premiers tests pas concluants du tout.
Pas de problème à la compilation, il me manquait juste libelf-dev.
Sur une même machine :
./xget ./test
puis
./xget -n 127.0.0.1 . ./dest
j'obtiens
Could not connect to server
Je me suis dis, sait on jamais qu'une machine ne pouvait pas être master et cliente.
Même manip sur 2 machines differentes sur un même réseau local, ni pare feu ni rien, pareil :/
[^] # Re: apt et xget
Posté par NeoX . Évalué à 1.
tu as installé le client xget
mais il doit te falloir un serveur qui repondra aux demandes des autres machines.
il est peut-etre compilé en meme temps, mais ne serait pas lancé.
[^] # Re: apt et xget
Posté par eoli3n (site web personnel) . Évalué à 1.
Quand on lance le binaire xget sans options :
root@xub64:~/xcpu/xcpu-1.2.3/xget# ./xget
usage as the master server: ./xget [-D debuglevel] [-p port] [-o] [-x] [-m] file|directory
usage as a client : ./xget [-D debuglevel] [-p port] <-n netaddr> [-s] [-o] [src file | src dir] … dest
Donc non.
[^] # Re: apt et xget
Posté par nono14 (site web personnel) . Évalué à 2.
Utilise l'option debug, ça aide souvent.
Système - Réseau - Sécurité Open Source
[^] # Re: apt et xget
Posté par NeoX . Évalué à 2.
mais tu lances l'un, puis l'autre ou le premier dans un terminal, que tu laisses tourner, puis le 2e dans un autre terminal ?
[^] # Re: apt et xget
Posté par eoli3n (site web personnel) . Évalué à 1.
J'apprecie l'intention, mais si tu voulais vraiment m'aider, tu testerais de ton côté pour valider le fonctionnement, et tu me dirais comment tu as fais ?
[^] # Re: apt et xget
Posté par NeoX . Évalué à 2.
en meme temps, quand j'essaie de telecharger xget en suivant les liens precedents,
le seul truc qu'on trouve c'est un liveCD vieux de 7 ans
et des liens vers un xget_tk datant des années 2000.
tu as essayé comment sur ta distrib ?
à partir de l'ISO ?
[^] # Re: apt et xget
Posté par eoli3n (site web personnel) . Évalué à 1.
http://sourceforge.net/projects/xcpu/files/XCPU/1.2.3/
le tar est là
Installation
Extract the XCPU tarball and use the target xget for make to build and install xget.
make xget
# Bokor
Posté par chimrod (site web personnel) . Évalué à 4.
Il y avait une présentation de bokor à Pas Sage en Seine 2015, pour télédistribuer un système et le contrôler par bittorent.
Par contre j'ai recherché les sources vite fait et n'ai pas pu les retrouver.
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 3.
Super ca, je regarde, merci !
https://github.com/bearstech/bokor
[^] # Re: Bokor
Posté par Zitune (site web personnel) . Évalué à 1.
Salut,
Le site de bokor : bokor.io
--
Zitune
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1.
Je regarde la conf, ca a l'air d'être parfaitement ce que je recherche.
[^] # Re: Bokor
Posté par chimrod (site web personnel) . Évalué à 2.
Merci, j'avais écrit le commentaire rapidement et rechercher « bokor » sur ddg n'avait pas donné de lien concret…
Puisque tu es dans la discussion, est-ce que tu penses que bokor peut être étendu pour déployer des systèmes ?
[^] # Re: Bokor
Posté par Zitune (site web personnel) . Évalué à 1.
Rapidement : Oui, Bokor peut être utilisé pour cela, mais …
En plus long :
Bokor est principalement un système RPC optimiser pour l'ajout de feature, où un master centralise les ordres pour les slaves.
On peut donc globalement rajouter les ordres qu'on veut, y compris des opérations systèmes.
C'est donc faisable, mais sans besoin spécifique c'est peut être un peu puissant pour faire des choses que des outils dédiés ferraient bien.
Evidemment si la problématique de déploiement comprends des gros fichiers à transmettre via bittorrent, et sachant que tout ce qu'il faut pour fournir une gestion fine d'arborescence est déjà présent (en plus de la gestion des transferts de fichiers), alors dans ce cas, oui Bokor est une bonne solution.
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1.
Dans la conf, tu dis que deployer des petits fichiers par bittorrent a un gros cout en ressource, le problème c'est qu'un systeme complet n'est composé quasiment que de ca.
[^] # Re: Bokor
Posté par ptit_poulet . Évalué à 1.
Au pire tu peux toujours déployer une archive contenant tous ces petits fichiers. Et puis sur chaque client un script décompresse l'archive une fois celle-ci reçue.
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1.
Ben le problème c'est que j'ai pour le moment 10Go de libre, mais ca risque d'evoluer, j'aimerais eviter de passer par une archive ou un dossier temporaire.
Après ca risque d'être chiant si j'utilise pas l'un de ces 2 fonctionnements.
Bittorrent ne gère pas les droits, donc si je mets à jour une machine à chaud, il faudrait repasser un script pour restaurer les droits. J'risque figer la machine si j'ecrase directement les fichiers existants via bitorrent, qui n'auront temporairement pas de droits… avant même de pouvoir lancer le script.
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1. Dernière modification le 28 janvier 2016 à 20:59.
root@xub64:/tmp# tar zcvf image.tar.gz / --exclude='/dev' --exclude='/proc' --exclude='/sys' --exclude='/tmp' --exclude='/run' --exclude='/mnt' --exclude='/media' --exclude='/lost+found' --exclude='/net' --exclude='/usr' --exclude='/auto_home' --exclude='/cdrom'
root@xub64:/tmp# du -hs image.tar.gz
2,5G image.tar.gz
ah ! Plus de 50% moins lourd que l'archive clonezilla, je test une decompression sur / d'une autre machine à chaud demain ! (j'exclude /usr et /net parce qu'ils ont une particularité sur notre systeme)
[^] # Re: Bokor
Posté par NeoX . Évalué à 3.
c'est pas ce que fait un installer de base ?
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1. Dernière modification le 28 janvier 2016 à 22:05.
Si, c'est ce que j'ai indiqué dans le schema de mon premier post.
Mais il serait plus flexible de pouvoir se passer d'une archive ou d'un dossier temporaire, depouvoir ecraser directement les données modifiés à la facon d'un rsync. Je ne pense pas que ce sera gerable ici, à voir.
Ici l'interêt serait de pouvoir detaré à chaud sur une machine en utilisation, c'est de ca dont je suis moins sûr.
[^] # Re: Bokor
Posté par NeoX . Évalué à 2. Dernière modification le 28 janvier 2016 à 22:21.
ben c'est facile, à chaud ca va etre dur, car il y a des programmes en cours d'utilisation, etc,
mais à froid (lors du reboot du matin) tu fais comme l'installeur avec une variante
on n'est toujours pas en peer2peer, mais ca limite la bande passante.
et ca suppose que tu ais :
- soit 800 machines identiques
- soit autant de master que de "salle info"
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1.
C'est ca l'idée, mais pour le côté à chaud, j'y crois. Si des binaires sont en cours d'execution, ils sont chargés en memoire, c'est ce qu'il se passe quand tu mets un paquet en cours d'utilisation à jour donc pas de soucis à priori.
Et pour le reste oui c'est ca, c'est d'ailleurs deja en prod avec le rsync pour la simple synchro des machines, c'est comme ca que je deploie des confs et des applis, bien que je ne rsync pas l'integralité de l'arborescence.
Et 800 rsync sur une même source, comparé à bittorrent, tu vois quoi ;)
[^] # Re: Bokor
Posté par NeoX . Évalué à 2.
le principe de bittorent, c'est que tu partes d'une source (le seed original)
qui sera ensuite proposée par ceux qui l'ont deja
pour pouvoir ensuite la fournir à d'autres clients. c'est le concept meme de peer2peer (les clients entre eux)
cela suppose donc que tes machines vont recevoir la mise à jour, et devenir source pour les machines qui vont demarrer plus tard.
cela impose donc que les machines du premier lot contiennent aussi le master pour les machines similaires du second lot…
mais à contrario, je ne vois pas pourquoi cfengine/puppet/capistrano, etc ne serait pas suffisant.
tu prepares des recettes (par logiciel, par type de machine)
pas besoin d'avoir un masterA complet, juste une base en installation automatique, puis plein de recettes pour installer, configurer des programmes, maintenir à jour qui feront de la machine, la machine A (conforme au masterA)
et avec d'autres combinaisons de recettes, ca fera la machine B (conforme au master B)
l'avantage de ces outils, c'est que ca te permet aussi de voir si une machine est "conforme" à tes recettes ou si l'utilisateur a fait des modifications de son coté…
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1.
Je ne vais pas recetter l'installation de 500 paquets et plein de confs tordus, quand je peux synchroniser niveau fichier. Et j'ai une image unique sur les 800 postes de configs materielles differentes, donc pas de soucis à ce niveau là.
[^] # Re: Bokor
Posté par eoli3n (site web personnel) . Évalué à 1.
"cela suppose donc que tes machines vont recevoir la mise à jour, et devenir source pour les machines qui vont demarrer plus tard.
cela impose donc que les machines du premier lot contiennent aussi le master pour les machines similaires du second lot…"
En quoi ce ne serait pas le cas dans le fonctionnement que je decris ?
[^] # Re: Bokor
Posté par NeoX . Évalué à 2.
je ne dis pas le contraire,
juste que je ne vois pas en quoi bittorrent va t'aider puisqu'au premier demarrage, disons le lundi matin, personne n'a le master à jour du WE.
donc tout le monde va prendre les données sur le seul seed (le serveur) => meme probleme de goulot d'etranglement que d'autres solutions.
et personne ne sera serveur tant que l'installation ne soit terminée
mais une fois l'installation terminée, ben il n'y a plus besoin de synchronisation.
les recettes ?
si tu ne fais rien de bizarre, c'est souvent juste un apt-get update, un yum update, un eventuel rsync de quelques fichiers vraiment speciaux
# FOGProject
Posté par ptit_poulet . Évalué à 1.
Regarde du côté de FOGProject il est question de déploiement unicast, multicast et torrent (mais pas encore fonctionnel). Mais essaye de fouiller un peu leur forum, peut-être que cette feature va vite arriver en production. Sinon ça fait tout le reste des fonctions que tu demandes ;)
[^] # Re: FOGProject
Posté par eoli3n (site web personnel) . Évalué à 1.
Aux dernieres nouvelles FOG etait axé Windows, gestion de Linux en beta seulement.
Et puis ca repond uniquement à la problématique de deploiement complet, pas de la maj de l'arborescence via un master.
Mais merci ;)
# Bokor ?
Posté par romain11 . Évalué à 1.
http://bokor.io/
[^] # Re: Bokor ?
Posté par eoli3n (site web personnel) . Évalué à 1.
On en parle juste un peu au dessus ;)
# m23 ?
Posté par ptit_poulet . Évalué à 1.
En faisant des recherches je suis tombé sur m23.
Ça fait tout ce que tu demandes, avec en plus le déploiement de packages, confs possible via bittorrent.
[^] # Re: m23 ?
Posté par eoli3n (site web personnel) . Évalué à 1.
Merci ! Je regarde
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.