Detecting exposed ports in images

[kadel]

One of the issues I'm constantly facing when using Kompose with various docker-compose files is that they don't always specify port. With docker-compose this is not an issue but, for Kompose it is as we need to create service for every exposed port.

We should investigate if it is possible to get exposed ports from image metadata without downloading image itself. Or maybe if there is some other solution for this.

[sebgoa]

So I looked into this a bit.

Lost of images do not have an exposed port, as you can reach a containerized service on any port even it is not 'EXPOSED'.

So even if we could introspect an image from a repo to figure out the EXPOSE, it may not even have one.

Case in point, the carts image form the sock shop example:

https://github.com/microservices-demo/carts/blob/master/Dockerfile

So I think we gonna have to create services with empty ports :( that will need to be edited by hand.

[sebgoa]

yeah that's a problem, as we need a port to create a service. Not sure how to solve this.

We can create a basic service set port to "1" but it won't work.

[kadel]

You are right. I forgot that when they are on the same network it doesn't mater what is in EXPOSE. :-(.

There is one solution that would probably work, but it is really ugly. We can generate Service with all 65536 ports 😆

[dustymabe]

There is one solution that would probably work, but it is really ugly. We can generate Service with all 65536 ports 😆

yeah. that could be our last resort. we could do this by default and then warn the user about this and tell them to either add port definition to docker compose file or edit the generated artifacts to put in the correct port.

[sebgoa]

that's pretty much impossible. afaik there is no wildcard for service ports in services. So that would mean creating 65k entries in the port definition of the service (so ugly). Plus pretty sure the proxy would run out of file descriptors somewhere, since it needs to listen on those ports...

[smarterclayton]

You can create a headless service (clusterIP: "None") and you should not be required to define ports.

[sebgoa]

but DNS won't work ?

[smarterclayton]

DNS works for headless services.

[sebgoa]

try this with a headless service:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: sockshop
  name: front-end
spec:
  clusterIP: None
  ports: null
  selector:
    service: front-end

But the endpoint does not seem to get set with the Pod IP matching the selector. Hence no DNS.
I will keep looking into it.

[sebgoa]

I have made a fix for this in 96493a5

We need to use a "dummy" port in the headless service creation, otherwise the endpoint does not get populated and DNS entries do not get created.

[surajssd]

@Runseb how about having a separate PR for this particular thing, rather than having it embedded in the "Socks Shop example"?

[sebgoa]

@surajssd ok, I broke things up. #157 addresses the headless service alone.

[surajssd]

@sebgoa thanks 👍

[cdrage]

@kadel #157 has been merged, would this be closed?

[surajssd]

@cdrage yes this can be closed.