Stratégies de Distribution Basées sur les En-têtes HTTP dans Nginx

Dans Nginx, les stratégies de distribution basées sur les en-têtes HTTP représentent une fonctionnalité flexible et puissante, adaptée à de multiples scénarios incluant la gestion de clusters multiples, le déploiement progressif de services, et l'adaptation aux navigateurs. Cet article présente en détail plusieurs stratégies de distribution courantes basées sur les en-têtes, avec des exemples de configuration et des résultats pratiques.

1. Distribution Basée sur l'En-tête Host

Cette approche convient aux entreprises hébergeant plusieurs sites web, chacun configuré comme un cluster distinct. Nginx peut acheminer les requêtes vers différents clusters backend en fonction du champ Host dans les en-têtes HTTP.

2. Distribution Basée sur le Langage de Développement

Pour les sites web développés avec plusieurs technologies, tels que des pages PHP et JSP, Nginx peut router les requêtes vers les serveurs backend appropriés en fonction d'un champ spécifique (comme X-Dev-Language personnalisé).

3. Distribution Basée sur le Navigateur

Typiquement utilisée pour différencier les clients desktop et mobile ou pour l'adaptation aux navigateurs. Nginx identifie le type de navigateur client en examinant le champ User-Agent et distribue les requêtes en conséquence.

4. Distribution Basée sur l'IP Source

À l'aide du module ngx_http_geo_module, Nginx peut acheminer les requêtes vers différents serveurs en fonction de l'adresse IP du client. Cette méthode est particulièrement utile pour la distribution géographique ou l'équilibrage de charge.

5. Transfert en Fonction des En-têtes HTTP vers Différents Services

C'est le focus principal de cet article. Les deux exemples suivants illustrent comment mettre en œuvre cette approche.

Exemple Un : Distribution Basée sur un En-tête Personnalisé

http {
    map $http_service_version $destination_cluster {
        default       cluster_principal;
        "v2.0"        cluster_secondaire;
    }

    upstream cluster_principal {
        serveur principal.example.com;
    }

    upstream cluster_secondaire {
        serveur secondaire.example.com;
    }

    serveur {
        écoute 80;

        emplacement / {
            proxy_pass http://$destination_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Description de la configuration :

• map $http_service_version $destination_cluster : Définit la variable $destination_cluster en fonction de la valeur de l'en-tête service_version. Si l'en-tête a la valeur v2.0, la variable est définie sur cluster_secondaire, sinon elle utilise cluster_principal par défaut.
• proxy_pass http://$destination_cluster : Redirige la requête vers le serveur backend approprié en fonction de la valeur de $destination_cluster.

Résultats d'exécution :

Envoyons une requête HTTP avec l'en-tête service_version: v2.0. Nginx transmettra alors la requête à secondaire.example.com. Sinon, la requête sera acheminée vers principal.example.com.

curl -H "service_version: v2.0" http://votre_serveur_nginx/

La vérification des journaux des serveurs backend confirmera si la requête a été correctement redirigée.

Exemple Deux : Distribution Basée sur l'En-tête Accept

http {
    map $http_accept $api_version {
        default "";
        "application/vnd.api.v2.0+json" "v2";
    }

    upstream cluster_v1 {
        serveur api-v1.example.com;
    }

    upstream cluster_v2 {
        serveur api-v2.example.com;
    }

    serveur {
        écoute 80;
        nom_de_serveur demo.fr;
        charset utf-8;
        autoindex off;

        emplacement / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Port $server_port;
            proxy_set_header X-Forwarded-Ssl on;

            si ($api_version = "v2") {
                proxy_pass http://cluster_v2;
                break;
            }

            proxy_pass http://cluster_v1;
        }
    }
}

Description de la configuration :

• map $http_accept $api_version : Définit la variable $api_version en fonction de la valeur de l'en-tête Accept. Si Accept a la valeur application/vnd.api.v2.0+json, la variable est définie sur v2, sinon elle reste vide par défaut.
• si ($api_version = "v2") : Vérifie la valeur de $api_version pour décider si la requête doit être redirigée vers cluster_v2.

Résultats d'exécution :

Envoyosn une requête HTTP avec l'en-tête Accept: application/vnd.api.v2.0+json. Nginx transmettra alors la requête à api-v2.example.com.

curl -H "Accept: application/vnd.api.v2.0+json" http://demo.fr/

Comme précédemment, la vérification des journaux des serveurs backend confirmera le bon acheminement des requêtes.

Points Importants

1. Sécurité : Lors de la distribution basée sur les en-têtes, il est essentiel de s'assurer que ces en-têtes proviennent de sources fiables pour éviter les requêtes malveillantes avec des en-têtes falsifiés.
2. Performance : Un trop grand nombre de conditions et de logiques de distribution peut affecter les performances de Nginx. Des tests et optimisations approfondis sont recommandés en environnement de production.
3. Compatibilité : Différents clients et navigateurs peuvent supporter différemment les en-têtes HTTP. Il est crucial de vérifier que la stratégie de distribution fonctionne correctement sur les clients cibles.