Journal Mise à jour de programmes

Posté par  .
Étiquettes : aucune
0
16
fév.
2005
Bonjour,

Tout d'abord, je poste ici parce que quand je poste dans les forums, personne ne me répond....

J'ai un problème de mise à jour de logiciels sur un grand nombre de serveurs. Je package les soft avec rpm et je les balance sur mes serveurs.

Le problème survient quand je dois mettre à jour un programme. Quelques fois, il n'y a qu'un seul fichier à redéployer et le package fait plus d'une centaine de Mo. Mis à part le fait que la liaison est une liaison WAN, je trouve ça débile de déployer 100Mo quant je veux juste modifier un petit txt.

Je peux bien sûr faire un patch en shell, mais dans ce cas, les versions des packages dans la base RPM ne correspondent plus ! Y a-t-il un moyen de hacker la base RPM pour lui upgrader manuellement sa version ?

Ce que j'aimerais avoir c'est un package A et un package A-patch qui soient équivalent au niveau de la base RPM. Je pense que ce problème a déjà du arriver à d'autres personnes mais je ne sais pas si ceux là ont trouvé des solutions.

De manière plus générale maintenant, comment maintenez vous vos socles techniques et applicatifs lorsqu'ils sont déployés sur des centaines de serveurs.
  • # Delta RPMs

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

    Va lire ce journal http://linuxfr.org/~JRM/16852.html(...) et les liens associés, je pense que ça répondra pile-poil à ta question.
  • # Re

    Posté par  . Évalué à 2.

    > Bonjour,

    'lut

    > Tout d'abord, je poste ici parce que quand je poste dans les forums, personne ne me répond....

    Tu vas te faire te faire taper dessus toi...

    >...

    À mon avis ça vient de la conception du "packetage" de ton soft, un rpm de plus de 100 Mo, c'est MAL©[1]. Tu devrais le couper en plusieurs sous rpms (qui dépendent les uns des autres comme il faut): *-devel, *-data, *-server, *-*, et tu mets à jour que celui qu'il faut, quitte à garder un paquet "tête" quasiment vide (que les dépendances en fait) qui "marque" la version.

    [1] oui je sais, certains (ooo pour ne pas les citer) font comme ça.
    • [^] # Re: Re

      Posté par  . Évalué à 2.

      Tu vas te faire te faire taper dessus toi...


      Ouais ben n'empêche que j'ai déjà commencé dans les forums => pas de réponse. Je poste ici et en deux heures des gens s'intéressent à mon cas...

      un rpm de plus de 100 Mo, c'est MAL©[1]


      Quand tu as beaucoup de données sans répartitions fonctionnelles précises, tu es bien obligé de le faire. Par exemple j'ai pour 100Mo d'images dans un paquet.

      Lorsque l'on découpe des paquets avec des -devel -man -data etc.... ce sont des découpages fonctionnels. Or si je découpe mes paquets, ce seront des découpages techniques, ce qui m'embête beaucoup car il n'ont aucune réalité fonctionnelle.

      Ca m'embêterait d'avoir a-1.rpm a-2.rpm a-3.rpm pour la simple raison qu'on ne sait pas quel fichier est dans quel rpm... .De plus pour supprimer le paquet a en entier, il faut supprimer 3 paquets.

      Enfin, quelle granularité appliquer aux RPMs ? De manière générale, je trouve qu'il est dommage de déployer ne serait-ce qu'1Mo lorsque l'on doit modifier un fichier texte de 2Ko !

      La solution à laquelle je pense le plus, c'est de ne pas utiliser RPM ! Je pense faire un repository central basé sur CVS ou SVN qui référence les fichiers de mes applis. Lorsqu'un des fichiers de mes appli change, je sais faire un patch de manière quasi automatique que je déploye ensuite sur tous mes serveurs. Les patchs pourront être packagés en RPM ;-)

      Au lieu d'avoir 1 base RPM sur chaque serveur (soit plus d'une centaine de bases), je n'aurais qu'une base centrale qui assurera la cohérence de mes packages déployés.
      • [^] # Re: Re

        Posté par  . Évalué à 1.

        > La solution à laquelle je pense le plus, c'est de ne pas utiliser RPM ! Je pense faire un repository central basé sur CVS ou SVN qui référence les fichiers de mes applis. Lorsqu'un des fichiers de mes appli change, je sais faire un patch de manière quasi automatique que je déploye ensuite sur tous mes serveurs. Les patchs pourront être packagés en RPM ;-)

        mélanger un système "perso" avec rpm, c'est pas forcement une bonne idée.

        Tes 100 Mo d'images ne sont pas modifiées à chaque fois, donc tu peux les mettre dans un rpm, et avoir un rpm avec tes prog/scripts/... séparés.

        Sinon, tes patches, c'est pour des binaires?
  • # Petites idées.

    Posté par  . Évalué à 1.

    1/ Pour ton pb de rpm.
    Dans le man de rpm il existe l'option --justdb ( Update only the database, not the filesystem.) Je ne l'ai jamais testée.


    2/ Plus généralement.
    As tu pensé à rsync ou unison ?
    Leur fonctionnement est semblable, tous les 2 n'envoient que la difference entre deux chemins de deux machines (on peut le faire en utilisant ssh). C'est donc économique en bp.
    Unison est en plus multiplateforme et synchonise dans les 2 sens.
    Perso je pencherais plus pour une solution mixte, à savoir mise à jour système par rpm et maj applicatifs/datas (web, photo etc) par rsync. Ca te permet de garder le confort de l'outil de maj de l'os (urpmi, up2date, yum ...).
  • # D'ailleurs...

    Posté par  . Évalué à 1.

    D'ailleurs, à ce sujet, quelqu'un ne connaitrait pas un équivalent free au Red Hat Network (qui dans sa version la plus évoluée permet de gérer des mises à jours sur des groupes de serveurs, des déploiements de fichiers de configuration...). C'est pour administrer des WhiteBox (clone de RHEL).

    Certes, on doit pouvoir faire l'équivalent avec ssh, yum et cfengine mais le ticket d'entrée est très élevé pour un admin unix débutant. C'est pour refiler le machin à un admin Windows débrouillard :-)

    Je cherche un truc simple (web de préférences) qui permet de faire tout ça quasiment à la souris. Il y un module webmin qui fait presque ça mais c'est pas très poussé ni convivial...

    Bref, si qqn connait qqch, qu'il fasse signe :)

Suivre le flux des commentaires

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