from WbrJr@lemmy.ml to selfhosted@lemmy.world on 27 Jan 00:20
https://lemmy.ml/post/25246067
Update: I was overwhelmed by settings. After some more research and thinking I got it working. My dns was set up incorrectly, i referenced the container with the wrong name (the name of the container is not the container_name, but the name of the service in the docker compose file). I then had some other issues with port collisions but could resolve them by killing (docker stop) thingsboard and restarting all services.
So: problem solved! thanks for the answers though!
Hi! I have a server with static ip, that runs docker with caddy and thingsboard (iot dashboard). I have my domain, that points to the servers ip (both ipv4 and ipv6). (I tried using with “www” and with wilcard “*” in the A and AAAA records)
Thingsboard can be reached in the browser via ip:8080, or domain.com:8080 (or with the wildcard “*” set in DNS records with (anything).domain.com:8080). It is set up this way by the creators, where i got the compose file (without caddy) guide here. So i guess no routing is done via caddy.
the caddyfile looks like this:
thingsboard.domain.com {
tls internal
reverse_proxy thingsboard:8080
}
Thingsboard cant be reached via thingsboard.domain.com which i would be expecting with this config. Below is the compose file.
They are all part of the same docker network (they get listed when i inspect the network).
some specific questions:
- how do i have to setup my dns records, so that all requests to any subdomain get send to caddy and i can do all the routing (from the subdomain to the service) in caddy? What am i missing in the caddyfile
- can i deactivate the port from the thingsboard container, so it cant be reached via the port from “outside” only from inside the docker network, by caddy?
- why am i struggling so much with this basic docker and networking stuff “docker is easy, you should try it” :D
Thanks a lot for reading, i hope someone can help! I dont know what to search for to get this working, networking stuff is still a blurr.
Here is the docker compose file:
services:
caddy:
image: caddy:latest
container_name: caddy
restart: unless-stopped
cap_add:
- NET_ADMIN
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- /srv/caddy/Caddyfile:/etc/caddy/Caddyfile
- /srv/caddy/site:/srv
- caddy_data:/data
- caddy_config:/config
networks:
- caddy_network
kafka:
restart: unless-stopped
image: bitnami/kafka:3.8.1
container_name: kafka
ports:
- 9092:9092 #to localhost:9092 from host machine
- 9093 #for Kraft
- 9094 #to kafka:9094 from within Docker network
environment:
ALLOW_PLAINTEXT_LISTENER: "yes"
KAFKA_CFG_LISTENERS: "OUTSIDE://:9092,CONTROLLER://:9093,INSIDE://:9094"
KAFKA_CFG_ADVERTISED_LISTENERS: "OUTSIDE://localhost:9092,INSIDE://kafka:9094"
KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: "INSIDE:PLAINTEXT,OUTSIDE:PLAINTEXT,CONTROLLER:PLAINTEXT"
KAFKA_CFG_INTER_BROKER_LISTENER_NAME: "INSIDE"
KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE: "false"
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: "1"
KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: "1"
KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: "1"
KAFKA_CFG_PROCESS_ROLES: "controller,broker" #KRaft
KAFKA_CFG_NODE_ID: "0" #KRaft
KAFKA_CFG_CONTROLLER_LISTENER_NAMES: "CONTROLLER" #KRaft
KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: "0@kafka:9093" #KRaft
networks:
- caddy_network
volumes:
- /srv/thingsboard/kafka-data:/bitnami
mytb:
restart: unless-stopped
container_name: thingsboard
image: "thingsboard/tb-postgres"
depends_on:
- kafka
ports:
- "8080:9090"
- "1883:1883"
- "7070:7070"
- "5683-5688:5683-5688/udp"
environment:
TB_QUEUE_TYPE: kafka
TB_KAFKA_SERVERS: kafka:9094
networks:
- caddy_network
volumes:
- /srv/thingsboard/.mytb-data:/data
- /srv/thingsboard/.mytb-logs:/var/log/thingsboard
#general networks
networks:
caddy_network:
driver: bridge
ipam:
config:
- subnet: 172.20.0.0/24
#general Volumes:
volumes:
caddy_data:
caddy_config:
kafka-data:
driver: local
threaded - newest
It looks like your thingsboard container is listening on 9090 internally. Try pointing caddy to that port.
Uff docker is easy yes, but this project has lots of fiddling. I personally avoid tools like this.
Just a hint maybe it’s just caddy. Pointing directly to the containername doesn’t work every time “reverse_proxy localhost:8080” should work, too.
As others have said, you have bound your host port 8080 to container port 9090 and then you use caddy to reverse proxy to container port 8080, which doesn’t exist.
As for DNS, it’s just a translation system - you send a domain, it returns its IP (for A or AAAA), everything else is done on server. So your current setup works.
Yes, you can deactivate the port, if you’re not gonna use it on the host, you don’t need it. Since you’re connecting via the internal network, you’re not using the bound ports.
As a side note, use some firewall and disable everything but 80, 443 and 22, you should not leave other ports open, especially if you’re binding all the ports in docker like that.
And perhaps make it a good habit to bind ports to 127.0.0.1 by default, that way no one outside the local server can access them. You can do it like this: “127.0.0.1:8080:9090”
I think you can also use expose instead of ports in the compose file to only make them available on the internal docker network.
IIRC, you can’t control to which port it’s bound which is not that useful.
We may be talking across each other here. Or I may be wrong about the details.
Instead of
You can use
And that port will only be usable on the declared caddy_network, so caddy could still reverse proxy to it but nothing from outside will be able to access it.
This answer surprised me. Træfik (on docker or podman) uses the internal (container’s) port, not the external (host exposed) port.