toggle quoted message
Show quoted text
On Thu, Aug 6, 2015 at 4:40 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
I'm still having a lot of trouble parsing your sentences. What I
understand is that you're asking the following two questions:
1. You have a gateway application that you want to provide a portal or UI
to see a bunch of other applications. And by "see other applications" I
imagine you mean the UI provides some nice links or something to the other
apps. You want these other apps to automatically show up in the
gateway/portal UI. And the specific "other applications" you want to show
up in this UI are all the ones that happen to have staged with a particular
buildpack "B1". Your question is how to have these other applications
automatically show up in this UI, is that correct?
2. You want to know how to drive the CC's RESTful HTTP API to push an
application, is that correct?
For 1, this is a rather broad question. It sounds like you're essentially
asking how to do service discovery. It sounds like you want new B1-built
apps to *register* themselves as a service (maybe under some B1 namespace)
and then you want the gateway app to *discover* all the registered services
(under the B1 namespace). There is no built-in service-discovery mechanism
in Cloud Foundry today, but there's plenty of resources on the Internet you
can find to research different patterns around service discovery.
You should not use the system etcd or consul, but one option is to deploy
your own cluster and expose it as a user-provided service, then have all
your apps bind to that service and register themselves. We are right in
the midst of extracting the etcd that's used in CF and Diego as a
standalone BOSH release so it will soon be easier to deploy your own etcd.
There's nothing special about etcd for service discovery. consul has
first-class support for DNS, but my guess is that doesn't even really
matter for you, since the gateway app isn't really trying to talk to the
other services, it's just providing a UI so people can see what the other
services are. You could build service discovery patterns on top of many
other services, including messaging services like Rabbit, key-value stores
like Redis, relational databases like MySQL or PostgreSQL. etcd and consul
are special because of their explicit focus on consistency and high
availability, but you can build service discovery patterns on top of many
different technologies. The first thing is just coming up with conventions
so that your "B1"-apps know where to write some metadata about themselves,
and your gateway app knows where to read all the metadata.
For 2, it looks like you've found the documentation on the topic you're
On Thu, Aug 6, 2015 at 3:30 AM, Ronak Agarwal <roagarwa(a)tibco.com> wrote:
We have a custom buildpack for our product lets say name B1.
I have query with respect to a custom Application Configuration App
which is build on Nodejs has it own UI to do -
1. Create a B1 - Application-1 properties like - URL, port, security
policies etc. Lets say assume for now one App of B1 has only one app
property, offcourse there is a possibility of having this as one to
many. This will get published as micro-Nodejs-app (gateway) on CF.
Now, we are thinking to consume our B1 apps as REST APIs
(micro-services) from that Nodejs-micro-gateway app. So basically we
are avoiding Service Discovery for our B1 apps. Is it a good approach?
Or we should have Server/Client Service Discovery by querying Etcd
2. Capability to Push this micro-Nodejs-app (gateway) from UI, may be
something like a HTTP REST 'cf push'. Is it possible?? I found
below REST api call from CF documentation -
Your comments will be really appreciated. Thanks.
On Wed, Aug 5, 2015 at 12:30 PM, Ronak Agarwal <roagarwa(a)tibco.com>
Hi Amit,with cf
Thanks for your update.
If we build our own micro gateway (a Nodejs app) and push it to CF and
bind all my apps to this micro-gateway. So is there a way - we can
read and update CF app parameters (app url, port,
profile-development/qa/production etc) inside this Nodejs app ??
On Wed, Aug 5, 2015 at 12:05 AM, Amit Gupta <agupta(a)pivotal.io> wrote:
The system etcd and consul should not be used for application service
discovery. There are various approaches to doing service discovery
applications, but no solution out of the box. The staging process
generally been seen as an implementation detail of a running
is typically not an appropriate place for a hook for service
Service discovery and registration should be done at runtime. The
solution involves binding multiple applications to a common service
instance, like a database or message queue. In the future, there may
etcd or consul service; there may also be some sort of service
built into the CF routing layer at some point.
On Mon, Aug 3, 2015 at 11:57 PM, Ronak Agarwal <roagarwa(a)tibco.com>
We are trying to introduce a new component that will work together
with our custom buildpack to expose and secure APIs (you can think of
it as a Micro Gateway). In order to configure those gateways a new
webbased UI (our new web component) will be introduced that should
know about all our custom buildpack applications that are pushed to CF
and expose APIs. Ideally speaking every time an app gets pushed to CF
it should also notify the webbased UI that a new API is available
(something like service discovery).
I know CF has Etcd component which is used for Service Discovery
webbased UI ?
we use it to push application cluster details to this custom
The other part of the question is that the webbased UI will create a
new app that will in turn expose an API as well. That new app will be
exposed to the outside world and route traffic to the pushed
application (our buildpack apps) offcourse after applying some
policies. Would that be possible to do with CF?
Can we setup a proxy for such requirement? which component of CF
(M) +91 8446044994
(O) +91 20 4150 7935
(M) +91 8446044994
(O) +91 20 4150 7935