WSO2-AM: appels API en magasin échouent après le redémarrage

Question

Nous avons mis sur les versions les plus récentes de

• API Gestionnaire
• Identity Server
• données Analytics Server

dans séparé pods sur un cluster kubernetes (nous avons utilisé les scripts existants comme base pour créer les images docker), tous partageant des bases de données MySQL pertinentes hébergées dans un autre pod sur le même cluster. Après beaucoup de configuration, tout fonctionne comme prévu, nous pouvons ajouter des utilisateurs/rôles, créer/publier/invoquer des API et collecter des analyses sur ces appels. Le dernier problème auquel nous sommes confrontés est qu'une fois qu'une API a été publiée, il est possible de l'invoquer dans le magasin. Le problème apparaît une fois le pod API-manager redémarré (par exemple en redimensionnant le déploiement concerné vers le haut/bas, pas en utilisant le tableau de bord carbone), une fois que le gestionnaire API est opérationnel après un redémarrage (hard), le API publiées sont encore visibles dans le magasin, cependant, si l'on essaie de faire un appel à l'un des points d'extrémité (travail précédemment), un message 404 est retourné et l'API-gestionnaire enregistre l'erreur suivante:

INFO {org.apache.synapse.mediators.builtin.LogMediator} - STATUS = Message dispatched to the main sequence. Invalid URL, RESOURCE = /"context"/"endpoint being called"

où "context" est le contexte défini pour une API donnée lors de sa publication et "endpoint being called" le point de terminaison REST du service devant recevoir l'appel. De plus, si nous essayons d'apporter une modification à l'API dans l'éditeur (c'est-à-dire la re-publier), il semble qu'il y ait une chance sur 50/50 que cela fonctionne et répare tous les problèmes jusqu'au prochain redémarrage du pod ou une erreur levé lorsque vous cliquez sur le bouton "Suivant: Implémenter" sur la première étape, qui a déjà été enregistré here (bien qu'il dise qu'il a déjà été résolu dans une version précédente).

La configuration restante est la suivante:

utilisateurs/rôles

• utilisateur: prod, utilisé pour la création et la publication d'une API dans l'éditeur

• Rôles: Pro- rôle (rôle vide sans privilège), interne/créateur, interne/éditeur

• utilisateur: contre, utilisé pour appeler une API dans le magasin

• Rôles: contre-rôle (rôle vide, pas priviledges, juste pour fournir accès à l'API dans le magasin), interne/abonné

bases de données

• des arbitres WSO2_CARBON_DB à une base de données sur le pod MySQL, utilisé uniquement par l'API-Manager

• WSO2REG_DB est censé être la base de données de registre partagé entre les trois modules (am, das, est)

extrait du maître-sources de données.xml de l'am:

 <datasource> 
      <name>WSO2_CARBON_DB</name> 
      <description>The datasource used by the registry</description> 
      <jndiConfig> 
       <name>jdbc/WSO2CarbonDB</name> 
      </jndiConfig> 
      <definition type="RDBMS"> 
       <configuration> 
       <url>jdbc:mysql://mysql-apimdb:3306/amcarbondb?autoReconnect=true&amp;useSSL=false</url> 
       <username>wso2carbon</username> 
       <password>abc</password> 
       <driverClassName>com.mysql.jdbc.Driver</driverClassName> 
       <maxActive>50</maxActive> 
       <maxWait>60000</maxWait> 
       <testOnBorrow>true</testOnBorrow> 
       <validationQuery>SELECT 1</validationQuery> 
       <validationInterval>30000</validationInterval> 
       </configuration> 
      </definition> 
     </datasource> 

     <datasource> 
      <name>WSO2AM_DB</name> 
      <description>The datasource used for API Manager database</description> 
      <jndiConfig> 
       <name>jdbc/WSO2AM_DB</name> 
      </jndiConfig> 
      <definition type="RDBMS"> 
       <configuration> 
        <url>jdbc:mysql://mysql-apimdb:3306/apimgtdb?autoReconnect=true&amp;useSSL=false</url> 
        <username>wso2carbon</username> 
        <password>abc</password> 
        <defaultAutoCommit>false</defaultAutoCommit> 
        <driverClassName>com.mysql.jdbc.Driver</driverClassName> 
        <maxActive>50</maxActive> 
        <maxWait>60000</maxWait> 
        <testOnBorrow>true</testOnBorrow> 
        <validationQuery>SELECT 1</validationQuery> 
        <validationInterval>30000</validationInterval> 
       </configuration> 
      </definition> 
     </datasource> 

     <datasource> 
      <name>WSO2UM_DB</name> 
      <description>The datasource used by user manager</description> 
      <jndiConfig> 
       <name>jdbc/WSO2UM_DB</name> 
      </jndiConfig> 
      <definition type="RDBMS"> 
       <configuration> 
       <url>jdbc:mysql://mysql-apimdb:3306/userdb?autoReconnect=true&amp;useSSL=false</url> 
       <username>wso2carbon</username> 
       <password>abc</password> 
       <driverClassName>com.mysql.jdbc.Driver</driverClassName> 
       <maxActive>50</maxActive> 
       <maxWait>60000</maxWait> 
       <testOnBorrow>true</testOnBorrow> 
       <validationQuery>SELECT 1</validationQuery> 
       <validationInterval>30000</validationInterval> 
       </configuration> 
      </definition> 
     </datasource> 

     <datasource> 
      <name>WSO2REG_DB</name> 
      <description>The datasource used for registry</description> 
      <jndiConfig> 
       <name>jdbc/WSO2REG_DB</name> 
      </jndiConfig> 
      <definition type="RDBMS"> 
       <configuration> 
        <url>jdbc:mysql://mysql-apimdb:3306/regdb?autoReconnect=true&amp;useSSL=false</url> 
        <username>wso2carbon</username> 
        <password>abc</password> 
        <driverClassName>com.mysql.jdbc.Driver</driverClassName> 
        <maxActive>50</maxActive> 
        <maxWait>60000</maxWait> 
        <testOnBorrow>true</testOnBorrow> 
        <validationQuery>SELECT 1</validationQuery> 
        <validationInterval>30000</validationInterval> 
       </configuration> 
      </definition> 
     </datasource> 

Toutes ces bases de données se peuplée de l'utilisation et sont initialisés en utilisant les DBScripts des différents produits pour la configuration initiale. En outre, le registry.xml est configuré comme suit (montrant seulement les changements, le reste du fichier est tel qu'il est configuré par défaut):

<currentDBConfig>wso2registry</currentDBConfig> 
<readOnly>false</readOnly> 
<enableCache>false</enableCache> 
<registryRoot>/</registryRoot> 

<dbConfig name="wso2registry"> 
    <dataSource>jdbc/WSO2CarbonDB</dataSource> 
</dbConfig> 
<dbConfig name="govregistry"> 
    <dataSource>jdbc/WSO2REG_DB</dataSource> 
</dbConfig> 

<remoteInstance url="https://localhost:9943/registry"> 
    <id>gov</id> 
    <dbConfig>govregistry</dbConfig> 
    <cacheId>wso2carbon@jdbc:mysql://mysql-apimdb:3306/regdb</cacheId> 
    <readOnly>false</readOnly> 
    <enableCache>false</enableCache> 
    <registryRoot>/</registryRoot> 
</remoteInstance> 

<mount path="/_system/governance" overwrite="true"> 
     <instanceId>gov</instanceId> 
     <targetPath>/_system/governance</targetPath> 
</mount> 

<mount path="/_system/config" overwrite="true"> 
     <instanceId>gov</instanceId> 
     <targetPath>/_system/config</targetPath> 
</mount> 

En fin de compte, il semble être un problème avec certaines données étant Perdu lors du redémarrage car la mémoire du module n'est pas persistante, puisque nous avons déplacé toutes les bases de données vers un stockage persistant sur un autre module. Cependant, cela ne devrait pas poser de problème - à moins d'avoir manqué quelque chose. Y a-t-il un autre registre/source de données à ajouter/modifier? Toutes les autres sources de données par défaut (STATS, MB_STORE, METRICS) sont configurées pour utiliser le serveur MySQL, donc à moins qu'il n'y ait autre chose que les sources de données dans le dossier datasource, toutes les données doivent rester dans les bases de données MySQL correspondantes .

Answer 1

Je suppose que vous n'avez utilisé aucun stockage persistant pour API Manager. Lorsque vous créez une API, l'artefact de l'API est créé dans le système de fichiers et stocké dans l'emplacement wso2am-2.1.0/repository/deployment/server/synapse-configs/de fault/api. Vous devez disposer d'un stockage persistant pour 'wso2am-2.1.0/repository/deployment/server /'. Dans votre cas, lors du redémarrage, vous n'avez pas de données pertinentes car vous avez un nouveau pack.