Azure API Management : Améliorer vos Policies

Bonjour, lors de mon dernier article, j’ai introduit Azure API Management. J’ai montré comment est-ce qu’on peut déployer une configuration d’APIM à travers Azure DevOps (Création d’une instance APIM, création des utilisateurs et groupes, déploiment du backend …). Comme je vous l’ai dit, API Management a une partie trop importante. Les policies !

Une policy est un document XML qui est composé d’une collection de déclaration “inbound” et “outbound” . vous pouvez trouver plus d’information dans la documentation Microsoft.

Les policies doivent être bien écrites (bien traitées :D). Ils vont contrôler vos APIs. Si vous écrivez une Policy qui n’est pas bonne, ça pourrait vous causer des problèmes en production ! Ci-dessous quelques bonnes pratiques que vous pouvez suivre pour bien “traiter” vos policies.

• Versionner vos Policies:

Après tout, les policies sont en quelques sortes un type de code qui doit être versionné. Imaginez que vous mettez à jours une policy, vous pensez que tout est bon, deux jours après, un client vous remonte un bug. Comment allez-vous faire un rollback ?

Bon, vous pouvez utiliser Git pour versionner les policies. Comme je vous ai dit, ils sont un fichier XML, vous n’avez qu’à mettre à jour ce fichier.

Prêtez attention à quelques détails qui concernent l’organisation de votre répertoire. Vous avez au moins deux policies. Une pour le produit et l’autre pour l’API. Votre répertoire doit être organisé selon une structure bien définie. Je vous propose la suivante :

Project Test : 
|-APIM
..|-Policies
  ..|-API
    ..|-myApiPolicy.xml
  ..|-Product
    ..|-myProductPolicy.xml

• Déployer automatiquement une Policie:

Oui ! Vous n’allez pas déployer la policy de l’environnement de Dev jusqu’à la prod manuellement. Vous pouvez créer une pipeline qui fera l’affaire à votre place.

Dans cet article, je vais créer une pipeline dans Azure DevOps qui va déployer la policy dans un environnement. J’utiliserai Azure Repos pour versionner mes policies.

Commençons par la création d’une nouvelle release pipeline. On doit choisir une source des artifacts :

Après en utilisant le fichier YML suivant

Ça va créer une tâche qui utilisera Azure Powershell. Pensez à changer AzureSubscription et ScriptPath ! L’étape doit être quelque chose qui ressemble à :

J’ai un script pour vous permettant de déployer une policy :D

Attends, attends qu’est ce que c’est ?

$ServiceName= $env:apimInstanceName
$ResourceGroupName = $env:resourceGroupName

Bon, j’ai défini le ressource groupe et le nom de l’instance APIM dans Azure DevOps. Donc le script sera indépendant de ces variables.

En lançant la pipeline, ça doit remplacer la policy par défaut par la suivante

Commençons la release

En vérifiant la policy

• Utilisation de “named values” :

Si vous avez des variables qui peuvent être utilisées dans des policies différentes ou de multiples fois dans une policy (un code de réponse ou un message d’erreur …). Je vous suggère d’utiliser les “named values” donc vous pouvez changer ces derniers sans avoir à redéployer la policy et changer dans toutes les policies (Risque d’oubli).

Imaginez que vous voulez appliquer des règles de throttling sur votre Instance d’APIM. Vous devez écrire une policy qui restreins une IP Cliente de ne réaliser que X appels chaque Y minutes :

<rate-limit-by-key  calls="X" renewal-period="Y" counter-key="IP" />

Maintenant, un jour vous décidez de changer les conditions en changeant la restreinte à X+10 appels par exemple. Sans named values, vous serez obligé de tout redéployer. Sauf si vous faites :

<rate-limit-by-key  calls={{numberOfCalls}} renewal-period={{restrictPeriod}} counter-key={{IpAdress}} />

Au lieu de tout redéployer, vous n’avez qu’à mettre à jour les named values d’APIM.

• Surveiller et test :

Si jamais vous écrivez une policy qui n’est pas bonne (même si vous croyez que ce n’est pas le cas :D), vous pourrez oublier quelque chose. L’idée c’est de construire des alertes sur la capacity.

Cliquez sur“New alert rule” et ajouter l’alerte

Il faut, toujours, toujours tester vos Policies avant le déploiement en production !

Tester la policy dépend de sa logique. Je vous propose de toujours écrire un script qui teste les policies (En envoyant des requêtes à APIM qui testera les impactes de votre modification) au lieu d’utiliser Postman !

Les policies peuvent augmenter la capacité de votre instance APIM.

Bella Ciao !