Open michelleN opened 7 years ago
Agreed. This as well as the default command used to boot the application are probably the biggest blockers to v1.0 in my mind.
One other open question about this: what about applications that listen on more than one port? Is that out of scope for Draft or does not reflect on the large majority of microservices being built today? Sorta an extended question on top of #39 but the question is relevant here too. I don't see too many multi-port containers being built today, but there are a few outliers like gerrit
which exposes a git endpoint as well as a web frontend in the same container, for example.
Having the ability to tunnel more ports could also be helpful for remote debugging.
@isutton @bacongobbler agreed. Let me know if #299 is what ya'll are thinking.
perfect. #299 answers my question.
I always like grabbing random repos off the web to see if Draft will work on them and one issue I run into frequently is the mismatching of the port on which my application is listening on and the internalPort value in the chart.
I as a developer generally know what port my application is listening on because I've defined it. Because this is something the application developer knows, we might want to think about either validating that the default internal port is correct or allowing the developer to more easily configure the internalPort value in the chart.