Les paquets système (RPM, deb) sont stables, testés, et mis à jour de manière intelligente, mais parfois on a besoin d'une version plus récente. Faire ses propres paquets systèmes et les charger dans un Docker ou un Puppet semble bien, mais c'est un investissement en temps
Pour l'avoir fait moi-même dans mon précédent job, faire un script qui génère des paquets binaires (j'insiste, parce que les paquets source c'est plus chiant, faut se taper toute l'usine a gaz pour build) pour les .deb est trivial, tant que tu ne t'embêtes pas a utiliser les scripts pre-rm, post-rm, pre-inst et post-int.
Concrètement, il suffit de faire un dossier DEBIAN, d'y écrire un fichier control, 2-3 autres fichiers qui détaillent les hash et les dépendances, de lancer un dpkg-deb avec l'option kivabien (je me souviens plus de son nom, ça date, mais apt-file show dpkg-dev devrais pouvoir t'aider), d'upload vers un serveur http géré par, il me semble, reprepro.
Tout ça s'automatise super facilement, vraiment. Je me suis débarrassé d'un tas de problèmes grâce à ça, malgré que je n'étais entouré que de "jeunes" développeurs, sortis de l'école (ou qui n'avaient pas touché au code depuis 30 ans littéralement) et 0 compréhension de comment une debian tourne.
Ce qui est magique avec le format .deb, c'est que c'est juste une archive standard (qui contiens un fichier texte qui décrit la version, 1 archive de meta-données, et 1 archive qui contiens la charge utile), donc tu peux simplement mettre en place ce genre de trucs juste en ouvrant les paquets qui marchent, même pas besoin de lire la doc! Il me semble que pour rpm ce n'est pas la même chanson, mais je n'en ai réellement aucune idée.
Le seul inconvénient de dpkg, c'est qu'il a "besoin" d'être root, mais... en vrai je pense que c'est faux, si on joue un peu avec les paramètres (de mémoire on peut ajuster ce type de paramètres) et qu'on le pointe sur des dossiers accessibles par des UID!=0. Pour dpkg, ça peut marcher, je pense, mais pour apt ou aptitude, c'est moins évident.
Pas sûr non plus que ça soit pertinent, après tout il suffit de coller une MàJ automatique des paquets dans une cron-tab, disons, le midi, et ça juste roule.
Après, la où les larmes risquent effectivement de couler, c'est quand tu vas essayer de convaincre tes collègues, à cause d'une mauvaise réputation (liée au fait que pour contribuer un paquet, il faut que ça soit un paquet source, et suivre les procédures debian, ce qui est normal... mais ici on parle d'un truc en interne, non?), ou si tout le monde ne marche pas sur une Debian-like...
De mon côté, j'avais bricolé un script shell sur quoi? 150 lignes? Il lisait un fichier texte qui décrivait les données a empaqueter et faisait office de "super-control", je gérais 2-3 bricoles automatiquement (l'archi matérielle, c'est trivial, l'auteur idem, et quelques autres bricoles YMMV) et l'outil était utilisé pour empaqueter:
4 daemon
1 lib commune a tout ce beau monde
lui-même
une bonne 20aine de scripts runit et autres qui étaient déployés en prod (chacun dans leur propre paquet)
quelques autres outils internes
En tout je devais avoir bien une 40aine de paquets... et franchement je n'ai jamais regretté mon choix. Il faut dire que je n'ai eu que moyennement le choix, vu qu'il fallait bien automatiser le déploiement via PXE, et clairement passer sur des .deb était de loin le moins prise de tête.
A l'origine, j'avais déployé le PXE à l'arrache et dans l'urgence, je dézippais littéralement des tarballs dessus après le debootstrap, et ça a été la cause de bien des larmes, justement, jusqu'à ce que je me bloque quelques heures pour faire ce fameux script, et la, magie, une source de galères au déploiement en moins, tout en n'utilisant que des trucs simples (pas de nouvelle dépendance, c'est agréable quand le système de destination est une beaglebone black ou une CM mano842 avec ses 8Gio de stockage... et même sans ça, c'est plus simple de s'assurer que tout marche, quand il y a moins de 400 .deb installés!).
Bon, de temps en temps un collègue ne comprenait pas pourquoi mon script refusais de tourner, dans ces moments je le débloquais, j'améliorais le message d'erreur, et j'améliorais la doc. Au fur et a mesure ces moments étaient de plus en plus rare, et oui, ils utilisaient parce qu'il n'y avait de toute façon aucun autre moyen de déployer :)
# c'est quoi le problème des .deb?
Posté par freem . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 10.
Pour l'avoir fait moi-même dans mon précédent job, faire un script qui génère des paquets binaires (j'insiste, parce que les paquets source c'est plus chiant, faut se taper toute l'usine a gaz pour build) pour les .deb est trivial, tant que tu ne t'embêtes pas a utiliser les scripts
pre-rm,post-rm,pre-instetpost-int.Concrètement, il suffit de faire un dossier
DEBIAN, d'y écrire un fichiercontrol, 2-3 autres fichiers qui détaillent les hash et les dépendances, de lancer undpkg-debavec l'option kivabien (je me souviens plus de son nom, ça date, maisapt-file show dpkg-devdevrais pouvoir t'aider), d'upload vers un serveur http géré par, il me semble,reprepro.Tout ça s'automatise super facilement, vraiment. Je me suis débarrassé d'un tas de problèmes grâce à ça, malgré que je n'étais entouré que de "jeunes" développeurs, sortis de l'école (ou qui n'avaient pas touché au code depuis 30 ans littéralement) et 0 compréhension de comment une debian tourne.
Ce qui est magique avec le format .deb, c'est que c'est juste une archive standard (qui contiens un fichier texte qui décrit la version, 1 archive de meta-données, et 1 archive qui contiens la charge utile), donc tu peux simplement mettre en place ce genre de trucs juste en ouvrant les paquets qui marchent, même pas besoin de lire la doc!
Il me semble que pour rpm ce n'est pas la même chanson, mais je n'en ai réellement aucune idée.
Le seul inconvénient de dpkg, c'est qu'il a "besoin" d'être root, mais... en vrai je pense que c'est faux, si on joue un peu avec les paramètres (de mémoire on peut ajuster ce type de paramètres) et qu'on le pointe sur des dossiers accessibles par des UID!=0. Pour dpkg, ça peut marcher, je pense, mais pour apt ou aptitude, c'est moins évident.
Pas sûr non plus que ça soit pertinent, après tout il suffit de coller une MàJ automatique des paquets dans une cron-tab, disons, le midi, et ça juste roule.
Après, la où les larmes risquent effectivement de couler, c'est quand tu vas essayer de convaincre tes collègues, à cause d'une mauvaise réputation (liée au fait que pour contribuer un paquet, il faut que ça soit un paquet source, et suivre les procédures debian, ce qui est normal... mais ici on parle d'un truc en interne, non?), ou si tout le monde ne marche pas sur une Debian-like...
De mon côté, j'avais bricolé un script shell sur quoi? 150 lignes? Il lisait un fichier texte qui décrivait les données a empaqueter et faisait office de "super-control", je gérais 2-3 bricoles automatiquement (l'archi matérielle, c'est trivial, l'auteur idem, et quelques autres bricoles YMMV) et l'outil était utilisé pour empaqueter:
En tout je devais avoir bien une 40aine de paquets... et franchement je n'ai jamais regretté mon choix. Il faut dire que je n'ai eu que moyennement le choix, vu qu'il fallait bien automatiser le déploiement via PXE, et clairement passer sur des .deb était de loin le moins prise de tête.
A l'origine, j'avais déployé le PXE à l'arrache et dans l'urgence, je dézippais littéralement des tarballs dessus après le debootstrap, et ça a été la cause de bien des larmes, justement, jusqu'à ce que je me bloque quelques heures pour faire ce fameux script, et la, magie, une source de galères au déploiement en moins, tout en n'utilisant que des trucs simples (pas de nouvelle dépendance, c'est agréable quand le système de destination est une beaglebone black ou une CM mano842 avec ses 8Gio de stockage... et même sans ça, c'est plus simple de s'assurer que tout marche, quand il y a moins de 400 .deb installés!).
Bon, de temps en temps un collègue ne comprenait pas pourquoi mon script refusais de tourner, dans ces moments je le débloquais, j'améliorais le message d'erreur, et j'améliorais la doc. Au fur et a mesure ces moments étaient de plus en plus rare, et oui, ils utilisaient parce qu'il n'y avait de toute façon aucun autre moyen de déployer :)