Repository navigation
Add possibility to resolve domains in the backend definition #347
Description
Activity
Hello,
The feature is a bit tricky, because we must think about where and how often the name check happens. The various solutions:
- the master checks the domain regularly and updates the configuration of the workers. A bit complex to implement but very few DNS requests (not all usages of this feature would rely on
/etc/hosts) and a small state to keep around - the worker checks the domain before connecting to the backend. Easy to do, but potentially lots of DNS requests. We can have a cache, but then each worker would end up with their own cache (or rely on the OS's DNS cache?)
In the configuration messages, do we make an enum
domain/IPto identify a backend?The
lookup_hostfeature in libstd is only available on nightly. Or do we embed a DNS client in sozu? TrustDNS is nicely designed.- the master checks the domain regularly and updates the configuration of the workers. A bit complex to implement but very few DNS requests (not all usages of this feature would rely on
we should do this now
Reacted by Pierre Zemb, mtfcd and Satoshi MisumiHello everyone. Is this still a thing? Do people want this? ping @PierreZ
Reacted by ToBinio, Evgeny Formanenko, mtfcd and Matthias HörmannReacted by mtfcdHow do you even run sozu in a Docker Compose or Kubernetes environment without this?
How do you even run sozu in a Docker Compose or Kubernetes environment without this?
in docker compose you can define a network with static ip addresses.
services: proxy: build: dockerfile: ./dockerfile.proxy context: . command: ["sozu", "start", "-c", "config.toml"] volumes: - ./sozu.toml:/etc/sozu/config.toml ports: - 8080:8080 - 80:80 - 443:443 networks: sozu_net: ipv4_address: 172.20.0.99 myapp: ... networks: sozu_net: ipv4_address: 172.20.0.1 volumes: data: networks: sozu_net: driver: bridge ipam: driver: default config: - subnet: 172.20.0.0/16 gateway: 172.20.0.1
How do you even run sozu in a Docker Compose or Kubernetes environment without this?
this is my quick workaround (works fine in Docker Compose)
I just let make render the config at startup and resolve service names into IPsdocker-compose.yml
services: api: build: api ports: - 8000:8000 frontend: build: frontend ports: - 3000:3000 proxy: build: proxy environment: - HOST_API=api - HOST_FRONTEND=frontend command: ["make", "run"] # ← run the Make target ports: - 8080:8080
Makefile
# Grab the first IPv4 for a hostname DOMAIN2IP = $(shell getent ahostsv4 $(1) | sed 's/\s.*//;q') # If env is empty, fall back to localhost IP_API := $(call DOMAIN2IP,$${HOST_API:-localhost}) IP_FRONTEND := $(call DOMAIN2IP,$${HOST_FRONTEND:-localhost}) run: ## generate sozu config and boot it printf '%s\n' "$${SOZU_CONFIG}" > out.toml sozu start -j -c ./out.toml print_sozu_config: printf '%s\n' "$${SOZU_CONFIG}" define SOZU_CONFIG [[listeners]] protocol = "http" address = "0.0.0.0:8080" [clusters] [clusters.Frontend] protocol = "http" frontends = [{ address = "0.0.0.0:8080", hostname="*", path="/front" }] backends = [{ address = "$(IP_FRONTEND):3000" }] [clusters.Api] protocol = "http" frontends = [{ address = "0.0.0.0:8080", hostname="*", path="/api" }] backends = [{ address = "$(IP_API):8000" }] endef export SOZU_CONFIG
Why this? Because in Compose the service names (
api,frontend) resolve nicely inside the network; I just turn them into IPs once at startup and bake them into the config.
Hi!
I was playing a bit with sozu yesterday. I had a configuration file like this:
Here's the log:
As I was playing with sozu with docker-compose using links, I don't have to use IPs. From what I see in the log
could not parse address: egress:8080doesn't seems to be parsed into an IPv4 address.Am i right? If so, is it possible to add the possibility to resolve domain using
/etc/hostsfile?As I am always looking for new challenges, if it's an easy PR, I would love to give it a try!