[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Routing SPI



Thank you for all your answers.

I have started an simple routing implementation with nginx here : https://github.com/worldline/openshift-nginx-routing
I get it very quickly and it works like a charm ;)

Now I would like to add the init configuration via a call to the gear_group.
Unfortunately I don't see how I can get the PORT of the web gear. But temporarily I can point to the Node Apache (port 80), and refactor it when the rest endpoint will be available.

About the DNS entry, if I understand well, every ha-xxxxx applications have a CNAME entry pointing to ROUTER_HOSTNAME (in broker.conf) ?

Thank you so much for the Routing SPI. It's very easy to use :)

Cheers
Romain

-----Message d'origine-----
De : Rajat Chopra [mailto:rchopra redhat com]
Envoyé : lundi 11 novembre 2013 22:58
À : Clayton Coleman
Cc : Philibert Romain; dev lists openshift redhat com
Objet : Re: Routing SPI






----- Original Message -----
> From: "Clayton Coleman" <ccoleman redhat com>
> To: "Philibert Romain" <romain philibert worldline com>
> Cc: dev lists openshift redhat com
> Sent: Monday, November 11, 2013 7:11:00 AM
> Subject: Re: Routing SPI
>
> Hey Romain - didn't see any responses to the public list, so I'll
> throw a couple of answers in where I know.
>
> On Nov 6, 2013, at 9:10 AM, Philibert Romain <
> romain philibert worldline com
> > wrote:
>
>
>
>
>
>
> Hello everyone,
>
>
>
> We are currently playing with the Routing SPI, on the latest master of
> origin.
>
>
>
> It works quite well. I published a gist explaining how to use it :
> https://gist.github.com/Filirom1/7334311
>
>
>
> Our goal is to build an nginx OpenShift LoadBalancer that will bypass
> Node Apache, HAProxy and Node Proxy.
>
> Nginx will be highly available because configured behind LVS, and the
> configuration will be sharded amoung severals servers.
>
>
>
> This project was done internally and is now open-sourced :
> https://github.com/worldline/paas-rproxy-agent
>
> This project doesn’t use the routing SPI, instead it spies mcollective
> messages and transmit configuration messages to another mcollective
> agent that will create nginx configuration… This source code doesn’t
> work anymore with the latest origin, this is the reason why we are
> looking at the Routing SPI now. It will make our code robust to future origin internal changes.
>
> Very awesome - that's an awesome integration, and should be useful to
> many people.
>
>
>
>
>
>
>
>
>
>
> Before starting our implementation with the routing SPI, I was
> wondering if there is a REST API to retrieve the whole routing table ?
> It would be useful to init nginx configuration before adding it to the cluster.
>
> gear-groups should be returning the endpoints of each gear in the
> application. We had been discussing a new rest endpoint that was
> easier to use but it hasn't been implemented yet.
>
>
>
>
>
>
>
>
>
>
> Another thing I notice, is that `add_gear` and `delete_gear` messages
> are only published if the application is HA. Is it wanted ?
>
> Sounds like a bug - I'll make sure one is filed.
>
>


It is an intended outcome. Not a bug. Isn't the entire routing SPI meant for applications who want to have the HA routing layer? So we skip the hassle for those who are not designated so.
We can always change the behaviour, counter-arguments please?


>
>
>
>
>
>
>
>
> The last question is how can I force every http request to pass
> through the nginx (nginx servers are different from node servers), and
> ssh/git requests to access the node directly ? Currently we solved
> this with this Pull Request :
> https://github.com/openshift/origin-server/pull/2877 . It replaces ssh node names by node IP, but it creates problems when moving gears.
> `.git/config` reference an IP (not a name anymore) that changed when
> the gear was moved.
>
> Will look to see if there's a good answer - it sounds reasonable.


The difference between web requests vs ssh/git requests should be resolved using the DNS entries.
There should be one DNS meant for web requests and another for ssh/git. And that is what the event 'make-ha' does.

 - A given app's default dns is not HA, because it points to the first-gear/head-gear/deploy-gear of the app. e.g. appname-namespace.rhcloud.com
 - If one uses the appname-namespace.rhcloud.com DNS then both the git/ssh and web/http requests land on the first gear without the router knowing anything about it.
 - Enter the HA DNS entry - ha-appname-namespace.rhcloud.com ! This dns points to the router with the assumption that some vhost/mod-rewrite/nginx-http-rewrite exists in the router to do forward/reverse proxy with the appropriate url mapping.

With two DNS entries, one pointing to the router and the other to the head-gear, we do not have to worry about 'move' etc. The fallout is that git-push/ssh is not HA. Only the web requests become HA. Eventually we can figure out how to resolve/re-map git/ssh DNS if the head gear/node goes down.


Hope I helped.
Rajat






>
> Thanks Romain!
>
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>


Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]