controller
controller copied to clipboard
deis
Proposal: Handling multiple ports for deis apps
Right now if it's a buildpack app the port is 5000 and for other apps we are pulling docker images and inspecting the image for ports. This has some performance issue and sometimes error prone if docker client faces any exception like couldn't reach docker hub or docker deis registry.
Suggestions:
- make changes to deis cli to read dockerfile and pass ports to workflow.
- command line feature like deis create -p [ set of ports ] Create a new service for every release if there is change of ports
make changes to deis cli to read dockerfile and pass ports to workflow.
If we wanted to infer ports by looking at the Dockerfile instead of inspecting the image, couldn't that still be done on the back-end? Adding logic like this to the CLI doesn't seem ideal.
command line feature like deis create -p [ set of ports ]
This would seem like a clunky user experience to me. If Dockerfiles already express which ports are exposed, this just forces a user to repeat him/herself.
Create a new service for every release if there is change of ports
What ever modifications do need to happen upon a new release, I would favor updating the existing service over creating a new one.
Right now we use the$PORT env variable for every type of application, especially for private docker images that the controller does not attempt to introspect. I think this has been resolved.
This ticket was more for multi-port support than single use port, so I wouldn't call it resolved
Ok, it didn't seem super obvious from the issue description (which seemed more like alternative ways of port discovery than just pulling the image), but I see the other multi-port issues have been closed in favor of this.
Looks like the title is better now 👍.
Still waiting for a handle on this feature though.
... it doesn't seem like many feel the traction with any haste, although #138 this seems to be the place to set the grounds for a multi-port exposed application.
I don't agree completely with @smothiki on the way to implement it from the cli, @krancour is right: there should be a Dockerfile/image introspection phase for extracting the application ports and the following generated Service should listen on all of these, desirably exposing a nodePort for each. The convention would then be to expose all your application ports through standard Dockerfile syntax, and let deis do the heavy-lifting afterwards.
@rawc0der we have attempted many different approaches to this problem. A non-exhaustive list would be
https://github.com/deis/router/pull/239 https://github.com/deis/router/pull/203 https://github.com/deis/deis/pull/2095
All of these proposals miss the target due to abstractions with the scheduler in one form or another, or poor UX design.
We hear this issue weekly, so it's constantly on our minds. If you feel like taking a cracking at it, please feel free to PR docs, API and client patches to get multi-port support in.
Also for what it's worth a much larger discussion is also available at https://github.com/deis/deis/issues/3069 for more history on this issue.