Activer les clients non SNI et HTTP

Cet article explique comment activer les clients non SNI, les clients HTTP ou une combinaison des deux pour une utilisation avec Apigee hybrid.

Comment configurer un client non SNI

Cette section explique comment activer la compatibilité avec les clients non SNI (Server Name Indication) dans Apigee hybrid. Un client non SNI utilise le port 443. Il est nécessaire si vous souhaitez intégrer des instances d'exécution hybride avec Google Cloud Load Balancing ou pour les clients qui ne sont pas compatibles avec SNI.

Créez une définition de ressource personnalisée (CRD) ApigeeRoute. Assurez-vous que enableNonSniClient est défini sur true :
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: route_name
  namespace: apigee
spec:
  hostnames:
  - "*"
  ports:
  - number: 443
    protocol: HTTPS
    tls:
      credentialName: credential_name
      mode: SIMPLE
      #optional
      minProtocolVersion: TLS_AUTO
  selector:
    app: apigee-ingressgateway
  enableNonSniClient: true
```
Où :
- route_name est le nom que vous donnez à la CRD.
- credential_name est le nom d'un secret Kubernetes déployé sur le cluster contenant les identifiants TLS de votre hôte virtuel. Vous pouvez trouver le nom de l'identifiant à l'aide de la commande kubectl suivante :
```
kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
```
- hostnames doit être défini sur le caractère générique "*".
  Remarque : Ne créez pas deux objets ApigeeRoute avec un nom d'hôte générique "*".
Ouvrez le fichier de remplacement et apportez la modification décrite à l'étape suivante.

Pour chaque groupe d'environnement, ajoutez le nom ApigeeRoute à la propriété additionalGateways. Exemple :

virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]

Enregistrez le fichier CRD. Par exemple : ApigeeRoute.yaml

Appliquez l'objet CRD au cluster :

kubectl apply -f ApigeeRoute.yaml -n apigee

Appliquez la modification à virtualhosts :

$APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT

Remarques sur l'utilisation

Que se passe-t-il si le cluster comporte plusieurs organisations ?
Comme l'entrée est au niveau du cluster pour un port donné (443), et qu'il n'y a qu'une seule paire clé/certificat pour la CRD ApigeeRoute, toutes les organisations doivent partager la même paire clé/certificat.
Que se passe-t-il si le cluster comporte plusieurs groupes d'environnements ? Fonctionnera-t-il si les hôtes virtuels partagent la même paire clé/certificat ?
Tous les noms d'hôte de tous les groupes d'environnements doivent utiliser la même paire clé/certificat.
Pourquoi créer une ApigeeRoute plutôt que Gateway ?
Les ApigeeRoutes peuvent être validées par Apigee, ce qui n'est pas le cas de Gateway (le CRD d'Istio). Techniquement, même Gateway peut fonctionner, mais nous pouvons éviter des erreurs de configuration potentielles (via un webhook de validation).

Activer les clients HTTP

Cette section explique comment activer la compatibilité des clients HTTP dans Apigee hybrid.

Créez une définition de ressource personnalisée (CRD) ApigeeRoute. Exemple :

apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: route_name
  namespace: apigee
spec:
  hostnames:
  - "*"
  ports:
  - number: 80
    protocol: HTTP
  selector:
    app: istio-ingressgateway
  enableNonSniClient: true

Où :

route_name est le nom que vous donnez à la CRD.
hostnames doit être défini sur le caractère générique "*".
Remarque : Ne créez pas deux objets ApigeeRoute avec un nom d'hôte générique "*".

Ouvrez le fichier de remplacement et apportez la modification décrite à l'étape suivante.

Pour chaque groupe d'environnement, ajoutez le nom ApigeeRoute à la propriété additionalGateways. Exemple :

virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]

Enregistrez le fichier CRD. Par exemple : ApigeeRoute.yaml

Appliquez l'objet CRD au cluster :

kubectl apply -f ApigeeRoute.yaml -n apigee

Appliquez la modification à virtualhosts :

$APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT

Activer la compatibilité pour les clients non-SNI et HTTP

Cette section explique comment activer à la fois les clients non SNI (port 443) et HTTP (port 80) pour une utilisation avec Apigee hybrid.

Créez une définition de ressource personnalisée (CRD) ApigeeRoute. Exemple :

apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: route_name
  namespace: apigee
spec:
  hostnames:
  - "*"
  ports:
  - number: 443
    protocol: HTTPS
    tls:
      credentialName: credential_name
      mode: SIMPLE
      #optional
      minProtocolVersion: TLS_AUTO
  - number: 80
    protocol: HTTP
  selector:
    app: istio-ingressgateway
  enableNonSniClient: true

Où :

route_name est le nom que vous donnez à la CRD.
hostname doit être défini sur le caractère générique "*".
Remarque : Ne créez pas deux objets ApigeeRoute avec un nom d'hôte générique "*".
credential_name est le nom d'un secret Kubernetes déployé sur le cluster contenant les identifiants TLS de votre hôte virtuel. Vous pouvez trouver le nom de l'identifiant à l'aide de la commande kubectl suivante :
```
kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
```

Ouvrez le fichier de remplacement et apportez la modification décrite à l'étape suivante.

Pour chaque groupe d'environnement, ajoutez le nom ApigeeRoute à la propriété additionalGateways. Exemple :

virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]

Enregistrez le fichier CRD. Par exemple : ApigeeRoute.yaml

Appliquez l'objet CRD au cluster :

kubectl apply -f ApigeeRoute.yaml -n apigee

Appliquez la modification à virtualhosts :

$APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT