February 24, 20179 yr Is there a way for a container to see the port mappings, and other settings that it is running under? I know you can set a variable on the container, and it will be able to access it, but I'm curious about the container being able to see a port or share setting.
February 28, 20179 yr Author So, I guess I figured some of this out on my own - looks like port mappings and such DO show up as environment variables. TCP_PORT_1234=1234 for instance, so that can be used in scripts it seems. Doesn't look to be the same situation for volume maps though. Edited February 28, 20179 yr by CraziFuzzy
February 28, 20179 yr Why do you need the container to see the port map or volume mount? The port is only made into a variable if you set a port mapping or the template have one and then change from bridge to host network mode.
February 28, 20179 yr Author ideally, this would be so that a non-standard port could be used on a congested host, and the application can be made aware of the difference for telling external clients what port to use.
March 1, 20179 yr Just change the port only on the host side as is standard practice. Take a look at the docker FAQ.
March 6, 20179 yr Author On 2/28/2017 at 4:02 PM, CHBMB said: Just change the port only on the host side as is standard practice. Take a look at the docker FAQ. The issue is some applications need to tell a client what port to connect a secondary or additional connection to, or are discovered via broadcast and then respond with the address/port to connect to. Those responses need to know what port they have assigned on the host, so they can tell the potential clients where to connect. As it is now, if there is a conflict between dockers, and this port needs to be changed from it's default, it not only needs to be changed in the container mappings, but also in the configuration of the internal app to reflect it (if that is even possible for the given app).
March 6, 20179 yr 1 hour ago, CraziFuzzy said: The issue is some applications need to tell a client what port to connect a secondary or additional connection to, or are discovered via broadcast and then respond with the address/port to connect to. Those responses need to know what port they have assigned on the host, so they can tell the potential clients where to connect. Those type of applications need to be run in host instead of bridge mode, and port conflicts will have to be manually detected and dealt with.
March 6, 20179 yr Author 1 minute ago, jonathanm said: Those type of applications need to be run in host instead of bridge mode, and port conflicts will have to be manually detected and dealt with. Yes. Which goes back to my original question, because if there WAS a way to view that port mapping from within the container, the docker scripting could easily deal with the scenario WITHOUT the manual intervention.
March 6, 20179 yr 3 minutes ago, CraziFuzzy said: Yes. Which goes back to my original question, because if there WAS a way to view that port mapping from within the container, the docker scripting could easily deal with the scenario WITHOUT the manual intervention. Host mode does NOT have port mappings to view or parse with a script.
March 8, 20179 yr Author On 3/6/2017 at 11:00 AM, jonathanm said: Host mode does NOT have port mappings to view or parse with a script. Not mappings, but they do have port entries, do they not? These allow conflicts to be more easily managed with other dockers by showing those ports in use.
March 8, 20179 yr 4 hours ago, CraziFuzzy said: Not mappings, but they do have port entries, do they not? These allow conflicts to be more easily managed with other dockers by showing those ports in use. No, there are no port entries in the template.
Archived
This topic is now archived and is closed to further replies.