Forum général.général Requête HTTP pour obtenir la version mise en cache, même périmée

Posté par raspbeguy (site web personnel, Mastodon) le 25 avril 2023 à 10:57. Licence CC By‑SA.

Étiquettes :

avr.

2023

Bonjour,

J'utilise un miroir avec mise en cache du dépôt Alpine Linux pour mes machines virtuelles, le but étant de minimiser l'usage de bande passante et de rendre les mise à jour plus rapides sur tout mon parc.

Pour faire ça j'utilise nginx, avec une config pompée là dessus. Ça marche impec.

Cependant je voulais savoir s'il existait un moyen pour un client HTTP de demander au miroir de lui servir une ressource en version mise en cache, même si elle est périmée (sauf bien sûr si cette ressource n'existe pas dans le cache, auquel cas le miroir devra quand même aller chercher la ressource depuis l'origine).

Le cas d'usage est le suivant : Pour la création de machines virtuelles j'ai écrit un script pour allouer les ressources, définir la VM et installer le système à partir du miroir. Pour augmenter la vitesse de création de la machine virtuelle, j'aimerai que ce script utilise les paquets que mon miroir a dans son cache même s'ils sont périmés. La mise à jour des paquets se ferait ultérieurement si besoin.

J'ai regardé du côté de l'en-tête HTTP Cache-Control, il semble que la valeur only-if-cached semble convenir. Est-ce que ma compréhension de cet en-tête est bonne, et pensez-vous qu'il s'agisse du meilleur moyen pour parvenir à mon but ?

# cache vs mirroir

Posté par NeoX le 25 avril 2023 à 14:54. Évalué à 4.

si tu fais du cache, il expire au bout d'un temps X
au dela de ce temps X, les pages/fichiers n'existent plus sur la machine
si tu demandes un objet à ce moment là, elle ira le chercher sur internet
et ta demande suivante (avant X) sera repondu plus rapidement

ce que tu cherches à faire ressemble plus à du "mirroir"
pour debian cela se fait tres bien avec apt-mirror
cela clone le depot sur ta machine 'serveur'

et tu configures tes "clients" (VMs) pour venir uniquement prendre sur ce serveur.
ce dernier se met à jour quand necessaire, et fournira meme si tu n'as plus d'internet

à voir si "alpine" prevoit une fonctionnalité "mirroir"
- [^] # Re: cache vs mirroir
  
  Posté par Sacha Trémoureux (site web personnel) le 25 avril 2023 à 18:00. Évalué à 2.
  
  Tout est là https://wiki.alpinelinux.org/wiki/How_to_setup_a_Alpine_Linux_mirror
  - [^] # Re: cache vs mirroir
    
    Posté par raspbeguy (site web personnel, Mastodon) le 26 avril 2023 à 10:41. Évalué à 2. Dernière modification le 26 avril 2023 à 10:41.
    
    Je faisait ça avant. Simplement, je n'ai pas envie de télécharger tous les paquets, seulement ceux dont mes machines ont besoin. D'où l'idée du cache.
    
    Un gentil du net
- [^] # Re: cache vs miroir
  
  Posté par Benoît Sibaud (site web personnel) le 08 mai 2023 à 17:16. Évalué à 3.
  - si le serveur fait miroir, les anciens paquets ne sont plus disponibles (ni comme fichiers, ni dans les métadonnées). Ex: tu veux la version libtropsecure-2.0.0-10 mais la version libtropsecure-2.0.0-11 est parue pour corriger un gros bug ou un souci de sécurité, alors l'ancien paquet va disparaître du dépôt officiel, et donc des miroirs.
  - si le serveur fait cache, alors les métadonnées ne référenceront plus les anciens paquets, donc il faut générer soi-même les métadonnées, lister tous les paquets disponibles, produire les métadonnées associées et les republier (soit sans signature GPG, soit avec une autre signature GPG que le dépôt initial s'il en avait une). Ex: ton cache contiendra libtropsecure-1.0.0-1 à -11 (ou plus probablement seulement celles qui ont été téléchargées depuis ce cache), tandis que le dépôt officiel ne les contiendra plus.
  On ne peut pas vraiment faire les deux simultanément… au mieux on peut avoir un cache complet, de tout ce qui a pu exister, mais les métadonnées seront différentes et potentiellement signées par une autre clé GPG, et ce cache complet contiendra certes tout ce qu'il y aurait comme paquets dans un miroir, mais aussi bien d'autres plus anciens.
  
  (autre problématique : quand le miroir se met à jour, il peut manquer des fichiers et/ou des métadonnées suivant l'ordre de mise à jour du serveur sur lequel on se base soi-même, et qui a lui-même le même souci ; quand le cache se met à jour, lui il a déjà les fichiers, mais il doit remettre à jour les métadonnées, et en général ce n'est pas une opération atomique donc ça se voit transitoirement pour un client qui l'utiliserait en récupération de métadonnées)
  
  (et il n'y a qu'un 'r' à miroir en français contrairement à mirror en anglais ou Mirrorseite en allemand)
# Miroir ou proxy ?

Posté par -=[ silmaril ]=- (site web personnel) le 25 avril 2023 à 15:14. Évalué à 5.
J'utilise un miroir avec mise en cache du dépôt Alpine Linux

ce n'est donc pas un miroir, juste un proxy cache.

Cependant je voulais savoir s'il existait un moyen pour un client HTTP de demander au miroir de lui servir une ressource en version mise en cache, même si elle est périmée

Souvent quand on pense devoir détourner le fonctionnement d'un outil c'est qu'on a soit pas compris les mechanismes racines de celui-ci ou qu'on a déployé une configuration qui ne correspond pas a nos besoins ^{^}

Dans ton exemple, la durée d'inactivité avant suppression du cache est d'un an, mais les données ne sont mise en cache au mieux que sur une journée ce n'est pas bien cohérent.

J'ai regardé du côté de l'en-tête HTTP Cache-Control, il semble que la valeur only-if-cached semble convenir. Est-ce que ma compréhension de cet en-tête est bonne, et pensez-vous qu'il s'agisse du meilleur moyen pour parvenir à mon but ?

pas vraiment non:

The “only-if-cached” request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code.

Si tu veut que ton cache soit utilisé en priorité sur de longues périodes il faut augmenter la durée de mise en cache et baisser les possibilitées de revalidation.
Dans ton cas l'index des APK n'est en cache que pour 1 minute a cause des lignes 57-60 du fichier en exemple:
```
location ~ ^/alpine/(?<target_uri>.*/APKINDEX\.tar\.gz)$ {
    proxy_pass http://alpine-mirrors/$target_uri;
    proxy_cache_valid 200 1m;
}
```
Ajouter "updating" à la ligne "proxy_cache_use_stale" permettra aussi à ton proxy de fournir la version précédente pendant la phase de mise à jour de la ressource ce qui devrait beaucoup aider à ton problème.

Au niveau validitées des caches, l'index je le monterai à 4h à minima, voir une journée, tandis que le reste doit pouvoir être monté à plusieurs mois, je ne connais pas alpine plus que ça mais un package n'a pas de raison d'être modifié in-place
- [^] # Re: Miroir ou proxy ?
  
  Posté par raspbeguy (site web personnel, Mastodon) le 26 avril 2023 à 10:50. Évalué à 1.
  Dans ton exemple, la durée d'inactivité avant suppression du cache est d'un an, mais les données ne sont mise en cache au mieux que sur une journée ce n'est pas bien cohérent.
  
  Ce n'est pas parce que les données sont "périmées" au sens HTTP que le serveur doit supprimer le cache, notamment pour ce que je cherche à faire.
  
  Dans ton cas l'index des APK n'est en cache que pour 1 minute a cause des lignes 57-60 du fichier en exemple
  
  Je pense que tu as mal recopié la conf, la config que j'ai mis en lien c'est ça :
```
    proxy_cache_valid any 1m;
    proxy_cache_valid 200 1d;
```
  Ce qui veut dire qu'il garde les réponses en 200 sur 1 jour et tout le reste une minute seulement.
  
  En pratique sur ma conf à moi j'ai changé pour que les 200 soient fraîches sur 1 an au lieu d'1 jour.
  
  Ajouter "updating" à la ligne "proxy_cache_use_stale" permettra aussi à ton proxy de fournir la version précédente pendant la phase de mise à jour de la ressource ce qui devrait beaucoup aider à ton problème.
  
  Je vais essayer, merci.
  
  Un gentil du net
  - [^] # Re: Miroir ou proxy ?
    
    Posté par Gil Cot ✔ (site web personnel, Mastodon) le 26 avril 2023 à 23:08. Évalué à 3. Dernière modification le 26 avril 2023 à 23:08.
    
    Je pense que tu as mal recopié la conf, la config que j'ai mis en lien c'est ça :
    
    Dans ce cas, je me demande si l'ordre n'a pas de l'importance (et donc que le cas any devrait être indiqué en dernier…)
    
    “It is seldom that liberty of any kind is lost all at once.” ― David Hume
  - [^] # Re: Miroir ou proxy ?
    
    Posté par -=[ silmaril ]=- (site web personnel) le 09 mai 2023 à 14:19. Évalué à 2.
    
    Ce n'est pas parce que les données sont "périmées" au sens HTTP que le serveur doit supprimer le cache, notamment pour ce que je cherche à faire.
    
    Vu que tu travaille avec un serveur de type proxy cache HTTP bien sûr que si.
    
    Je pense que tu as mal recopié la conf, la config que j'ai mis en lien c'est ça :
    …
    
    Ce sont les lignes 41/42 oui mais la ligne 59 override ce paramêtrage pour les index de paquets:
    
    location ~ ^{/alpine/(?.*/APKINDEX.tar.gz)$} {
    proxy_pass http://alpine-mirrors/$target_uri;
    proxy_cache_valid 200 1m;
    }
    
    sinon si tu veut gérer plus finement ton cache le mieux est probablement de faire un vrai mirroir pour le coup:
    https://wiki.alpinelinux.org/wiki/How_to_setup_a_Alpine_Linux_mirror
# Alpine APK

Posté par steph1978 le 08 mai 2023 à 16:29. Évalué à 2.

Ce que tu décris n'est pas faisable en tant que tel.

Il faut que tu te familiarises avec le système de gestion de paquets logiciels de Alpine : https://wiki.alpinelinux.org/wiki/Apk_spec#Index_Format_V2

Suivre le flux des commentaires

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