Web service on Docker deployments is exposed even if port is not specified (for Traefik usage)

Wappler v5.5.0

Web service on Docker deployments is exposed even if port is not specified in target settings (for Traefik usage)

      - 'db'
      - '3000'

The ports property should be removed if no port is specified in the target settings, otherwise Docker will publish a randomly chosen port to the container’s port 3000. Traefik doesn’t use the ports property above, and instead uses the container’s port specified through a Traefik label (already present but not shown on the excerpt above)

1 Like

Just trying to understand. How will this affect local development if ports property is removed or, am I interpreting your request incorrectly?

Good catch. If the ports property is removed for the local target, you wouldn’t be able to preview your project on the browser. For local development, we can keep the the property - this would be nice for a future Wappler release where you could have multiple projects open at the same time, with the services at randomly assigned ports. I believe most Wapplers would have a port set at the project settings though, so it wouldn’t affect those users.

For remote deployments, generally you have something like Traefik, so you want the web service to be accessible solely through Traefik and not directly through a port :slight_smile:

If you don’t mind sharing. What would be an ideal way of how you would structure the docker-compose.yml for production target yml?

If I am thinking correctly here instead of ports: use command: and run the node index.js, and one could handle the volumes however they want on the production server I guess. What you think?

version: '3'




      - '../../../app:/opt/node_app/app'

      - '../../../lib:/opt/node_app/lib'

      - '../../../views:/opt/node_app/views'

      - '../../../public:/opt/node_app/public'

      - '../../../extensions:/opt/node_app/extensions'

      - '../../../db:/opt/node_app/db'

      - '../../../certs:/opt/node_app/certs'

 #   ports:

 #     - '8100:3000'
        - NODE_ENV=production      
    command: node index.js

The volumes of the docker-compose you show are optimized for local development, not sure if you’re aware of that (e.g.: you’re bind-mounting a lot of directories like /app /lib /views /public /extensions that are unlikely to change in production; ideally these would be bundled in the image through the Dockerfile)

The command part looks good, though it could also go inside the Dockerfile instead of docker-compose

I’m actually still looking forward crafting my own docker-compose, the Wappler Docker deployment didn’t convince me much tbh, lacks stuff like management of certificates, assumption of using Let’s Encrypt, lack of rate-limit controls

Yes I am aware of optimization indeed. I was lazy for not removing volumes in that example when I grab the yml from the compose file. But I was just referring to the environment and command part. Good to know that you agree with command part tho.

Maybe the production yml could have this setup.

While the base yml could look something like this.

And the docker file could look like this then

What you think?

I think that’s interesting, never did that before :hushed:

Note the image built will have NODE_ENV hard-coded, so you can’t push a locally built image to a remote Docker repository (else NODE_ENV would be “development”)

What you think would be an ideal way to handle the port issue then base on how you were explaining the Traefik handling of port? I am just as curious as you are that all.

Not sure if I understand your question

The ports property is just to expose a port, but if you don’t expose anything, the container still has an open port (where NodeJS is running), and Traefik can connect to it internally through Docker’s networking

Through a Traefik label you can specify the port where Traefik should connect to, here’s how Wappler do it:

  - 'traefik.http.services.my-project__staging_web.loadbalancer.server.port=3000

Also check this reply of mine if it’s useful, the topic is hidden:

Btw we are also considering dumping nodemon in production and indeed run node directly

1 Like