Hi James,

thanks for the tip. I think the approach is not totally suitable for my
situation. I would rather not define all the databases for one server in one
place for two reasons:

I would like to have it very easy to "move" the database to a different server
(only in the sense that it gets installed on a different server if I run
everything from scratch to install a test/staging environment)

Also quite important is that I want to be able to run a playbook that installs
just db01 and not db02 to save development time (e.g., when I change the
database schema of db01, but do not want to run the tasks that check if there
needs to be updates to db02 or when I want to setup a new test environment
where I know that I do not need db02...).

Maybe there is a way to setup things that I have to compromise at most on one
of these things?



On 20.11.2014 17:18, James Cammarata wrote:
> Hi David, the best way to do this would be to make the role aware of the fact
> that there may be more than one database installed on it, so that the
> variables in the group would then become an array:
> 
> # group_vars/foo.yml:
> databases:
> - name: db01
>   user: db_user1
>   password: xxxxxx
> - name: db02
>   user: db_user2
>   password: xxxxxx
>   ...
> 
> And then you would loop over this list in your role tasks.
> 
> Hope that helps!
> 
> 
> On Thu, Nov 20, 2014 at 5:30 AM, David Fritzsche
> <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     Hi all,
> 
>     in the setup I would like to automate with ansible I have mostly servers 
> with
>     distinct purposes and on each server they may be several distinct
>     services/components. The plan is to use ansible to have the configuration 
> of
>     all these servers in one place and to enable us to setup staging 
> environments
>     for the new software we develop and for new releases of the software 
> stack we
>     use (mariadb, nginx, ...)
> 
>     Since we want to be able to rearrange the "services" (i.e., a database or 
> a
>     FastCGI application) independently to different hosts I started to 
> organize
>     everything into ansible groups, i.e., I have groups like
> 
>     - database_01
>     - database_02
>     - ...
>     - fcgi_01
>     - fcgi_02
>     - ...
> 
>     for each group I set variables in group_vars/<group-name>, which looks a
>     little bit like the following:
> 
>     group_vars/database_01::
>     ---
>     database_name: db01
>     database_user: user01
>     database_password: xxxxx
>     ....
> 
>     and then I have defined roles so that I can use very simple playbooks to 
> roll
>     this setup out:
> 
>     database_01.yml::
>     ---
>     - hosts: database_01
>       roles: [ database_role ]
> 
> 
>     Now for the tricky part: The way ansible works this can not work if I 
> have two
>     databases on the same host. Then I would have two database groups (e.g.,
>     database_01 and database_01) that contain the same host
> 
>     hosts::
>     [database_01]
>     db_host
> 
>     [database_02]
>     db_host
> 
>     and the playbook would load for host db_host the variables of all groups 
> that
>     include db_host, i.e, the variables of both database_01 and database_02 
> are
>     loaded and I do not install the correct database when running the 
> playbook.
> 
> 
>     Is there some best practice how to configure small "components" 
> (databases,
>     fastcgi applications, ...) so that I can separate the configuration of the
>     component from the configuration where the component is going to be 
> installed
>     and I can have multiple "components" of the same kind on the same host?
> 
>     --
>     You received this message because you are subscribed to the Google Groups
>     "Ansible Project" group.
>     To unsubscribe from this group and stop receiving emails from it, send an
>     email to [email protected]
>     <mailto:ansible-project%[email protected]>.
>     To post to this group, send email to [email protected]
>     <mailto:[email protected]>.
>     To view this discussion on the web visit
>     
> https://groups.google.com/d/msgid/ansible-project/546DD0E0.9070207%40mvua.de.
>     For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CAMFyvFiBJy%2BvD90h_9zTBCqLxaXd6qV76LUnavdq9XqdW68hGQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/ansible-project/CAMFyvFiBJy%2BvD90h_9zTBCqLxaXd6qV76LUnavdq9XqdW68hGQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/546E20C2.7050400%40mvua.de.
For more options, visit https://groups.google.com/d/optout.

Reply via email to