Separating code from site‑specific information is a DevOps best practice.
So in your Playbooks, you define the configuration you want, but
there also needs to be a level of abstraction.
So if you're developing flexible code, you have to separate site‑specific
information from that code. You really don't want your Playbooks to be too
specific, so as a best practice, always maintain a level of abstraction in
Playbooks and keep out very specific information.
This will give you the level of abstraction needed for rolling
out multiple site deployments or complex environments with
just a single shareable Playbook.
If you develop dynamic code along with your static information,
you can use this on any site with just minor
modifications to the variables themselves.
Unlike other configuration management tools,
Ansible is agentless and requires nothing to be
installed on the managed systems.
Its architecture is serviceless and agentless, so it has a minimal footprint.
On the other hand,
some of the configuration management systems, such as Chef and Puppet, are
pull‑based by default. Where agents are installed, periodically check in with
a central service and pull‑down configurations.
So,
Ansible is agentless and does not require the installation of an agent on the
target host for Ansible to communicate to the target host.
However,
it does require connectivity from the target host to the target
devices that are listed in the inventory. And this needs to be a
trusted relationship between the two.
So Ansible uses SSH to Linux and macOS machines and WinRM
to connect to Windows machines. Then we have network
devices that could be managed over,
let's say, HTTPS or SSH. So if your hosts don't support SSH, Ansible can
use a variety of connection methods beyond SSH. Here you can select
different connection plugins. As already mentioned,
there is no need to install additional software targets hosts
provided that, say, on Linux machines we have Python and on Windows
machines we have PowerShell already installed.
So to manage service with Ansible, Linux servers need SSH and Python
installed, while Windows servers need WinRM. With Windows,
Ansible uses PowerShell instead of Python. One really important point about
Ansible is that when it's installed, it does not add a database, and there
will be no daemons to start or to keep running.
You only need to install it on one machine, and in some cases, this could
be okay in a laptop, and then it could be used to manage an entire fleet
of remote machines from that central point,
so there's no Ansible agent listening on a port.
Therefore, when you're using Ansible, there is no additional attack
surface for a bad actor to play with, and this really is a big win
for security, and it's following one of the main security principles
of reducing the attack surface. So as soon as you run an Ansible
Playbook command,
Ansible connects to the remote servers and carries out
what you want it to do. So by the defaults, Ansible is
pretty streamlined out of the box,
but you can enhance it by configuring the ansible.cfg file to be even more,
let's say, automated.