I tried docker compose up
with this config:
version: '2'
services:
beh-myodoo-$SUFFIX:
build: beh-myodoo
ports:
- "$PORT:$PORT"
links:
- beh-db-$SUFFIX:db
beh-db-$SUFFIX:
image: postgres:9.4
environment:
POSTGRES_USER: odoo
POSTGRES_PASSWORD: odoo
However that doesn't seem to work:
ERROR: Validation failed in file './docker-compose.yml', reason(s):
Invalid service name 'beh-myodoo-${SUFFIX}' - only [a-zA-Z0-9\._\-] characters are allowed
I think variable substitution should work there as well.
That's right, variables are only supported in values. Why do you need a variable in the service name?
I'm playing with some stuff inside containers, and for reference I'd like to keep old ones around at the moment.
That's why I intended to do something like SUFFIX=mar16 docker-compose up
to generate a beh-myodoo-mar16
and a beh-db-mar16
container.
If there's a better way to do this, I'm all ears - I'm quite new to both Docker and Compose.
Sounds like the COMPOSE_PROJECT_NAME environment variable would suit your use case.
That'd work, thanks! I think the docs on variable substitution should maybe mention this. :smile:
It is called out as the first feature in the Compose docs: https://docs.docker.com/compose/overview/#multiple-isolated-environments-on-a-single-host
Yeah, I mean something like "Note variable substitution won't work for service names, you might want to consider using COMPOSE_PROJECT_NAME
instead." or so in the docs for Variable substitution. At least that's where I was looking :wink:
I want to build an image that gets the same name as the service name, which is the same name as the directory where the Dockerfile lives. Using a single .env entry for all of these things would go a long way to templating out a reusable Dockerfile for multiple similarly structured microservice projects.
Is there a philosophical reason for not doing this, or is it technically infeasible? I'd love to have this as a feature.
Most helpful comment
I want to build an image that gets the same name as the service name, which is the same name as the directory where the Dockerfile lives. Using a single .env entry for all of these things would go a long way to templating out a reusable Dockerfile for multiple similarly structured microservice projects.
Is there a philosophical reason for not doing this, or is it technically infeasible? I'd love to have this as a feature.