Outils pour utilisateurs

Outils du site


projets:informatique:simulation_de_flux

Simulation de flux RSS pour FreshRSS

FreshRSS est un agrégateur de flux RSS. Il permet de regrouper au même endroit les articles proposés en scannant périodiquement les données mises à disposition par les sites. C'est très pratique car cela évite de devoir faire cela manuellement. Mais lors du développement de la solution ou lors de tests, cette fonctionnalité devient génante car les données changent. C'est pourquoi simuler les flux RSS dans ces conditions devient nécessaire.

Pour cela, nous allons utiliser un serveur de « mocks » qui nous servira des contenus prédéfinis. Ici, nous allons utiliser WireMock mais il existe d'autres solutions disponibles.

Mise en place de l'arborescence

Dans le répertoire de travail de WireMock, il faut créer les répertoires __files et mappings avec la commande suivante :

mkdir __files mappings

Le répertoire __files contiendra les fichiers de données des flux RSS tandis que le répertoire mappings contiendra les fichiers de correspondance entre les requêtes reçues et les réponses retournées.

Ces répertoires doivent être créés avec les permissions utilisées par le conteneur de Wiremock. Si ce n'est pas le cas, les fichiers pourraient ne pas être accessibles depuis le réseau interne. Pour éviter cela, il suffit de démarrer le conteneur de Wiremock. Celui-ci se chargera de créer les répertoires manquants.

Récupération des données des flux RSS

Il existe plusieurs méthodes pour récupérer les données d'un flux RSS. Ici, nous allons utiliser wget avec la commande suivante :

# Version courte
wget https://reddit.com/r/breadit/new/.rss -O breadit.rss
 
# Version longue
wget https://reddit.com/r/breadit/new/.rss --output-document breadit.rss
  • -O ou --output-document permet de nommer le fichier téléchargé.

Pour que cela fonctionne correctement, il faudra soit directement télécharger le fichier dans le répertoire __files soit l'y déplacer une fois téléchargé.

Configuration statique

Maintenant que nous avons nos données, il faut dire à WireMock comment les restituer. Pour cela, nous allons créer un fichier de configuration dans le répertoire mappings. Son nom n'a pas d'importance mais il doit posséder l'extension json et contenir du JSON valide. Nous allons créer le fichier breadit.json avec le contenu suivant :

{
	"request": {
		"method": "GET",
		"url": "/breadit.rss"
	},
	"response": {
		"status": 200,
		"bodyFileName": "breadit.rss",
		"headers": {
			"Content-Type": "application/rss+xml"
		}
	}
}

Ce fichier indique à WireMock de retourner le contenu du fichier précédemment téléchargé lors d'un appel GET sur l'URL définie.

Il faudra créer un fichier de configuration pour chaque fichier de données téléchargé. Pour 1 ou 2 fichiers, la tâche n'est pas trop importante mais nous allons vite nous rendre compte que ce n'est pas soutenable si le nombre de fichiers augmente sérieusement. C'est pour cela qu'il vaut mieux utiliser une configuration dynamique comme décrite plus bas.

Configuration dynamique

Pour traiter de nombreux messages, il vaut mieux opter pour une configuration dynamique. Nous allons donc créer le fichier feed.json dans le répertoire mapping avec le contenu suivant :

{
	"request": {
		"method": "GET",
		"urlPathPattern": "/.*"
	},
	"response": {
		"status": 200,
		"bodyFileName": "{{request.pathSegments.[0]}}",
		"transformers": ["response-template"],
		"headers": {
			"Content-Type": "application/rss+xml"
		}
	}
}

Voici ce qui change par rapport à la précédente configuration :

  • WireMock ne surveille pas une URL en particulier mais toutes les URLs qui ont le même format que celui décrit 1).
  • Le nom du fichier à retourner est directement extrait de la requête. Il est ajouté dans le modèle de réponse.
  • L'utilisation d'un système de modèle de réponse 2).

Le système de modèle de réponse ne fait pas partie intégrante de WireMock, c'est une extension. Il faudra donc la charger lors du démarrage pour pouvoir en profiter.

Lancement de WireMock

# Version courte pour configuration statique
docker run -it --rm -p 9090:8080 --name wiremock --network freshrss-network -v $PWD:/home/wiremock wiremock/wiremock:latest-alpine
 
# Version longue pour configuration statique
docker run --interactive --tty --rm --publish 9090:8080 --name wiremock --network freshrss-network --volume $PWD:/home/wiremock wiremock/wiremock:latest-alpine
 
# Version courte pour configuration dynamique
docker run -it --rm -p 9090:8080 --name wiremock --network freshrss-network -v $PWD:/home/wiremock wiremock/wiremock:latest-alpine --local-response-templating
 
# Version longue pour configuration dynamique
docker run --interactive --tty --rm --publish 9090:8080 --name wiremock --network freshrss-network --volume $PWD:/home/wiremock wiremock/wiremock:latest-alpine --local-response-templating
  • -i ou --interactive permet de garder l'entrée standard ouverte.
  • -t ou --tty permet l'allocation d'un pseudo-TTY.
  • --rm supprime automatiquement le conteneur lors de sa fermeture.
  • -p ou --publish permet de lier les ports du conteneur avec ceux de l'hôte.
  • --name nomme le conteneur.
  • --network permet de lier le conteneur à un réseau existant.
  • -v ou --volume permet de monter un répertoire local dans le conteneur.
  • --local-response-templating permet d'utiliser localement l'extension ResponseTemplateTransformer qui met en forme la réponse envoyée grace à un système de modèles. 3) 4)

Lors de l'utilisation avec configuration dynamique, il est important de charger l'extension appropriée. Si ce n'est pas le cas, cela ne fonctionnera pas.

Utilisation des données

Maintenant que notre conteneur est lancé, il est possible d'accéder aux données :

Mise à jour des configurations

Pour mettre à jour les configurations, il faut :

  • soit redémarrer le conteneur,
  • soit envoyer une requête POST à l'URL __admin/mappings/reset.

Liens

1)
Ici, toutes les URLs sont traitées
2)
Sans ce transformateur, la configuration de bodyFileName est inutile car elle ne sera pas interprétée comme un modèle de réponse
3)
Utile uniquement lors de l'utilisation de configurations dynamiques
4)
Ce n'est pas une option de docker, c'est un argument de la commande utilisée dans le conteneur.
5)
Utilisé quand le système de développement est dans un autre conteneur
6)
Utilisé quand le système de développement est sur le système hôte
projets/informatique/simulation_de_flux.txt · Dernière modification : 2022/10/03 18:46 de alexis