Is deis workflow support applications wich expose more then one port?

[Cryptophobia]

From @rvadim on June 15, 2016 3:53

Hello,
In our organization we can use kubernetes as containers infrastructure and kubernetes can expose more then one port for applications, but we don't want to give kubctl(apiserver) access for many dev teams, due to kubernetes interface is complex. Also many developers are familiar with deis cli and can use it. The problem is that: some developers use java and want to use separate port(TCP) for monitoring and some developers need specific software tools like Sonar which need to expose 2 HTTP ports, but currently deis workflow have not this feature.

Is there a workaround for this problem?
Thank you.

Copied from original issue: deis/workflow#324

[Cryptophobia]

From @bacongobbler on June 15, 2016 21:38

Hi @rvadim! For Workflow v2.0.0, we intended to stick with v1 compatibility for the initial release. Because of this, deis/deis#3069 is still an open issue. However, now that we are on top of Kubernetes, it should only be a matter of modifying the router to proxy any ports a k8s "routable" service exposes, then make the controller deploy a k8s service manifest to expose all the container's ports.

This is probably a good opportunity to close the older issue in favor of this one so we can keep tracking it for Workflow, so thank you for reviving this conversation! :)

[Cryptophobia]

From @bacongobbler on June 15, 2016 21:48

Also to add to this:

some developers use java and want to use separate port(TCP) for monitoring

That is also something we do not support yet; see deis/deis#1315.

[Cryptophobia]

From @zzp8164 on June 27, 2016 2:44

looking forward this feature :-)

[Cryptophobia]

From @drauschenbach on August 19, 2016 18:49

Also note that Deis provides release versioning for Dockerfiles, which is a powerful workflow feature in front of bare Kubernetes, that is not easy to roll on one's own.

More reason to support multiple port EXPORTs, as well as TCP based (non-HTTP) services. They are all in desperate need of the workflow, just as much as the single-PORT buildpack-orieneted projects are.

[Cryptophobia]

From @bacongobbler on August 19, 2016 19:5

Note that I did propose an idea at deis/router#203. The problem is the following:

Apps that expose more than one port expect the app to be routed to that same port. For example, an app called foo that exposes port 80 and 2223 would expect that the application is available at http://foo.mydomain.com and foo.mydomain.com:2223. If apps only expose one port, it needs to route to port 80 to retain backwards compatibility.

We have components like the builder that run through a TCP connection in the router, which of course does not use virtual host routing but grabs the entire port, making that one specific port unavailable for apps. We need to add special cases for ports that are unavailable for application use.

Also, the Kubernetes service for the application is created at app creation time, rather than the time that the pod is created. We also support deis config:set PORT for some use cases, which would also need to be addressed.

I'm not saying that this can't be done in a backwards-compatible fashion, it's just a lot to chew. I do agree that this is something I'd like to see in Workflow, it's just a ton of work to get in that spans several projects. The first and easiest thing to tackle would be the router if anyone wants to take a crack at that implementation.

[Cryptophobia]

From @bacongobbler on August 19, 2016 20:3

deis/router#239 should resolve the router side of things, should it be accepted.