advice on how to organize variables (and roles) in a run book

Hi all!

I have a fairly simple (at least it seems that way!) question about how to arrange variables – or even roles for that matter-- for a runbook that I’ve written for my presentation at AnsibleFest on the Docker module.

the issue is this: I use the docker module for launching a specific number docker containers and have specific images for each type of container, those types being broken into roles. The types are simply web (apache), db (percona xtradb cluster), and haproxy. There is not much in the way for this talk to try to configure the launched containers as it’s more about the ability to launch the containers.

Now, currently, I have within each of the roles of course a vars/main.yml file with a variable I was going to use “containers_count”. There is a task in roles/common/tasks/main.yml that simply launches containers

  • name: docker image control
    docker: image=“{{repository_name}}/{{ image }}” name=“{{ type }}_{{ item }}” state={{ docker_state }}
    with_sequence: count={{ containers_count }}

The top level playbook simply does this:

  • hosts: docker
    roles:

  • common

  • web

  • hosts: docker
    roles:

  • common

  • db

  • hosts: docker
    roles:

  • common

  • haproxy

This results in the above task being called for each “type” and each role has its own “container_count” from the role’s vars.

It was pointed out to me that roles need to be more of a plugin ability and specific things like a count of containers being more site-specific, perhaps using inventory. The issue with this is that inventory is per host, correct? So, in my testing, the only host is localhost, where I’m running docker. For my presentation, hosts will be a certain number and on each a certain number of containers running.

Where then would it make sense to specify the count of containers per type? Say for instance, I want 9 cluster node containers, 3 haproxy containers and 10 web containers-- what would be a portable and flexible way to do this? What is best practices in this case?

Thank you!

PS: my respository is https://github.com/CaptTofu/ansible-docker-presentation for more context.

" The issue with this is that inventory is per host, correct?"

Not to be pedantic, but Inventory is one thing that contains many hosts.

“Where then would it make sense to specify the count of containers per type?”

How about a role that deploys the container, and you specify it as a parameter to the role how many you want of each image?

(To be clear, I’m not sure why you’d want more than one identical container per host anyway)

For instance: I have an image with Percona XtraDB Cluster installed with everything I need, running in bootstrap mode. I then merely have to update it’s my.cnf file and restart MySQL versus having to install all the packages per-container. Same thing goes for simple apache web heads.

In the VM world: you are running a DBaaS service, you are certainly going to launch multiple instances using the same VM image and just tweak configs according to customer.

"In the VM world: you are running a DBaaS service, you are certainly going to launch multiple instances using the same VM image and just tweak configs according to customer. "

But not on the same host, definitely.

This is the problem with Docker int hat the cloud API to disperse images amongst host in a uniform way is up to you.

I think it’s not Ansible’s place to place them - though it’s unclear whether Shipyard, Atomic, OpenStack, etc, will evolve first.

This is why I was quite interested to see ElasticBeanStalk support Docker - (patches to add an EB module may be relevant) as those that want to use the container tech to deploy images after building them with ansible
would have a cloud engine to place them.

I don’t think Ansible should be that cloud engine though, that is, keeping track of where your containers and running and implementing a lightweight cloud is going to leave off some of the capabilites you might want later, such
as storage management or putting nodes on underutilized containers or migrating them.

Sorry, thinking ahead.