How to control versions and configs for launched containers

Rancher 1.x
1

(this is a topic that was started offline with Will @ Rancher, moved here at his suggestion)

I have a particular image that I launch into containers, distributed across my network, about 40-50 times. Each time, however, the configuration is slightly different:

  • Label - each time it gets a label, e.g. “myservice.name=$name” where $name is unique to each instance (yes, I know what it is and store it in global configs)
  • volume - each one gets a volume mounted that depends on the same variable, e.g. -v /opt/mystuff/configs/$name/conf:/opt/mystuff/conf (in other words, host already has all of the configs, I map the unique config to this one)
  • Image version - each config has a version of the image it runs. All will run “myimage”, but which version it runs depends on the config
  • IP and networking - see questions How to launch with custom network configuration?

So I might have a config that looks like:

NAME=foo1
VERSION=8.2.5
IP=1.2.3.4

And another config looks like

NAME=bar1
VERSION=2.2.6
IP=8.9.6.7

I am trying to understand how I would manage these within a Rancher environment. In pure command-line Docker, I would wrap a script that would pull these variables from the service (read global config or ini file, or query DNS, or use Consul or etcd or ZooKeeper). How would I launch these 40-50 containers, each with a slightly different variable-driven config?

2

Hi deitch,
I’m currently working on a templating feature for rancher-compose that will allow for variable substitution within the template. You’ll be able to specify macros within the compose.yml.template file such as:

service:
image: myimage:%{version}
labels:
myservice.name=%{name}
volumes:
- /opt/mystuff/configs/%{name}/conf:/opt/mystuff/conf

rancher-compose will accept a .yml answer file or prompt for these values if no answer file if provided. If you’re using rancher’s VIP for the container, that’ll have to be queried from a new service we’re developing. If it’s just an IP that you want to pass into the container, you should be able to specify this in an environment variable.

Please let me know if this helps or answers your question. Also, any feedback is greatly appreciated. Thanks!

3

Hi @sonchang

Will had told me you guys were working on a templating feature, essentially generating docker-compose files from a template built on the fly from variables.

I think it is a great idea. I am not sure if I prefer the macro substitution (handlebars-style) or variables, but I guess it doesn’t matter.

I think it would be important to have it be an inherited service, so I can define “serviceA” that is inherited from “service-top-template” with a bunch of variables.

Inputting from a yml or ini or env file is great (don’t care which, pick one), but defining it in the Web UI also is great. Think how I would use it. Applications team defines lots of services that inherit from a base template. They then hand it off to ops, who define the vars for each one, and use the Web UI to scale and launch.

So, for now, it is individual services, but soon enough I can extract the vars to separate space, and manage them separately.

4

Hi @deitch
The ‘extends’ functionality from compose will also apply to the templates. So you can have one template extend another template with different substitution variables in each.

5

Templating still is the key, though. I am surprised docker-compose doesn’t support it yet. Maybe I will open an issue with them…

6

Well, it looks like there have been open requests for this for some time.




7

:+1: for this.

I was planning on generating the compose files dynamically anyway, but templating might make that process simpler.

8

This is one of the last miles for more elegant CI/CD. Once available we can see if there is anything else that needs improvement when used in conjunction with rancher-compose upgrade.