I've been doing something similiar but now I want to bring my Ansible roles under CM. I haven't fully worked out yet how to structure. I have in mind something like the layout below. The baseline for Host A might look like:
Host A - Kickstart 1.2.3 - DNS BIND 9.1.2 - DNS BIND Role 1.2.3 - App x 3.4.5 - App x Role 1.0.4 - Common Role 2.3.4 Every CI (kickstart file, applications, Ansible roles, etc.) has a version ID. My CMDB will track these IDs. Prod and staging (and other environments) will have a different baseline. If Common Role 2.3.5 makes it through testing and my change control process, then it gets pushed to production. (BTW, This is why I think Ansible's push mode is far better then Chef's pull mode for real CM.) If Common 2.3.5 causes a problem despite having been tested, and that happens, then I can rollback Common to the last known working rev--2.3.4. This is the idea at least. I'm still working through the toolchain to support it and how to adapt Ansible to this model. On Sunday, April 27, 2014 2:18:33 PM UTC-4, Adam Morris wrote: > > > > On Sunday, April 27, 2014 4:49:15 AM UTC-7, Aaron Hunter wrote: >> >> Peter, >> >> As for terminology I use "baseline" and "configuration item" (CI) >> according to normal usage in the CM context (see IEEE 828-2012 and ISO >> 10007:2003). Unfortunately "CI" is frequently used to mean continuous >> integration (like with Jenkins) so that's confusing. CM requires a >> baseline and a set of CIs. My question was, if people are not using roles >> as a CI then what are they using? In other words how are you tracking the >> versions of your baseline and the versions of the changes you make using >> Ansible? >> >> > CM 'of course' being configuration management... > > Actually, I'm using a combination of a kickstart file and an Ansible role > to establish my baseline... (I suppose that you could argue that the > kickstart is my baseline, but the "common" Ansible role is applied to all > servers so it is really part of the baseline. > > We haven't got to the point where all changes are made using Ansible so > this is more academic on my part... We have multiple Roles so far that > apply to different servers for different purposes. For example, the common > role sets up a baseline. I have a "group" role that does some fact > gathering and then sets up various host groups automatically (OS and > version, hardware platform, and so on) (that's actually the first one > run)... We have a role to setup a monitoring agent, we have roles to set up > some hardware dependent software... I would consider the physical machine > (or VM or partition or...) to be the CI. A combination of roles is applied > to a given CI (and Ansible can tell us which roles) will be applied. > > As for versioning, at this stage I always want the latest version of each > role applied, so that's not an issue for me... I can always run Ansible in > check mode to see if it would change anything. (I wish check mode was more > complete and accurate, but it's good enough). > > Adam > -- 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/8f26cd19-e807-43c9-a80d-3f3e8f43108a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
