Confuse in compose deploy endpoint_mode and service port setting

Hi, I got confused in compose deploy endpoint_mode and service port settings.
below are my config files.

version: "3.9"
    image: miracle/wpstpdfconverter:v1.3
      - /opt/wwwroot:/opt/wwwroot:rw
      - target: 8083
        #published: 9001
        mode: host


      mode: replicated
      replicas: 4
      endpoint_mode: vip

      - RACK_ENV=development
      - SHOW=true
      - USER_INPUT
      - TZ=Asia/Shanghai
      - "com.miracle.description=wpstpdf converter"

        - subnet: ""

when services.deploy.endpoint_mode=vip should i config a ip address for the service? I setting the ip but i got “error response from daemon: Address already in use” if not setting the ip address what will the virtual ip be? and what port will outside client access for ?

if i config the port using map like “8083:8083” , and it will got the same error. and I saw the document that the can be “ingress” for load blance what is the relationsip between ports.mode and deploy.endpoint_mode ?

my purpose is to deploy 4 instance container for the service and using virtual ip and public port to provide service , how can i make it work and what should I setting in the compose file? thank you!

Those settings only apply for swarm stack deployments (docker stack deploy) and do not apply for (docker compose) deployments.

The rest of my answer is in the context of swarm stack deployments - there is no way to use any of this for compose deployments!

ports.mode defines how a published port is bound.

  • ingress: (default) a published port will be bound on each node
  • host: a published port will only be bound on a node if one or more replica of the service is running there.

Note: Ingress does not retain the source ip, host does.

deploy.endpoint_mode defines how the service is reachable inside the container network.

  • vip: (default) a virtual ip is used, the service name resolves to the vip, which load balances round-robin to the swarm tasks (as in containers). This can cause problems with long living connections, as connections are terminated after 900 seconds
  • dnsrr: the service name will resolve to a multi-value dns record listing
    the ips of all swarm tasks. This is suitable for long living connections like database connection pools. Clients that cache the dns resolution result might end up communicating to the same swarm task (nginx does this by default)

With docker compose: the only setting that apply is replica, which will not work in combination with published port. You would need a loadbalancer/reverse proxy service that publishes ports and sends the traffic to the target service (regardless if it has replicas or is a global service).