6 ms·

Ansible 101 by Jeff Geerling – new series on YouTube

92 points by geerlingguy 7y ago

geerlingguy 7y ago
In addition to announcing this new streaming series (hope it's helpful if you don't know Ansible yet!), I wanted to also remind anyone who hasn't taken me up on the offer yet: Ansible for DevOps[1] and Ansible for Kubernetes[2] are available free on LeanPub the rest of this month! [1] https://www.ansiblefordevops.com https://www.ansiblefordevops.com [2] https://www.ansibleforkubernetes.com https://www.ansibleforkubernetes.com
- boomskats 7y ago
  Hey Jeff, this is awesome. Ansible for DevOps was my bible for a long time - I wasn’t aware the k8s book was even in the works! I’ll definitely be taking you up on that.
- YPCrumble 7y ago
  Thank you for your incredible contributions to Ansible. I help maintain an Ansible script for Django applications (https://github.com/jcalazan/ansible-django-stack https://github.com/jcalazan/ansible-django-stack) and your blog and repos have been invaluable. Your blog posts on testing using Molecule, your htpasswd role, and so many others have come in handy. I'll add these links and your YouTube channel to our README now :).
- hattori 7y ago
  Thank you this is very kind! Great stuff.
BiteCode_dev 7y ago
I'm hopping someday people will provide a friendly Python API on top of ansible so that I don't have to write its YAML DSL anymore. The "it must be idempotent" argument lead to putting conditional into a a language that was never meant to be, doing the whole "store" danse that could be done with simple function calls and whole lot of conventions instead of a proof tested import system. It's calling python code behind the scene anyway, and nothing reads the playbook apart from ansible itself. Ansible is a great tool, but I strongly believe the experience would be 100% better without learning, crafting and debugging those twisted .yml.
- geerlingguy 7y ago
  _Technically_ there's a Python API on it: https://docs.ansible.com/ansible/latest/dev_guide/developing_api.html https://docs.ansible.com/ansible/latest/dev_guide/developing... There's also a utility to help with the running of Ansible playbooks via Python (https://github.com/ansible/ansible-runner https://github.com/ansible/ansible-runner). However, I've said this many times before—if your playbooks start mixing Python into tasks, you're either doing something wrong (it could be architected better), or it's time to write a custom Ansible module so the Python goes into a `.py` file and not into YAML. 99% of my playbooks are strict YAML with maybe a few Jinja filters, which make everything very readable. But I've also seen a ton of YAML that makes me want to barf.
  - BiteCode_dev 7y ago
    Keyword being "friendly". See, if hello world is: - name: Hello Ansible hosts: ansibleclient01.local tasks: - name: Copy '/tmp/testfile.txt' into 'hello world'. copy: content: hello worldn dest: /tmp/testfile.txt Then it would become: from icandream import playbook pb = playbook("Hello Ansible", hosts=["ansibleclient01.local"]) with db.define_task(Copy '/tmp/testfile.txt' into 'hello world') as task: task.copy(content="hello worldn", dest="/tmp/testfile.txt) Instant benefits: - Python interpretter is very good at telling you error messages. - You get an exception system, stack trace and a debugger for free - The entire python tooling ecosystem, including full monthy IDE support, linters and formaters, is at your disposal - Any more complex example is going to be much cleaner than the yaml version, exponentially. And no need to live in the "yaml/python module" dichotomy to keep PB clean. - No need to reinvent the wheel. Python has elegant import, namespaces, ways to pass data around, conditionals, etc., - You can import Python libs. Event if it's just for declarative stuff like pendulum, appdirs.. The only cons are: - idempotence needs to be enforced culturally. It's already the case for people writing the module behind the scene, and a good API + some warning tricks would be enough IMO. - can't read the files outside of Python. But nobody does it anyway, and we can always let the Python files output the yaml representation if needed. Now I don't hold my breath because it's a lot of work and the ansible community usually don't like the idea at all, and I'm not willing to do it. Fair is fair.

92 points by geerlingguy 7y ago

In addition to announcing this new streaming series (hope it's helpful if you don't know Ansible yet!), I wanted to also remind anyone who hasn't taken me up on the offer yet: Ansible for DevOps[1] and Ansible for Kubernetes[2] are available free on LeanPub the rest of this month! [1] https://www.ansiblefordevops.com https://www.ansiblefordevops.com [2] https://www.ansibleforkubernetes.com https://www.ansibleforkubernetes.com

boomskats 7y ago
Hey Jeff, this is awesome. Ansible for DevOps was my bible for a long time - I wasn’t aware the k8s book was even in the works! I’ll definitely be taking you up on that.
YPCrumble 7y ago
Thank you for your incredible contributions to Ansible. I help maintain an Ansible script for Django applications (https://github.com/jcalazan/ansible-django-stack https://github.com/jcalazan/ansible-django-stack) and your blog and repos have been invaluable. Your blog posts on testing using Molecule, your htpasswd role, and so many others have come in handy. I'll add these links and your YouTube channel to our README now :).
hattori 7y ago
Thank you this is very kind! Great stuff.

BiteCode_dev 7y ago

I'm hopping someday people will provide a friendly Python API on top of ansible so that I don't have to write its YAML DSL anymore. The "it must be idempotent" argument lead to putting conditional into a a language that was never meant to be, doing the whole "store" danse that could be done with simple function calls and whole lot of conventions instead of a proof tested import system. It's calling python code behind the scene anyway, and nothing reads the playbook apart from ansible itself. Ansible is a great tool, but I strongly believe the experience would be 100% better without learning, crafting and debugging those twisted .yml.

geerlingguy 7y ago
_Technically_ there's a Python API on it: https://docs.ansible.com/ansible/latest/dev_guide/developing_api.html https://docs.ansible.com/ansible/latest/dev_guide/developing... There's also a utility to help with the running of Ansible playbooks via Python (https://github.com/ansible/ansible-runner https://github.com/ansible/ansible-runner). However, I've said this many times before—if your playbooks start mixing Python into tasks, you're either doing something wrong (it could be architected better), or it's time to write a custom Ansible module so the Python goes into a `.py` file and not into YAML. 99% of my playbooks are strict YAML with maybe a few Jinja filters, which make everything very readable. But I've also seen a ton of YAML that makes me want to barf.
- BiteCode_dev 7y ago
  Keyword being "friendly". See, if hello world is: - name: Hello Ansible hosts: ansibleclient01.local tasks: - name: Copy '/tmp/testfile.txt' into 'hello world'. copy: content: hello worldn dest: /tmp/testfile.txt Then it would become: from icandream import playbook pb = playbook("Hello Ansible", hosts=["ansibleclient01.local"]) with db.define_task(Copy '/tmp/testfile.txt' into 'hello world') as task: task.copy(content="hello worldn", dest="/tmp/testfile.txt) Instant benefits: - Python interpretter is very good at telling you error messages. - You get an exception system, stack trace and a debugger for free - The entire python tooling ecosystem, including full monthy IDE support, linters and formaters, is at your disposal - Any more complex example is going to be much cleaner than the yaml version, exponentially. And no need to live in the "yaml/python module" dichotomy to keep PB clean. - No need to reinvent the wheel. Python has elegant import, namespaces, ways to pass data around, conditionals, etc., - You can import Python libs. Event if it's just for declarative stuff like pendulum, appdirs.. The only cons are: - idempotence needs to be enforced culturally. It's already the case for people writing the module behind the scene, and a good API + some warning tricks would be enough IMO. - can't read the files outside of Python. But nobody does it anyway, and we can always let the Python files output the yaml representation if needed. Now I don't hold my breath because it's a lot of work and the ansible community usually don't like the idea at all, and I'm not willing to do it. Fair is fair.