Compose: No variable substitution in service names

Created on 4 Mar 2016  路  7Comments  路  Source: docker/compose

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.

areconfig kindocs

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.

All 7 comments

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.

Was this page helpful?
0 / 5 - 0 ratings