Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: ignored objects in compose file #2578

Closed
GeorgeTaveras1231 opened this issue Dec 26, 2015 · 4 comments
Closed

Proposal: ignored objects in compose file #2578

GeorgeTaveras1231 opened this issue Dec 26, 2015 · 4 comments

Comments

@GeorgeTaveras1231
Copy link

Recently, I've been writing compose files where many of the services had small similarities. The way in which I attempted to deal with this was by using yaml's inheritance. The reason why I wanted to use yaml's inheritance feature was because using docker-compose's extends feature felt like an overkill. It also did not help that in order to extend a service, the base service had to have a valid service configuration, otherwise, docker-compose would complain. Also, if I define random shared objects at the top level, when I run docker-compose up -d it will attempt to create docker containers based on those objects.

My proposal is to support a top level namespace that can be used to define any yaml object you want. This will provide a namespace to define shared properties and leverage yaml's inheritance.

Here is an example, (leveraging the proposed format in #2478):

ignore:
  has_special_env: &has_special_env
     VAR_A: 1
     VAR_B: 2

services:
  a:
    environment:
      <<: *has_special_env
      CUSTOM_VAR: 3
  b:
    environment:
      <<: *has_special_env

It would be nice if this was included in #2504

@dnephin
Copy link

dnephin commented Jan 17, 2016

We've been hesitant to add any special sections for the purpose of yaml anchors. You can always create an anchor in the first section it's used and refer to it again later.

Also overlaps a bit with #1655

@GeorgeTaveras1231
Copy link
Author

@dnephin You can do that in the scenario where the first section is a exact subset of the other. There may be scenarios where that is not the case. For example:

services:
  a:
    environment:
      VAR_A: 1
      VAR_B: 2
      CUSTOM_VAR: 3
  b:
    environment:
       VAR_A: 1
      VAR_B: 2
      CUSTOM_VAR: 4

@sblackstone
Copy link

sblackstone commented Sep 14, 2016

I had a good use case for this just today, (as see in the dupe ticket #3947)

I have several services running delayed_job and they need to share most of the app's config, but not all - e.g. it shouldn't be trying to publish ports.

This is what I wanted to do - instead I had to create a dummy service called default and set the command to just echo "hi"..

version: '2'

default: &default
  image: my_app
  build: .    
  volumes:
    - .:/app
  environment:      
    RAILS_ENV: development
    DATABASE_URL: mysql2://dba:abcd1234@10.0.0.1/my_database

services:      
  app:
    <<: *default
    ports:
      - "3000:3000"
    command: /app/docker-up.sh

  delayed_job_default:
    <<: *default
    command: bin/delayed_job --queue default run

@dnephin
Copy link

dnephin commented Aug 17, 2017

Closing as duplicate of #2942

@dnephin dnephin closed this as completed Aug 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants