Closed jstrachan closed 9 years ago
Why would you do id/namespace rather namespace/I'd?
When you say node based do you mean nodejs?
good point ;) - and yes
@jimmidyson updated the description to use namespace first
BTW here's the project that has a kinda hard-coded proxy that at least works with HTTP based kubernetes: https://github.com/hawtio/hawtio-kubernetes
(though we've not yet updated it to include the namespace too ;)
here's the little proxy : https://github.com/hawtio/hawtio-kubernetes/blob/master/gulpfile.js#L111
@jimmidyson btw am sure we could have a really tiny pure Go Lang proxy too; to serve up the static content from hawtio and proxy HTTP/HTTPS requests to the services/pods inside kubernetes (so that the docker image is nice and small)
I was kind of thinking that... I think we need to have a chat about general hawtio/fabric8 v2 architecture. It would be good to have an overview we can publish to help others understand direction as well as being easier for contributions.
On 17:33, Fri, 23 Jan 2015 James Strachan notifications@github.com wrote:
@jimmidyson https://github.com/jimmidyson btw am sure we could have a really tiny pure Go Lang proxy too; to serve up the static content from hawtio and proxy HTTP/HTTPS requests to the services/pods inside kubernetes (so that the docker image is nice and small)
— Reply to this email directly or view it on GitHub https://github.com/hawtio/hawtio-kubernetes/issues/2#issuecomment-71220774 .
agreed.
In general we're trying to make the entire hawtio console plugins require as little back end services as possible (e.g. just being able to talk to a proxy to talk to the kube REST API) so that the server can be integrated inside the openshift executable, inside kubernetes or any other go/java/nodejs server.
Then everything else (jolokia connections, API Registry, App Library) are separate REST services somewhere inside kubernetes that the console talks to.
So the only real back end required right now for hawtio is a proxy to access services/pods by namespace/id ;)
Yeah that's what I guessed & it definitely is the right direction. Awesome!
On 17:44, Fri, 23 Jan 2015 James Strachan notifications@github.com wrote:
agreed.
In general we're trying to make the entire hawtio console plugins require a little back end services as possible (e.g. just being able to talk to a proxy to talk to the kube REST API) so that the server can be integrated inside the openshift executable, inside kubernetes or any other go/java/nodejs server.
Then everything else (jolokia connections, API Registry, App Library) are separate REST services somewhere inside kubernetes that the console talks to.
— Reply to this email directly or view it on GitHub https://github.com/hawtio/hawtio-kubernetes/issues/2#issuecomment-71222968 .
BTW the current hawtio 2.x kubernetes console kinda works - against Jube (the HTTPS / HTTP stuff is gonna take a while to figure out though for kubernetes/openshift ;) - with no server side java required; just the nodejs proxy in gulp is enough https://github.com/hawtio/hawtio-kubernetes
still lots to fix up since the move to the latest angular/bootstrap etc...
Cool. Are you going to get this pattern working nicely before bringing over too much other stuff?
On 17:48, Fri, 23 Jan 2015 James Strachan notifications@github.com wrote:
BTW the current hawtio 2.x kubernetes console kinda works - against Jube (the HTTPS / HTTP stuff is gonna take a while to figure out though ;) - with no server side java required; just the nodejs proxy in gulp is enough https://github.com/hawtio/hawtio-kubernetes
still lots to fix up since the move to the latest angular/bootstrap etc...
— Reply to this email directly or view it on GitHub https://github.com/hawtio/hawtio-kubernetes/issues/2#issuecomment-71223630 .
Yep, that's kinda the plan :-)
Nice!
On 18:14, Fri, 23 Jan 2015 Stan Lewis notifications@github.com wrote:
Yep, that's kinda the plan :-)
— Reply to this email directly or view it on GitHub https://github.com/hawtio/hawtio-kubernetes/issues/2#issuecomment-71227799 .
This is done now
... so that hawtio browser can access a service or pod by ID via these URIs...
So that the service/pod ID is looked up for the given namespace; the IP/port is found (via the pods / services API requests in kubernetes - which can be cached; once an ID+namespace has an IP/port it never changes); then the rest of the somePath is passed to the underlying service.
I guess the ports can pass through; so if https comes in, we pass it through to the underlying service/proxy; ditto for http?
It'd be nice to be able to reuse the same nodejs proxy inside gulp or as a stand alone docker container serving up the static content for hawtio and doing the proxying