Skip to content
This repository has been archived by the owner on Nov 30, 2021. It is now read-only.

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

Open
rvadim opened this issue Jun 15, 2016 · 7 comments
Open

Comments

@rvadim
Copy link

rvadim commented Jun 15, 2016

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.

@bacongobbler
Copy link
Member

bacongobbler commented Jun 15, 2016

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! :)

@bacongobbler
Copy link
Member

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.

@shaman2009
Copy link

looking forward this feature :-)

@drauschenbach
Copy link

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.

@bacongobbler
Copy link
Member

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.

@bacongobbler
Copy link
Member

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

@Cryptophobia
Copy link

This issue was moved to teamhephy/workflow#55

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants