gpe_mw_ansible.3scale_multitenant
:scrollbar: :data-uri: :toc2: :linkattrs:
= 3scale_multitenant
== Vue d'ensemble
Cette charge de travail provisionne un seul 3scale API Manager centralisé dans un seul namespace OCP.
Cette charge de travail doit être exécutée une seule fois par cluster OCP.
Elle permet également la gestion (c'est-à-dire : création / suppression) d'un nombre configurable de locataires API dans l'installation du 3scale API Manager.
Ce rôle pourrait être précieux dans les circonstances suivantes :
. Formation dirigée par un instructeur (ILTs), hackathons et ateliers : + Étant donné un nombre X d'étudiants dans une ILT nécessitant 3scale, provisionnez un seul Red Hat 3scale API Manager multi-locataires central où chaque étudiant se voit attribuer son propre locataire. + L'étudiant reçoit des identifiants administratifs pour son locataire assigné. + Cette approche peut être plus souhaitable que l'alternative où chaque étudiant provisionne son propre 3scale API Manager.
. Activation de Red Hat 3scale + Quelques objectifs d'apprentissage pourraient être :
.. Démontrer le provisionnement de 3scale sur OCP. .. Intégration avec un fournisseur SMTP externe pour envoyer des e-mails et faciliter un flux d'auto-inscription des utilisateurs. .. Invocation de l'API REST Admin de 3scale en utilisant les tokens d'accès et de rafraîchissement OAuth2.
=== Prérequis
. La version de 3scale provisionnée dans ce laboratoire (v2.4) est connue pour fonctionner sur OpenShift Container Platform 4.8. + Cette version d'OpenShift doit déjà être préinstallée avant d'exécuter ce rôle Ansible.
. Utilisez une version de l'utilitaire oc qui correspond à votre cluster OCP cible, assurez-vous que l'utilitaire oc est déjà authentifié en tant qu'admin du cluster.
. Ce rôle Ansible nécessite l'installation des modules Python lxml et openshift sur l'hôte cible exécutant cet Ansible. c'est-à-dire : +
dnf install python3-lxml
dnf install python3-openshift
== API Manager
L'ansible décrit dans cette section peut provisionner un API Manager 3scale en utilisant des templates OpenShift.
=== Problèmes connus
. link:https://issues.redhat.com/browse/THREESCALE-5725[API Manager sur OpenShift compatible FIPS] . Correction ciblée : 3scale 2.12
=== Exigences de ressources
Ce rôle Ansible permet de provisionner 3scale de différentes tailles en fonction de la valeur de la variable Ansible suivante : is_production
. Utilisation des ressources : is_production = true .. Le quota de cluster pour le CPU et la RAM est fixé assez haut par défaut : ... Limite CPU : 30 cœurs ... Limite RAM : 30 Gi .. Les limites de CPU et de RAM définies dans le modèle 3scale API Manager sont également fixées assez haut. .. Ces paramètres par défaut sont intentionnellement définis élevés pour permettre un fort débit.
. Utilisation des ressources : is_production = false + C'est le paramètre par défaut. Les ressources nécessaires pour provisionner 3scale tombent à environ 12 Gi de RAM et 6 CPU.
=== Fournisseurs SMTP Vous devez vous être inscrit auprès d'un fournisseur SMTP pour permettre au 3scale API Manager d'envoyer des e-mails.
Dans 3scale, les paramètres SMTP sont configurés globalement et sont utilisés par tous les locataires API.
Quelques fournisseurs SMTP avec Plans Gratuits que ce rôle Ansible a testé sont listés ci-dessous :
. SocketLabs : Offre actuellement un plan gratuit permettant de link:https://www.socketlabs.com/signup/[2000 e-mails par mois]. . SendGrid : Offre actuellement un plan gratuit permettant de link:https://sendgrid.com/pricing/[100 e-mails par jour].
=== Variables d'environnement Toutes les variables d'environnement sont optionnelles.
Si aucune variable d'environnement n'est spécifiée, un plan de contrôle 3scale API Manager sera provisionné qui attend au moins un PVC RWX et ne s'intègre pas avec un fournisseur SMTP.
Le API Manager sera provisionné dans le namespace suivant : 3scale-mt-api0.
. amp_master_passwd + Optionnel. Valeur par défaut = master.
. master_access_token + Optionnel. Valeur par défaut = wtqhhsly.
. default_tenant_access_token + Optionnel. Valeur par défaut = 3832cnj371woiduh.
. is_production + Optionnel. Valeur par défaut = false.
. use_rwo_for_cms + Optionnel. Valeur par défaut = false. + Le plan de contrôle 3scale comprend un système de gestion de contenu (CMS) qui est généralement étendu pour améliorer les performances dans un environnement de production. Ce CMS nécessite ensuite un mode d'accès ReadWriteMany pour son PVC "system-storage" correspondant. Dans un déploiement de l'API Manager sur OCP 4.* où AWS EBS est utilisé pour le stockage, un mode d'accès ReadWriteMany link:https://docs.openshift.com/container-platform/4.2/storage/understanding-persistent-storage.html#pv-access-modes_understanding-persistent-storage[n'est pas disponible]. Dans ce scénario, réglez cette variable d'environnement sur : true. Cela permet de modifier le modèle du plan de contrôle 3scale pour spécifier ReadWriteOnce (et non ReadWriteMany). Si vous réglez ceci sur true, alors ne tentez pas de créer plus d'une réplique du pod system-app.
. Configurations SMTP pour permettre au API Manager d'envoyer des e-mails + Les e-mails sont utilisés de manière extensive pour soutenir les différents flux d'inscription vers le portail développeur 3scale. + L'intégration entre un fournisseur SMTP et 3scale se fait globalement pour l'ensemble du API Manager.
.. smtp_userid + Optionnel. Valeur par défaut = null. Si null, l'intégration entre le 3scale API Manager et le fournisseur SMTP ne sera pas configurée.
.. smtp_host .. smtp_port .. smtp_authentication .. smtp_passwd .. smtp_domain
. adminEmailUser + Optionnel. Valeur par défaut = jdoe.
. adminEmailDomain + Optionnel. Valeur par défaut = redhat.com.
. RESUME_CONTROL_PLANE_GWS + Optionnel. Valeur par défaut = true. + Le 3scale API Manager comprend par défaut une passerelle de mise en scène et une passerelle de production. Ces deux passerelles ne sont généralement pas utilisées pour appliquer des politiques API aux demandes car le "plan de données" (également appelé : passerelles) tend à être déployé dans un environnement différent. Cependant, la passerelle de mise en scène est nécessaire pour l'application web du fournisseur système pour détailler les politiques de l'API Gateway. Par conséquent, la valeur par défaut est : true.
. OCP_AMP_ADMIN_ID + Optionnel. Valeur par défaut = api0. + Utilisateur OCP qui possède le namespace OCP où se trouve l'API Manager. Un quota de cluster est attribué à cet utilisateur. REMARQUE : cet utilisateur OCP n'a pas nécessairement besoin d'exister.
=== Exécution
. Provisionner l'API Manager : +
$ ansible-playbook playbooks/apimanager.yml
. Remarquer toutes les routes de l'API Manager dans le namespace 3scale-mt-api0 : +
$ oc get route -n 3scale-mt-api0
. Optionnel : Supprimer l'API Manager : +
$ ansible-playbook playbooks/apimanager.yml -e ACTION=uninstall
== Locataire API Avec le provisionnement du 3scale API Manager, un locataire par défaut est créé.
Si nécessaire, l'ansible décrit dans cette section peut créer des locataires supplémentaires.
=== Variables d'environnement Toutes les variables d'environnement sont optionnelles.
Si aucune variable d'environnement n'est spécifiée, alors un seul locataire (appelé : ocp01) sera créé dans l'API Manager avec un utilisateur admin locataire de : api01 / admin. Des passerelles correspondantes seront également créées dans un namespace appelé : ocp01.
. orgName + Optionnel : Valeur par défaut = ocp01. + Spécifie le nom du locataire ainsi que le nom du namespace où les passerelles correspondantes seront provisionnées. + Utile si l'intention est de créer un seul locataire avec un nom spécifique.
. tenant_admin_user_name_base + Optionnel. Valeur par défaut = api. + Nom de base des utilisateurs API qui seront administrateurs de leurs locataires API (et administrateurs de leurs propres passerelles API). c'est-à-dire ; si les noms d'utilisateur API souhaités sont : api01, api02, api03 ....... , alors la valeur de cette variable devrait être : "api".
. tenantAdminPasswd + Optionnel : Valeur par défaut = admin.
. create_gws_with_each_tenant
+
Optionnel : Valeur par défaut = true.
+
Si vrai, alors un projet OCP avec des passerelles API sera créé pour chaque locataire correspondant dans le même cluster OCP où réside l'API Manager.
. ocp_user_name_base
+
Optionnel. Valeur par défaut = ocp.
+
Détermine le nom de base des utilisateurs OCP qui auront accès à leurs projets liés à la gestion des API correspondants.
c'est-à-dire ; si les noms d'utilisateur OCP sont : user01, user02, user03 ....... , alors la valeur de cette variable devrait être : "user".
. START_TENANT + Optionnel. Valeur par défaut = 1.
. END_TENANT + Optionnel. Valeur par défaut = 1.
. use_padded_tenant_numbers + Optionnel. Valeur par défaut = true. + Si vous créez des locataires génériques séquentiels, spécifiez si les noms des locataires doivent inclure un nombre avec un remplissage ou non. c'est-à-dire ; ocp01, ocp02 ... ocp10 ou ocp1, ocp2 ... ocp10. La valeur par défaut est true. La valeur par défaut correspond à l'utilisation par défaut de nombres avec remplissage dans : https://github.com/gpe-mw-ansible-org/rh-sso-multi-realm.
=== Exécution
. Provisionner : +
$ ansible-playbook playbooks/api_tenant.yml
. Après la fin du provisionnement des locataires, vous verrez des messages similaires aux suivants à la fin de la sortie standard d'ansible : +
ok: [localhost] => { "msg": [ "tenant_output_dir: /home/jbride/provisioning_output/3295.openshift.opentlc.com/tenants_3scale-mt-api0", "tenant_provisioning_log_file = /home/jbride/provisioning_output/3295.openshift.opentlc.com/tenants_3scale-mt-api0/tenant_provisioning.log", "tenant_provisioning_results_file = /home/jbride/provisioning_output/3295.openshift.opentlc.com/tenants_3scale-mt-api0/tenant_info_file_1_2.txt", "start and end tenants = 1 2", "create API Gateways for each tenant = true" ] }
. Le tenant_provisioning_results_file contient les détails d'identification et les URL de chaque locataire provisionné. + C'est un fichier délimité par des tabulations qui peut être importé dans Google Spreadsheets ou LibreOffice Calc.
== Passerelles API
Si votre API Manager et vos locataires sont déjà provisionnés et que des passerelles apicast correspondantes spécifiques à ce locataire sont souhaitées, alors cet ansible sera utile.
=== Variables d'environnement
. threescale_tenant_admin_accesstoken + Requis. + Valeur de la variable suivante lorsque le locataire 3scale a été créé : ADMIN_ACCESS_TOKEN. Alternativement, un nouveau token d'accès peut être créé depuis l'interface utilisateur d'administration du locataire 3scale : Icône d'engrenage -> Paramètres personnels -> Tokens -> Tokens d'accès -> Ajouter un token d'accès. Alternativement, cela peut être la "Provider API key" de votre administrateur de locataire 3scale.
. threescale_tenant_admin_hostname + Requis. + URL de la route administrateur fournisseur du locataire 3scale cible. + c'est-à-dire : t1-admin.apps.cluster-4663.4663.sandbox758.opentlc.com.
. gw_namespace + Optionnel. Valeur par défaut = user1-gw.
. threescale_version + Optionnel. Valeur par défaut = 3scale-2.10.0-GA-jbride. + D'autres balises sont listées link:https://github.com/3scale/3scale-amp-openshift-templates/tags[ici].
=== Exécution :
. Déployer les passerelles apicast +
$ ansible-playbook playbooks/api_gw.yml
-e threescale_tenant_admin_accesstoken=$threescale_tenant_admin_accesstoken
-e threescale_tenant_admin_hostname=$threescale_tenant_admin_hostname
== Ancien
=== Configuration Ansible
. Installer ce rôle localement +
$ ansible-galaxy install gpe_mw_ansible.3scale_multitenant --force -p $HOME/.ansible/roles
. Créer le Playbook : +
$ echo "
- hosts: all
become: false
gather_facts: False
vars_files:
roles:
- gpe_mw_ansible.3scale_multitenant " > /tmp/3scale_multitenant.yml
=== Provisionner le 3scale API Manager
Le namespace OCP pour l'application multi-locataire 3scale sera possédé par l'utilisateur suivant : {{OCP_AMP_ADMIN_ID}}.
{{OCP_AMP_ADMIN_ID}} se verra assigner un quota de cluster afin de gérer les limites et requêtes assignées à 3scale.
. Exécutez : +
Provisionnement de l'API Manager
$ ansible-playbook playbooks/apimanager.yml \
-e"use_rwo_for_cms=$use_rwo_for_cms"
-e"smtp_port=$smtp_port"
-e"smtp_authentication=$smtp_authentication"
-e"smtp_host=$smtp_host"
-e"smtp_userid=$smtp_userid"
-e"smtp_passwd=$smtp_passwd"
. Après environ 5 minutes, le provisionnement de l'API Manager devrait se terminer. . Étant donné que l'API Manager est une grande application avec de nombreux composants différents, les composants sont activés de manière ordonnée. + Par conséquent, l'ansible se place dans une boucle d'attente à chaque étape du processus de provisionnement.
=== Locataires nommés
Autre alternative à la capacité de créer une séquence de locataires génériques, un locataire nommé peut être créé individuellement.
orgName=openbanking-prod
ocpAdminId=ocp01 # nom de l'utilisateur OCP qui aura accès à leurs projets de gestion API correspondants.
tenantAdminId=api01 # nom de l'utilisateur API qui sera administrateur de leurs locataires API (et administrateurs de leurs propres passerelles API).
create_gws_with_each_tenant=true # si vrai, alors un projet OCP avec des passerelles API sera créé pour chaque locataire correspondant dans le même cluster OCP où se trouve l'API Manager.
gw_project_name=$orgName-gw
$ ansible-playbook -i localhost, -c local /tmp/3scale_multitenant.yml
-e"ACTION=tenant_mgmt"
-e"API_MANAGER_NS=$API_MANAGER_NS"
-e"adminEmailUser=$adminEmailUser"
-e"adminEmailDomain=$adminEmailDomain"
-e"create_gws_with_each_tenant=$create_gws_with_each_tenant"
-e"orgName=$orgName"
-e"ocpAdminId=$ocpAdminId"
-e"tenantAdminId=$tenantAdminId"
-e"gw_project_name=$gw_project_name"
-e"rht_service_token_user=$rht_service_token_user"
-e"rht_service_token_password=$rht_service_token_password"
==== Identifiants d'utilisateur du locataire
Chaque locataire est provisionné avec un utilisateur ayant des privilèges admin pour ce locataire.
L'identifiant et le mot de passe sont générés à l'aide des variables Ansible suivantes trouvées dans defaults/main.yml :
. Identifiant d'utilisateur admin locataire : {{ tenant_admin_user_name_base }} (c'est-à-dire : api01, api02, api03 ...., api10 ) . Mot de passe admin locataire : {{ tenantAdminPasswd }}.
=== État WILDCARD_DOMAIN obsolète dans l'API Manager Il peut y avoir des scénarios où le DNS de votre API Manager provisionné initialement est modifié. Spécifiquement, la valeur du paramètre WILDCARD_DOMAIN utilisée dans le provisionnement initial de votre API Manager n'est plus valide.
Un exemple de scénario où cela pourrait se produire est dans Ravello, où le provisionnement initial du 3scale API Manager serait capturé en tant que Blueprint Ravello. À l'exécution, une application Ravello est instanciée à partir de ce blueprint Ravello et le DNS d'exécution réel de l'application Ravello est appliqué. Ce DNS appliqué à l'application d'exécution sera différent du DNS utilisé initialement lors de la création du blueprint.
Pour corriger les problèmes liés à cet état obsolète, les étapes suivantes doivent être suivies :
. Mettre à jour toutes les routes dans le namespace de votre API Manager. . Mettre à jour les URL obsolètes trouvées dans la table system.accounts dans la base de données system-mysql du API Manager. . Changer la valeur de la variable THREESCALE_SUPERDOMAIN dans la configmap : system-environment.
Des exemples montrent comment modifier ce qui précède sont trouvés ici : link:https://gist.github.com/jbride/be32113707418cb43d73c9ef28a09b9d[ici].
ansible-galaxy install gpe_mw_ansible.3scale_multitenant