We (Sumedha, Srinath, Azeez, Sanjiva and a few from the APIM-Team) had a
meeting to discuss on $subject and we came to a conclusion to maintain
production and sandbox environments only. The reason is that since we're
talking about APIs and not about the actual implementation of it, it does
not make much sense to have an API deployed on multiple environments. An
API could either be in production or in sandbox. Whatever that is not
production is considered to be sandbox.
The concept of promoting from sandbox to production was also invalidated.
If a given API has both production and sandbox endpoints, it will be
deployed onto both environments at the time of publishing. If it has only
one it will only be deployed onto the relevant environment. If the other
endpoint is added later, it will be deployed onto that environment at that
point.
After the conclusions of the discussions, the environment configuration
would be similar to the following.
<Environments>
<Environment>
<Type>production</Type>
<ServerURL>https://192.168.10.100:9443/services/<https://192.168.10.101:9443/services/>
</ServerURL>
<Username>admin</Username>
<Password>admin</Password>
<APIEndpointURL>http://192.168.10.100:8280<http://192.168.10.101:8280/>
,https://192.168.10.100:8243 <https://192.168.10.101:8243/></APIEndpointURL>
</Environment>
<Environment>
<Type>sandbox</Type>
<ServerURL>https://192.168.20.100:9443/services/<https://192.168.10.101:9443/services/>
</ServerURL>
<Username>admin</Username>
<Password>admin</Password>
<APIEndpointURL>http://192.168.20.100:8280<http://192.168.10.101:8280/>
,https://192.168.20.100:8243 <https://192.168.10.101:8243/></APIEndpointURL>
</Environment>
</Environments>
Thanks,
NuwanD.
On Thu, Jul 18, 2013 at 8:43 AM, Nuwan Dias <[email protected]> wrote:
> 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
>
--
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
