You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, when I moved port host interface publishing out of start-web-deploy and into this, I also removed the PORT file.
The way Dokku is supposed to work, apps get bound to a host port as an alternative to having a domain name. However, Dokku doesn't do anything to redeploy to that port (even though it saves its value), so in reality the port (possibly/probably) changes every time the app is redeployed (every restart and every push).
Now, it could be arranged that a plugin could bind the app to a persistent port, either letting the port be specified manually or saving the randomly-assigned port from Docker and re-using it on every future deploy. (That plugin would then be in charge of determining how it would save its bound ports, probably by reintroducing the PORT file.)
That plugin could even, in theory, be this one. However, this plugin's view of published ports is more that they are an unfortunate side-effect (one that alternative plugins should rectify). If this app is going to do anything with published ports, it would be to hide them from non-loopback interfaces using something like iptables.
Perhaps this plugin should call out to an app-port-published hook, and only default to randomly binding the port if the hook yields no output. (If it does yield output, we let that plugin handle the Docker option itself: it should be allowed to work in the absence of a plugin like this one.)
The text was updated successfully, but these errors were encountered:
So, when I moved port host interface publishing out of start-web-deploy and into this, I also removed the PORT file.
The way Dokku is supposed to work, apps get bound to a host port as an alternative to having a domain name. However, Dokku doesn't do anything to redeploy to that port (even though it saves its value), so in reality the port (possibly/probably) changes every time the app is redeployed (every restart and every push).
Now, it could be arranged that a plugin could bind the app to a persistent port, either letting the port be specified manually or saving the randomly-assigned port from Docker and re-using it on every future deploy. (That plugin would then be in charge of determining how it would save its bound ports, probably by reintroducing the PORT file.)
That plugin could even, in theory, be this one. However, this plugin's view of published ports is more that they are an unfortunate side-effect (one that alternative plugins should rectify). If this app is going to do anything with published ports, it would be to hide them from non-loopback interfaces using something like iptables.
Perhaps this plugin should call out to an app-port-published hook, and only default to randomly binding the port if the hook yields no output. (If it does yield output, we let that plugin handle the Docker option itself: it should be allowed to work in the absence of a plugin like this one.)
The text was updated successfully, but these errors were encountered: