Skip to main content

A docker-compose wrapper. Compose your docker-compose files.

Project description

Dompose

If 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 manager uswgi-emperor.

Installation

pip install dompose

Usage

Start with a directory for your related services and include a 'services-available' folder, and a .env file.

my-services/
├── .env
└── services-available/

You can then add your interelated docker-compose services in the services-available folder.

my-services/
├── .env
└── services-available/
    ├── php.yml
    └── my-website.yml

The config files can just be docker-compose config files but you can also make user of extra composer features.

php.yml

version: "3"
services:
  ${PHP_FPM_NAME}:
    build: /path/to/docker/file
    container_name: ${PHP_FPM_NAME}
    image: ${PHP_FPM_NAME}
    volumes:
    networks:
      - ${MY_NETWORK}
    restart: always
networks:
  ${MY_NETWORK}:
    driver: bridge
volumes:

composer_base: true

my-website.yml

version: "3"
services:
  ${WEBSITE_NAME}:
    container_name: ${WEBSITE_NAME}
    image: nginx
    volumes:
      - /path/to/my/website:/var/www/website.com
    networks:
      - ${MY_NETWORK}
    depends_on:
      - ${PHP_FPM_NAME}
    restart: always
composer_compositions:
  - type: add
    value: /path/to/my/website:/var/www/website.com
    to:
      - services
      - ${PHP_FPM_NAME}
      - volumes

.env

PHP_FPM_NAME=php-fpm
WEBSITE_NAME=website
MY_NETWORK=web-network

The extra syntax visible in this example is:

  • Environment variables everywhere e.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_compositions
    The syntax for modifying other services. In the example we want to add our file path mapping /path/to/my/website:/var/www/website.com to the php services volumes section. The to value is just the path within the yml file.
  • composer_base
    Composer will combine all the services into a single docker-compose.yml. To do this one config must be nominated as the base config. 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 them

dompose enable php
dompose enable my-website

Which would symlink them into a new folder services-available

my-services/
├── .env
├── services-available/
│   ├── php.yml
│   └── my-website.yml
└── services-enabled/
    ├── php.yml
    └── my-website.yml

Running the script once more

doompose

Will generate a docker-compose.yml

my-services/
├── .env
├── services-available/
│   ├── php.yml
│   └── my-website.yml
├── services-enabled/
│   ├── php.yml
│   └── my-website.yml
└── docker-compose.yml

And then you can use docker-compose as normal

docker-compose up -d

Enabling and disabling services is as simple as removing their files from the services-enabled folder, manually or using the inbuilt command

dompose disable my-website

You can also list a few more configuration arguments for dompose

./dompose --help

Internals

There's nothing complicated in the script, so reading it probably isn't a terrible way to find out how it works.

The enable/disable commands work by adding and removing symlinks into the enabled folder, with some file system checking etc.

The main run command 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.

Limitations

  • At the moment the only composition is the add composition 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.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for dompose, version 0.0.3
Filename, size File type Python version Upload date Hashes
Filename, size dompose-0.0.3-py3-none-any.whl (5.8 kB) File type Wheel Python version py3 Upload date Hashes View hashes
Filename, size dompose-0.0.3.tar.gz (5.7 kB) File type Source Python version None Upload date Hashes View hashes

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page