Make common commands easier

[carolynvs]

Let's think about if we could have the mixin make common commands easier to run, and with less yaml. Sometimes, for example with helm, this gave us an opportunity to add logic that adapted an imperative CLI to a more state driven experience to improve how the mixin worked over just using the CLI directly.

For example here is upcommand:

docker-compose:
  description: "Run test services"
  arguments:
    - up
    - --detach
    - --no-color

Perhaps we could agree on a set of useful default when running docker-compose in a bundle, like you will usually want to run with --detach, and should not do color output because Porter doesn't support it.

docker-compose:
  description: "Run test services"
  command: up

Questions

• Would this be helpful or get in the way?
• Would this be a maintenance problem?
• How would we tell people to tweak the defaults for a command? Override them with arguments and flags?
• What commands should get first class commands?
• Is this the right syntax for doing this? e.g. command: up vs something like

up:
    - serviceA
    - serviceB

or

up: serviceA serviceB...

[jaudiger]

Here are my thoughts. I think docker-compose mixin should at least support the most used docker-compose commands. I have in mind:

• up
• down
• pull

If someone wants another command, this could be done later. At least, these commands subset could fulfill a lot of use cases right now.

For each command, the docker-compose mixin could provide the following (but not complete) syntaxes:

1. up: As suggested by @carolynvs, the arguments --detach and --no-color should be provided by default, in addition of that:

docker-compose:
  description: "Run services"
  command: up
  services:
  - serviceA
  - serviceB
  recreate: true # Implies `--force-recreate`
  build: true # Implies `----build`
  remove-orphans: true # Implies `--remove-orphans`

2. down

docker-compose:
  description: "Shutdown services"
  command: down
  volumes: true # Implies `--volumes`
  remove-orphans: true # Implies `--remove-orphans`

3. pull

docker-compose:
  description: "Pull services"
  command: pull
  services:
  - serviceA
  - serviceB

[vdice]

The thoughts above look great to me! One thing on the flags with comments -- they seem to be inverted?

Currently, for example:

remove-orphans: false # Implies `--remove-orphans`

I would assume if remove-orphans is set to false, the --remove-orphans flag would not be appended to the docker-compose command, correct? For this flag in particular, I would expect false to be the default value (maybe that's what was intended here?). Then, if users want to override and set remove-orphans to true, the --remove-orphans flag would be appended.

[jaudiger]

Exactly, this is was I was trying to say by using the false value. This value should be the default value and when the boolean is set to true, the variable implies the corresponding docker-compose argument.

I updated the example to reflect the comment, but it does not reflect the default value.

[jaudiger]

@vdice The discussion we are doing here (getporter/docker-mixin#34) could be replicate dor docker-compose once we agree on the best approach.

[vdice]

@jaudiger Yes, as it sounds like getporter/docker-mixin#34 (comment) is the preferred approach, we can certainly implement this similarly, with each supported command a first-class yaml field e.g.

docker-compose:
  description: "Pull services"
  pull:
    services:
    - serviceA
    - serviceB