Did docker compose up -d, create a public sub domain hostname under my main domain as wordpress.<domain>.com pointing at the container service as → http (protocol) and wodpress:8092 (service), it was working fine yesterday.
So, after I was done with my testing, I did docker compose down.
And today I did docker compose up -d → it is not working, giving me 502 (error) - I haven’t even touched anything it it broken now, don’t what is the cause.
Also, do take a note here^, the compose container is accepting connections to from my LAN (local network) but not via the cloudflared container.
So to double check I created a new service, with same docker-compose.yml and it is working fine with that.
If someone can help, would be really appreciated, this^ same scenario also happened before when I 1st tried the cloudflared like 2 months back.
I’ve already checked reddit and Cloudflare community itself, nothing robust.
Okay, so this is for whoever comes here in the near future.
It seems like there is some issue with the base image of cloudflared (official one) with local name resolution.
So, on the main zero trust dashboard under the services and under the public hostname section, I specifically put the targeted service as <IP-of-my-local-machine-on-which-cf-container-and-service-is-running>:<port-of-targeted-service>
It is working now.
If someone from the cf community side of cf people wants to clarify this further, feel free to leave your comments.
When you map ports, it only makes it accessible to hosts outside the docker network. You can still use docker-to-docker without mapping ports, so 80 should work while I don’t see 8092 working for container to container.
Oh, I didn’t knew about this, so you are suggesting is that I can simply put the : and CloudFlared container running under a compose stack can pass traffic to main container without specifying the host level information on zero trust dashboard under public hostname? If ‘yes’ then it is super cool.
Deleted my last reply, because it was my fault, I placed wrong target service in public hostname.
Seems like it worked well now.
So, for future comers what I did is, I kept the mapping ports section for main container, just in case if I want to access the service locally and under the public hostname section on zero trust dashboard, I place target as http (depends upon you service) and then target as <name-of-service>:<port-on-which-container-is-listening> (I haven’t place the mapped port here, just the service name and service port).
# mapping? -> because I want to access the service on my LAN as well
- type: bind
- type: bind
command: tunnel run