Edge pour Private Cloud v. 4.17.01
Une installation sur site de Edge Private Cloud, ou instance Edge, se compose de plusieurs Composants Edge installés sur un ensemble de nœuds de serveur L'image suivante illustre la relation entre la planète, les régions, les pods, les organisations, les environnements et les hôtes virtuels qui constituent Instance périphérique:
Le tableau suivant décrit ces relations:
|
Contient |
Associé à |
Par défaut |
|
|---|---|---|---|
|
Planète |
Une ou plusieurs régions |
n/a |
|
|
Région |
Un ou plusieurs pods |
"dc-1" |
|
|
Pod |
Un ou plusieurs composants Edge |
"central" |
|
|
Entreprise |
Un ou plusieurs environnements |
Un ou plusieurs pods contenant des processeurs de messages et un utilisateur agissant en tant qu'administrateur de l'organisation |
aucun |
|
Environment |
Un ou plusieurs hôtes virtuels |
Un ou plusieurs processeurs de messages dans un pod associé à l'organisation parente |
aucun |
|
Hôte virtuel |
Un ou plusieurs alias d'hôte |
aucun |
À propos de Planets
Une planète représente tout un environnement matériel et logiciel Edge, et peut contenir une ou plusieurs régions. Dans Edge, une planète est un regroupement logique de régions. Vous ne créez ni ne configurez explicitement une planète lors de l'installation d'Edge.
À propos des régions
Une région est un regroupement d'un ou de plusieurs pods. Par défaut, lorsque vous installez Edge, le programme d'installation crée une région unique nommée "dc-1" contenant trois pods, comme dans le tableau ci-dessous : affiche:
|
Région |
Pods de la région |
|---|---|
|
"dc-1" |
"gateway", "central", "analytics" |
L'image suivante montre les régions par défaut :
Cette image montre l'équilibreur de charge dirigeant le trafic vers le pod "gateway". La "passerelle" série d'annonces contient les composants de routeur Edge et de processeur de messages qui gèrent les requêtes API. Sauf si vous définissez plusieurs centres de données, vous ne devriez pas avoir à créer de régions supplémentaires.
Dans une installation plus complexe, vous pouvez créer deux régions ou plus. L'une des raisons de créer plusieurs régions est d’organiser les machines géographiquement, ce qui réduit le temps d’acheminement sur le réseau. Dans ce scénario, vous hébergez des points de terminaison d'API afin qu'ils soient géographiquement "proches" des consommateurs de ces API.
Dans Edge, chaque région est appelée centre de données. Un centre de données situé dans l'est des États-Unis peut ainsi gérer les requêtes provenant de Boston (Massachusetts), tandis qu'un centre de données situé à Singapour peut gérer les requêtes provenant d'appareils ou d'ordinateurs en Asie.
Par exemple, l'image suivante montre deux régions correspondant à deux centres de données :
À propos des pods
Un pod est un groupe d'un ou plusieurs composants Edge et de datastores Cassandra. Les composants Edge peuvent être installés sur le même nœud, mais ils sont plus couramment installés sur différents nœuds. Un datastore Cassandra est un référentiel de données utilisé par les composants Edge du pod.
Par défaut, lorsque vous installez Edge, le programme d’installation crée trois pods et associe le les composants Edge suivants et les datastores Cassandra avec chaque pod:
|
Pod |
Composants Edge |
Datastores Cassandra |
|
|---|---|---|---|
|
"gateway" |
Routeur, processeur de messages |
cache-datastore |
keyvaluemap-datastore |
|
"central" |
Serveur de gestion, Zookeeper, LDAP, UI, Qpid |
application-datastore
apimodel-datastore
audit-datastore
auth-datastore
|
identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-datastore
|
|
"données analytiques" |
Postgres |
analytics-datastore |
reportcrud-datastore |
Les composants Edge et les datastores Cassandra du pod "gateway" sont nécessaires au traitement des API. Ces composants et ces datastores doivent être opérationnels pour traiter les requêtes API. Les composants et les datastores des pods "central" et "données analytiques" ne sont pas nécessaires pour traiter les API, mais ils ajoutent des fonctionnalités supplémentaires à Edge.
L'image suivante montre les composants de chaque pod :
Vous pouvez ajouter des pods de processeur de messages et de routeur aux trois pods créés par par défaut. Vous pouvez également ajouter des composants Edge supplémentaires à un pod existant. Par exemple, vous pouvez ajouter des routeurs et des processeurs de messages supplémentaires au pod de passerelle pour gérer les charges de trafic accrues.
Notez que la "passerelle" le pod contient les composants de routeur Edge et de processeur de messages. Les routeurs n'envoient des requêtes qu'aux processeurs de messages du même pod et non aux processeurs de messages d'autres pods.
Vous pouvez utiliser l'appel d'API suivant pour afficher les informations d'enregistrement du serveur à la fin de l'installation pour chaque pod. C'est un outil de surveillance utile.
curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=podName
où ms_IP est l'adresse IP ou le nom DNS du serveur de gestion, et podName est :
- passerelle
- central
- analytics
Par exemple, pour la "passerelle" pod:
> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway
Le résultat s'affiche sous la forme suivante :
[ {
"externalHostName" : "localhost",
"externalIP" : "192.168.1.11",
"internalHostName" : "localhost",
"internalIP" : "192.168.1.11",
"isUp" : true,
"pod" : "gateway",
"reachable" : true,
"region" : "dc-1",
"tags" : {
"property" : [ {
"name" : "jmx.rmi.port",
"value" : "1101"
}, ... ]
},
"type" : [ "message-processor" ],
"uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
},
{
"internalIP" : "192.168.1.11",
"isUp" : true,
"pod" : "gateway",
"reachable" : true,
"region" : "dc-1",
"tags" : {
"property" : [ ]
},
"type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
"uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
},
{
"externalHostName" : "localhost",
"externalIP" : "192.168.1.11",
"internalHostName" : "localhost",
"internalIP" : "192.168.1.11",
"isUp" : true,
"pod" : "gateway",
"reachable" : true,
"region" : "dc-1",
"tags" : {
"property" : [ {
"name" : "jmx.rmi.port",
"value" : "1100"
}, ... ]
},
"type" : [ "router" ],
"uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]
L'attribut type indique le type de composant. Notez qu'il liste les datastores Cassandra enregistrés dans le pod. Alors que les nœuds Cassandra sont installés dans la "passerelle" pod, vous les datastores Cassandra enregistrés auprès de tous les pods s'affichent.
À propos des organisations
Une organisation est un conteneur pour tous les objets d'un compte Apigee, y compris les API, les produits d'API, les applications et les développeurs. Une organisation est associée à un ou plusieurs pods, où chaque pod doit contenir un ou plusieurs processeurs de messages.
Dans une installation sur site d'Edge Private Cloud, aucune organisation n'est créée par défaut. Lorsque vous créez une organisation, vous spécifiez deux informations:
- Utilisateur qui joue le rôle d'administrateur de l'organisation. Cet utilisateur peut ensuite ajouter utilisateurs à l'organisation et définir le rôle de chaque utilisateur.
- La "passerelle" pod contenant les processeurs de messages.
Une organisation peut contenir un ou plusieurs environnements. La procédure d'installation Edge par défaut vous invite à créer deux environnements : "test" et "prod". Toutefois, vous pouvez créer d'autres environnements si nécessaire, tels que "préproduction", "tests", etc.
L'organisation fournit des champ d'application pour certaines fonctionnalités d'Apigee. Par exemple, un mappage clé-valeur (KVM) les données sont disponibles au niveau de l'organisation, c'est-à-dire dans tous les environnements. D'autres fonctionnalités, telles que la mise en cache, sont limitées à un environnement spécifique. Les données d'analyse Apigee sont partitionnées en fonction d'une combinaison d'organisation et d'environnement.
Ci-dessous figurent les principaux objets d'une organisation, y compris ceux définis à l'échelle mondiale dans le organisation, et celles qui sont définies spécifiquement pour un environnement:
À propos des environnements
Un environnement est un contexte d'exécution d'exécution pour les proxys d'API dans une organisation. Vous devez déployer un proxy d'API dans un environnement avant de pouvoir y accéder. Vous pouvez déployer un proxy d'API dans un seul environnement ou dans plusieurs environnements.
Une organisation peut contenir plusieurs environnements. Par exemple, vous pouvez définir un environnement "dev", "test" et "prod" dans une organisation.
Lorsque vous créez un environnement, vous l'associez à un ou plusieurs processeurs de messages. Vous pouvez considérer un environnement comme un ensemble nommé de processeurs de messages sur lesquels les proxys d'API s'exécutent. Toutes les peuvent être associés aux mêmes processeurs de messages ou à des processeurs différents.
Pour créer un environnement, spécifiez deux informations:
- Organisation à laquelle appartient l'environnement.
- Les processeurs de messages qui gèrent les requêtes de proxy d'API vers l'environnement. Ces messages
Les processeurs doivent se trouver dans un pod associé à l'organisation parente de l'environnement.
Par défaut, lorsque vous créez un environnement, Edge associe tous les processeurs de messages disponibles dans la "passerelle" le pod avec l'environnement. Vous pouvez également spécifier un sous-ensemble des processeurs de messages disponibles afin que différents processeurs de messages gèrent les requêtes vers différents environnements.
Un processeur de messages peut être associé à plusieurs environnements. Par exemple, votre Edge contient deux processeurs de messages: A et B. Vous créez ensuite trois environnements dans votre organisation : "dev", "test" et "prod" :
- Pour les développeurs vous associez le processeur de messages A, car vous ne vous attendez pas à un volume important de trafic.
- Pour l'environnement de test, vous associez le processeur de messages B, car vous ne vous attendez pas à un volume de trafic important.
- Pour la "production" vous associez les processeurs de messages A et B pour gérer au niveau de la production.
Les processeurs de messages attribués à un environnement peuvent tous provenir du même pod plusieurs pods dans plusieurs régions et centres de données. Par exemple, vous définissez environnement "global" de votre organisation qui comprend des processeurs de messages de trois régions, ce qui signifie trois centres de données différents: États-Unis, Japon et Allemagne.
Le déploiement d'un proxy d'API dans l'environnement "global" entraîne l'exécution du proxy d'API sur les processeurs de messages de chacun des trois centres de données. Le trafic API arrivant à un routeur dans l'un de ces centres de données ne sera dirigé que vers les processeurs de messages de ce centre de données, car les routeurs ne redirigent le trafic que vers les processeurs de messages du même pod.
À propos des hôtes virtuels
Un hôte virtuel définit le port sur le routeur Edge sur lequel un proxy d'API est exposé et, par extension, l'URL que les applications utilisent pour accéder au proxy d'API. Chaque environnement doit définir au moins un hôte virtuel.
Assurez-vous que le numéro de port spécifié par l'hôte virtuel est ouvert sur le nœud de routeur. Vous pouvez puis accéder à un proxy d'API en envoyant une requête à:
http://<routerIP>:<port>/{proxy-base-path}/{resource-name}
https://<routerIP>:<port>/{proxy-base-path}/{resource-name}
où :
- http ou https : si l'hôte virtuel est configuré pour prendre en charge TLS/SSL, utilisez HTTPS. Si l'hôte virtuel n'est pas compatible avec TLS/SSL, utilisez HTTP.
- <routerIP>:<port> est l'adresse IP l'adresse e-mail et le numéro de port de l'hôte virtuel.
- {proxy-base-path} et {resource-name} sont définis lorsque vous créez le proxy d'API.
En règle générale, vous ne publiez pas vos API pour les clients avec une adresse IP et un numéro de port. À la place, vous définissez une entrée DNS pour le routeur et le port. Exemple :
http://myAPI.myCo.com/{proxy-base-path}/{resource-name}
https://myAPI.myCo.com/{proxy-base-path}/{resource-name}
Vous devez également créer pour l'hôte virtuel un alias d'hôte correspondant au nom de domaine du DNS entrée. Dans l'exemple ci-dessus, vous spécifiez un alias d'hôte de myAPI.myCo.com. Si vous ne disposez pas d'entrée DNS, définissez l'alias d'hôte sur l'adresse IP du routeur et le port de l'hôte virtuel, comme <routerIP>:port.
Pour en savoir plus, consultez la page http://apigee.com/docs/api-services/content/virtual-hosts.
en créant votre première organisation, l'environnement et l'hôte virtuel
Une fois le processus d'installation d'Edge terminé, votre première action consiste généralement à créer une organisation, un environnement et un hôte virtuel via le processus d'intégration. Pour effectuer intégration, exécutez la commande suivante sur le nœud du serveur de gestion Edge:
/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile
Cette commande prend en entrée un fichier de configuration qui définit un utilisateur, une organisation, un environnement et un hôte virtuel.
Par exemple, vous pouvez créer les éléments suivants:
- un utilisateur de votre choix qui occupe le rôle d'administrateur de l'entreprise ;
- Une organisation nommée example
- Un environnement de l'organisation nommé prod associé à tous les processeurs de messages du pod "gateway"
- Un hôte virtuel dans l'environnement nommé default qui autorise l'accès HTTP sur le port 9001
- Alias d'hôte pour l'hôte virtuel
Après avoir exécuté ce script, vous pouvez accéder à vos API à l'aide d'une URL au format suivant:
http://<router-ip>:9001/{proxy-base-path}/{resource-name}
Vous pourrez ajouter un nombre illimité d'organisations, d'environnements et d'hôtes virtuels ultérieurement.
Pour en savoir plus sur l'intégration, consultez Intégrer une organisation.