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

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
11
6
jan.
2017

En suite à :
http://linuxfr.org/forums/linux-general/posts/deploiement-et-maintenance-de-parc-via-bittorrent

Bonjour,

De l'eau a coulé sous les ponts et je suis arrivé à mes fins !
Cela fait maintenant quelques mois que j'ai une solution de déploiement system basé sur Murder.

Les performances sont impressionnantes, 18G compréssé à 4,5G en xz -9e, deployés sur ~800 machines en 45 minutes, décompression comprise.

Le relais est ensuite passé à Ansible que j'utilise en mode pull, avec un service qui le lance au démarrage de la machine.

J'aimerais bien partager tout ca mais il y a … un mais.
Tout est exclusivement "développé" en une somme de scripts bash sur mesure (table de partition, montages, partitions à restaurer, outils de compression, etc…).

Je voudrais rendre le tout dynamique et distribuable, mais je peste contre le fonctionnement de Clonezilla et ses menus dialog. Je préférerais un fonctionnement plus déclaratif, ou l'on construirait des playbooks de creation d'image, ou de déploiement, à la ansible, modulable.

Example de "playbook" de creation d'image

package :
  _nom_package_
partition_table :
  dump
savefs :
  sda2, xz, default
  sda3, xz, default
  sda5, gzip, extra
bittorrent :
  create_file, default
  create_file, extra

Example "playbook" de restauration

package :
  _nom_package_
partition_table :
  restore
erase : 
  sda2
  sda3
bittorrent :
  peer, default
  peer, extra
restfs :
  sda2
  sda3
  sda5
shell : rm somedir/somefile
bootloader :
  grub

savefs et restfs passant le relais à fsarchiver
partition_table à sfdisk
bittorrent à murder

Codé en python, en laissant la possibilité de creer de nouveaux modules pour des besoins particuliers ou d'utiliser les modules ansible.

Bref, ca c'est l'idée, ya du boulot, j'y réfléchis, je peaufine, ca pourrait le faire.

Mais avant je voudrais qu'on m'ôte d'un doute.
Ca fait quelques années que j'explore tout l'internet à la recherche de la solution de déploiement miracle. J'en ai testé un bon paquet, et la seule qui retenait mon attention a été SystemImager.

Je suis étonné de ne trouvé aucune projet sérieux pour un besoin si élémentaire, SystemImager étant tombé en désuétude, y aurait-il un successeur ?

  • # Merci

    Posté par  (site web personnel) . Évalué à 2.

    Merci d'avoir pris le temps de nous faire un retour !

  • # le tiens !

    Posté par  . Évalué à 3. Dernière modification le 06 janvier 2017 à 14:51.

    salut

    pas a ma connaissance, probablement des outils interne chez les gafa.

    après tu fais une startup ou tu place tout en GPL ? que pense ton employeur qui possède la propriété sur ton code ?

    :), après le développement fun, la partie juridique toujours aussi glamour …

  • # Fonctionnement ?

    Posté par  . Évalué à 0.

    Salut,

    Peux-tu détailler un peu le fonctionnement stp ?

    Tes machines bootent sur le réseau via une mini distrib qui lance un démon murder pour ensuite télécharger et appliquer l'image ? Comment cela se passe-t-il exactement ?

    Merci d'avance ;)

    • [^] # Re: Fonctionnement ?

      Posté par  (site web personnel) . Évalué à 2.

      Grossièrement :

      Je lance le tracker de murder sur mon serveur.

      Sur une machine source, je crée un archive tar.xz contenant tout le système, je dump la table de partition avec sfdisk, puis le fichier .torrent associé à l'archive est généré, stocké via NFS.

      J'ai un serveur PXE avec un nfsroot (debootstrap de debian 8)
      Un script me permet de creer les fichiers de boot pxe par machine, s'appuyant sur mon fichier hosts d'ansible, je peux donc pointer des groupes de machine facilement.

      Le fichier de boot pxe generé, passe en paramètre du kernel le nom de l'image à déployer, et d'autres variables.

      Quand la machine cliente boot pxe, un service parse les options du kernel, puis un autre lance le script de déploiement sur tty1.

      Le script restore le dump de la table de partition, monte les partitions locales, formate proprement tout ca, lance un client bittorrent pour récupérer l'archive, décompresse où il faut, puis réinstalle le bootloader.
      Un webservice sur le serveur attend une requête du client lui disant qu'il a terminé le déploiement, pour pouvoir supprimer son fichier de boot pxe.

      • [^] # Re: Fonctionnement ?

        Posté par  . Évalué à 0.

        Merci pour les explications.

        A la fin, une fois que le client est installé, j'imagine qu'il garde aussi l'image en stock afin de lui même la distribuer aux autres PC ?

        • [^] # Re: Fonctionnement ?

          Posté par  (site web personnel) . Évalué à 1.

          Non.

          1° parce que d'après mes tests, pour 800 machines à 1Gbps, les performances sont optimales à partir de 6 primo-seeders (seeders qui ont toutes les parts du fichier). Ca ne sert donc à rien d’encombrer le réseau avec 800 seeders qui parlent sans cesse avec le tracker.

          2° parce que si je déploie une nouvelle image, je dois la déployer partout, en une fois, donc les seeders en question devront eux aussi rebooter pour se redeployer = les primo-seeders doivent être des serveurs à part.

          • [^] # Re: Fonctionnement ?

            Posté par  . Évalué à 0.

            Ah mince… ça perd son charme au final. Je pensais que chaque PC était capable d'aider son voisin…

            • [^] # Re: Fonctionnement ?

              Posté par  (site web personnel) . Évalué à 1. Dernière modification le 08 janvier 2017 à 23:17.

              Les machines s’échangent des parts entre elles pendant qu'elles téléchargent d'autres parts. Comme les machines doivent continuer leur processus de déploiement, il ne sert à rien qu'elles continuent d’émettre après avoir récupérer l’intégralité de l'archive… si ce n'est, perdre du temps.

              En ce qui concerne le nombre de primo seeder, c'est un prérequis au fonctionnement optimal du système, n'as tu jamais vu de torrent avec 10000 peers bloqués à 98% ?
              Bien que tous les clients discutent entre eux, le processus global est limité par la vitesse d’émission du primo-seeder, d'où la nécessité de multiplier les seeds possédant toutes les parts du fichier pour "ouvrir les robinets au maximum".

      • [^] # Re: Fonctionnement ?

        Posté par  . Évalué à 2.

        Très sympa ton projet.
        Continue à nous tenir au courant je testerai avec plaisir ;)
        Petite question comment ton script gère le formatage des partitions pour être sûr de taper sur la bonne et les différentes tailles de disque des machines du parc ?

        • [^] # Re: Fonctionnement ?

          Posté par  (site web personnel) . Évalué à 1.

          Quand je parle de formatage, je parle de monter la partition et de rm -Rf *
          mkfs ne supprime pas les données, et restaurer une table de partition par dessus une ancienne identique revient à ne rien faire.

          • [^] # Re: Fonctionnement ?

            Posté par  . Évalué à 2. Dernière modification le 08 janvier 2017 à 17:06.

            Oui en effet peu importe la méthode. Je comprends que cela règle la problématique des tailles de disques différentes, la table des partitions n'étant pas modifiée.
            La question portait surtout sur la façon dont le script cible la bonne partition avant de lancer l'opération. Si sur une première machine sdx1 est la partition /boot et sur une autre le / par exemple.

            • [^] # Re: Fonctionnement ?

              Posté par  . Évalué à 0.

              D'après ce que j'ai compris la table de partition sera toujours la même, car si elle est différente elle sera écrasée par la nouvelle, donc plus de problème de savoir quelle partition fait quoi.

              • [^] # Re: Fonctionnement ?

                Posté par  (site web personnel) . Évalué à 1.

                Tout est exclusivement "développé" en une somme de scripts bash sur mesure (table de partition, montages, partitions à restaurer, outils de compression, etc…).

                Je voulais dire par là que ce n'est pas encore dynamique, pour le moment, j'indique les partitions à traiter en dur dans le fichier. Par la suite ce sera via le fichier de configuration en yaml que j'ai mis dans mon premier post

          • [^] # Re: Fonctionnement ?

            Posté par  . Évalué à 2.

            Quand je parle de formatage, je parle de monter la partition et de rm -Rf *

            C'est plus lent que mkfs, sauf s'il y a peu de fichiers.
            mkfs assure que la structure de la partition est bien propre.

            mkfs ne supprime pas les données

            ?!
            Tu peux détailler ? :-)

Suivre le flux des commentaires

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