Local

[lippserd]

Discussion

This PR suggests two ways to map ports. Port mapping occurs only when the Docker host is considered remote, which is assumed when the Docker host's address scheme is not unix.
The first way, which is used as an example for icinga 2, is based on the publish all option and gets the assigned port from the running container. The second way chooses a free port itself and uses this information when creating the container.

Depends On

• Expose port 5665 docker-icinga2#71

Blocks

• Local tests icingadb#398

fixes #1

[N-o-X]

Works great on MacOS, but breaks the tests on Linux (Port 5665 missing here):

2021-11-29T13:13:03.127Z	FATAL	icinga2 failed to start in time	{"icinga2": true, "container-name": "icinga-testing-5ccf0926-icinga2-1-master", "container-id": "d9af68d11a5f4f0b107285ab724bd1b84ade677c57e21389e5a6dc717a2b15a2", "error": "Get \"https://192.168.32.6:/\": dial tcp 192.168.32.6:443: connect: connection refused"}

[N-o-X]

Works great on Linux now:

CGO_ENABLED=0 go build ./cmd/icingadb && (cd tests && go test -o ../icingadb-test -c .) && ICINGA_TESTING_ICINGADB_BINARY=$(pwd)/icingadb ICINGA_TESTING_ICINGADB_SCHEMA=$(pwd)/schema/mysql/schema.sql ./icingadb-test -icingatesting.debuglog debug.log -test.v
...
PASS

[lippserd]

This PR suggests two ways to map ports. Port mapping occurs only when the Docker host is considered remote, which is assumed when the Docker host's address scheme is unix.
The first way, which is used as an example for icinga 2, is based on the publish all option and gets the assigned port from the running container. The second way chooses a free port itself and uses this information when creating the container.

@julianbrost Which way do you prefer for port forwarding?

[julianbrost]

Port mapping occurs only when the Docker host is considered remote, which is assumed when the Docker host's address scheme is unix.

I think that should say "is not unix". But just because you can directly access the container addresses doesn't mean that that's the way you should do it. So simply doing it always should make it everywhere without special-cases.

The ports should only be exposed on localhost and I don't know if it's possible to achieve this with publish all. It's possible to explicitly specify the container port and host address but let Docker choose the host port: docker run --rm -it -p 127.0.0.1::5665 icinga/icinga2 (probably setting the port to 0 using the API has the same effect). That would be my preferred way as it combines all benefits: Docker chooses the port with no potential for race-conditions but also precise control over what is exposed.

[lippserd]

The ports should only be exposed on localhost and I don't know if it's possible to achieve this with publish all.

This is not possible with publish all and does not work for remote docker hosts like docker machine, right?

Port mapping occurs only when the Docker host is considered remote, which is assumed when the Docker host's address scheme is unix.

I think that should say "is not unix".

Yep, fixed.

[Al2Klimov]

But just because you can directly access the container addresses doesn't mean that that's the way you should do it.

Why? And what's the problem?

[julianbrost]

But just because you can directly access the container addresses doesn't mean that that's the way you should do it.

Why? And what's the problem?

From my understanding, the actual address you see within the container is more of an implementation detail and it just happens to be accessible when using Docker on Linux. But I think things might be different on Windows or Mac OS (I haven't used Docker on any of these though) and the proper way to access some service running in Docker from outside a Docker container is to publish that port.

[Al2Klimov]

Good point. My Docker for Desktop (VM) listens on /var/run/docker.sock, but I seem to can't reach the containers' internal addresses. What about always publishing everything to ::/128 and equipping all services with a password?