docker expose wrong ports open

Question

I have a docker image with a wildfly server that binds to ports 8080, 8443, 8787 and 9990 on the 0.0.0.0 interface (for development and remote debugging).

The Dockerfile itself does not include any EXPOSE statements, since I want to expose ports selectively using the docker-compose.yml.

Dockerfile (shortened)

FROM ubuntu:bionic
ARG DEBIAN_FRONTEND=noninteractive
RUN     apt-get update && \
        apt-get install -y -q some,packages,here
        && apt-get clean \
        && apt-get autoclean \
        && apt-get --purge -y autoremove \
        && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
ENV WILDFLY_VERSION 16.0.0.Final
ENV WFLY_DIR /wildfly-$WILDFLY_VERSION
ENV JBOSS_HOME $WFLY_DIR
ADD /wildfly-$WILDFLY_VERSION 
RUN groupadd -g 999 wildfly && useradd -r -u 999 -g wildfly --home= --shell=/bin/bash wildfly
RUN chown -R wildfly:wildfly /wildfly-$WILDFLY_VERSION 
RUN chmod 755  $WFLY_DIR/bin/*.sh 
USER wildfly

The docker-compose.yml file contains essentially this:

version: "3.5"
services:
  appsvr:
    build: ../../images/myimage/
    command: ["/bin/bash", "/start.sh"]
    expose:
      - 8443
      - 8787

I start the container with docker-compose up -d and wildfly comes up as expected. Now I check which ports are exposed and get the ip of the container:

 bash% docker inspect --format=" {{ .NetworkSettings.Ports }} " containername
 map[8443/tcp:[] 8787/tcp:[]]
 bash% docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'  containername
172.20.0.10

That seems correct. I can connect to 8443, but I cannot connect to 8787, futher analysis with nmap on the IP yields:

 bash% nmap -p8000-10000 172.20.0.10

Starting Nmap 6.40 ( http://nmap.org ) at 2019-10-04 16:33 UTC
Nmap scan report for ip-172-20-0-10.eu-central-1.compute.internal (172.20.0.10)
Host is up (0.00029s latency).
Not shown: 1998 closed ports
PORT     STATE SERVICE
8080/tcp open  http-proxy
8443/tcp open  https-alt
9990/tcp open  osm-appsrvr

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

That is odd, since I do not expose 8080 or 9990 (I checked and it is indeed wildfly on 8080 responding to requests). And 8787 - although exposed via docker-compose (and also open inside the container after shelling into it!) - is not.

My docker-engine and docker-compose versions

bash% docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
 Built:             Fri Jun 28 23:16:08 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a/18.06.1-ce
  Built:            Fri Jun 28 23:17:39 2019
  OS/Arch:          linux/amd64
  Experimental:     false

bash% docker-compose version
docker-compose version 1.21.2, build a133471
docker-py version: 3.3.0
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

Is that to be expected? I don't think it is. Or did I misunderstand something conceptually about how EXPOSE should work (I was assuming ports not exposed are not visible and vice versa?)

Good answer here https://stackoverflow.com/questions/40801772/what-is-the-difference-between-docker-compose-ports-vs-expose — VelikiiNehochuha, Oct 04 '19 at 17:30
"Expose" means almost nothing in Docker, as the linked question suggests you need the Docker Compose `ports:` option to be able to reach the container. You should generally put `EXPOSE` and `CMD` in your Dockerfile as a suggestion as to how the image should be used. — David Maze, Oct 04 '19 at 18:01
Thank you for your comments. I actually don't want to expose ports via "ports" since I have a traefik reverse proxy to do that as needed, I access the non-published ports via an ssh tunnel, and that is adequate. But I learned something new, I'd assumed that EXPOSE was a way to explicitly open select ports as needed and assumed others were therefore closed. Incorrect. Now I just have to figure out why 8787 is unavailable, probably my own issue though. — sprockets, Oct 04 '19 at 22:06

docker expose wrong ports open

0 Answers0