Hi Imesh, Your intention I believe is to make API Manager artifact synchronisation possible in containerized environments without modifying the existing product and without using deployment synchronizer. Correct?
Looking at the suggested approach from a high level, this is quite similar to using dep-sync with a periodic svn checkout on the Gateway worker nodes instead of relying on the cluster message to arrive to check of updates. If we opt for the dep-sync option without relying on the cluster message, will it still be a problem for containers? On Tue, Apr 26, 2016 at 3:15 PM, Imesh Gunaratne <[email protected]> wrote: > Hi All, > > This is to propose a new model for synchronizing Synapse APIs generated by > API Publisher in API Gateway worker nodes in containerized environments. > Here we are trying to avoid using SVN based deployment synchronizer. This > proposal may apply to Kubernetes, Apache Mesos or any other container > cluster management systems. Please refer the below diagram: > > > The idea is to use one of the standard API-M deployment patterns and > deploy two new components in Gateway Manager node and Gateway Worker nodes > for synchronizing APIs; API Sender WAR and API Receiver Bundle. This is how > it would work: > > - User publishes an API via API Publisher > - API Publisher makes a service call to API Gateway Manager to > generate the Synapse API > - API Gateway writes the Synapse API definition to the disk > - API Sender WAR exposes the Synapse API definition on the filesystem > via an API endpoint (X) > - API Receiver Bundle will poll the above API endpoint (X) with a > given time interval, if any new APIs available those will be pulled and > deployed in each API Gateway Worker node. > > You will have to check for new APIs and modifications to existing APIs as well. Which means you will have to write something quite similar to what the svn diff tool does. We will have to be a bit careful here because if the receiver bundle consumes a lot of resources, it'll affect the API traffic too. And the load on the Manager will increase as the number of workers grow. *Important* > > - We might not be able to scale API Gateway Manager node more than one > instance because API Publisher talks to it via a service call. If we do, > all the instances of the API Gateway Manager cluster would not have all the > Synapse API definitions. > > If there are more than 1 manager nodes, we can configure the publisher to publish APIs to all of them. > > - API Gateway Manager pod needs to mount a volume to persist the > Synapse APIs. This is vital for allowing the Gateway Manager pod to auto > heal without loosing the Synapse APIs on the filesystem. > > > - This design does not depend on any native features of the container > cluster management system. > > > Thanks > > -- > *Imesh Gunaratne* > Senior Technical Lead > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: http://imesh.io TW: @imesh > Lean . Enterprise . Middleware > > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
