Forum Linux.général Deploiement et maintenance de parc via bittorrent

Posté par (page perso) . Licence CC by-sa
2
27
jan.
2016

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 :

Graphique torrent

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.

Algo

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 . É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 . É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 (page perso) . Évalué à 2. Dernière modification le 28/01/16 à 08:17.

      • Si j'ai bien compris, Puppet / chef /ansible etc necessitent de scripter l'installation de la machine depuis une installation nu, charge de travail (l'image contient enormement de logiciels/configurations) inutile si on raisonne au niveau fichier.
      • Avec une synchronisation au niveau fichier, impossibilité qu'une "recette" plante.

      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 . Évalué à 2.

        Pour LTSP, imagines le serveur qu'il faut pour pouvoir deservir 800 machines.

        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 (page perso) . Évalué à 1. Dernière modification le 28/01/16 à 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 . É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 (page perso) . Évalué à 0. Dernière modification le 28/01/16 à 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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 1. Dernière modification le 28/01/16 à 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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . Évalué à 2.

                Utilise l'option debug, ça aide souvent.

                Système - Réseau - Sécurité Open Source

              • [^] # Re: apt et xget

                Posté par . Évalué à 2.

                Sur une même machine :
                ./xget ./test
                puis
                ./xget -n 127.0.0.1 . ./dest
                j'obtiens
                Could not connect to server

                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 (page perso) . É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 . É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 ?

  • # Bokor

    Posté par (page perso) . É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 (page perso) . Évalué à 3.

      Super ca, je regarde, merci !

      https://github.com/bearstech/bokor

      • [^] # Re: Bokor

        Posté par (page perso) . Évalué à 1.

        Salut,

        Le site de bokor : bokor.io

        --
        Zitune

        • [^] # Re: Bokor

          Posté par (page perso) . Évalué à 1.

          Je regarde la conf, ca a l'air d'être parfaitement ce que je recherche.

        • [^] # Re: Bokor

          Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . Évalué à 1. Dernière modification le 28/01/16 à 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 . Évalué à 3.

                      c'est pas ce que fait un installer de base ?

                      format partition
                      mount partition /target
                      tar zxvf image.tgz -C /target
                      mount /dev /target/dev
                      mount /otherdir /target/otherdir
                      chroot /target
                      script modifiant les trucs specifiques à cette machine
                      grub --install /dev/ledisque
                      exit
                      reboot
                      • [^] # Re: Bokor

                        Posté par (page perso) . Évalué à 1. Dernière modification le 28/01/16 à 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 . Évalué à 2. Dernière modification le 28/01/16 à 22:21.

                          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.

                          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

                          format partition
                          mount partition /target
                          tar zxvf image.tgz -C /target
                          mount /dev /target/dev
                          mount /otherdir /target/otherdir
                          chroot /target
                          grub --install /dev/ledisque

                          rsync --delete -aP /mnt/lasource-sur-le-reseau/* /target
                          script modifiant les trucs specifiques à cette machine
                          exit
                          reboot

                          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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 . Évalué à 2.

                                    En quoi ce ne serait pas le cas dans le fonctionnement que je decris ?

                                    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 . É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 (page perso) . É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 . Évalué à 1.

  • # m23 ?

    Posté par . É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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.