Journal Mon premier projet open source

Posté par  . Licence CC By‑SA.
Étiquettes :
30
6
déc.
2017

Salut les moules,

Après des années passées à être simple utilisateur du libre, j'ai décidé de passer le cap et de rembourser un peu ma dette infinie envers le libre.

Pour les plus pressés, c'est ici que ça se passe.

Le concept? J'en avais marre de faire du port-forwarding avec mes conteneurs Docker. Du coup j'ai décidé de d'implémenter un serveur DNS qui résout les noms des conteneurs.

Bon ok c'est pas grand chose, mais c'est un début. Si je vous parle de ça, c'est surtout pour soumettre le projet à la critique de la communauté (et je sais qu'ici les gens sont plutôt exigeants). N'hésitez pas à aller jeter un oeil dans le code, c'est pas compliqué (enfin je ne pense pas) et ça ne fait que 150 lignes.

Merci à toutes les bonnes âmes qui me feront des critiques constructives :)

  • # Docker-network ?

    Posté par  . Évalué à 5.

    Excuse moi, mais quel est l'intérêt d'un tel projet ? Si tu crée un docker network, ou même lorsque tu utilise docker compose pour démarrer tes projets, les conteneurs peuvent communiquer entre eux avec leur hostname, pas besoin de DNS.

    • [^] # Re: Docker-network ?

      Posté par  . Évalué à 7.

      Je crois que c’est pour accéder aux hostnames à l’extérieur du réseau Docker, pas en étant à l’intérieur.

      Me trompé-je ?

      • [^] # Re: Docker-network ?

        Posté par  . Évalué à 2.

        Pas mis en oeuvre moi-même, mais il me semble que ce serait faisable avec mDNS.

        • [^] # Re: Docker-network ?

          Posté par  . Évalué à 1.

          Pour ce qui est de mDNS, j'avoue que je ne connais pas trop, j'ai regardé un peu, mais pas sur de bien saisir le concept. Le but serait que des services s'enregistre auprès d'un serveur mDNS pour dire à quelle addresse ils sont joignables et ce qu'ils fournissent comme service (c'est ce que j'ai compris en lisant de la documentation zeroconf et le code source du package python du même nom). J'ai bon?

          • [^] # Re: Docker-network ?

            Posté par  . Évalué à 2.

            mDNS n'utilise pas de server (C'est en faite le super avantage). Chaque service fait du multicast et recois des autres pour mettre a jour sa table DNS locale. Tant que tu n'as pas trop de nodes, ca marche tres bien

      • [^] # Re: Docker-network ?

        Posté par  . Évalué à 3.

        Effectivement l'idée initiale est de pouvoir accéder à mes conteneurs depuis mon hôte, pas en étant au sein d'un network Docker

  • # J'ai rien compris mais bravo quand même !

    Posté par  . Évalué à 10.

    C'est un peu du chinois pour moi tout ça mais je comprend que tu avais un problème, que tu a fais un programme pour le résoudre et que tu le partages en tant que logiciel libre et ça c'est chouette !

    BeOS le faisait il y a 20 ans !

  • # service discovery

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

    L'idée est cool.

    Une idée d'amélioration : utiliser les health check s'ils sont défini et pas juste l'état start/die. Ainsi si un conteneur met du temps à booter ton dns ne le retournera que lorsqu'il sera pleinement accessible et pas juste démarré.

    Et après, c'est grosso modo le principe qu'on trouve derrière les parties de service discovery de coreDNS/etcd/consul mais tout dépend de l'usage que tu en fait ;-)

    • [^] # Re: service discovery

      Posté par  . Évalué à 1.

      Effectivement je n'avais pas pensé aux health check. Je le rajoute à la roadmap :)

      etcd et consul sont juste des services clef/valeur qui sont utilisés pour faire du service discovery. Par contre il est vrai que coreDNS aurait pu faire l'affaire (et à regarder vite fait il a l'air fait pour ça).

      • [^] # Re: service discovery

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

        etcd et consul sont juste des services clef/valeur qui sont utilisés pour faire du service discovery

        Nope ;-)

        etcd et consul permettent aussi de résoudre du DNS. J'ai du docker avec nomad, dès qu'une instance est en route elle apparait dans le DNS de consul. Y compris avec des enregistrements SRV

        dig _web._tcp.service.consul SRV

;; ANSWER SECTION:
_web._tcp.service.consul. 0     IN      SRV     1 1 3000 core-2.staging.node.dc1.consul.
_web._tcp.service.consul. 0     IN      SRV     1 1 3000 core-3.staging.node.dc1.consul.
_web._tcp.service.consul. 0     IN      SRV     1 1 3000 core-1.staging.node.dc1.consul.

  • # Petite revue de code...

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

    …parce que ça m'amuse.

    def __init__(self, dockerClient, servers=[]):

    En général il est déconseillé d'utiliser des objet mutable comme valeur par défaut (car c'est au final une variable globale utilisée par tous les appels à la fonction/méthode).

    resolvconf = open("/etc/resolv.conf", "r")

    Il serait mieux d'utiliser with, ce qui fermerait proprement et automatiquement le fichier.

    Sinon ça me parait OK.

    • [^] # Re: Petite revue de code...

      Posté par  . Évalué à 3.

      Pour le coup de la liste en paramètre, on préfère en effet initialiser à une valeur comme None, puis tester if servers is None: servers = list() dans le cœur de la fonction.

      On pourrait aussi dire que dans le parser, "store" est l'action par défaut (donc peut-être supprimé), et qu'une option comme --mon-option a automatiquement un dest qui vaut mon_option. Je m'appuie toujours dessus pour ne pas surcharger la lecture des parsers. Le seul cas où je définis dest explicitement, c'est lorsque j'utilise action='store_false', par exemple: 

      parser.add_argument('--no-retry', action='store_false', dest='retry')

      Ce qui permet d'avoir ensuite dans le code if args.retry (et pas un horrible if not args.no_retry) tout en ayant une valeur par défaut à True.

      • [^] # Re: Petite revue de code...

        Posté par  . Évalué à 1.

        Chouette de la revue de code! J'avoue que c'était aussi pour ça que je postais ici (en dehors du simple fait de faire la pub de mon projet).

        Je vais prendre en compte vos remarque, ça arrivera dans une prochaine version :)

  • # Autre que pour Docker?

    Posté par  . Évalué à 0.

    Dans mon entreprise, on utilise le port forward SSH (qui tourne en permanence) sur un serveur principal pour accéder aux serveurs aux travers de VPNs et rebonds SSH en une seul connexion de manière transparente. Je me demandais si avec ton projet, on ne pourrait pas "nommer" ces serveurs.
    Je m'explique. Pour accéder au serveur filialeA sur le pour 22 on se connecte sur le port 10022 de 192.168.15.110. Pour accéder au port 80 du même serveur on se connecte au port 10023 du même serveur 192.168.15.110. C'est pratique car ainsi, les utilisateurs n'ont pas besoin de faire les rebonds nécessaires (ou d'établir des VPN) et chaque changement réseau est transparent. Cependant il faut connaître tous les ports (on les enregistre évidemment mais c'est beaucoup de config sur chaque PC). L'idée ce serait de pouvoir attribuer a un nom par exemple "mafilliale_22" (ou mieux port 22 de "mafilliale") le bon port sur 192.168.15.110 de manière transparente. Bien sûr avec un serveur DNS et une adresse IP virtuelle qui serait routé via 192.168.15.110 et une configuration de routeur adéquate (et complexe) on peux y arriver mais c'est trop lourd pour le besoin.
    Est-ce que ce serveur DNS pourrait résoudre ce problème plus simplement?

    • [^] # Re: Autre que pour Docker?

      Posté par  . Évalué à 2. Dernière modification le 09 décembre 2017 à 15:27.

      Le serveur DNS que j'ai développé ne répondrais pas à ce besoin. Par contre tu peux développer le tien en te basant sur mon travail, c'est pas trop compliqué, il s'agit d'une application Twisted. Tu as juste à implémenter un Resolver qui répond à tes besoins et c'est bon.

      Sinon, vu les remarques assez pertinentes d'autres personnes ici même, tu peux regardé du côté de la découverte de service (etcd/consul).

Suivre le flux des commentaires

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