Show HN: Ansible Kernel – Run Ansible Tasks and Plays with Jupyter Notebook
github.comUntil there is a meaningful `git diff` for jupyter notebooks I can't see them being a step in the right direction for anything but transient experiments (and of course what Jypyter is great at; communication, documentation, low barriers etc.)
This is effectively a solved problem, but it does require some tooling. Pre-commit hooks can strip things like execution count and/or outputs from the notebook: https://gist.github.com/minrk/6176788
See also: nbdime to diff / merge notebooks https://github.com/jupyter/nbdime
Thanks will give this a try
caveat: I haven't tested this particular one, it was just the first thing I found in a quick search.
This post has more detail on a faster approach using jq: http://timstaley.co.uk/posts/making-git-and-jupyter-notebook...
Something I always wondered about: why are Jupyter Notebooks JSON-Files and not directories where each cell and result has a coresponding single file? Would also make managing attatchments and versionscontrol per notebook quite easy.
I have been making Jupyter notebook for managing our container environment. Some work is still only possible through Ansible, so I've been wondering how to integrate that. Well, I need not wonder no more!
This looks very promising:
* auto completion!
* integrated documentation!
* exporting Ansible YAML!
I didn't yet have change to play with this, so I just note the ways I see Jupyter can be good fit for Ansible. You can try each step and see it working before moving to next one. There doesn't seem to be support yet for richer results view nor Jupyter Widgets, but imagine looking at actual error messages and result views instead of JSON as text. Getting and setting parameters for playbooks could be done using external data sources instead of hand-crafting inventories and config files. You could use same approach as Ara [1] and trace execution of tasks.
I assume you can run Ansible kernel from JupyterLab instance, so you can do file management and use terminal right on the machine you're running Ansible commands. Also, I'd imagine connecting with Jupyter Console (formerly IPython) to same kernel state as notebook is running with is possible here as well. This provides Terminal goodness alongside browser's visuals.
[1] Ara: http://ara.readthedocs.io/en/latest/
Try it on Binder here:
https://mybinder.org/v2/gh/ansible/ansible-jupyter-kernel/ma...
Hi, and thank you. It works well. Example play books already contain the basics I'd need for my playbooks.
Could you perhaps elaborate how the kernel directs Ansible?
Also, is there any difference between local and remote Ansible runs?
Ansible Kernel calls ansible-playbook on a specially constructed playbook. Ansible Kernel constructs a playbook with a two tasks in it: 1. wait for the kernel and 2. include tasks from a file that does not exist yet. When you enter a #task cell we write that included file and then tell the wait task to proceed. The included file contains the #task cell contents, a wait task, and another include task. This continues until you stop the kernel, the playbook dies on an error, or you enter a #play cell. On a #play cell ansible kernel throws away the old playbook and make a new one with the new arguments. The exported playbook just contains the content on the page (without the wait/include tasks) and should work with ansible-playbook normally.
This does sound like Ansible does not make it easy to control it from pure Python. It looks an ingenious way to get around it.
I came across this Python wrapper around Ansible yesterday: http://suitable.readthedocs.io/en/latest/ Official docs declare themselves deprecated...
Anyway, I'll have to start testing this soon. Thank you so much for making it!
You're welcome. I hope that you find it useful.
Reminds me of the "Literate Devops with Emacs" article that has been discussed on HN before. Orgmode is well suited for this sort of thing:
I really like the idea of notebooks for ops tasks - its a great combination of code, documentation and step by step execution. I'm surprised it is not more popular.
I... don’t get the use case for this? What am I missing?
To me it looks like a REPL for Ansible. If it does let you build each task in a cell then you could develop the whole playbook interactively and incrementally. It could reduce the turn around time of having to run a long playbook and waiting till the latest step you wrote.
Doesn't ansible core have ansible console already? This seems very bizarre and solution in search of a problem. An alexa skill for ansible would be interesting, but I wouldn't use it, either.
edit: https://docs.ansible.com/ansible/latest/cli/ansible-console.... "REPL console for executing Ansible tasks."
What Jupyter (regardless of its kernel: Ansible, Python etc...) does is just adding a GUI interface on top of an existing REPL console you mentioned. For example, you already have a working iPython REPL console, you don't really need the heavy Jupyter system to run scientific Python codes.
If you prefer to use the REPL consoles directly for your own propose then Jupyter will add no value on it. However, Jupyter let you save results for each commands without running them again, and you can add Markdown documentations. This is useful when you want document your codes (with results) and share them with others.
Jupyter is merely a productivity tool like an IDE, not a framework. Jupyter may not be suitable for running production codes anyway.
That makes sense, but you could also just tag that step and run it with the tag if you are testing it.
Notebooks allows you to have snippets of code next to the historic results of their execution
It is not just litterate programming, but more like an IDE that does not require your code to keep working (CI/CD... ) : you can refactor at your own pace, iterate, introspect past results, etc.
You prototype like crazy, iterate much faster, and can tweak much more.
However, notebooks are not popular with many programmers. They stick to IDEs. Their loss.
This isn't data science. The output of a playbook is dependent on a huge amount of external dependencies and state, and the execution can conditionally depend on that. Maybe programmers should use notebooks more (and I have no opinion on that) but this isn't a situation where they would confer much benefit.
I have more of an opinion there: Maybe programming should be more like data science. Prototypes are thrown away, but must exist at one point. They should be encouraged - like versionning, it is part of a core of good practices that admit few exceptions
External dependencies, state etc will all be handled, once excution is ironed out
Sure, but that's not super different that series of commits along a feature branch. I think they accomplish the same goal. But am not dismissing notebooks as a way of doing that. I'm more familiar with ipython than jupyter, but particularly for more algorithmically complex programming tasks I think notebooks are a good tool.
I disagree with you only that this might be a good way of prototyping for something like ansible playbooks/modules, chef recipes, puppet manifests, etc. So much of the state is external (and intrinsic to what is being built) that I don't think it's a match of the rhythm of development there. But just my two cents, the best process is what works for you.
I agree with you, ansible may not be the best showcase of the notebook (much is external) but I think it still remains practical for prototyping: I consider the notebook as a giant notepad, that shows you at the same time your code and the results of the code - in multiple versions, as many as tabs. Better than tabs, or terminals
I suppose it's a nice interface, like Ansible Tower.