Ajouter plusieurs organisations hybrides à un cluster

Cet article explique comment ajouter une deuxième organisation Apigee hybrid (organisation) à un cluster Kubernetes existant. Dans cette configuration multi-organisation, les deux organisations utilisent et partagent le même anneau Cassandra. Vous pouvez configurer plusieurs environnements et groupes d'environnement pour chaque organisation.

Limites

Une configuration multi-organisation par cluster est soumise aux limitations suivantes. Tant que ces limitations ne sont pas corrigées, nous vous déconseillons d'utiliser cette configuration :

  • Si vous prévoyez de disposer de plusieurs instances Apigee hybrid, chaque instance doit avoir son propre cluster. Le fait d'exécuter plusieurs instances Apigee hybrid sur un même cluster Kubernetes peut entraîner des problèmes d'instabilité, ce qui peut entraîner des temps d'arrêt.
  • Toutes les journalisations des pods sont envoyées au premier projet Google Cloud configuré. Cette limitation est plus évidente dans l'outil Cloud Logging. Les métriques des autres organisations Apigee ne seront pas envoyées au projet Google Cloud correspondant. Les journaux sont toujours capturés au niveau du pod et peuvent être récupérés à l'aide des commandes kubectl. Ils ne sont toutefois pas envoyés au bon projet Cloud via Cloud Logging.
  • Vous ne pouvez pas supprimer les données d'organisation d'une seule organisation dans la base de données Cassandra. Cela signifie que vous ne pouvez pas supprimer les organisations de manière sélective. Toute modification de la configuration de la base de données affecte toutes les organisations déployées sur ce cluster.
  • La procédure de mise à niveau hybride met à niveau l'intégralité du cluster en une seule fois.
  • La sauvegarde et la restauration sont effectuées en tant que cluster et ne peuvent pas être effectuées pour une organisation spécifique.
  • La fonctionnalité Apigee API Monitoring (Chronologie, Récente, Examen) ne fonctionne que pour la première organisation configurée et déployée. Elle ne fonctionnera pas pour les autres organisations d'un cluster multi-organisation.

Options multi-organisation

Cette section décrit comment l'assistance Apigee gère les clusters multi-organisations existants et fournit des recommandations pour les déploiements ultérieurs :

  • Si vous avez déployé des clusters Kubernetes multi-organisations dans des contextes hors production et de production, l'assistance Apigee continuera à les prendre en charge. Notez toutefois les limites techniques décrites dans la section suivante. Nous vous recommandons de modifier vos déploiements de production futurs pour utiliser une organisation Apigee par cluster.
  • Si vous possédez des clusters multi-organisation existants dans des contextes hors production, l'assistance Apigee continuera à les prendre en charge. Nous vous recommandons de migrer tous les clusters de production vers une nouvelle configuration utilisant une organisation Apigee par cluster.

Prérequis

Avant de continuer, tenez compte des points suivants :

  • Vous devez disposer d'une organisation hybride existante avec un ou plusieurs environnements installés et configurés dans un cluster Kubernetes existant. Consultez les instructions d'installation de la solution hybride.
  • Lorsque vous combinez plusieurs organisations dans un seul cluster, les versions hybrides doivent toutes correspondre. Avant d'ajouter une deuxième organisation à un cluster, mettez à niveau l'installation hybride existante, si nécessaire. Consultez la page Mettre à niveau Apigee hybrid.

Créer une organisation à ajouter au cluster existant

Pour créer l'organisation supplémentaire, suivez les étapes décrites dans la section Partie 1 : Configuration du projet et de l'organisation.

Configurer la nouvelle organisation

Dans les étapes suivantes, vous allez créer un fichier de remplacement et le configurer pour la nouvelle organisation. Un fichier overrides.yaml n'accepte que les informations d'une organisation. Par conséquent, vous devez créer un fichier overrides.yaml et l'appliquer au cluster Kubernetes existant.

  1. Créez des comptes de service à utiliser avec la nouvelle organisation. Consultez la section Créer des comptes de service.
  2. Notez les fichiers de certificat TLS (.key et .pem) dans votre répertoire certs. Si vous devez les recréer, vous pouvez suivre les instructions de la section Créer des certificats TLS.
  3. Copiez le fichier overrides.yaml existant dans un nouveau fichier à utiliser comme point de départ pour configurer votre nouvelle organisation. Par exemple : new-overrides.yaml.
  4. Modifiez le nouveau fichier de remplacement avec les configurations suivantes :
    org: "new-org-name"
    instanceID: "instance-id"   ## Must match the instanceID of your existing org.
    
    multiOrgCluster: true ## Enables exporting metrics for this org to the Google Cloud Project named with gcp:projectID
    
    k8sCluster:
      name: "existing-cluster-name"
      region: "existing-cluster-analytics-region"
    
    gcp:
      projectID: "new-project-id"
      name: "new-project-id"
      region: "new-project-default-location"
    
    namespace: namespace ## must be the same for both new and existing orgs
    
    virtualhosts:
      - name: new-environment-group-name
        sslCertPath: ./certs/cert-file-name # .crt or .pem
        sslKeyPath: ./certs/key-file-name # .key
    
    envs:
      - name: new-environment-name
        serviceAccountPaths:
          runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json
          synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json
          udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json
    
    connectAgent:
      serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json
    
    mart:
      serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json
    
    metrics:
      serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json
    
    watcher:
      serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json
    

    Le tableau suivant décrit chacune des valeurs de propriété que vous devez fournir dans le fichier de remplacement. Pour en savoir plus, consultez la documentation de référence sur les propriétés de configuration.

    Variable Description
    new-org-name Nom de votre nouvelle organisation
    instance-id Toutes les organisations de ce cluster doivent avoir le même ID d'instance. Par conséquent, il doit correspondre à l'entrée instanceID du fichier de remplacement de votre organisation d'origine.
    existing-cluster-name Nom du cluster auquel vous ajoutez cette organisation. Il doit correspondre à l'entrée k8sCluster.name du fichier de remplacement de votre cluster d'origine.
    existing-cluster-analytics-region La région dans laquelle le cluster d'origine est provisionné. Il doit correspondre à l'entrée k8sCluster.region du fichier de remplacement de votre cluster d'origine.
    new-project-id ID de votre nouveau projet L'ID du projet et le nom de l'organisation sont identiques.
    new-project-default-location Région d'analyse que vous avez spécifiée lors de la création de la nouvelle organisation. Cet emplacement ne doit pas nécessairement être identique à celui de l'organisation existante.
    namespace Toutes les organisations du cluster doivent partager le même espace de noms. Veillez à utiliser le même espace de noms que celui utilisé pour l'organisation d'origine. L'espace de noms de la plupart des installations est apigee.
    new-environment-group-name Le groupe d'environnements que vous avez créé pour la nouvelle organisation.
    cert-file-name et
    key-file-name
    Les certificats TLS et les fichiers de clé pour le cluster que vous avez vérifié ou créé à l'étape 1 dans cette section.
    new-environment-name Nom de l'environnement que vous avez créé pour la nouvelle organisation.
    new-service-accounts-directory Répertoire où se trouvent les fichiers de clés du compte de service que vous avez créés pour la nouvelle organisation.

Appliquer la configuration

Appliquez la configuration de la nouvelle organisation à votre cluster :

  1. Procédez à une installation de dry run (test à blanc) pour détecter les problèmes éventuels :
    helm upgrade ORG_NAME apigee-org/ \
      --install \
      --namespace apigee \
      --atomic \
      -f OVERRIDES_FILE.yaml \
      --dry-run
    
  2. Si aucun problème ne se produit, appliquez les composants au niveau de l'organisation. Cette étape installe les tâches Cassandra (utilisateur et schéma), Apigee Connect, Apigee Watcher et les services MART :
    helm upgrade ORG_NAME apigee-org/ \
      --install \
      --namespace apigee \
      --atomic \
      -f NEW_OVERRIDES_FILE.yaml
    
  3. Installez l'environnement. Cette étape installe les composants apigee-runtime, du synchronisateur et UDCA, par environnement :
    helm upgrade ENV_NAME apigee-env/ \
      --install \
      --namespace apigee \
      --atomic \
      --set env=ENV_NAME \
      -f overrides.yaml \
      --dry-run
    
    helm upgrade ENV_NAME apigee-env/ \
      --install \
      --namespace apigee \
      --atomic \
      --set env=ENV_NAME \
      -f overrides.yaml
    
  4. Appliquez les modifications de l'équilibreur de charge. Cette étape configure l'entrée pour écouter les nouveaux hôtes virtuels pour la deuxième organisation :
    helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
      --install \
      --namespace apigee \
      --atomic \
      --set envgroup=NEW_ENV_GROUP_NAME \
      -f overrides.yaml \
      --dry-run
    
    helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
      --install \
      --namespace apigee \
      --atomic \
      --set envgroup=NEW_ENV_GROUP_NAME \
      -f overrides.yaml
    
  5. Activez l'accès au synchronisateur pour votre nouvelle organisation en suivant les étapes décrites dans la section Activer l'accès au synchronisateur.
  6. Par défaut, lorsque vous installez pour la première fois l'environnement d'exécution Apigee hybrid, le composant Telemetry est configuré avec le paramètre multiOrgCluster désactivé. Procédez comme suit pour activer la télémétrie multi-organisation pour chaque organisation de votre cluster :
    1. Supprimez le composant Telemetry existant à l'aide des commandes suivantes :
      helm delete telemetry
      
    2. Ajoutez la ligne suivante au fichier overrides.yaml de votre organisation existante.
      multiOrgCluster: true
    3. Appliquez les modifications afin d'installer le composant Telemetry pour l'organisation.

      Effectuez d'abord une simulation :

      helm upgrade telemetry apigee-telemetry/ \
        --install \
        --namespace apigee \
        --atomic \
        -f FIRST_OVERRIDES_FILE.yaml \
        --dry-run
      

      Si la simulation réussit, appliquez les modifications et installez le composant Telemetry :

      helm upgrade telemetry apigee-telemetry/ \
        --install \
        --namespace apigee \
        --atomic \
        -f FIRST_OVERRIDES_FILE.yaml
      
    4. Assurez-vous que la ligne suivante se trouve dans le fichier overrides.yaml de chaque nouvelle organisation.
      multiOrgCluster: true
    5. Appliquez les modifications afin d'installer le composant Telemetry pour chaque nouvelle organisation. Répétez cette opération pour chaque nouvelle organisation de votre cluster multi-organisations.

      Effectuez d'abord une simulation :

      helm upgrade telemetry apigee-telemetry/ \
        --install \
        --namespace apigee \
        --atomic \
        -f NEW_OVERRIDES_FILE.yaml \
        --dry-run
      

      Si la simulation réussit, appliquez les modifications et installez le composant Telemetry :

      helm upgrade telemetry apigee-telemetry/ \
        --install \
        --namespace apigee \
        --atomic \
        -f NEW_OVERRIDES_FILE.yaml