4:59 a.m.
Hello All.
I did not follow the recent Ansible developments, but at the time when I
researched it looked like a fancy SSH playbook library (a "better" fabric)
rather than "configuration management" system. This is not always bad
depending on what we want.
1. The strongest benefit of the Ansible is that it is easy to start using
it for anybody knowing Python, same way as fabric it is essentially SSH
client with imperative Python code that sequentially execute the actions.
They claim the concept of idempotence, but it is not desired state system
like Puppet, so instead of declaring a desired state and letting the
computer do the magic, you just list the steps to execute it imperatively
and if done right several runs won't break anything due to idempotence.
2. Also it is push approach and uses SSH so unless we want to execute it
from personal laptops as with fabric we will have to have a central server
with root SSH access to all our Ansible-managed servers where we can
execute it. There were orchestration tools such as Tower, but they were not
open source and looks like are not open source yet. Maybe there is
something other I am not aware about, please let me know.
Given those two items I really not sure we can use Puppet and Ansible
systems together as configuration management tools. The only ways to use
them together that I see are:
1. Use Ansible as a fabric replacement - to run things ad hoc (e.g. running
yum upgrade openssl) This does not work for mailman3 as it will be
"unpuppetized" in our terms.
2. Use Ansible only on part of the hosts. This works for mailman3, but for
us those host will leave as "unpuppetized" again plus we have to come up
with infra to support those hosts deployment due to luck of foreman
support. In addition we have to develop a way to transfer our users (puppet
classes + hiera now) to those servers that complicates deployment even more.
However it is not all or nothing problem, so the short term solution I
would propose and agree with:
It is ok to use Ansible for a limited set of hosts because it is easier for
people to learn and use it and hence - contribute deployment instructions
to us. But I would treat those hosts as "unpuppetized" on our side. The
motivation for that is that well, we do have a bunch of unpuppetized hosts
and obviously puppetizing everything is not a one day effort deal. Myabe it
should not block PHX migration. If somebody wants to use Ansible instead of
manually configuring hosts over SSH it is great. The host is still
unpuppetzied, but same way we have deployment instructions as a playbook in
SCM. And to get our users on the host we can use foreman + puppet infra
classes the same way we do for manually installed servers. So the
requirement for PHX migration than will be relaxed: deployment should be
reproducible + the host should support our infra tools such as foreman and
user classes.
Anton.
--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat