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 upL’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
- Page du projet (81 clics)
- Instance de demo (51 clics)
# Autre serveur http
Posté par alpha_one_x86 (site web personnel) . Évalué à 2. Dernière modification le 19 mars 2020 à 04:20.
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 Rémi Duraffort (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 Wawet76 . É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 Wawet76 . É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 Rémi Duraffort (site web personnel) . Évalué à 4.
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).
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 Wawet76 . É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.
[^] # Re: Autre serveur http
Posté par Rémi Duraffort (site web personnel) . Évalué à 1.
Quand varnish est configuré en reverse proxy, un seul serveur pourra être mettre en cache (le backend).
# Bayard presse
Posté par martoni (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
[^] # Re: Bayard presse
Posté par Rémi Duraffort (site web personnel) . Évalué à 3.
Je n'avais même pas fait le lien :D
# Invalidation ?
Posté par Nicolas Boulay (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 Rémi Duraffort (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 Nicolas Boulay (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 steph1978 . Évalué à 0.
Moui, en quoi est-ce plus simple que squid ?
[^] # Re: vraiment ?
Posté par Rémi Duraffort (site web personnel) . Évalué à 4.
Moins de 500 lignes de code à maintenir.
[^] # Re: vraiment ?
Posté par steph1978 . É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 Rémi Duraffort (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 steph1978 . É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.
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 Rémi Duraffort (site web personnel) . Évalué à 3.
voir "Cas d’usage" dans l'article.
Exactement c'est pour le système de CI.
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.
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 claudex . Évalué à 3.
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 Rémi Duraffort (site web personnel) . Évalué à 2.
Il faut aussi connaître la liste des domaines qui va falloir mettre en cache pour les inclure dans le Root CA.
[^] # Re: usage ?
Posté par steph1978 . É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 Rémi Duraffort (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.