HI everyone,
I wanted to share a quick update on Ansible Commander -
https://github.com/ansible/ansible-commander/. For those not
familiar, Ansible Commander's goal is to be an optional REST API and
GUI on top of Ansible, to make things easier and also provide a lot of
ability to drill down into Ansible data. The ansible project will
never require commander, but it will be easy to install if you want to
drive Ansible though a web interface.
When using commander, playbooks will still be kept in git, so it won't
lock you in to just using the GUI, or anything like that.
So, update...
I've been working on Ansible Commander a lot in the last week or so
and wanted to share a quick update about how it was being built so
that people will be able to help with development later, and
understand what we are doing. Pretty much everything so far has been
about the REST API.
If you are not a Python developer or someone with a deep-ceded
interest in REST APIs, this is probably not going to make a lot of
sense, and that's ok. You'll have a nice interface in the near
future and won't need to understand *ANY* of this.
So, if you want to read on at your own risk, interested parties should
probably start here with this skeleton of the API guide:
https://github.com/ansible/ansible-commander/blob/master/docs/api_guide.md
In the API guide, currently there are two major services that are
available -- Organizations and Users.
Organizations are the basic unit of multi-tenancy in Ansbile
Commander, and would be things like "Engineering" and "Finance".
Sharing across organizations is possible, but organization admins have
power to do things to users in organizations, and not users in /other/
organizations. Basically org admins are almost gods, so you don't
want to assign this to everyone -- they can mark users in their
organization as deleted, for instance.
Users are pretty obvious -- and they can belong to organizations as
regular people or as admins. They can login and change their
passwords. Stuff like that.
The next steps are to build out the API for inventory editing via web
interfaces, which should be more or less immediately usable once
complete -- even if you ignore the user/organization stuff.
Once that (inventory) is done, we'll be building out concepts of
Projects and Teams and Credentials, and the somewhat involved RBAC
system that will allow users on projects and teams to be able to do
certain things and not other things.
There are also already some basic hooks for being able to run a
playbook via the Celery API (a python task engine) but you will need
to setup inventory using Django Admin (a built in admin GUI in Django)
until there is an accompanying REST way to do it. I don't recommend
folks try this as it will evolve some, but it's there! There will
also be some guts added soon to allow different credentials to be
used, and the celery system will probably know how to work ssh-agent
for you, and things like that. Initially it might require unlocked
keys in the first release, but I suspect it won't.
Another thing is that the inventory source is decoupled from the rest
of Commander, so if you want to just use commander to edit inventory
and not launch jobs, that should be doable pretty quick. Given
dynamic inventory is also very useful, I imagine what will happen is
Ansible Commander will have a way to sync with ansible inventory
scripts, or there will be a flag on the inventory object that says
"external" where you can specify an inventory script (or directory)
instead of the built in API based inventory.
Note: this is of current interest to developers of Python
applications and those folks who develop against REST APIs. It is not
ready for us yet and you should not try to use it.
Python developers should be grok this a bit better by looking at the tests:
https://github.com/ansible/ansible-commander/tree/master/lib/main/tests
And the guts of the code are the files in the root of this directory:
https://github.com/ansible/ansible-commander/tree/master/lib/main
We are using Django-rest-framework to do a good chunk of the heavy lifting.
As you can see, a lof the work here has gone into the basic framework
and the need to have a lot of control over user access.
Further notes: Ansible Commander is not in a state where anyone
should be using it yet, and I reserve the right to completely rebuild
the database migrations at any time. You are also advised to test it
only on a stand alone machine, as right now, it will template over
your PostgreSQL access control configuration.
Ansible Commander is of course set up by an Ansible playbook. To read
more about this, see "SETUP.md" in the source checkout, and also take
a look at the Makefile for how to initiate various Django operations.