KissCache un service de mise en cache KISS

Posté par  (site web personnel) . Édité par palm123, Davy Defaud, Nils Ratusznik, Pierre Jarillon, patrick_g et Ysabeau 🧶. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
26
18
mar.
2020
Administration système

KissCache est un serveur de cache sous licence MIT pensé suivant le principe KISS : Keep It Simple Stupid.

Contrairement à un serveur mandataire (proxy) transparent comme Squid, pour utiliser KissCache, il faut (et suffit) de préfixer l’adresse URL voulue par celle de l’instance locale de KissCache. KissCache va alors télécharger en arrière‑plan le fichier demandé et le transmettre au client. Si plusieurs clients demandent le même fichier au même moment, celui‑ci ne sera téléchargé qu’une seule fois. KissCache n’étant pas transparent, il peut tout à fait mettre en cache des fichiers disponibles via HTTPS.

Cas d’usage

Chez Linaro, nous utilisons KissCache dans notre infrastructure de validation. En effet, les différents tests de validation vont tous utiliser les mêmes ressources (noyaux Linux, système de fichiers racine, dtb…) au même moment. Grâce à KissCache notre infrastructure de validation ne téléchargera chaque ressource qu’une seule fois, réduisant drastiquement la charge réseau.

Nous avons longtemps utilisé squid, mais nous n’avons jamais réussi à le configurer pour :

  • télécharger une seule fois chaque fichier, même en cas de demande parallèle ;
  • mettre en cache les ressources disponibles via HTTPS.

Utilisation

Pour installer une instance locale :

git clone https://git.lavasoftware.org/ivoire/KissCache
cd KissCache
docker-compose build
docker-compose up

L’instance sera disponible à l’adresse http://localhost:8001.

Il suffit maintenant de préfixer les adresses URL par celle de notre instance KissCache :

curl "http://localhost:8001/api/v1/fetch/?url=https://linuxfr.org"

KissCache va alors télécharger la page pour vous et vous la transmettre.

Configuration

TTL

Par défaut, KissCache va garder chaque fichier pendant dix jours. Cette valeur par défaut peut être changée par l’administrateur ou via le paramètre ttl dans l’adresse URL.

curl "http://localhost:8001/api/v1/fetch/?ttl=1d&url=https://linuxfr.org"

Quota

Par défaut, KissCache n’utilisera que 2 Gio d’espace disque et retournera un code d’erreur 507 (Insufficient Storage) pour toute requête supplémentaire. Il est, évidemment, possible de changer cette valeur ou même de supprimer tout quota.

Accès

L’accès à l’instance KissCache peut être restreint par adresse IP pour, par exemple, n’autoriser que les machines de validation. L’interface Web sera toujours accessible à tous, mais seules les adresses IP autorisées auront le droit d’utiliser le système de cache.

Technique

KissCache est une application Django qui utilise Celery pour la récupération des ressources en arrière‑plan.

Aller plus loin

  • # Autre serveur http

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 19 mars 2020 à 04:20.

    télécharger une seule fois chaque fichier même en cas de demande parallèle

    Avez vous testé nginx et apt-cacher-ng?

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

    • [^] # Re: Autre serveur http

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

      apt-cacher-ng étant un proxy transparent il n'est pas possible de mettre en cache des ressources disponible via https.

      En fait c'est possible mais il faut installer un certificat racine sur chaque client et générer des certificats signés avec ce certificat racine pour chaque domaine. Il faut donc créer de faux certificats SSL!
      Sachant que certains client peuvent se rendre compte de cette manipulation et fermer la connexion.

      Le fait de préfixer l'url avec celle de l'instance de KissCache permet de mettre en cache des url https. En effet, le client se connecte à KissCache qui retourne son propre certificat (valide) et les données en cache. De son côté KissCache se connecte en https au site demandé et valide lui même le certificat.

      Il faut donc avoir confiance en l'instance KissCache mais moins que dans le cas où il faut installer un certificat racine maison.

    • [^] # Re: Autre serveur http

      Posté par  . Évalué à 2.

      Ça me semble étrange également de réécrire un serveur de cache.

      Et je suis épaté par le fait que Squid fasse plusieurs requêtes en cas de demandes simultanées. D'un autre côté en y réfléchissant, tant qu'il n'a pas reçu de réponse pour une ressource, il ne peut pas regarder dans les en-têtes si elle peut être gardée en cache.

      En proxy-cache qui marche bien, j'entends souvent parler de Varnish (pas essayé).

      • [^] # Re: Autre serveur http

        Posté par  . Évalué à 2.

        (Mais j'ai bien compris que Kiss-Cache ne faisait pas juste ce qu'on attend de base d'un proxy-cache)

      • [^] # Re: Autre serveur http

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

        Et je suis épaté par le fait que Squid fasse plusieurs requêtes en cas de demandes simultanées. D'un autre côté en y réfléchissant, tant qu'il n'a pas reçu de réponse pour une ressource, il ne peut pas regarder dans les en-têtes si elle peut être gardée en cache.

        Exactement, KissCache est pensé pour ne faire qu'une seule requête et cela demande un peu de gymnastique. Donc c'est assez logique que squid ne le fasse pas (squid faisant énormément de chose que KissCache ne fera jamais).

        En proxy-cache qui marche bien, j'entends souvent parler de Varnish (pas essayé).

        Malheureusement toujours la même réponse : Varnish étant un proxy, il ne supporte pas le https

        J'aurai largement préféré utiliser un logiciel existant plutôt que de devoir en développer un nouveau. Malheureusement je n'ai rien trouvé.

        • [^] # Re: Autre serveur http

          Posté par  . Évalué à 1.

          En proxy ça ne va pas, mais Varnish s'utilise en reverse-proxy. Et tu peux mettre du https derrière je suppose.

          Ce qu'ils ne veulent pas faire, c'est que Varnish serve du https. Pas qu'il en consomme.

  • # Bayard presse

    Posté par  (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 19 mars 2020 à 08:25.

    Kiskache est aussi le nom de personnages dans Pom d'api : la famille kiskache.
    Les familles droguées à bayard presse auront certainement tiltées ;)

    J'ai plus qu'une balle

  • # Invalidation ?

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

    Venant du hardware, je suis toujours étonné de voir des systèmes de caches logiciels sans système robuste d'invalidation et de gestion propre de l'espace limité.

    Pourquoi kisscache n'a pas de LRU pour évincer les fichiers les moins utilisés au lieu de renvoyer une erreur ?
    Pourquoi kisscache n'utilise pas les mécanismes http de demande de modification pour retélécharger un fichier qui a changé ? (ici, on peut utiliser un cache de quelques minutes, tout de même)

    "La première sécurité est la liberté"

    • [^] # Re: Invalidation ?

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

      Je suis tout à fait d'accord sur le fait que l'on peux faire beaucoup mieux et que de nombreuses choses peuvent-être améliorés dans KissCache.

      Mais le but est d'avoir un logiciel simple et qui correspond au cas d'usage, d'où son nom.

      Dans le cas d'un système de CI, les ressources sont construites (par Gitlab ou Jenkins), mise à disposition via un serveur https (S3, nginx, …) puis testé par LAVA.
      Les urls étant unique pour chaque version testé, il n'est pas utile de vérifier que les ressources distantes changent.

      Suite à une demande d'un utilisateur, je suis en train de voir pour ajouter l'éviction du cache.

      Prends aussi en compte que c'est environ une semaine de boulot, pas plus.

      • [^] # Re: Invalidation ?

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

        Je n'avais pas compris que c'était un dev de votre part.

        Attention tout de même pour la gestion de ressources immuables, même des boites comme Netlify qui ne faisait que ça, sont passés à un mode qui gère les modifications. Vous pouvez jouer sur un cache de quelques dizaines de minutes, il n'est pas utile d'avoir la bonne ressource à la minute.

        "La première sécurité est la liberté"

  • # vraiment ?

    Posté par  . Évalué à 0.

    KISS
    …
    KissCache est une application Django qui utilise Celery pour la récupération des ressources en arrière‑plan.

    Moui, en quoi est-ce plus simple que squid ?

    • [^] # Re: vraiment ?

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

      Moins de 500 lignes de code à maintenir.

      • [^] # Re: vraiment ?

        Posté par  . Évalué à 4.

        Je m'attendais au LoC…
        Mais la complication de KissCache est dans ses dépendances : django, celery, postgres, redis. Et autant de containers lancés. Ah oui et donc docker aussi comme dépendance.
        Malgré cela, je pense que ce projet est un très bon démonstrateur pour cette stack. D'ailleurs je m'en sers pour déclencher des chaînes de traitements en self-service.
        Mais justement, dans mon cas d'usage il s'agit d'un traitement qui se fera plus tard alors que dans le cas d'un cache, il s'agit d'un traitement qui doit se faire pendant la durée de la requête client.
        Autrement dit, le client d'un cache n'attend pas un 'ok je m'en occupe, reviens plus tard' (=http 202) mais un 'ok, voici le résultat de ta demande' (=http 200).
        Cela ne justifie pas l'utilisation de celery. Pour moi, l'utilisation de python-request aurait suffit.
        Tout ça pour dire que se revandiquer du KISS est toujours casse-gueule.

        • [^] # Re: vraiment ?

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

          Lorsqu'une requête arrive, KissCache va vérifier si l'url est déjà en cache (via la db).

          Si la ressource existe déjà dans la DB (qui garantie donc l'unicité des ressources), django stream la ressource au client
          Si la ressource n'existe pas, django démarre une tache Celery et stream la ressource au client (même code que dans le premier cas).

          Le fait d'utiliser Celery permet de ne télécharger chaque url qu'une unique fois. De plus, si le client ferme la connexion, l'url continuera d'être téléchargée par la tache Celery.

  • # usage ?

    Posté par  . Évalué à 1.

    Quel est l'usage ?

    Clairement, cela ne peut pas être utilisé pour surfer le web car l'utilisateur ne va pas réécrire toutes les URL.
    D'autre part, le changement de domaine brise un certain nombre de mécanisme sécurités.

    Si plusieurs clients demandent le même fichier au même moment

    Qu'est-ce que "au même moment" ? Cela ne me paraît pas se produire souvent…

    Mais cela l'air d'avoir répondu à un de vos problèmes, j'aimerai comprendre lequel.

    • [^] # Re: usage ?

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

      Quel est l'usage ?

      voir "Cas d’usage" dans l'article.

      Clairement, cela ne peut pas être utilisé pour surfer le web car l'utilisateur ne va pas réécrire toutes les URL.

      Exactement c'est pour le système de CI.

      D'autre part, le changement de domaine brise un certain nombre de mécanisme sécurités.

      Oui et non car KissCache va :
      1/ valider les certificats SSL
      2/ le client s’adresse explicitement à l'instance KissCache donc fait explicitement confiance à cette instance.

      Pour faire la même chose avec un proxy, il faut :
      1/ créer un certificat racine
      2/ l'installer sur chaque client
      3/ forger des certificats pour chaque domaine demandé

      Le client fait donc entièrement confiance au proxy qui va forger des certificats pour linuxfr.org par exemple.
      Ceci brise l'intégralité des mécanismes de sécurité car le client doit fait entièrement confiance au certificat racine du proxy. Un attaquant qui prend le contrôle du proxy peut alors mettre en place un MitM sans aucun problème avec l'intégralité des domaines.

      Qu'est-ce que "au même moment" ? Cela ne me paraît pas se produire souvent…
      Dans un système de validation où plusieurs job sont lancé en parallèle avec les même artefacts cela arrive absolument tout les jours.

      Dans notre cas, LKFT va valider chaque RC du noyaux linux sur 6 types de machines en lançant pour chaque type une dizaine de job différent. Sachant que nous avons au minimum 4 machine de chaque type, LAVA va nécessairement faire tourner des jobs en parallèle et donc utiliser les même artefacts au même moment.

      • [^] # Re: usage ?

        Posté par  . Évalué à 3.

        Ceci brise l'intégralité des mécanismes de sécurité car le client doit fait entièrement confiance au certificat racine du proxy.

        Tu peux faire un certificat racine avec des contraintes pour qu'il ne soit valable que pour certains domaines. https://tools.ietf.org/html/rfc5280#section-4.2.1.10

        (bon, il faut que l'implémentation tls cliente en tienne compte)

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: usage ?

        Posté par  . Évalué à 1.

        ok
        donc "au même moment" signifie "dans une fenêtre de temps réduite" et pas "toutes les requêtes arrivent en même temps, la première va chercher sur le web et les autres attendent".

        • [^] # Re: usage ?

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

          Dans le cas de Squid, tant que l'url n'aura pas été mise en cache, toute requête forcera un second téléchargement.

          Avec KissCache, la première requête déclenche le téléchargement, toute requête suivante ne fera que streamer le fichier au client, y compris durant le téléchargement par la tache Celery.

          Ce fonctionnement permet de fortement diminuer l'utilisation réseau. Chose que squid ne peux malheureusement pas faire.

Suivre le flux des commentaires

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