Gérer les composants du plan d'exécution

Cet article explique comment configurer et gérer les composants du plan d'exécution Apigee hybrid. Pour obtenir la liste des composants du plan d'exécution que vous pouvez configurer, consultez la section Présentation de la configuration du service d'exécution.

À propos du fichier de remplacement

La première fois que vous installez l'environnement d'exécution hybride dans un cluster, vous devez créer un fichier de remplacement de configuration. Ce fichier vous permet de remplacer les valeurs de configuration par défaut si nécessaire, de configurer des environnements, de référencer des certificats TLS et des clés de comptes de service, d'attribuer des pools de nœuds Kubernetes à des composants hybrides spécifiques, etc.

Les étapes d'installation du système hybride décrivent le processus de création d'un fichier de remplacement et le processus d'application de votre configuration à un cluster. Si vous souhaitez modifier la configuration ultérieurement, modifiez le fichier de remplacement que vous avez créé, puis appliquez-le à nouveau.

Modifier une configuration

Pour modifier la configuration d'un composant du plan d'exécution hybride, modifiez votre fichier de remplacement et appliquez les modifications avec Helm ou apigeectl en fonction de votre outil de gestion.

Par exemple, pour modifier le nombre d'instances dupliquées sur le processeur de messages, procédez comme suit :

  1. Ouvrez votre fichier OVERRIDES.yaml. Veillez à utiliser le même fichier de remplacement que celui utilisé pour installer l'environnement d'exécution hybride dans le cluster.
  2. Recherchez l'élément runtime dans le fichier. Exemple : 
    ...
runtime:
  nodeSelector:
    key: cloud.google.com/gke-nodepool
    value: apigee-runtime
  replicaCountMin: 1
  replicaCountMax: 2
...
  3. Modifiez les propriétés du nombre d'instances répliquées, selon vos besoins. Exemple : 
    runtime:
  nodeSelector:
    key: cloud.google.com/gke-nodepool
    value: apigee-runtime
  replicaCountMin: 2
  replicaCountMax: 20
  4. Appliquez les modifications à l'aide des commandes suivantes :

    Helm

    Vous devez installer un environnement à la fois. Spécifiez l'environnement avec --set env=ENV_NAME.

    1. Effectuez d'abord une simulation: 
      helm upgrade ENV_RELEASE_NAME apigee-env/ \
--install \
--namespace APIGEE_NAMESPACE \
--set env=ENV_NAME \
-f OVERRIDES_FILE \
--dry-run
      • ENV_RELEASE_NAME est le nom avec lequel vous avez déjà installé le chart apigee-env. Dans la version 1.10 d'Apigee hybrid, il s'agit généralement de apigee-env-ENV_NAME. Dans Apigee hybrid v1.11 et versions ultérieures, il s'agit généralement de ENV_NAME.
      • ENV_NAME est le nom de l'environnement que vous mettez à niveau.
      • OVERRIDES_FILE est le chemin d'accès à votre fichier de remplacements.1.3.6.
    2. Mettez à niveau le graphique : 
      helm upgrade ENV_RELEASE_NAME apigee-env/ \
--install \
--namespace APIGEE_NAMESPACE \
--set env=ENV_NAME \
-f OVERRIDES_FILE

    apigeectl

    Utilisez apigeectl pour appliquer la modification au cluster :

    apigeectl apply -f OVERRIDES.yaml --org --env apigee-env
  5. Vérifiez qu'il est opérationnel en vérifiant l'état de l'environnement correspondant : 
    kubectl -n APIGEE_NAMESPACE get apigeeenv

    NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d

Quelles propriétés de configuration pouvez-vous modifier ?

Vous trouverez la liste complète des propriétés configurables dans la documentation de référence sur les propriétés de configuration. La référence ne répertorie que les propriétés que vous pouvez modifier. Si vous essayez de modifier une propriété qui ne figure pas dans la référence, la modification est ignorée.

Comment utiliser la référence de configuration ?

La documentation de référence sur la propriété de configuration utilise la notation par points pour décrire les éléments de configuration. Le premier élément est le nom de l'élément de niveau supérieur suivi des propriétés et des propriétés enfants. Exemple :

ao.image.pullPolicy

Dans le fichier de remplacement, les propriétés sont au format YAML approprié. Dans l'exemple ci-dessus, l'élément ao de niveau supérieur est mis en retrait à gauche et les propriétés des sous-éléments sont mis en retrait juste en-dessous. Le code YAML requiert également le signe "deux-points" à la fin de chaque élément et sous-élément.

Par exemple, pour définir la propriété ao.image.pullPolicy sur Always, recherchez ce stanza YAML dans le fichier de remplacement et définissez-le comme suit :

ao:
  image:
    pullPolicy: Always

Autre exemple, la propriété cassandra.auth.admin.password (telle qu'elle est répertoriée dans la référence de la propriété Configuration) est utilisée pour définir le mot de passe administrateur Cassandra. Pour le modifier, localisez le code YAML suivant dans le fichier de remplacement et définissez-le comme suit :

cassandra:
  auth:
    admin:
      password: abc123

N'oubliez pas que la référence sur les propriétés de configuration décrit toutes les propriétés que vous pouvez définir dans des composants de plan d'exécution hybride. Suivez le modèle expliqué ci-dessus pour modifier ces éléments dans votre fichier de remplacement avant d'appliquer les modifications à votre cluster.

Utiliser un exemple prédéfini de fichier de remplacement

Lorsque vous installez pour la première fois l'environnement d'exécution hybride, Apigee vous recommande d'utiliser l'un des exemples de fichiers de remplacement préconfigurés. Ces exemples fournissent un ensemble complet de propriétés de configuration pour des scénarios d'installation spécifiques, tels que la configuration d'une installation de production ou de test. Il vous suffit de fournir les valeurs appropriées pour les propriétés et d'appliquer le fichier de remplacement à votre cluster. Pour en savoir plus, consultez la section Étape 6 : Configurer le cluster.

À propos de la configuration par défaut

Apigee conserve la configuration de ses composants par défaut dans le fichier HYBRID_ROOT_DIR/config/values.yaml. Vos fichiers de remplacement suivent la même structure YAML que values.yaml.

Un fichier de remplacement n'inclut généralement qu'un sous-ensemble des propriétés de configuration trouvées dans values.yaml. N'oubliez pas que toutes les propriétés ne sont pas modifiables. Lorsque vous appliquez une configuration à un cluster, vos remplacements sont fusionnés avec les valeurs par défaut pour créer la configuration complète du cluster Kubernetes. Consultez également la section Tester la configuration fusionnée.

Le code suivant montre la configuration par défaut du composant mart, figurant dans values.yaml. Notez que certaines valeurs ont des valeurs par défaut, tandis que d'autres, telles que sslCertPath et sslKeyPath, n'en ont pas. Vous devez fournir ces valeurs manquantes dans votre fichier de remplacement, comme expliqué dans la procédure d'installation. Si vous souhaitez modifier l'une des valeurs par défaut, assurez-vous qu'elles sont modifiables en consultant la documentation de référence sur les propriétés de configuration.

...
mart:
  replicaCountMin: 2
  replicaCountMax: 4
  targetCPUUtilizationPercentage: 75
  terminationGracePeriodSeconds: 30
  sslCertPath:
  sslKeyPath:
  hostAlias:
  nodeSelector:
    key:
    value:
  revision: blue
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-mart-server"
    tag: "1.3.6"
    pullPolicy: IfNotPresent
  resources:
    requests:
      cpu: 500m
      memory: 512Mi
  initCheckCF:
    resources:
      requests:
        cpu: 10m
  livenessProbe:
    timeoutSeconds: 1
    failureThreshold: 12
    periodSeconds: 5
    initialDelaySeconds: 15
  readinessProbe:
    timeoutSeconds: 1
    successThreshold: 1
    failureThreshold: 2
    periodSeconds: 5
    initialDelaySeconds: 15
  metricsURL: "/v1/server/metrics"
  cwcAppend: |
...

Si vous souhaitez modifier les valeurs par défaut d'un composant et que le composant ne se trouve pas déjà dans votre fichier de remplacement, vous pouvez copier son code YAML depuis values.yaml dans votre fichier de remplacement et le modifier à partir de ce dernier.

Exemples de fichiers de remplacement

Apigee fournit un ensemble d'exemples de fichiers de remplacement pour vous aider à configurer votre déploiement hybride. Il est recommandé de copier et de modifier le fichier de remplacement qui correspond le mieux à vos exigences d'installation.

Les exemples suivants sont inclus dans le répertoire HYBRID_ROOT_DIR/examples :

Exemples de fichiers de remplacement Description
overrides-small.yaml Cet exemple est idéal pour débuter et progresser rapidement. Il utilise l'empreinte minimale recommandée pour démarrer les composants d'exécution hybride. Cet exemple de configuration repose autant que possible sur les paramètres et les valeurs par défaut. Toutes les instances répliquées minimales sont définies sur 1.
overrides-medium.yaml Cet exemple constitue un bon point de départ pour les environnements de test et de contrôle qualité. Des composants individuels se sont vus attribuer un niveau supérieur de ressources pour traiter le trafic supplémentaire. Cassandra utilise des disques SSD pour améliorer les performances. Dans cet environnement, il est recommandé aux utilisateurs d'installer des composants avec état et sans état sur des nœuds distincts. Consultez la section Configurer des nœuds dédiés.
overrides-large.yaml Cet exemple constitue un bon point de départ pour les environnements hautes performances tels que la préproduction et la production. L'exemple comprend des propriétés permettant de définir des clés de chiffrement, des mots de passe, etc. Les composants individuels disposent d'au moins deux instances répliquées.

Annotations personnalisées

Les annotations sont des mappages clé-valeur permettant d'associer des métadonnées à des pods Kubernetes Apigee Hybrid. Vous pouvez créer des annotations personnalisées pour les propriétés suivantes, répertoriées dans la documentation de référence sur les propriétés de configuration :

Pour ajouter une annotation personnalisée, ajoutez un stanza au fichier OVERRIDES.yaml pour le composant correspondant.

L'exemple suivant montre comment une annotation peut être spécifiée dans les pods runtime :

runtime:
  annotations:
    businessunit: "bu1"

Tester la configuration fusionnée

Vous pouvez utiliser l'option --dry-run pour tester le fichier de configuration fusionnée sans l'appliquer réellement à votre cluster. Cette option est utile pour déboguer un problème d'installation, car elle indique exactement ce qui sera appliqué au cluster. Il est également recommandé de tester la configuration et de la stocker dans le système de gestion de code source pour que vous ayez une référence des ressources installées et configurées dans le cluster.

Helm

kubectl apply -k  apigee-operator/etc/crds/default/
      
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run
 
helm upgrade ingress-manager apigee-ingress-manager/ /
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run

apigeectl

APIGEECTL_HOME/apigeectl init -f overrides/OVERRIDES.yaml --dry-run=client

Pour en savoir plus, consultez la page apigeectl.

Créer plusieurs fichiers de remplacement selon vos besoins

Vous pouvez créer autant de fichiers de remplacement que vous le souhaitez, chacun d'entre eux répondant à une exigence spécifique. Par exemple, vous pouvez disposer d'un fichier de remplacement qui ajuste votre cluster pour la production, et un autre pour la création d'un cluster de test. Vous pouvez ensuite conserver ces fichiers dans votre système de gestion de code source.

Par exemple :

Helm

helm upgrade test-1-env apigee-env/ \
  --namespace apigee \
  --atomic \
  --set env=test-1-env \
  -f test-1-env-overrides.yaml

apigeectl

$APIGEECTL_HOME/apigeectl apply -f test-1-env-overrides.yaml --env test-1-env

Supprimer des composants spécifiques hybrides du plan d'exécution

Les composants du plan d'exécution incluent synchronizer, mart, runtime, cassandra et udca.

Pour supprimer les composants spécifiques hybrides du plan d'exécution de votre cluster, utilisez la commande helm delete ou apigeectl delete. Veillez à spécifier le même fichier de remplacement que celui utilisé pour installer les composants d'exécution.

Par exemple :

Helm

Avec Helm, vous devez supprimer chaque composant individuellement. Par exemple, pour supprimer le composant cassandra, exécutez la commande suivante : 
helm -n apigee delete datastore

Dans l'exemple ci-dessus, le composant Datastore a été installé sous le nom "datastore". Si vous l'avez installé avec un autre nom, vous devez fournir ce nom pour supprimer le composant. Par exemple, si vous avez installé le chart apigee-datastore avec helm install my-cassandra-storage apigee-datastore/, supprimez-le à l'aide de la commande suivante : 

helm delete -n apigee my-cassandra-storage

apigeectl

Avec apigeectl, vous pouvez supprimer tous les composants d'exécution en même temps ou limiter le champ d'application pour supprimer un composant à la fois. Par exemple, pour supprimer tous les composants en une seule fois : 
$APIGEECTL_HOME/apigeectl delete -f OVERRIDES_FILE.yaml

Pour supprimer le composant cassandra, procédez comme suit :

$APIGEECTL_HOME/apigeectl delete -f OVERRIDES_FILE.yaml --datastore

Pour recréer un ou plusieurs composants spécifiques (le groupe d'environnements dans cet exemple), procédez comme suit :

Helm

helm upgrade ENV_GROUP apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE.yaml

apigeectl

$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE.yaml --env ENV_NAME --settings virtualhosts