Forum Linux.général Docker - Incron

Posté par  . Licence CC By‑SA.
Étiquettes :
2
20
août
2024

Bonjour,

Voila je suis entrain de mettre dans un docker une application web qui a entre autre des interactions avec le système.
Cette interaction de passe principalement en créant un fichier dans un dossier particulier qui dans une installation "standard" est surveillé par un "incron" fait avec systemd.

Le soucis est la non présence d'incon dans Debian 11 et la non présence de systemd dans mon container.

Des idées pour effectué le même type de comportement ?
À savoir exécuter un événement a la création de fichier dans un dossier particulier ?

Merci pour votre aide.

  • # Debian 11 EOL

    Posté par  (site web personnel) . Évalué à 6 (+4/-0).

    Le rappel en sujet étant fait…

    Un rétroportage existe :

    incron     | 0.5.12-3~bpo11+1 | bullseye-backports       | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

    Sinon, inotify-tools propose inotifywatch (entre autres outils).

    Debian Consultant @ DEBAMAX

    • [^] # Re: Debian 11 EOL

      Posté par  . Évalué à 1 (+0/-0). Dernière modification le 21 août 2024 à 08:18.

      Bonjour,

      Merci de vais regarde cela.

      Bonne journée

  • # interaction avec quel système ?

    Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

    Hello,

    C'est avec quel système que l'application doit avoir une interaction ? Est-ce avec le Linux du container ou celui de l'hôte ?

    Si c'est celui de l'hôte, tu peux profiter du systemd de l'hôte comme ça :

    • tu partages le dossier de l'hôte avec le container via un volume
    • sur l'hôte :
      • tu créés une unité systemd.path pour surveiller ce dossier (ou tu utilises, incron, mais systemd sait déjà faire ça nativement)
      • tu créés un service systemd qui exécute une commande dans le container avec quelque chose comme: docker exec le-nom-du-container la-commande (ce service doit avoir le même nom que l'unité path créé au point d'avant)

    Comme ça l'hôte averti le container avec la commande voulue dès qu'un fichier est créé dans le volume partagé.

    • [^] # Re: interaction avec quel système ?

      Posté par  . Évalué à 3 (+2/-0).

      Bonjour,

      Non, l'application interagis avec le système du container.

      Sur le système actuel c'est déjà la solution que j'utilise avec plus ou moins de succès, j'en profit du portage dans docker pour revoir un peut tout ça.

      Bonne journée

      • [^] # Re: interaction avec quel système ?

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        Tiens, je n'arrive pas à voir l'usage alors. Tu pourrais nous en dire plus sur cette interaction ?

        Dans quel cas le système du container doit créé un fichier ? Ensuite il exécute quoi comme commande pour l'application web ?

        • [^] # Re: interaction avec quel système ?

          Posté par  . Évalué à 3 (+2/-0).

          Voici en gros le fonctionnement

          L'application web administre un script système qui doit être exécuté en root

          Apache a les droits d'écriture sur un dossier particulier.
          Lorsque un fichier normalisé est écrit dans ce dossier, incron exécute le script système avec les droit root
          Bien-sur si le fichier n'est pas normalisé comme il faut le script le supprime sans rien d'exécuter d'autre.

          Cela permet, enfin il me semble, un cloisonnement des autorisations a peut prêt propre sans laissé a Apache la possibilité d’exécuter des script bash directement. Encore moins un root.

          J'essaye de voir pour reproduire cela dans un container sans interaction avec le système host.

  • # des pistes

    Posté par  . Évalué à 3 (+0/-0).

    utiliser un volume "tampon" entre le docker et la machine principale
    c'est alors la machine principale qui surveille le dossier, et lance le script, eventuellement via un docker exec lescript

Envoyer un commentaire

Suivre le flux des commentaires

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