Versions Compared

Old Version 27

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added a note on deprecated steps

Multiexcerpt include
MultiExcerptNameold-dep-pattern
PageWithExcerptUsing Puppet Modules to Set up WSO2 API-M with Pattern 0

Hiera data sets that match the distributed profiles of WSO2 API Manager (api-store, api-publisher, api-key-manager, gateway-manager, gateway-worker, traffic-manager) are shipped with clustering related configuration that is already enabled. Therefore, you need to only do a few changes to set up a distributed deployment in your preferred deployment pattern, before running the Puppet Agent.

Follow the instructions below to configure clustering for a selected pattern:

Note

The following section contains clustering information for all the patterns. Therefore, make sure to only follow the configurations based on the pattern that you are working on.

  1. Add or update the host name mapping list.
    Puppet adds the required host entries explicitly in the /etc/hosts file in the Puppet Agent. For this purpose you have to update the hosts mappings appropriately in one of the following Hiera data files (YAML file) based on the pattern that you are using.

    • /etc/puppet/hieradata/<environment-name>/dev/wso2/wso2am_runtime/<pattern-number>/default.yaml

    • /etc/puppet/hieradata/<environment-name>/dev/wso2/wso2am_runtime/<pattern-name>/common.yaml 

    Localtabgroup
    localtab
    Localtab
    activetrue
    titlePattern 0

    If you are using pattern 0, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-0/default.yaml file.

    Code Block
    wso2::hosts_mapping:
  api_manager:
    ip: 127.0.0.1
    name: am.dev.wso2.org
    titlePattern 1

    If you are using pattern 1, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-1/default.yaml file.

    Code Block
    wso2::hosts_mapping:
  api_manager:
    ip: 127.0.0.1
    name: am.dev.wso2.org
    Localtab
    titlePattern 2

    If you are using pattern 2, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-2/default.yaml file.

    Code Block
    wso2::hosts_mapping:
  apim_analytics_server:
    ip: 192.168.57.29
    name: analytics.dev.wso2.org
  api_manager:
    ip: 127.0.0.1
    name: am.dev.wso2.org
    Localtab
    titlePattern 3

    If you are using pattern 3, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-3/common.yaml file.

    Code Block
    wso2::hosts_mapping:
  apim_keymanager:
    ip: 192.168.57.186
    name: km.dev.wso2.org
  apim_store:
    ip: 192.168.57.21
    name: store.dev.wso2.org
  apim_publisher:
    ip: 192.168.57.219
    name: pub.dev.wso2.org
  apim_gateway:
    ip: 192.168.57.216
    name: mgt-gw.dev.wso2.org
  apim_gateway_worker:
    ip: 192.168.57.247
    name: gw.dev.wso2.org
  apim_traffic_manager:
    ip: 192.168.57.35
    name: tm.dev.wso2.org
  svn:
    ip: 192.168.100.1
    name: svn.gw.am.dev.wso2.org
  apim_analytics_server:
    ip: 192.168.57.29
    name: analytics.dev.wso2.org
    Localtab
    titlePattern 4

    If you are using pattern 4, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-4/common.yaml file.

    Code Block
    wso2::hosts_mapping:
  apim_keymanager:
    ip: 192.168.57.186
    name: km.dev.wso2.org
  apim_store:
    ip: 192.168.57.21
    name: store.dev.wso2.org
  apim_publisher:
    ip: 192.168.57.219
    name: pub.dev.wso2.org
  apim_gateway_manager:
    ip: 192.168.57.216
    name: mgt-gw.dev.wso2.org
  apim_gateway_worker:
    ip: 192.168.57.247
    name: gw.dev.wso2.org
  apim_traffic_manager:
    ip: 192.168.57.35
    name: tm.dev.wso2.org
  svn:
    ip: 192.168.100.1
    name: svn.gw.am.dev.wso2.org
  apim_analytics_server:
    ip: 192.168.57.29
    name: analytics.dev.wso2.org
  apim_gateway_manager_dmz:
    ip: 192.168.57.5
    name: dmz-mgt-gw.dev.wso2.org
  apim_gateway_worker_dmz:
    ip: 192.168.57.218
    name: dmz-gw.dev.wso2.org
    Localtab
    titlePattern 5

    If you are using pattern 5, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-5/common.yaml file.

    Code Block
    wso2::hosts_mapping:
  apim_store:
    ip: 192.168.57.21
    name: store.dev.wso2.org
  apim_publisher:
    ip: 192.168.57.219
    name: pub.dev.wso2.org
  apim_gateway_manager:
    ip: 192.168.57.216
    name: mgt-gw.dev.wso2.org
  apim_gw_plus_km:
    ip: 192.168.57.247
    name: am.dev.wso2.org
  apim_traffic_manager:
    ip: 192.168.57.35
    name: tm.dev.wso2.org
  svn:
    ip: 192.168.100.1
    name: svn.gw.am.dev.wso2.org
  apim_analytics_server:
    ip: 192.168.57.29
    name: analytics.dev.wso2.org
    Localtab
    titlePattern 6

    If you are using pattern 6, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-6/common.yaml file.

    Code Block
    wso2::hosts_mapping:
  apim_keymanager:
    ip: 192.168.57.186
    name: km.dev.wso2.org
  apim_publisher_plus_store:
    ip: 192.168.57.21
    name: am.dev.wso2.org
  apim_gateway:
    ip: 192.168.57.216
    name: mgt-gw.dev.wso2.org
  apim_gateway_worker:
    ip: 192.168.57.247
    name: gw.dev.wso2.org
  apim_traffic_manager:
    ip: 192.168.57.35
    name: tm.dev.wso2.org
  svn:
    ip: 192.168.100.1
    name: svn.gw.am.dev.wso2.org
  apim_analytics_server:
    ip: 192.168.57.29
    name: analytics.dev.wso2.org
    Localtab
    titlePattern 7

    If you are using pattern 7, update the following section in the /etc/puppet/hieradata/dev/wso2/wso2am_runtime/pattern-7/default.yaml file.

    Code Block
    wso2::hosts_mapping:
  api_manager:
    ip: 127.0.0.1
    name: am.dev.wso2.org
  identity_server:
    ip: 192.168.57.35
    name: is.dev.wso2.org

  2. Add the Well Known Address (WKA) list for Gateway clusters and Publisher-Store cluster.
    The required configurations for clustering are already added, but you need to update the WKA IP addresses in the respective Hiera data files based on your deployment.

    Note

    This is not applicable to patterns 0, 1, 2, and 7 as those patterns do not have Gateway or Publisher-Store clusters.

    Localtabgroup
    Localtab
    activetrue
    idpattern3
    titlePattern 3

    There are 2 clusters in the pattern-3 deployment. Update the Well Known Address (WKA) list for the clusters as follows:

    Publisher-Store cluster
    This is a cluster of the Publisher node and the Store node. Update the WKA list in both the api-publisher.yaml and the store.yaml files with the IP addresses of Publisher and Store nodes.

    Code Block
      wka:
    members:
      -
        hostname: 192.168.57.219
        port: 4000
      -
        hostname: 192.168.57.21
        port: 4000


    Gateway cluster

    This is a cluster for the Gateway Manager node and the Gateway Worker node. Update the WKA list in both the gateway-manager.yaml and gateway-worker.yaml files with the IP addresses of Gateway Manager node and the Gateway Worker node.

    Code Block
      wka:
    members:
      -
        hostname: 192.168.57.216
        port: 4000
      -
        hostname: 192.168.57.247
        port: 4000
    Localtab
    idpattern-4
    titlePattern 4

    There are 3 clusters in the pattern-4 deployment. Update the Well Known Address (WKA) list for the clusters as follows:

    Publisher-Store cluster
    This is a cluster of the Publisher node and the Store node. Update the WKA list in both the api-publisher.yaml and the store.yaml files with the IP addresses of Publisher and Store nodes.

    Code Block
      wka:
    members:
      -
        hostname: 192.168.57.219
        port: 4000
      -
        hostname: 192.168.57.21
        port: 4000


    Gateway cluster

    There are 2 Gateway clusters in this pattern. One is in the ENV1 and the other one is in the ENV2. Each of those clusters consist of a Gateway Manager node and a Gateway Worker node.

    1. Configure the Gateway cluster in the ENV1
      Update the WKA list in both the gateway-manager-env1.yaml and gateway-worker-env1.yaml files with the IP addresses of Gateway Manager node and Gateway Worker node in the ENV1.

      Code Block
        wka:
    members:
      -
        hostname: 192.168.57.216
        port: 4000
      -
        hostname: 192.168.57.247
        port: 4000

    2. Configure the Gateway cluster in the ENV2
      Update the WKA list in both the gateway-manager-env2.yaml and gateway-worker-env2.yaml files with the IP addresses of the Gateway Manager node and the Gateway Worker node in the ENV2.

      Code Block
        wka:
    members:
      -
        hostname: 192.168.57.5
        port: 4000
      -
        hostname: 192.168.57.218
        port: 4000
    Localtab
    idpattern5
    titlePattern 5

    There are 2 clusters in the pattern-5 deployment. Update the Well Known Address (WKA) list for the clusters as follows:

    Publisher-Store cluster
    This is a cluster of the Publisher node and the Store node. Update the WKA list in both the api-publisher.yaml and the store.yaml files with the IP addresses of Publisher and Store nodes.

    Code Block
      wka:
    members:
      -
        hostname: 192.168.57.219
        port: 4000
      -
        hostname: 192.168.57.21
        port: 4000


    Gateway cluster

    This is a cluster for the Gateway Manager node and the node that has the Gateway Worker together with the Key Manager. Update the WKA list in both the gateway-manager.yaml and gw-plus-km.yaml files with the IP addresses of Gateway Manager node and the node that has the Gateway Worker together with the Key Manager.

    Code Block
      wka:
    members:
      -
        hostname: 192.168.57.216
        port: 4000
      -
        hostname: 192.168.57.247
        port: 4000
    Localtab
    idpattern6
    titlePattern 6

    There is one cluster in the pattern-6 deployment. Update the Well Known Address (WKA) list for the cluster as follows:

    The Gateway cluster is a cluster for the Gateway Manager node and the Gateway Worker node. Update the WKA list in both the gateway-manager.yaml and gateway-worker.yaml files with the IP addresses of Gateway Manager node and the Gateway Worker node.

    Code Block
      wka:
    members:
      -
        hostname: 192.168.57.216
        port: 4000
      -
        hostname: 192.168.57.247
        port: 4000

  3. Modify all the MySQL based datasources in the respective Hiera data file (YAML file) that corresponds to the pattern you are using in order to point to the external MySQL servers. 

    Note

    This is not applicable for pattern 0 as pattern-0 uses a H2 database.

    Update the following in the /etc/puppet/hieradata/wso2/wso2am_runtime/[pattern-number]/default.yaml file for patterns 1, 2 and 7 and  /etc/puppet/hieradata/wso2/wso2am_runtime/[pattern-number]/common.yaml file for patterns 3 to 6.

    1. You need to only replace the IP address, with the IP address of database server that you are using.

      Note

      If you want to use any other database except MySQL, update the data sources appropriately.

      Code Block
      titleExample:
         wso2_am_db:
      name: WSO2_AM_DB
      description: The datasource used for API Manager database
      driver_class_name: "%{hiera('wso2::datasources::mysql::driver_class_name')}"
      url: jdbc:mysql://192.168.57.210:3306/apimgtdb?autoReconnect=true
      username: "%{hiera('wso2::datasources::mysql::username')}"
      password: "%{hiera('wso2::datasources::mysql::password')}"
      jndi_config: jdbc/WSO2AM_DB
      max_active: "%{hiera('wso2::datasources::common::max_active')}"
      max_wait: "%{hiera('wso2::datasources::common::max_wait')}"
      test_on_borrow: "%{hiera('wso2::datasources::common::test_on_borrow')}"
      default_auto_commit: "%{hiera('wso2::datasources::common::default_auto_commit')}"
      validation_query: "%{hiera('wso2::datasources::mysql::validation_query')}"
      validation_interval: "%{hiera('wso2::datasources::common::validation_interval')}"

    2. Create following database schemas in MySQL server. The databases need to be created in each of the pattern is listed below.

      Names of the databases that need to be createdDescription
      apimgtdbDatabase used for managing APIs.
      configdbDatabase used for the config registry.
      govregdbDatabase used for the gov registry.
      userdbDatabase used for the user management and user store.
      mbstoredbDatabase used for message broker.
      statdbDatabase used for getting statistics for API Manager.
      Note

      Addition to that if you are using pattern-6, create analyticseventstoredb and analyticprocesseddatastoredb which are used for Analytics recode store.

      You need to run MySQL database scripts for following tables as mentioned below.

      databasescript
      apimgtdb

      <API-M_HOME>/dbscripts/apimgt/mysql.sql

      Note

      If you are using MySQL 5.7 or later version, select mysql5.7.sql located in same directory without using mysql.sql script.

      configdb

      <API-M_HOME>/dbscripts/mysql.sql

      Note

      If you are using MySQL 5.7 or later version, select mysql5.7.sql located in same directory without using mysql.sql script.

      govregdb

      <API-M_HOME>/dbscripts/mysql.sql

      Note

      If you are using MySQL 5.7 or later version, select mysql5.7.sql located in same directory without using mysql.sql script.

      userdb

      <API-M_HOME>/dbscripts/mysql.sql

      Note

      If you are using MySQL 5.7 or later version, select mysql5.7.sql located in same directory without using mysql.sql script.

      mbstoredb

      <API-M_HOME>/dbscripts/mb-store/mysql-mb.sql

      Note

      You do not need to run the database scripts against following databases as the database tables of them will be created at run time.

      • statdb
      • analyticseventstoredb
      • analyticprocesseddatastoredb

    3. If you are using a MySQL database, make the following changes:

      1. Download and copy the MySQL driver JAR (mysql-connector-java-5.1.39-bin.jar) to the locations /etc/puppet/environments/production/modules/wso2am_runtime/files/configs/repository/components/lib and /etc/puppet/environments/production/modules/wso2am_analytics/files/configs/repository/components/lib in Puppet Master.

      2. Uncomment the file_list entry for JDBC connector JAR in the relevant Hiera data files.

        Code Block
        wso2::file_list:
	- "repository/components/lib/%{hiera('wso2::datasources::mysql::connector_jar')}"

      3. Update the JAR file name appropriately if your file name is not mysql-connector-java-5.1.39-bin.jar, which is set as the default value.

        Code Block
        wso2::datasources::mysql::connector_jar: mysql-connector-java-5.1.39-bin.jar

  4. Configure deployment synchronization in each of the Gateway related nodes. 
    Use one of the following methods to carry out this configuration. 

    • Rsync

      Note

      WSO2 recommends rsync instead of SVN, for deployment synchronization as it is an efficient, easy to use and lightweight solution compared to SVN.


      Why can't I use SVN based deployment synchronization (Dep Sync)?

      WSO2 has identified some inconsistencies when using Hazelcast clustering. As a result, from API-M 2.1.0 onwards WSO2 API-M has been designed so that it is possible to deploy API-M in a clustered setup without using Hazelcast clustering, so that users can use Hazelcast clustering only when absolutely necessary. However, if you use deployment synchronization as a content synchronization mechanism, you are compelled to use Hazelcast clustering. Therefore, WSO2 does not recommend using SVN based deployment synchronization.

      If you prefer to use rsync, see Configuring rsync for Deployment Synchronization.

    • SVN Based
      Make the respective SVN based configurations in the following files based on the pattern that you are using.

      PatternFiles to Update
      Pattern 3/etc/puppet/hieradata/wso2/wso2am_runtime/pattern-3/gateway-manager.yaml /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-3/gateway-worker.yaml
      Pattern 4

      /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-4/gateway-manager-env1.yaml
      /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-4/gateway-worker-env1.yaml
      /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-4/gateway-manager-env2.yaml
      /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-4/gateway-worker-env1.yaml

      Pattern 5/etc/puppet/hieradata/wso2/wso2am_runtime/pattern-5/gateway-manager.yaml /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-5/gw-plus-km.yaml.yaml
      Pattern 6/etc/puppet/hieradata/wso2/wso2am_runtime/pattern-6/gateway-manager.yaml /etc/puppet/hieradata/wso2/wso2am_runtime/pattern-6/gateway-worker.yaml

      Configure the SVN based deployment synchronization changes as follows:

      1. Uncomment the SVN based deployment synchronization configurations in the following files based on the pattern and update the configurations where required.
        Patterns 3 to 6 are configured for SVN based deployment synchronization; however, the configurations are commented out by default.

        Code Block
        titleExample
        wso2::dep_sync:
    enabled: true
    auto_checkout: true
    auto_commit: true
    repository_type: svn
    svn:
       url: http://svnrepo.example.com/repos/
       user: username
       password: password
       append_tenant_id: true
      2. Copy the required JARs for SVN, into the respective locations.
        1. Copy the svnkit-all-1.8.7.wso2v1.jar into the <PUPPET_HOME>/modules/wso2am/files/configs/repository/components/dropins directory.
        2. Copy the  trilead-ssh2-1.0.0-build215.jar into the <PUPPET_HOME>/modules/wso2am/files/configs/repository/components/lib directory.

        3. Uncomment the file_list entries for the latter mentioned two JAR files in the respective Hiera data files related to gateway nodes. 

          Code Block
          wso2::file_list:
   -  "repository/components/dropins/svnkit-all-1.8.7.wso2v1.jar"
   -  "repository/components/lib/trilead-ssh2-1.0.0-build215.jar"