4 ms·
I never get guides like this. This is a configuration management tool, and they're telling people to manually bootstrap their systems to use it. Great, you've h
by peterwwillis 7y ago
I never get guides like this. This is a configuration management tool, and they're telling people to manually bootstrap their systems to use it. Great, you've helped someone do the thing the tool is intended not to do.
First of all, no, don't create an ansible user. Never use generic shared accounts. I mean, you can, but you can also just SSH into root. (You know what the difference between using the -B option and SSHing into root are? There is none.)
Second, either use sssd to enable an SSO system, or bootstrap all your hosts with an SSH CA so you don't have to constantly run jobs to add SSH public keys to all your nodes, which when you eventually start using ephemeral nodes, won't work at all unless it's using a shared account; see above paragraph.
Third, if you're going to use a plaintext inventory, generate it on the fly, and definitely don't write it to a single global root-owned file, because you may want to update it some time, and you may be running ansible more than once on that host at that time.
Fourth, they didn't really go over the anguish of trying to manage system-installed python packages and running Ansible. You need to install and run Ansible in a virtualenv with pinned versions, don't use a system-packaged version.
Five, don't use any complicated logic in your tasks or playbooks, or later you'll be kicking yourself because of how much of a huge pain in the ass it is to debug playbooks and tasks and inventories and filters and the non-standard fake YAML config format and a million other things. Keep it really really simple.
Six, run ansible-pull on a cron job with random jitter every 10-20 minutes, because your system and code will deviate over time, and you won't know it until you try to run Ansible again after 3 months and everything breaks. You'll also want a system to alert you when Ansible fails so you can find out what broke.
Seven, try to make any Ansible you use obsolete by baking Docker images, VM images, system packages, and other versioned immutable infrastructure artifacts. If you start out with that in mind, you may not ever have to touch Ansible once, and may even eventually achieve immutable infrastructure, and what a wonderful world that is. (I'm serious... everyone should be working to remove configuration management from their stack wherever it's feasible)
- xorcist 7y ago> You'll also want a system to alert you when Ansible fails Indeed. This is what makes a configuration management tool work in practice.
- thisguyuknow 7y agoGood advice. Far better than the Red Hat branded info presented here. Personally, I prefer to push rather than pull, and I also use mitogen as the ssh strategy. It's incredible how much one line in requirements.in and another in ansible.cfg can speed things up.
- senorsmile 7y agoHalf of this is ok advice, the other half highly opinionated (and wrong in my opinion).