Package: dompose
DomposeIf you have lots of docker containers that you need to run, and they have complicated configurations or dependencies then you would likely start using Docker Compose. Docker Compose allows you to write config files for your containers, including setting up interdependent networks and volumes. It even allows you to specify whether containers depend on other containers and will then change the boot order to ensure that the dependencies start first.But what if one of the dependencies needs to change because of a container that relies on it? For example, you have a PHP container, and you have website containers. The website container volumes need to be mounted in the PHP container, but the websites are dependent on the PHP container. Sure you could manually manage the compose file so that each time you add a new service you edit the config of the dependency but if you are frequently switching services in and out this is a pain. It would be better if the dependency container did not have to know anything about its dependants.I wrote a Python script to add an extra layer of management around Docker Compose, called Docker Composer. It's inspired by the style of the uswgi manageruswgi-emperor.Installationpip install domposeUsageStart with a directory for your related services and include a 'services-available' folder, and a.envfile.my-services/
├── .env
└── services-available/You can then add your interelated docker-compose services in theservices-availablefolder.my-services/
├── .env
└── services-available/
    ├── php.yml
    └── my-website.ymlThe config files can just be docker-compose config files but you can also make user of extra composer features.php.ymlversion:"3"services:${PHP_FPM_NAME}:build:/path/to/docker/filecontainer_name:${PHP_FPM_NAME}image:${PHP_FPM_NAME}volumes:networks:-${MY_NETWORK}restart:alwaysnetworks:${MY_NETWORK}:driver:bridgevolumes:composer_base:truemy-website.ymlversion:"3"services:${WEBSITE_NAME}:container_name:${WEBSITE_NAME}image:nginxvolumes:-/path/to/my/website:/var/www/website.comnetworks:-${MY_NETWORK}depends_on:-${PHP_FPM_NAME}restart:alwayscomposer_compositions:-type:addvalue:/path/to/my/website:/var/www/website.comto:-services-${PHP_FPM_NAME}-volumes.envPHP_FPM_NAME=php-fpmWEBSITE_NAME=websiteMY_NETWORK=web-networkThe extra syntax visible in this example is:Environment variables everywheree.g.${WEBSITE_NAME}This is an improvement on the normal docker compose environment variable. You can even use them as service names. These are picked up from the .env file.composer_compositionsThe syntax for modifying other services. In the example we want toaddour file path mapping/path/to/my/website:/var/www/website.comto the php services volumes section. Thetovalue is just the path within the yml file.composer_baseComposer will combine all the services into a single docker-compose.yml. To do this one config must be nominated as thebaseconfig. This could either be one that is expected to run all the time (as in the php example) or a blank config.So with the configuration files in place you would enable themdomposeenablephp
domposeenablemy-websiteWhich would symlink them into a new folderservices-availablemy-services/
├── .env
├── services-available/
│   ├── php.yml
│   └── my-website.yml
└── services-enabled/
    ├── php.yml
    └── my-website.ymlRunning the script once moredoomposeWill generate adocker-compose.ymlmy-services/
├── .env
├── services-available/
│   ├── php.yml
│   └── my-website.yml
├── services-enabled/
│   ├── php.yml
│   └── my-website.yml
└── docker-compose.ymlAnd then you can usedocker-composeas normaldocker-composeup-dEnabling and disabling services is as simple as removing their files from theservices-enabledfolder, manually or using the inbuilt commanddomposedisablemy-websiteYou can also list a few more configuration arguments for dompose./dompose--helpInternalsThere's nothing complicated in the script, so reading it probably isn't a terrible way to find out how it works.Theenable/disablecommands work by adding and removing symlinks into the enabled folder, with some file system checking etc.The mainruncommand reads all the files from the enabled folder as strings. It firstly does a find/replace for all the environment variables and then it parses them into python dictionaries.The base config is found and then that is used to recursively merge the dictionaries on top of that base. It does nothing clever to manage key collisions, the later read configs will simply overwrite earlier configs.With the fully merged dictionary it runs through all of the compositions from each config and applies the changes specified.Finally it dumps the dictionary to a yaml file.LimitationsAt the moment the onlycompositionis theaddcomposition which is the only one I have found useful. I can imagine uses for more verbs and it would not be too difficult to add them.It's not super clever. I think it could manage more of the bringing containers up and down itself, and do it automatically i.e wrap more of the docker-compose functionality so things can be done in fewer commands. A recompile and refresh/rebuild command might be nice. Though in some ways its nice to leave it simple and not try to solve solved problems.