4 ms·

There's one use case for Ansible that it handles amazingly well that seems to get ignored pretty frequently. It's an extremely useful tool for setting up the sa

There's one use case for Ansible that it handles amazingly well that seems to get ignored pretty frequently. It's an extremely useful tool for setting up the same machine it's running on using the local connection type. I've been involved in projects where we setup a small-ish bash wrapper script that can be curled onto a linux machine or mac that installs Ansible, asks a few user specific up front questions, and then installs the rest of a relatively complex development environment. It took a while to build, but makes setting things up so much easier to deal with.

_red 6y ago
This past year I committed myself to learn ansible and fully script my full desktop setup as a series of ansible roles. This included not just package management but also things like gsettings gnome configuration, gnome extension installs, python virtualenv environments, email / chat client setup, etc. As it happens, a few months after I did that my hard drive failed on my Centos desktop. I was able to install a new drive, install base OS, and run my ansible role(s). Within ~45 mins I was back to my exact desktop with all local files restored from backup. Since then I've kept up any small changes by keeping my roles in sync with my setup. The result is a self-documenting setup. I started this as an excuse to learn ansible but I now realize I've relieved lots of mental burdens from myself. Its so nice to go thru life now confident that I can go from complete bare-metal to "my setup" over lunch.
mdaniel 6y ago
And its companion, ansible-pull which can periodically run to sync changes _onto_ a machine which doesn't otherwise allow inbound connections: https://docs.ansible.com/ansible/2.10/user_guide/playbooks_intro.html#ansible-pull https://docs.ansible.com/ansible/2.10/user_guide/playbooks_i... In your scenario, once those changes are captured, they can be written into `/etc/ansible/facts.d` and they'll show up in future playbook runs: https://docs.ansible.com/ansible/2.10/user_guide/playbooks_vars_facts.html#facts-d-or-local-facts https://docs.ansible.com/ansible/2.10/user_guide/playbooks_v...
- dreamcompiler 6y ago
  At the moment I'm using git hooks on bare repos on a deployment machine to automatically build detached work trees whenever someone pushes the deployment branch. This works well because no secret keys need exist on the deployment machine. Even if encrypted, I don't want secret keys sitting on a deployment machine. Does ansible pull require a secret ssh key on the pulling machine? Seems like it would but I don't remember.
  - mdaniel 6y ago
    It would only require credentials if you need them to fetch from a private git repo (or other protected playbook source); otherwise it (traditionally) uses the "local" connection, meaning it will launch python subprocesses rather than trying to ssh into localhost

_red 6y ago

This past year I committed myself to learn ansible and fully script my full desktop setup as a series of ansible roles. This included not just package management but also things like gsettings gnome configuration, gnome extension installs, python virtualenv environments, email / chat client setup, etc. As it happens, a few months after I did that my hard drive failed on my Centos desktop. I was able to install a new drive, install base OS, and run my ansible role(s). Within ~45 mins I was back to my exact desktop with all local files restored from backup. Since then I've kept up any small changes by keeping my roles in sync with my setup. The result is a self-documenting setup. I started this as an excuse to learn ansible but I now realize I've relieved lots of mental burdens from myself. Its so nice to go thru life now confident that I can go from complete bare-metal to "my setup" over lunch.

mdaniel 6y ago

And its companion, ansible-pull which can periodically run to sync changes _onto_ a machine which doesn't otherwise allow inbound connections: https://docs.ansible.com/ansible/2.10/user_guide/playbooks_intro.html#ansible-pull https://docs.ansible.com/ansible/2.10/user_guide/playbooks_i... In your scenario, once those changes are captured, they can be written into `/etc/ansible/facts.d` and they'll show up in future playbook runs: https://docs.ansible.com/ansible/2.10/user_guide/playbooks_vars_facts.html#facts-d-or-local-facts https://docs.ansible.com/ansible/2.10/user_guide/playbooks_v...

dreamcompiler 6y ago
At the moment I'm using git hooks on bare repos on a deployment machine to automatically build detached work trees whenever someone pushes the deployment branch. This works well because no secret keys need exist on the deployment machine. Even if encrypted, I don't want secret keys sitting on a deployment machine. Does ansible pull require a secret ssh key on the pulling machine? Seems like it would but I don't remember.
- mdaniel 6y ago
  It would only require credentials if you need them to fetch from a private git repo (or other protected playbook source); otherwise it (traditionally) uses the "local" connection, meaning it will launch python subprocesses rather than trying to ssh into localhost