search

QubitProducts / bamboo

HAProxy auto configuration and auto service discovery for Mesos Marathon
Apache License 2.0
794 stars 214 forks source link

serviceports aren't available in templates #37

Closed rasputnik closed 9 years ago

rasputnik commented 9 years ago

Our current setup involves running each app on a standard port on the haproxy layer (this is how marathons old haproxy_cfg used to generate configs).

Apps are deployed with a specific port as a way to 'tag' them for a given service.

Would be useful to expose that port for Bamboo templates too (I notice Bamboo currently only exposes 1 port for tasks so I propose to keep that behaviour).

j1n6 commented 9 years ago

I can see this fit into part of a feature request related to support Both TCP and HTTP protocol.

The way I had in mind to implement it is setting values in Zookeeper as:

/bamboo/state/app-id (Acl rule) /bamboo/state/app-id/protocol (HTTP or TCP) /bamboo/state/app-id/port (default 80 )

Or migrate the current ACL value in app-id path in zookeeper to a JSON struct.

I haven't decided which way would be better, any thoughts?

On 10 Oct 2014, at 20:17, Dick Davies notifications@github.com wrote:

Our current setup involves running each app on a standard port on the haproxy layer (this is how marathons old haproxy_cfg used to generate configs).

Apps are deployed with a specific port as a way to 'tag' them for a given service.

Would be useful to expose that port for Bamboo templates too (I notice Bamboo currently only exposes 1 port for tasks so I propose to keep that behaviour).

— Reply to this email directly or view it on GitHub.

rasputnik commented 9 years ago

To be honest I think that's something marathon or mesos should be providing to tools like Bamboo and other frontends - currently there's no way to define what a port is actually carrying, it'd be good if there was a way to specify metadata about an apps various ports.

My suggestion would be to stick with providing a solid http frontond for the short term and wait to see how things fall out up in marathon land.

There are still features they provide that aren't exposed yet (multiple ports for apps, a way to define which port a health check should be on, etc.).

On 10 October 2014 20:45, Jing Dong notifications@github.com wrote:

I can see this fit into part of a feature request related to support Both TCP and HTTP protocol.

The way I had in mind to implement it is setting values in Zookeeper as:

/bamboo/state/app-id (Acl rule) /bamboo/state/app-id/protocol (HTTP or TCP) /bamboo/state/app-id/port (default 80 )

Or migrate the current ACL value in app-id path in zookeeper to a JSON struct.

I haven't decided which way would be better, any thoughts?

On 10 Oct 2014, at 20:17, Dick Davies notifications@github.com wrote:

Our current setup involves running each app on a standard port on the haproxy layer (this is how marathons old haproxy_cfg used to generate configs).

Apps are deployed with a specific port as a way to 'tag' them for a given service.

Would be useful to expose that port for Bamboo templates too (I notice Bamboo currently only exposes 1 port for tasks so I propose to keep that behaviour).

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/QubitProducts/bamboo/issues/37#issuecomment-58706624.

j1n6 commented 9 years ago

Agree. I think there's a request in Marathon adding tags or labels ( https://github.com/mesosphere/marathon/issues/599). I am also waiting for those features to implement versioning for upgrading or rollback.

On 10 October 2014 21:19, Dick Davies notifications@github.com wrote:

To be honest I think that's something marathon or mesos should be providing to tools like Bamboo and other frontends - currently there's no way to define what a port is actually carrying, it'd be good if there was a way to specify metadata about an apps various ports.

My suggestion would be to stick with providing a solid http frontond for the short term and wait to see how things fall out up in marathon land.

There are still features they provide that aren't exposed yet (multiple ports for apps, a way to define which port a health check should be on, etc.).

On 10 October 2014 20:45, Jing Dong notifications@github.com wrote:

I can see this fit into part of a feature request related to support Both TCP and HTTP protocol.

The way I had in mind to implement it is setting values in Zookeeper as:

/bamboo/state/app-id (Acl rule) /bamboo/state/app-id/protocol (HTTP or TCP) /bamboo/state/app-id/port (default 80 )

Or migrate the current ACL value in app-id path in zookeeper to a JSON struct.

I haven't decided which way would be better, any thoughts?

On 10 Oct 2014, at 20:17, Dick Davies notifications@github.com wrote:

Our current setup involves running each app on a standard port on the haproxy layer (this is how marathons old haproxy_cfg used to generate configs).

Apps are deployed with a specific port as a way to 'tag' them for a given service.

Would be useful to expose that port for Bamboo templates too (I notice Bamboo currently only exposes 1 port for tasks so I propose to keep that behaviour).

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/QubitProducts/bamboo/issues/37#issuecomment-58706624.

— Reply to this email directly or view it on GitHub https://github.com/QubitProducts/bamboo/issues/37#issuecomment-58710768.

This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to

the wrong person. Thanks.