Benjamin Wohlwend
Benjamin Wohlwend

Reputation: 31828

docker-compose: where to store configuration for services?

I'm building an ELK (elasticsearch/logstash/kibana) stack using docker-compose/docker-machine. The plan is to deploy it to a digitalocean droplet and, if needed, use Swarm to scale it.

It works really well, but I'm a bit confused where I should store configuration for the services (e.g. configuration files for logstash, or the SSL certs for nginx).

At first, I just mounted a host directory as volume. The problem with that is that all the configuration files have to be available on the docker host, so I have to sync them to the digitalocean droplet.

Then I thought I had a very smart idea: create a data container with all the configuration, and let the other services access it using volumes_from:

config:
    volumes:
        - /conf
    build:
        context: .
        # this just copies the conf folder into the image
        dockerfile: /dockerfiles/config/Dockerfile

logstash:
    image: logstash:2.2
    volumes_from:
        - config

The problem with this approach became obvious quite fast: every time I change any configuration, I need to stop all containers that are linked to the config container, recreate the config image and container, and then start up the services again. Not great for uptime :(.

So, what's the best way? Ideally, the configuration files would be inside a container, so I can just ship it to wherever.

Upvotes: 0

Views: 1742

Answers (2)

Daniel N.
Daniel N.

Reputation: 891

Did you consider to use the extension mechanism and override a settings file? Put a second docker-compose.override.yml in the same directory as the main compose file, or use explicit extension within the compose file. See

https://docs.docker.com/compose/extends/

That way you could integrate a configuration file in a transparent way, or control the parameters you want to change via environment variables that are different in the overriding composition.

Upvotes: 0

dnephin
dnephin

Reputation: 28080

One common solution to this problem is to put a load balancer in front of the services. That way when you want to change the configuration you can start a new container and the load balancer will pick it up, then stop the old container. No downtime, and it lets you reload the config.

Another option might be to use a named volume. Then you can just modify the contents of the named volume and any containers using it will see the new files. However if you are using multiple nodes with swarm, you'll need to use a volume driver that supports multi-host volumes.

Upvotes: 2

Related Questions