Add environment override configuration support.

[ryanissamson]

Purpose: In some organizations, a single team provides shared
configuration across multiple projects.

Allowing for one or even an arbitrary amount of environment override
files should be doable, I think. It's just a matter of whether or not it makes sense for Docksal to support.

In my situation, one team desires the ability to create a custom docksal-local-overrides.yml file to make some configuration standard across all the organization's projects in an automated fashion. But the preference is for this to stand alone in its own configuration file.

[ryanissamson]

A quick note here, I haven't tested this, but am opening up to begin the discussion before I invest a ton of time into it (also it's late on a Friday :) ). Hoping that I didn't miss anything obvious here.

[lpeabody]

So, Docksal combines multiple compose configuration files together when it runs docker-compose commands against a given a project. Its effectively something like:

docker-compose -f ~/.docksal/stacks/services.yml -f ~/.docksal/stacks/stack-acquia.yml -f ./project/.docksal/docksal.yml -f ./project/.docksal/docksal-local.yml

Where you could add in something like this overrides feature, I would argue that:

1. The environment-specific Docksal configuration file (e.g. docksal-local.yml) must always be loaded last, because it should have the last say. It is extremely confusing if you add something in a local-only file only to see that what you added is being overridden by something else that is hardcoded and unchangeable.
2. This could be handled more generally by having a feature that allows you to chain additional compose configuration files and environment files in the docker-compose configuration command that gets assembled (see above), with the caveat that all of Docksal's standard configuration/env files come first, and the environment-specific file(s) are always added last in the chain.

So, if something were implemented like in point 2, you'd be able to include these additional configuration files, either in the global Docksal directory somewhere or your project's .docksal directory. Does that sound like a solution that would work for you?

[lpeabody]

@ryanissamson would you also be able to share your specific use case?

[ryanissamson]

@lpeabody Something like #2 sounds like it'd work great. I also had seen the documentation for docker-compose to allow for multiple configuration files, so I think that sounds great!

In my specific use case, our organization has a great many Drupal properties. which use Docksal for local development. These Drupal properties are mostly different enough to need their own unique configurations (their own custom docksal-local.yml), but there are common, shared tools that all properties utilize. A single team manages those shared tools. Currently, when a shared tool is implemented/updated, the Necessary Docksal updates to configuration have to be manually completed for each property, even though we also have the same team's non-docksal infrastructure updates ingested automatically to each property and built via composer. If we could have a separate docksal-configuration.yml file, each project would get the updates on a regular composer update, removing the manual updates.

I'll go one step further to demonstrate the need, even though that paragraph may have been enough—I have explored patching the docksal-local.yml files on composer install as a post script, but being that it's a .yml file, I can't rely on updates being appended under the correct properties. I say this just to demonstrate that altering an existing file doesn't seem feasible, causing us to look for a way to include a separate file.

[lpeabody]

@ryanissamson I've started an independent issue to track this ask #1558. Let's suss out the details in there. I've marked this as draft pending where we net out in that conversation.