And do not forget that etcd is the registry used in OpenShift, so can be
convenient to think in using as state-sharing server etcd as well.
2015-07-23 17:57 GMT+02:00 Eric Wittmann <eric.wittmann(a)redhat.com>:
+1 - in production you would want separate docker containers for the
API
Manager vs. the API Gateway. We don't have these docker
images/containers defined yet.
As for scaling out the gateway - my suggestion for deployments is to
have a single logical gateway made up of multiple identical (clustered)
gateway docker containers. The gateway image would not have any
bootstrapping to do. But each gateway container would connect to the
same state-sharing server (e.g. elasticsearch or infinispan). Thus they
all share registry info and rate limiting state, etc. It also means
that a new gateway node can be spun up easily.
-Eric
On 7/23/2015 10:28 AM, Keith Babo wrote:
> Interesting discussion. Another aspect to consider here is how the
docker image will work with various deployment architectures. For the
“kick the tires” use case, I expect you will want all of apiman (admin
server/console, gateway) and all of the configuration built into your
image. Makes it really easy to get off and running with a known state.
>
> In the “production” use case, I wonder if things will change a bit. In
that scenario, I can see the need for separate images for the gateway and
for the admin server/console. This would allow the gateway containers to
scale up independent of the admin container. Does baking the config into
the image make sense here? Maybe it does for initial configuration, but
you’ll also need a way to pull configuration into new gateway containers as
they scale up.
>
> cheers,
> keith
>
>> On Jul 23, 2015, at 9:34 AM, Eric Wittmann <eric.wittmann(a)redhat.com>
wrote:
>>
>> I think it would be possible to have a run-once shell script. Either by
>> writing/checking some sort of "already run" file. Or else by
querying
>> apiman to see if a particular entity exists. For example, query to see
>> if "My-Custom-Organization" exists ... if it does then skip the
script.
>> If not, then run the multitude of curl commands to do what you want.
>>
>> -Eric
>>
>> On 7/23/2015 7:48 AM, Arun Gupta wrote:
>>> I've been thinking something on those lines.
>>>
>>> - Invoke shell script from Dockerfile
>>> - Start API Man
>>> - Run shell scripts
>>> - Shut it down
>>> - Go back to Dockerfile which will then start it
>>>
>>> Will share something, stay tuned.
>>>
>>> Arun
>>>
>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann <
eric.wittmann(a)redhat.com> wrote:
>>>> You are probably more deft with docker than I am, but perhaps a shell
script
>>>> could be used to send a bunch of curl commands?
>>>>
>>>> -Eric
>>>>
>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote:
>>>>>
>>>>> Thanks!
>>>>>
>>>>> What is the recommended design pattern to extend the Dockerfile in
the
>>>>> meanwhile?
>>>>>
>>>>> Arun
>>>>>
>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann <
eric.wittmann(a)redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> That is not currently a feature. But I've now added a JIRA
for it,
>>>>>> since it seems like a nice idea (especially for extending the
docker
>>>>>> container).
>>>>>>
>>>>>>
https://issues.jboss.org/browse/APIMAN-566
>>>>>>
>>>>>> -Eric
>>>>>>
>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote:
>>>>>>>
>>>>>>> This indeed would be very useful.
>>>>>>> Tim
>>>>>>>
>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote:
>>>>>>>>
>>>>>>>> I've created a Dockerfile [1] that will attempt to
create
different
>>>>>>>> resources. Is there any standard format where I can
drop
>>>>>>>> <organization>.yml in a pre-defined directory and
API Man will
read
>>>>>>>> the resources defined there and create them?
>>>>>>>>
>>>>>>>> This will simplify how the resources are created using
Docker. The
>>>>>>>> samples at [2] do not show that.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
https://github.com/arun-gupta/microservices/blob/master/microservice/dock...
>>>>>>>> [2]
https://registry.hub.docker.com/u/jboss/apiman-wildfly/
>>>>>>>>
>>>>>>>> Arun
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apiman-user mailing list
>>>>>>> Apiman-user(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user