Handling of optional services in docker-compose
At the moment docker-compose is split into aura-web and aura-playout. In general both projects contain all services necessary to run the respective setup, so:
aura-web:
- tank (+ database)
- steering (+ database)
- dashboard
- dashboard-clock
aura-playout:
- engine (+ database)
- engine-core*
- engine-api (+ database)
If you want to add optional services, there's the possibility to add them directly to the docker-compose-files. We do this in two cases at the moment. Firstly there's an optional icecast-service for aura-web. Secondly engine-core is also using a profile, since at the moment a bare-metal deployment of engine-core is to be expected.
Problems with using profiles
Regarding profiles there's one downside: docker-compose in general first evaluates the whole docker-compose-file and then applies profiles. This is a problem, when we use "required" variables (which we do at the moment). So if there's a required variable in a service using a profile, it will be required regardless of whether the profile is used or not.
To take our icecast example:
Icecast uses multiple passwords which it takes from env-variables, for example the ICECAST_SOURCE_PASSWORD. When iceast is activated, these passwords are required variables. But we can't set them as such in the docker-compose, since docker-compose will produce an error if they are not set, even when the icecast-profile is not active.
A further small problem, exists regarding dependencies. Some of our containers use depends_on to make sure that another container (e.g. the database) is up and running before the container starts. We wanted to set engine and engine-api to depend on engine-core, but this leads to them not starting at all, if the engine-core is deactivated for running as bare-metal.
Potential of using profiles
Using profiles has potential in auras setup.
One part is regarding adding new services. At the moment two new projects which can optionally be added to the deployment are in the works: recorder and cut&glue. Both of these can be added to the setup via profiles and there's no need for adding new docker-compose-files.
Another usecase would be reworking aura-playout in a way that it supports the different deployment-types of engine. So to have (multiple) nodes with engine, engine-core and engine-api and one node running only engine-api as sync-host.
A third usecase would be to merge aura-web and aura-playout together and have the distinction represented as profiles. This has the benefit of certain variables only having to be defined in one env-file. A (small) downside of this approach would be the longer sample.env.
Alternative to using profiles
Of the discussed downsides I think the dependency-one is potentially a bigger issue than the problem with the variables - since the variables are mostly a failsafe to make sure the .env-file was filled out correctly, while not using the depends_on-directive might lead to containers failing due to startup being slower than expected.
In general I think it'd be more sensible to fix these issues in docker-compose and use profiles.
Nevertheless, there's an alternative approach to using profiles. Instead we could use override-files (similar to the ones we use for a dev-setup). In these we'd define additional services (and also adapt our existing services to the new services). This has the downside of being less intuitive in the .env-file than using profiles and stretching out the configuration over multiple files.