On Wed, Jul 17, 2013 at 5:56 PM, Samisa Abeysinghe <[email protected]> wrote:
> > > > On Wed, Jul 17, 2013 at 5:30 PM, Nuwan Dias <[email protected]> wrote: > >> On Wed, Jul 17, 2013 at 5:14 PM, Samisa Abeysinghe <[email protected]>wrote: >> >>> Is the design such that, if we want more than 2 environments, that can >>> be facilitated? >>> >> >> Yes, this can be facilitated. >> > > Where would that config go? Also, ideally, want to be able to use my own > names in my setup rather than sandbox/prod say staging/live > Yes, that's the idea. These names will be displayed on the Store when listing the environments. The config would reside in the api-manager.xml. Although you can have multiple environments those will have to be categorized into two main types (production and sandbox) since we only support two key-types. I haven't thoroughly thought about the xml config but I'm guessing it would be similar to the following. <Environments> *<environment>* * <name>Live</name>* * <type>production</type>* * <deployByDefault>false</deployByDefault>* * <ServerURL>https://192.168.10.100:9443/services/</ServerURL>* * <Username>admin</Username>* * <Password>admin</Password>* * <APIEndpointURL>http://192.168.10.100:8280, https://192.168.10.100:8243</APIEndpointURL>* * </environment>* <environment> <name>Staging</name> <type>production</type> <deployByDefault>false</deployByDefault> <ServerURL>https://192.168.10.101:9443/services/</ServerURL> <Username>admin</Username> <Password>admin</Password> <APIEndpointURL>http://192.168.10.101:8280, https://192.168.10.101:8243</APIEndpointURL> </environment> <environment> <name>QA</name> <type>sandbox</type> <deployByDefault>true</deployByDefault> <ServerURL>https://192.168.20.100:9443/services/</ServerURL> <Username>admin</Username> <Password>admin</Password> <APIEndpointURL>http://192.168.20.100:8280, https://192.168.20.100:8243</APIEndpointURL> </environment> <environment> <name>Development</name> <type>sandbox</type> <deployByDefault>true</deployByDefault> <ServerURL>https://192.168.20.101:9443/services/</ServerURL> <Username>admin</Username> <Password>admin</Password> <APIEndpointURL>http://192.168.20.101:8280, https://192.168.20.101:8243</APIEndpointURL> </environment> </Environments> The 'type' attribute specifies the environment type whereas the 'deployByDefault' attribute specifies whether an API should be deployed onto that environment by default when an API is published. If 'deployByDefault' is false, the API will have to be promoted onto that environment from another. Thanks, NuwanD. > >> Another requirement which I missed to mention earlier is that we need to >> have a control of the environments in which a given API will reside. For >> example when an API is published, we need to say that it will initially be >> deployed on the Sandbox Gateway only. Once the user is satisfied with it he >> can promote it to Staging, Production, etc. >> >> Thanks, >> NuwanD. >> >>> >>> >>> On Wed, Jul 17, 2013 at 3:02 PM, Nuwan Dias <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> This is regarding supporting multiple environments (production/sandbox) >>>> for the API Gateway. Currently API Manager allows having two endpoints per >>>> API. These are the production and sandbox endpoints. Although the sandbox >>>> endpoint is supposed to be used for testing purposes, both production and >>>> sandbox traffic is handled through a single Gateway. This can cause the >>>> production Gateway be loaded with test traffic as well. >>>> >>>> This feature is to allow having two Gateway nodes (at least) for >>>> serving production and sandbox traffic separately. Following is how it is >>>> supposed to work. >>>> >>>> 1. When an API is published, it will be deployed on both the production >>>> and sandbox Gateway nodes. >>>> 2. The production Gateway will only serve production traffic and the >>>> sandbox Gateway will only serve sandbox traffic. >>>> 3. The Gateway will use the token type (production or sandbox) to >>>> identify requests being received. >>>> 4. The Token endpoint (/token) will remain same on both nodes. The >>>> token being generated will depend on the type of >>>> consumer-key/consumer-secret used. >>>> 5. Both Gateway nodes will share a single APIMGT database. This is >>>> where information related to APIs, Applications, Token, etc are stored. >>>> This will be the same database as used by the publisher/store nodes. >>>> >>>> Currently an xml template is used for generating an API configuration >>>> (synapse configuration). To allow the above mentioned feature to work, a >>>> separate xml template will have to be maintained for each endpoint type >>>> (production template and sandbox template). >>>> >>>> The api-manger.xml currently defines the location (url) of the Gateway. >>>> A similar configuration will be introduced to define the location of the >>>> sandbox Gateway. The API Store will display both endpoints accordingly. >>>> >>>> Thoughts/Suggestions welcome. >>>> >>>> Thanks, >>>> NuwanD. >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Senior Software Engineer - 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 >>>> >>>> >>> >>> >>> -- >>> >>> Thanks, >>> Samisa... >>> >>> Samisa Abeysinghe >>> VP Engineering >>> WSO2 Inc. >>> http://wso2.com >>> http://wso2.org >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nuwan Dias >> >> Senior Software Engineer - 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 >> >> > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Nuwan Dias Senior Software Engineer - 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
