Monter son premier Azure Application Gateway

Azure Application Gateway (AAG) est un service que je suis en train de découvrir sur mon projet. J’aimerai faire partager mon expérience, faire avec vous quelques expériences de configuration, voir comment le déboguer.

Je vais faire une petite série d’articles sur le sujet, on va commencer par un Hello World classique.

Au programme:

  • C’est quoi AAG
  • Déployer une gateway
  • Tester
  • Les erreurs que j’ai commis

C’est quoi AAG ?

Un équilibreur de charge qui agit sur les protocoles HTTP/HTTPS. Donc du web.

Il agit au niveau de la couche OSI niveau 7. La couche 7 est la plus proche de l’application web, AAG voit donc ce que voit l’appli, c’est à dire sa requête HTTP. AAG pourra donc router le traffic en fonction de l’url, du port, de cookies, de headers… Dans la terminologie AAG, les services cibles sont appelés des backends.

Il est possible d’exposer AAG sur internet, il est alors publiquement accessible. on peut aussi l’exposer sur une adresse privée.

 

Je n’en ferai pas la démonstration, mais on peut intégrer AAG avec App Insights ou Azure Monitor.

Une configuration AAG est composée de 5 objets:

  1. Un écouteur (listener)
    C’est le point d’entrée d’AAG.
    Une IP publique ou privée associée à un protocole en général HTTPS
  2. Des configurations HTTP
    C’est ici que l’on va renseigner le domaine et le certificat SSL/TLS
  3. des backends
    Les services cibles. N’importe quel service accessible via une IP: webb app bien sûr, mais aussi des VM par exemple. Les services peuvent très bien être hors Azure.
  4. Des backend pools
    Les backends que l’on cible avec les mêmes règles de routage peuvent être rassemblés dans un pool commun appelé backend pool
  5. une règle (rule)
    La règle va tout simplement agréger les 3 objets qui précèdent.

Un point à souligner: AAG est un service régional, il sera donc déployé à l’échelle d’une région. On peut mettre par dessus un Front Door par exemple qui est un service global.

Pour terminer sur le sujet, AAG existe en deux catégories:

  1. Standard
  2. Standard V2

2022-05-12_21-12-53

WAF est une option que je démontrerai dans un autre article. Il s’agit d’un pare-feu applicatif. On peut le mettre en place plus tard.

La version V2 offre diverses capacités supplémentaires. Par exemple:

  • Mise à l’échelle automatique
  • Zone de redondance
  • Intégration avec AKS ou KV (certificats)
  • Réécriture d’en-tête HTTP
  • Règle WAF personnalisées

Pour comprendre l’architecture d’AAG on peut consulter cette documentation:

https://docs.microsoft.com/fr-fr/azure/application-gateway/how-application-gateway-works

 

Préparation

Nous allons préparer tout de suite 3 services. Ces services serviront pour toute la série d’articles qui suit. On va déployer l’infrastructure suivante dans le groupe de ressources RG1:

2022-05-12_20-45-20

Deux Web Apps et un Key Vault. Prenez le Service Plan le moins cher.

  • Keyvault:
    amethystekv
  • Web apps:
    amethysteweb1
    amethysteweb2

Ouvrez ensuite la console afin de créer une page par défaut sur chaque site:

2022-05-15_14-50-33

 

Saisissez la commande:

echo « AmethysteWeb 1 » > Default.htm

Le site doit afficher:

AmethysteWeb 1

Faites de même pour AmethysteWeb2.

Monter une instance de AAG

Nous allons déployer les ressources suivantes:

  • Resource Group: RG2
  • AAG: amethystegw

Déployer

Basics

Le formulaire commence ainsi:

2022-05-12_21-10-05

 

  • Name: amethystegw
  • Tier: Standard
    Nous testerons d’autres options plus tard. Je n’ai pas encore parlé de la partie WAF qui fera l’objet d’un article.
  • VNET: on fera NEW et on garde les options par défaut
    AAG est déployé dans un sous-réseau qui doit lui être réservé.
  • SKU: small (les autres sont plutôt coûteux)

Frontends

L’onglet suivant s’appelle Frontends:

2022-05-11_23-08-06

C’est ici que l’on décide si AAG sera public ou pas. On garde l’option public, on peut revenir sur ce choix plus tard. Je créée aussi une IP publique avec les options par défaut.

Cette adresse sera celle consommée par les clients de l’AAG.

Backends

On passe à l’onglet Backends:

2022-05-11_23-29-22

On peut ajouter des backends à la configuration. On va installer un seul backend, mais on peut en ajouter plus tard. Cliquons sur ADD NEW BACKEND POOL. Une popin s’ouvre. On créé le backend :

  • amethyste1back

2022-05-12_21-35-34

Target Type est une liste déroulante dans laquelle je choisis le type de service de mon backend. Ici c’est App Services bien entendu:

2022-05-11_23-34-04

Vous noterez la possibilité d’une cible FQDN, on peut donc utiliser une ressource hors Azure comme backend du moment qu’elle a une IP.

En fonction du choix posé, Target affichera les options trouvées dans la région de l’AAG.

On peut aussi choisir plus tard la cible.

Au final:

2022-05-14_17-07-28

Configuration

Le dernier onglet est l’onglet Configuration. Il est doté de deux sous-onglets:

2022-05-14_17-10-15

C’est ici que l’on définit une règle. On clique sur ADD A ROOTING RULE:

2022-05-12_23-06-45

  • Rule name: rule1
  • Listener name: listener1

On laisse les valeurs par défaut des autres paramètres. Notez juste que l’option Error Page url permet d’ajouter des pages d’erreur pour les code 403 et 502:

2022-05-14_17-13-06

 

On passe ensuite sur l’onglet Backend targets:

2022-05-12_23-15-10

 

On a deux options:

  1. On route vers un des backends
  2. on route vers une url donnée

On va choisir la première option.

Des settings sont également attendus. On a en pas encore déclaré, on fait donc ADD NEW:

2022-05-15_15-42-16

 

  • Name: settings1
  • Protocol: HTTPS
  • HOST NAME: YES
  • Override: Pick host name from backend target

2022-05-14_17-17-33

 

Et voilà, il ne reste plus qu’à déployer:

2022-05-12_23-37-27

 

Bilan du déploiement

On teste

Ben oui on est impatient!

On récupère l’IP dans Overview:

2022-05-15_16-04-37

Et on lance:

2022-05-15_16-06-24

Tout baigne.

Une AAG c’est d’abord un équilibreur de charge. On va donc ajouter un deuxième membre dans le backend pool:

2022-05-15_16-17-03

On peut parfaitement ajouter autant de cible qu’on le souhaite dans un backend pool. Ces cibles ont simplement en commun de réagir à la même règle.

2022-05-15_16-20-58

L’opération prends quelques minutes.

Lancez plusieurs fois l’url maintenant. Vous devriez voir successivement les messages:

AmethysteWeb 1

AmethysteWeb 2

Est-ce terminé?

Avons nous terminé le déploiement?

On a vu comment accéder au site via la gateway, le problème est que l’accès direct est encore actif. Essayez de lancer :

https://amethysteweb2.azurewebsites.net/

Par exemple.

On a encore un peu de travail.

Première étape, dans Overview on récupère les infos de VNET:

2022-05-15_17-12-04

On se rend dans le portail de chaque Web Apps. Direction le menu Settings/Networking:

2022-05-15_17-13-38

On sélectionne Access restriction:

2022-05-15_17-15-38

On constate que l’on a une seule règle qui accepte n’importe quel trafic. Corrigeons ce point pour n’accepter que le trafic de la Gateway.

NOTE: On peut aussi remarquer les deux onglets. Il est en effet possible de poser des règles d’accès au site administratif (Kudu).

 

On fait ADD RULE:

  • Name: allow-aag
  • Priority: 1
  • Description: Accepte le trafic de l’AAG
  • Type: Virtual Network

On sélectionne les informations du réseau.

2022-05-15_17-20-56

On fait ADD RULE:

2022-05-15_17-22-08

Maintenant l’accès direct n’est plus possible:

2022-05-15_17-23-55

Par contre la Gateway y parvient sans problème.

 

On constatera que l’url reste sur l’IP de la gateway. Si ce n’était pas le cas, alors il y a sans doute un problème de configuration car vous ne passez plus par AAG.

La plus courante est peut-être de configurer (portail ou code de l’appli) une redirection automatique de HTTP vers HTTPS. Dans ce tuto on est en HTTP, ne pas oublier.

 

Les erreurs commises

Ma principale erreur a été de ne pas configurer l’option: PickHostNameFromBackendAddress.

2022-05-15_15-42-37

Comme on le fait dans les exemples où le site est déposé sur une VM.

On obtient alors des erreurs 502 et le statut du Backend est donc Unhealthy. 502 signifie qu’un problème de configuration de la Gateway se pose.

Une autre source de difficulté est de veiller à ce que les ressources soient dans la même région.

Examinons le portail

Jetons tout d’abord un œil sur le portail pour repérer les points intéressants.

Le menu le plus important est Backend Health:

2022-05-15_16-41-23

Il nous donne le statut des différents backend déclarés dans les pools.

Ici tout va bien. On se souvient que le statut UNHEALTHY est typique des backend mal configurés.

Si je stoppe une des Web Apps:

2022-05-15_16-44-49

Le problème est remonté et on ne balancera jamais sur l’instance en défaut.

NOTE: pour accélérer le cycle de test, allez dans Backend settings et faites une petite modification pour relancer un test de la ligne de vie.

 

L’assistant de création est un peu confus, mais une fois dans le portail, les choses sont mieux rangées:

2022-05-15_16-50-11

Configuration est intéressant pour modifier des réglages tels le nombre d’instances, le SKU ou le Tier:

2022-05-15_16-52-16

Les menus 2, 3, 4, 5 sont clairs je pense.

Le menu 6 (Health Probe) permet de déclarer des sondes personnalisées. C’est utile avec certains backend. On notera que l’assistant de déploiement en a créé une pour nous:

2022-05-15_16-54-25

Le menu Monitoring/Insights est intéressant:

2022-05-15_17-04-53

Il nous offre un état des lieux de ce qui a été déployé. C’est parfois utile pour s’y retrouver.

Les éléments sont cliquables.

Bibliographie

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s