port mapping parsing issue

[chhsiung]

Hi

We have written an external configuration handler to read Docker Compose yaml files so we can use the same yaml files in our maven builds as we do when we use the Docker Compose CLI. But we are running into a few issues related to how the docker-maven-plugin works with the port mappings.

• There doesn't seem to be support for the "single container port definition, i don't care about host port" option found in Docker Compose. See https://docs.docker.com/compose/yml/#ports - "just the container port (a random host port will be chosen)". This is preventing us from using something like "3000" in our docker-compose yaml file and forcing us to use "3000:3000" when really the first 3000 is of little importance to us.
• From https://github.com/rhuss/docker-maven-plugin/blob/master/doc/manual.md#port-mapping, it seems if I use the "host.port:80" option with a string value, I can get similar functionality with the random host port being mapped to a maven property, but this breaks in Docker Compose 1.4 because Docker Compose does not recognize "host.port:3000" as a valid port mapping.

Do you have any suggestions on how we can continue to use the docker-maven-plugin, but with a Docker Compose yaml file that is supported in 1.4. We do want access to the random host port assigned to our service so the mapping to the maven property gives us that, but then prevents us from using the same yaml file for both maven builds and Docker Compose CLI.

Thanks

[jgangemi]

even if you could trigger the plugin to use a random port w/o specifying host.port, there would be no key to bind the port to in the maven properties, so you'd never be able to access it.

i'm not sure this is going to be possible but @rhuss may have a suggestion i haven't thought of.

[jgangemi]

actually - if you wrote your own handler, couldn't you just handle this there once you've parsed the yaml file and extracted the port? you could build the port stanza host.port:3000 there so the plugin would work properly.

you still need to solve where your handler would get the property name from, but you could store this in a label that your handler would know to read for this value.

[chhsiung]

@jgangemi - thanks for the quick response!

with regards to using a random port w/o specifying host.port, there are some instances where we don't ever need to directly access the port. in these cases, we can naively just take the container port and map the host port to the same number, but this kind of implicit mapping leads to potential port collision. i'd rather be able to just get a random port assigned.

for our problem of how to get the property name, that's the main problem we are running into... we've tried the following:

• using labels to tell the handler what property name to store the random port in, but it seems possibly an overload of the labels in Docker Compose.
• adding in the mapping in our pom file similar to how the external PropertyConfig handler works. but we end up with a messy config block looking like:

                <configuration>
                    <images>
                        <image>
                            <external>
                                <type>compose</type>
                                <config>${basedir}/src/test/resources/compose/docker-compose-simple.yml</config>
                                <ports.1>service1.port:3000</ports.1>
                                <ports.2>service2.port:9656</ports.2>
                                <ports.3>service2.admin.port:9657</ports.3>
                                <ports.4>service2.debug.port:5555"</ports.4>
                                <ports.5>service3.port:5555</ports.5>
                            </external>
                        </image>
                    </images>
                </configuration>

this seems messy because the mapping is separate from the docker compose yaml file so we will need to make sure the files are kept in coordination. there is also an implicit naming convention we have to assume (we parse the first part of the property name to be the service name in order associate the property with the correct image's port)

both solutions we've tried seem less than ideal :( hoping others have run into similar problems and might have a nice clean solution?

[rhuss]

One suggestion is to allow dynamically assigned ports in d-m-p without associated properties and then compute property names where to put the assigned port into. E.g. sth like port_<image-or-alias-name>_<fixed container_port>.

Would this help ?

[rhuss]

btw, we plan to support docker-compose natively (#57). 'would be super cool if you could contribute your docker compose external config handler somehow ;-)

[jgangemi]

👍 for contributing back the external handler.

@rhuss's suggestion about dynamically creating property names based upon some known pattern is also what i came up w/ while thinking about this as well.

[chhsiung]

@rhuss - yup, the ability to allow dynamically assigned ports in dmp without associated properties would be nice.

we are working out a few possible ways to compute the property names now.

we may be interested in helping contribute back some of our docker compose handler stuff but we are still working out the kinks :)

[jgangemi]

@chhsiung did you guys come to any resolution on contributing back some of this support? there request for docker-compose has been inquired about n #57 again.

[ambition-consulting]

isn't this what the portPropertyFile exists for?