Parcours F5 · Administrateur NGINX

Administrer NGINX : les quatre examens F5CAN

Comprendre NGINX OSS, lire sa configuration, publier les services, sécuriser les accès et diagnostiquer HTTP/TLS.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (5)

Prérequis et périmètre

Aucune certification préalable. Les quatre examens peuvent être passés dans n’importe quel ordre ; une pratique de Linux et HTTP facilite la progression.

Le catalogue affiche F5CAN1 à F5CAN4 ; certaines anciennes URLs et ressources emploient F5N1 à F5N4. Le blueprint concerne NGINX Open Source, pas les fonctionnalités propres à NGINX Plus. Consulter la fiche officielle F5.

F5CANR est le renouvellement pour les personnes ayant déjà obtenu F5-CA NGINX. Sa numérotation est globale (1.x à 4.x), contrairement aux quatre examens initiaux qui commencent chacun à 1.1. Consulter la fiche officielle F5.

Les étapes et exercices ci-dessous sont une proposition pédagogique Samhan. Les objectifs sont reformulés en repères courts ; leur périmètre détaillé reste celui des blueprints. Les exemples sont à adapter à un laboratoire autorisé et à la documentation de vos versions.

Examens associés

Comprendre en imageUne progression avec des preuves
Une progression avec des preuves Suivre une requête dans la configuration NGINX puis vérifier un changement avec une requête et les traces correspondantes. Objets, conditions et comparaisons du guide Configuration includes et contextes Requête vhost et location Service fichier ou upstream Diagnostic statut et journaux Modification validation et reload Recette requête reproductible Comprendre l’instance NGINX Le parcours porte sur NGINX Open Source.Commencez par distinguer contenu statique,reverse proxy, répartition et cache. Relevez lebinaire, les modules disponibles et les fichiersréellement chargés : l’emplacement des includesdépend notamment du paquet installé. Publier, répartir et mettre en cache Repérez le server sélectionné puis la location quireçoit la requête. Distinguez les en-têtes envoyésau serveur avec proxy_set_header et ceux ajoutésà la réponse avec add_header. Vérifiez aussi latransformation de l’URI selon la forme deproxy_pass. Régler accès, connexions, logs et TLS La limitation du nombre de connexions, celle desrequêtes et celle du débit répondent à desbesoins distincts. Justifiez la clé de comptage etles effets d’un proxy en amont avant d’utiliserl’adresse source comme identité. Valider un changement et isoler unepanne Tester une configuration ne revient pas àl’appliquer. nginx -t vérifie la syntaxe et l’accèsaux fichiers référencés ; nginx -T ajoute unaffichage de la configuration. Un reload réussiintroduit de nouveaux workers tandis que lesanciens terminent leurs connexions.

Suivre une requête dans la configuration NGINX puis vérifier un changement avec une requête et les traces correspondantes.

Télécharger le schéma en SVG · version claire
Étape 1

Comprendre l’instance NGINX

Le parcours porte sur NGINX Open Source. Commencez par distinguer contenu statique, reverse proxy, répartition et cache. Relevez le binaire, les modules disponibles et les fichiers réellement chargés : l’emplacement des includes dépend notamment du paquet installé.

Dessinez les contextes main, events, http, server et location. Identifiez le compte des workers et les droits nécessaires sur les fichiers. Pour chaque directive, vérifiez son contexte et sa règle d’héritage ; toutes les directives ne se transmettent pas de la même façon.

Exercice de compréhension

Sur une instance de laboratoire, localisez la configuration effective, ses includes et les comptes de processus. Expliquez où les workers partagent un état et où ils possèdent leurs propres ressources.

Inventaire et validation : nginx -T peut afficher des données sensiblesBash
nginx -v
nginx -V
sudo nginx -t
sudo nginx -T

Lectures pour cette étape

Étape 2

Publier, répartir et mettre en cache

Repérez le server sélectionné puis la location qui reçoit la requête. Distinguez les en-têtes envoyés au serveur avec proxy_set_header et ceux ajoutés à la réponse avec add_header. Vérifiez aussi la transformation de l’URI selon la forme de proxy_pass.

Pour le cache, définissez les réponses partageables, la clé et les conditions de contournement. Pour un upstream, comparez la méthode choisie et la détection passive des échecs. Une fonctionnalité Plus ne doit pas être supposée disponible dans le périmètre OSS.

Exercice de compréhension

Publiez deux backends de recette et une route statique. Testez le choix du vhost, le chemin transmis, un backend indisponible et un contenu authentifié qui doit rester hors cache.

Lectures pour cette étape

Étape 3

Régler accès, connexions, logs et TLS

La limitation du nombre de connexions, celle des requêtes et celle du débit répondent à des besoins distincts. Justifiez la clé de comptage et les effets d’un proxy en amont avant d’utiliser l’adresse source comme identité.

Conservez des journaux permettant de distinguer erreur client, NGINX et backend, sans y ajouter de secrets. Pour HTTPS, identifiez le certificat présenté, la clé privée, la chaîne et les contraintes du client. Un chiffrement client ne prouve pas que la connexion vers le backend est vérifiée.

Exercice de compréhension

Décrivez trois chemins : utilisateur autorisé, accès refusé et backend en erreur. Pour chacun, annoncez le statut, la trace attendue et le côté TLS impliqué.

Lectures pour cette étape

Étape 4

Valider un changement et isoler une panne

Tester une configuration ne revient pas à l’appliquer. nginx -t vérifie la syntaxe et l’accès aux fichiers référencés ; nginx -T ajoute un affichage de la configuration. Un reload réussi introduit de nouveaux workers tandis que les anciens terminent leurs connexions.

Face à un 403, 404 ou 502, cherchez la couche responsable avant de modifier la configuration. Comparez le vhost, la location, les permissions, les contraintes SELinux, le backend et les deux échanges TLS éventuels. Gardez une requête reproductible pour confirmer la correction.

Exercice de compréhension

Introduisez une erreur de syntaxe dans une copie de configuration de recette, puis un mauvais port backend. Expliquez pourquoi ces deux incidents ne se diagnostiquent pas avec la même preuve.

Requête de recette : nom, port et chemin à adapter à votre laboratoireBash
curl --resolve revision.example:8080:127.0.0.1 \
    -i http://revision.example:8080/health

Lectures pour cette étape

Relier les étapes

Préparez une publication de recette reproductible, son changement de configuration et un dossier de panne HTTP/TLS. Vérifiez les possibilités de votre binaire avant d’utiliser une directive.

Blueprints et références officielles

Références consultées le . Les versions et conditions d’accès évoluent : vérifiez votre fiche d’examen avant l’inscription.

Retrouver tous les parcours F5 · L’expertise F5 de Samhan

Échange

Un besoin concret autour de vos services applicatifs ?

Échangeons sur vos applications, vos accès et vos contraintes d’exploitation.