Good morning @patrick I know you are busy, but could you help me with this?
I’ve already done some error handling in the container but the socket.io still doesn’t work in Digital Ocean, I don’t know what else to do.
I really like Digital Ocean and feel great sadness seeing that socket.io doesn’t work via docker over there, please help me solve this problem.
Hi Adriano,
Well maybe some firewall is blocking your websockets. Check the firewall settings in the digital ocean dashboard and otherwise contact their customer support.
I contacted the Digital Ocean support and they said that I created the machine with my own configurations, that is, Wappler set up the container, uploaded and installed the application.
Everything was working perfectly until I put the Traefic after installing the traefic, the socket stopped working.
I believe this is not a Digital Ocean problem but a Wappler one, since it worked perfectly before Traefic.
Please, I ask you to upload an application from this one made in Wappler with socket io and point to a domain with SSL enabled to see where the error is.
Well we use all the same configuration for Digital Ocean or AWS, so if it works with AWS it should also work with Digital Ocean.
Do you have the site live somewhere so we can check?
Yes I will send you the private access to the website.
After long investigation with Adriano, I’m happy to say we found the problem.
It was Redis configuration when used with Traefik.
It was not joining the same network as the rest of the services when Traefik is used.
So when Traefik is used the Redis service also need:
networks:
proxy: ~
so it becomes in the docker-compose.yml
redis:
image: 'redis:alpine'
hostname: 'redis'
networks:
proxy: ~
volumes:
- 'redis-volume:/data'
we will fix that in the next update.
Does Traefik uses Redis at all? I’m thinking you might be doing a mistake, and instead what’s missing is the project’s network itself which might not be being created by default because you already specified a network “proxy” in the docker-compose file
Be really careful about this, you could be mixing Redis instances of different projects due to being on the same network “proxy”
No Trafiek doesn’t need Redis, but your NodeJS web site might. So when you enable Redis it is used in NodeJS for sessions for example. However when also Traefik is enabled, all the docker services like web and db are placed in special network proxy so that are isolated from the rest of the world and only accessible via Traefik and each other. But Redis wasn’t placed in the same network so that is why it wasn’t accessible even if it was running and also the web service couldn’t find Redis and NodeJS was crashing.
So placing also Redis in the same network solve all the problems.
So the correct solution is for each project/docker-compose have its own network, and only the web service joins the “proxy” network (as well as the project’s own network)
With your approach there’s a problem, how do you handle the case of you having many projects running on the same server, but the “db” or “redis” are accessible on the global “proxy” network? How does a Wappler project knows it’s connecting to its DB and not some other project’s? There are no guarantees, the hostname of Redis/DB container is the same for every project
redis:
image: 'redis:alpine'
hostname: 'redis' # So every project has same hostname? Disaster waiting to happen
networks:
proxy: ~
volumes:
- 'redis-volume:/data'
The correct solution I mentioned in the 1st paragraph
Very good question. Currently we didn’t deal much with that as you are usually deploying one project per server, but as we move to allowing more projects on the same server, we should definably address this.
So what is your suggestion? Specific network per project? And Traefik giving access to all those networks?
Maybe something like this, untested
Docker-compose networks:
networks:
default: ~
proxy:
name: 'wappler-compose_proxy'
external: true
And Redis service:
redis:
image: 'redis:alpine' # Remember to set Redis version
hostname: 'redis'
networks:
- default
volumes:
- 'redis-volume:/data'
Web service, relevant excerpt:
web:
networks:
- default
- proxy
The project’s network I named “default”, which would be what docker-compose would create for each project if you didn’t specify the “proxy” network (feel free to edit this name), so the actual real name becomes something like “projectName_default” (docker-compose does this automatically)
So, each service joins the “projectName_default” network, and the web service also joins the global “proxy” network
yes indeed something similar is described here as solution:
https://hollo.me/devops/routing-to-multiple-docker-compose-development-setups-with-traefik.html
Well it seems that placing all the docker services in a single traefik proxy network is not a problem at all with multiple projects, as each of their hostname get prefixed with the project name. So it works all fine and seems they can find each other perfectly as well Traefix redirects to the right service
Fixed in Wappler 5.5.2
This topic was automatically closed after 26 hours. New replies are no longer allowed.