Feature: Pass source containers environment vars and volumes to new container

[alister-cf]

Looking to do something similar to the example below but for several containers. I could manually add the volumes and name (used to create a container specific backup directory, stop container before backup, pull additional details from docker inspect) but wouldn't it be nice if they could be picked up and provided automatically?

Given the following stripped docker compose:
version: "3"
...
nginx:
image: nginx
volumes:
- nginx_config: /etc/nginx
labels:
chadburn.enabled: "true"
chadburn.job-run.backup-volumes.schedule: "@every 1h"
chadburn.job-run.backup-volumes.command: "backup volumes full"
chadburn.job-run.backup-volumes.image: custom-backup:latest
chadburn.job-run.backup-volumes.volume: ["/opt/backups:/backup:rw"]
chadburn.job-run.backup-volumes.provide: ["name", "volumes"]
chadburn.job-run.backup-volumes.env: ["id=my_id", "key=my_key"]

this would result in the following:
docker run --rm -e name=nginx -e id=my_id -e key=my_key -v /opt/backups:/backups:rw -v nginx_config:/etc/nginx custom-backup:latest backup volumes full

an exec example would be the same, but I can't see any way to pass volumes so would have to skip that!
docker run --rm -e name=nginx -e id=my_id -e key=my_key custom-backup:latest backup volumes full

"provide" takes an array of properties from the container it's specified on, useful things that come to mind would be container name, volumes, ip, environment vars, labels

Thinking too much about it, it could just be docker inspect values in some sort of dot notation like .Config.Hostname, .Config.Image, .Config.Labels["com.docker.compose.project"], .Config.Env["my_env"] to make it flexible

env would be for additional environment variables to pass to the new container or existing container.

The main thing I was looking for was a way to identify the container that the new container/exec was triggered for!, but I got carried away with dreams and came up with the above!

[maietta]

I'm swamped with existing work, but I do have a new version of Chadburn in the works. The next major version may very well support a plugin architecture, which means a plugin could be written to extend the core functions to include what you are trying to achieve. I don't think it should include what you want in the core. It should be a plugin.

The reason I haven't released it yet is because even if I clearly state it isn't to be used in production, people will use it in production. There will likely be a lot of breaking changes soon after release, which is why I'm work on it as I can, trying to get it to a state I believe will be useful for the long haul.

Great feature request, btw.

[ocomsoft]

@maietta Can I suggest that maybe a Docker Compose config is used for the inspiration here?

@alister-cf I found this because I wanted the same thing.. but as I read this I reaslied there might be another way. I have not tried it yet. However we use DroneCI and need to do something similar - what we end up doing was use a container like this 'docker/compose:1.29.2' and running this command 'docker-compose -f /app/docker-compose.yml' aslong as the Docker socket volume is added and the docker-compose.yml file is there it will "fire" up the service and there is really no limit to what you can start! Again I have not tried it with Chadburn but I thought I should write this before I forget.

Also @maietta maybe this could be a Hack to Create a docker container from this image using the compose.yml from the config and then just "running it". Instead of implementing a whole config like Compose. It also allows it to upgrade quickly as compose is updated.. Just a suggestion. I hope this helps someone.

UPDATE: It occurred to me that this might not work as I assume the docker socket volume is not automatically added to the containers that are run.