Proposal: Allow fig up (no other arguments) to run a subset of containers

[nonsensery]

TL;DR

It seems like it would be useful to be able to specify a subset of "default" containers that would be run when using plain old fig up.

Background

As a concrete example, I have a Rails app that uses Cucumber for feature testing. (The Cucumber tests run as a separate process that makes requests to a running instance of the application.) I would like to have the Cucumber tests containerized along side my application so that my team (and our CI server) can easily run the feature tests.

If I do this, though, then a plain fig up has the effect of starting all of my containers (including the Cucumber container), running the feature tests, and then shutting down.

A work-around is to use fig up app to launch the app (and db, etc), but this just doesn't sit right with me. It seems like anywhere Fig is being used, I should be able to run fig up and get a running version of the thing.

Proposed Solution

What if there were a way to designate one or more containers as the "default" containers? Running fig up would then be equivalent to running fig up <default containers>. (That is, the default containers and all of their linked containers would be started.)

A Strawman

I hesitate to spell out exactly what this setting might look like, because I'm afraid it will cause people to fixate on that aspect. But, it seems like it would be useful for illustration, so here is one way it could be done:

app:
  default: true # <= This is the container that most people will want to run most often
  build: .
  command: bundle exec rails server
  volumes:
    - ".:/code"
  links:
    - mysql
    - redis
  ports:
    - "3000:3000"

cucumber:
  build: cucumber
  command: cucumber
  volumes:
    - "cucumber:/code"
  links:
    - app

db:
  image: mysql

redis:
  image: redis

Using this file, running fig up would be equivalent to fig up app. It would start up the db, redis and app containers and run until the app container exited.

Impact Assessment

Obviously, changing the behavior of such a basic command is a Big Deal, and backwards-compatibility is important. Compatibility could be maintained via a "fallback" behavior where if there are no "default" containers, then you just run 'em all like before. That would allow people to opt into this new behavior. The behavior of fig up xxx yyy would be unchanged.

[dnephin]

If I understand this correctly, the only difference would be that you could run fig up instead of fig up app, but the behaviour would be the same as if you had run fig up app, is that right?

[nonsensery]

@dnephin Yup!

[hugochinchilla]

+1

[srobertson]

Looking for this feature as well.

My needs are similar. We have several services that should start on fig up and several one-off admin type process like "restore database", "unit test"... etc that should only be ran manually with fig run.

[itoed]

This proposal is quite nicely written. I think fig users would definitely benefit from it, and I certainly have a need for this. However, I would personally prefer to see fig exec be prioritized, as per #423.

[hadim]

+1

[hadim]

In the same spirit, could you allow fig rm to remove a subset of containers ?

For example it can be usefull to remove all containers except them with data volume.

[dnephin]

I don't think this is a good idea (for both up and rm).

You can already start or rm a subset of containers by using their names:

fig up web # also start all dependencies 
fig up web redis db

fig rm redis
fig rm db redis

Having these default to a subset of services makes it less intuitive, and it doesn't give you any extra functionality. This feature would actually remove functionality, since it would make it impossible to perform some action on all containers if you were to specify a subset.

[Vrakfall]

I think their idea is more like being able to write shorter command lines, being able to fig up several containers by walling one group rather than calling all of them and rather than having to go in the directory in order to write a simple fig up. It's more about user customization in my ears.

[mathroc]

I'd like to see something like this for fig up (not fig rm) because of utility or "one shot" container (eg: database initialization).

I don't want fig up to ru-run the one shot containers each time

but instead of adding default: true to container I want to start and let fig guess that if there is no container with default: true it should start all of them, I'd like to add default: false or autostart: false to container I don't want to start

[bfirsh]

Thanks for the suggestion! I've created an issue here to aggregate many similar suggestions: #1896