I keep the texperience production services in separate compose files - reverse proxy, web app, search index, a few others. Each independently deployable. When I first split them apart, the backend couldn't resolve elasticsearch:9200. Separate compose files, separate default networks.
The external network approach
The conventional fix is an external network:
# Step 0: docker network create shared
networks:
shared:
external: true
services:
my-service:
networks:
- sharedThree things to dislike here. docker network create shared is a manual prerequisite. Forget it after provisioning a new server and docker compose up fails with network shared not found. Every compose file needs an explicit networks section. And every service needs a networks list.
Sharing the project name
Docker Compose creates a default network named {project_name}_default and attaches every service to it. The top-level name property sets the project name. Use the same name in every compose file:
# reverse-proxy/compose.yml
name: texperience
services:
web-reverse-proxy:
image: nginx:1.27
# ...# elasticsearch/compose.yml
name: texperience
services:
elasticsearch:
image: elasticsearch:8.12.2
# ...# cloudapps/compose.yml
name: texperience
services:
backend:
environment:
ELASTICSEARCH_URL: http://elasticsearch:9200The backend resolves elasticsearch by service name across compose files. All three problems gone. The first docker compose up creates texperience_default. Every subsequent project joins it.
Each file stays independently managed. Bring services up and down separately. docker compose down tries to remove the shared network but skips with a warning when other containers still use it. On the last active project it succeeds, but the next up recreates it. In practice, the reverse proxy is always running. One side effect: docker compose up will warn about orphan containers from the other compose files. Ignore it, because --remove-orphans would tear down their services.
Without name, the project name defaults to the directory name - each directory gets its own network. The COMPOSE_PROJECT_NAME environment variable achieves the same but overrides the file-level name, so mixing the two can break the setup. Putting it in the file is one less thing to forget during provisioning.