From Fedora Project Wiki
Fedora Infrastructure and Ansible
Fedora infrastructure has been trying out ansible [1] as systems mgmt software for some of our systems. This may help answer some questions we've been getting regarding it.
Why is Fedora Infrastructure trying out ansible
- small code base
- easier to get into the code. The modules are also fairly simple to develop/enhance
- push-based maintenance
- pull based has its advantages but it means your managed systems have to know A LOT about where and how to contact the central mgmt system. It also means you have to scale your central mgmt system out heavily as you add hosts. If you plan to spin up lots of transient hosts this becomes cumbersome. Push-based mgmt lets you do provisioning/maintenance/configuration runs when you want to on the schedule you choose, not whenever a remote system has decided it will
- no additional language requirements
- most everything we do is in python - we don't need a special language stack just to manage our systems.
- no managed system software required
- the systems being managed don't need to have anything on them other than ssh and a shell. Ansible can push its modules over and run them. In reality it needs python-simplejson but we have that installed by default and python is a prereq for our systems running at all. :)
- b/c nothing is required on the managed system we are not version-locked based on compat between client and server. which means managing a fedora rawhide host with a rhel6 server is quite trivial.
- ssh-based
- we use ssh for all our other access. Opening another port for systems mgmt just means a new attack vector to protect.
- additionally, all the cloud instances we have worked with always offer ssh as their default access - so using that for provisioning fits with what we think of as the future of our systems
- simple configuration "language"
- playbooks are simple yaml construct with relatively little programming-style syntax. Simple to follow and b/c of naming requirements for tasks often self-documenting.
- does not require manual intervention to setup
- no step necessary to sign a key like with func/puppet/etc
- being push based means never giving out any auth data to a system that has just spun up.
- no chore to 'deauthorize' a system and revoke a key - just remove the system from the inventory file.
- api and cli interface for both direct mgmt and configuration application
- everything you can do from the cli or from a playbook you can also do from an api
- simple model for mgmt and code
- ssh connects
- ansible pushes over script + args to run job
- ansible runs job
How is Fedora Infrastructure trying out ansible
- Right now we are using it for our koji builder deployment and maintenance. We were restructuring them and b/c of its relative isolation from the rest of our systems we decided they would be a good place for a trial of another config mgmt/provisioning system
- we have developed some api-using tools and a number of playbooks for creating/provisioning builders and other release-engineering related systems.
How does Fedora Infrastructure plan to proceed
- depending on the results of our trial of ansible we may choose to expand to other infrastructure beyond the koji builders.
- b/c of ansible's model we do not have anything installed on the builders themselves. Which means if we decide we do not want to continue using it we can simply stop using it w/o changing the builders at all.