I am suspecting that more people than us are using both cobbler and ansible. Right now we are kind of in the process of merging more and more of our old procedures into cobbler, which leaves the question of where ansible fit it.
I guess you could do it in multiple ways, but I'd be glad to hear how someone else have drawn the line.
Right now we put lots of config files in HERE documents by "snippets" in cobbler, but I'm thinking if they might better be handled by ansible and the templating system.
Any impressions or reactions?
/andreas
Hi,
I am suspecting that more people than us are using both cobbler and ansible. Right now we are
kind of in the process of merging more and more of our old procedures into cobbler, which
leaves the question of where ansible fit it.
I guess you could do it in multiple ways, but I'd be glad to hear how someone else have drawn
the line.
Right now we put lots of config files in HERE documents by "snippets" in cobbler, but I'm
thinking if they might better be handled by ansible and the templating system.
Any impressions or reactions?
I'm at the very beginning of a multi-tenant infrastructure automation
project. I have to admit that I never liked here docs because they
always appeared as a mix of logic and content, which should be avoided
for many reasons. One good answer to this problem is templating.
My current PoV about where to draw the line between provisioning and
configuration management is that provisioning should go no further
than the point where the system is bootable and manageable by the
configuration management system (this may require integration in AAA
system). With Ansible, this just requires a pair of python modules and
OpenSSH, which are installed anyway, so this is a very bare OS
install.
At this stage (system booted and accessible via SSH), configuration
management takes over to apply the classes/groups/playbooks needed for
the node to provide the service it is aimed at.
Hope it helps
Bests
I'm at the very beginning of a multi-tenant infrastructure automation
project. I have to admit that I never liked here docs because they
always appeared as a mix of logic and content, which should be avoided
for many reasons. One good answer to this problem is templating.
I agree.
My current PoV about where to draw the line between provisioning and
configuration management is that provisioning should go no further
than the point where the system is bootable and manageable by the
configuration management system (this may require integration in AAA
system). With Ansible, this just requires a pair of python modules
and OpenSSH, which are installed anyway, so this is a very bare OS
install. At this stage (system booted and accessible via SSH),
configuration management takes over to apply the
classes/groups/playbooks needed for the node to provide the service
it is aimed at.
Thanks for your feedback!
Anyone else having something to say on the matter which feels this is not the forum for it, feel free to email me.
/andreas
My current PoV about where to draw the line between provisioning and
configuration management is that provisioning should go no further
than the point where the system is bootable and manageable by the
configuration management system (this may require integration in AAA
system). With Ansible, this just requires a pair of python modules and
OpenSSH, which are installed anyway, so this is a very bare OS
install.
Definitely -- Deploying a minimal generic system in kickstart is the way to go regardless of what configuration system you use.
I do like to try to run the configuration tool in %post or at first boot time if possible though.
James Cammarata at one point was quite interested in improving Ansible support in Cobbler, I would assume with a better external inventory script than the one I wrote and a few basic snippets. This might be worth bringing up on Cobbler's list too. (I'll leave that for others to do though).
The most logical thing to me, I think, is if you wanted to set up Ansible-pull. (IF). This gives you a way to make sure things are fully configured immediately post kickstart. This could be done in %post. If you did not, you'd have to make it a two stage deploy, which is where scripts like Seth's provisioning script that uses virt-install would come into play.
The other thing in Cobbler that is really useful is the keep_ssh_host_keys snippet, especially if using the SSH connection type (because paramiko is a bit less picky about changing keys). This snippet removes nearly ALL of the SSH reprovisioning pain people talk about -- and is really a pretty neat trick. For the uninitiated, what it does is preserve the host's SSH keys in a /tmp partition while you are reinstalling via kickstarts, so Anaconda doesn't blow them away.
We decided not to use cobbler, as we use an inventory script (yaml) which we plan to connect directly to a corporate CMDB at some point.
The provisioning is done using a simple kickstart and mrepo (synchronizing with RHN). The kickstart file has a very brief post-install that keeps sshd running in the chrooted system to complete the configuration management with Ansible.
I plan to automate the provisioning using kickstart as well, but given we need iLO, VMware and KVM support this is not something we are looking at right away. However I would still like to have something that waits until the post-installation has kicked in to continue the configuration management phase.
Due to strict security requirements we are not looking into ansible-pull. Systems often are isolated and cannot initiate communication other than what is strictly necessary (and configuration management is not considered a strict requirement, and definitely not something that should require permanent access).
Given some of these requirements we build similar solutions for different customers based on common principles.
Hi,
James Cammarata at one point was quite interested in improving Ansible support in Cobbler,
That would be nice...
The most logical thing to me, I think, is if you wanted to set up Ansible-pull. (IF).
This gives you a way to make sure things are fully configured immediately post
kickstart. This could be done in %post.
Will test this in my preseed/late_command...
If you did not, you'd have to make it a two stage deploy, which is where scripts like
Seth's provisioning script that uses virt-install would come into play.
Any pointer for this ? I'd love to study it !
Bests
'k,got got it, sorry for the noise