PKGI, création rapide d'environnements applicatifs indépendants sous Debian

Posté par  . Modéré par Mouns.
Étiquettes :
25
2
juin
2009
Debian
Quand vous partagez un serveur Linux entre plusieurs équipes et plusieurs projets, chacun se retrouve isolé dans son propre répertoire (éventuellement sur son propre système de fichiers). Pour utiliser les logiciels installés sur le système, vous n'avez pas d'autres choix que de réécrire vos scripts de contrôle (arrêt, démarrage, statut, etc.). Plutôt que de refaire des scripts qui seront, dans la majorité des cas, moins bons que ceux livrés avec le système vous pouvez utiliser PKGI.

PKGI est un logiciel sous licence LGPL, fonctionnant sous Debian et vous permettant de déployer dans un répertoire quelconque une arborescence applicative autonome. Vous pourrez ainsi utiliser et gérer en tout indépendance : Apache, MySQL, Tomcat, OpenLDAP, phpMyAdmin, tmpreaper, logrotate, cron, ... (à développer).

Bien sûr, à la place, on pourrait utiliser une machine virtuelle mais cela oblige chaque équipe à maîtriser l'administration d'un système complet. Ce qui demande des compétences qu'un développeur n'a ou ne veut pas avoir. On pourrait également, à la manière des FAIs, utiliser les capacités de mutualisation de certain logiciel (apache et ses virtuals hosts par exemple). Mais cela rend les équipes interdépendantes, cela oblige à mettre en place une architecture mutualisée (ce qui augmente le coût de gestion du système pour ses administrateurs), mais surtout cela ne permet pas de répondre aux besoins spécifiques de chaque projet.

Aller plus loin

  • # ...

    Posté par  . Évalué à 1.

    ça se positionne comment par rapport à du chroot par ex ? quid du partage des ressources ?

    Ca me fait penser un peu à la logique de container sous Solaris qui peuvent être soit isolés (et donc "identique" à une VM), soit "'mutualisés" et donc bénéficie des binaires de la machine hôte.

    • [^] # Re: ...

      Posté par  . Évalué à 1.

      Hum pour ce que j'en connais de PKGI... Il ne s'agit que de l'instanciation de templates de fichiers de configuration.

      Ainsi le partage des ressources est laissé tout naturellement aux admins du serveur hôte.

      Pas de chroot, mais ça ne devrait pas être compliqué à mettre en place.

  • # production

    Posté par  . Évalué à 7.

    Mais tu sais que c'est génial ça !

    Personnellement, je passe mon temps à casser les paquets des distrib pour arriver à mettre binaire+conf+scripts sur le même FS ! (+ un FS pour les données + un FS pour les logs).

    Le l'internet est d'avoir un user applicatif+un repertoire dédié à chaque instance de logiciel. Grâce à ça, on mutualise beaucoup plus facilement.
    Ca permet à chaque équipe de gerer ses propres applications, (presque) sans marcher sur les autres (et sans avoir le compte root !!)
    Pour les migrations de serveurs, un tar et hop tout bascule d'un coup (et je parle pas des cas ou il n'y a qu'une bascule de disk à faire sur le SAN...)

    Dans les boites un peu grosses, où les besoins de mutualisation sont importants, on est constamment obliger de faire ce découpage.

    Ca me fait penser qu'avec ces histoire de mutualisation de serveur par virtualisation ou Vserver, j'ai l'impression qu'on a perdu de vue qu'Unix était déjà multi-utilisateur et multi-processus...

    Je vais étudier ta solution!

  • # Et les ports

    Posté par  . Évalué à 4.

    Une question qui est peut-être bête ^^. En admettant que c'est une plateforme de dev web par exemple, il faut pour chaque instance changer les ports par défaut des différents logiciels ?

    • [^] # Re: Et les ports

      Posté par  . Évalué à 2.

      Il faut évidemment que chaque équipe (appli) ait ses propres ports, mais à l'instanciation des templates (comprendre à la configuration des services) la question du port est posée... Suffit de remplir.

      Étant moi-même un utilisateur (de la version 1), le système est plutôt simple et efficace.

      • [^] # Re: Et les ports

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

        o_O pourquoi ne pas avoir des ServerName différents ? ça rajoute une couche DNS mais bon...

        • [^] # Re: Et les ports

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

          En faite, au sein d'un même processus tu peux bien sûr utiliser des ServerName pour faire du "virtual host" sur le même port mais vu qu'avec pkgi tu as N processus (car 1 par appli, user unix), ces processus ne peuvent pas écouter sur le même port et t'es obligé d'associer un port différent par application.

    • [^] # Re: Et les ports

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

      En effet, on va ainsi déployer N sites Web indépendants avec N numéros de ports différents (supérieurs à 1024 car pas exécuté par root).

      Pour garder des URLs du type http://www.exemple.fr et pas des trucs moches comme http://www.exemple.fr:50389 on peut alors utiliser un apache frontal en mode reverse proxy. C'est ce que l'on fait dans mon entreprise.

  • # J'utilise et j'approuve !

    Posté par  . Évalué à 1.

    Ça facilite grandement les choses !

    Développer de nouveaux modules semble très simple, en tout cas j'en ai dérivé et ça se fait facilement : édition de fichiers de configuration connus, déplacements de fichier.

    Personnellement, j'utilise pkgi-1 sur une Debian Etch avec un apache2, php, pear (qui n'a pas fonctionné, je n'ai pas creusé très loin), bientôt mysql...

    Seul reproche que je ferais : pkgi-1 ne respecte pas une hiérarchie standard, et c'est d'ailleurs pour ça que je dérive les modules. D'autre part, la documentation n'est pas très précise/complète, mais ça s'améliore dans la version 2, et puis il suffit de fouiller dans les fichiers de pkgi pour vite comprendre ce qu'il s'y passe.

  • # Ça tombe à pic !

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

    Merci pour les nouvelles, je suis en plein dedans... je vais regarder ça de plus près !

  • # Openpkg

    Posté par  . Évalué à 1.

    Cela ressemble beaucoup au projet OpenPKG (www.openpkg.org).

    • [^] # Re: Openpkg

      Posté par  . Évalué à 3.

      Je ne crois pas, car le but de pkgi n'est de packager des binaires mais de faciliter leur utilisation dans un repertoire non standard.

      • [^] # Re: Openpkg

        Posté par  . Évalué à 1.

        Certes Openpkg permet de compiler les binaires, mais il permet également la gestion et l'installation de ceux-ci dans des répertoires non standard.

  • # ???

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

    Les dévs qui veulent pas toucher aux couches sysadmins ça existe ? Euh, comment ils font pour développer du web ?

    Puis (je suis plus perl/PHP à la base), mais avec turbogears en python, tu as le même résultat sans pkgi

    http://turbogears.org/2.0/docs/main/DownloadInstall.html#ins(...)

    C'est quoi l'intérêt de pallier aux problèmes des mauvais outils en rajoutant un niveau de complexité ?

    • [^] # Re: ???

      Posté par  . Évalué à 7.

      En tant que sysadmin, je n'ai surtout pas envie de laisser un dev faire autre chose que du code. Sans blagues, entre les bouts de conf trouvés à gauche et à droite, les chmod 777 et les mots de passe "toto", j'ai trop peur pour mon système !

      Maintenant, à savoir si j'utiliserais PKGI : pas sûr. J'irai plutôt vers de la virtualisation style OpenVZ.

      • [^] # Re: ???

        Posté par  . Évalué à 2.

        Dans l'ensemble tu as raison, c'est du vécu :-)

        Mais (neuneu != dev)

        On en connaît tous des programmes mal fait. Ils sont mal fait lorsque le dev est un neuneu. Ou que son supérieur en est un, ce qui au final revient au même.

        On en connaît tous des programmes bien fait. Et par des personnes qui se prétendent uniquement dev.

        Cela dit, le meilleur arrive probablement lorsque les besoins du dev et de l'admin se rencontre, qu'il y a bataille d'arguments, et que les bons arguments sont sélectionnés.

        • [^] # Re: ???

          Posté par  . Évalué à 4.

          Mais (neuneu != dev)
          Certes, mais sysadmin != dev. De la même façon qu'on ne demandera pas à un admin de faire plus que scripter pour l'admin justement (je me vois mal demander à un sysadmin de développer une application critique temps réel pour faire décoller une fusée), je me vois mal demander à un dév de faire de l'admin. Oh, il finira peut-être par faire marcher l'appli, mais ce sera certainement au mépris des règles d'admin et/ou de sécurité élémentaires, vu que c'est pas son boulot, et qu'il ne sait pas forcément quelles contraintes il doit respecter.

          Dans ton post, on peut d'ailleurs substituer « dev » par « admin » et « programme » par « config ». Ce qui commencerait comme ça : « On en connaît tous des configs mal faites. Elles sont mal faites lorsque l'admin est un neuneu. [...] »

Suivre le flux des commentaires

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