uuid: - value: 1f3f5a8f-412f-4da1-8e7a-4303962079d1 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:55+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'Using Ansible for server configuration' created: - value: '2022-09-04T00:00:00+00:00' changed: - value: '2025-05-11T09:00:55+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2022/09/04/using-ansible-for-server-configuration langcode: en body: - value: |

In yesterday's email, I described how to set up a blank server with Ansible.

Now that we've done that, it needs to be configured.

Once the server’s IP address or hostname has been added to a hosts.ini file, you can run ad-hoc commands against it - such as ansible all -i hosts.ini -m ping to run Ansible's ping module on all of the hosts in your inventory and check that you can connect to them.

Another useful one that you can use is the shell module, that runs ad-hoc run commands on each host. If you need to check the uptime of each of your servers, run ansible all -i hosts.ini -m shell -a uptime. You can replace the last argument with any other shell command that you need to run, like df or free.

Running commands in this way is great for getting started, for routine maintenance, or an emergency free disk space check, but for more complex tasks like configuration management, using playbooks is the better option. They are YAML files that contain lists of tasks that Ansible will run through and execute in order.

If you have a group of related tasks, such as for installing a piece of software, then you can combine them into roles. In fact, Ansible Galaxy has thousands of pre-built collections and roles that you can download, include in your playbooks, configure, and run.

Very quickly, you can get a full stack installed and configured - ready to serve your application.


Want to learn more about how I use Ansible? Register for my upcoming free email course.

format: full_html processed: |

In yesterday's email, I described how to set up a blank server with Ansible.

Now that we've done that, it needs to be configured.

Once the server’s IP address or hostname has been added to a hosts.ini file, you can run ad-hoc commands against it - such as ansible all -i hosts.ini -m ping to run Ansible's ping module on all of the hosts in your inventory and check that you can connect to them.

Another useful one that you can use is the shell module, that runs ad-hoc run commands on each host. If you need to check the uptime of each of your servers, run ansible all -i hosts.ini -m shell -a uptime. You can replace the last argument with any other shell command that you need to run, like df or free.

Running commands in this way is great for getting started, for routine maintenance, or an emergency free disk space check, but for more complex tasks like configuration management, using playbooks is the better option. They are YAML files that contain lists of tasks that Ansible will run through and execute in order.

If you have a group of related tasks, such as for installing a piece of software, then you can combine them into roles. In fact, Ansible Galaxy has thousands of pre-built collections and roles that you can download, include in your playbooks, configure, and run.

Very quickly, you can get a full stack installed and configured - ready to serve your application.


Want to learn more about how I use Ansible? Register for my upcoming free email course.

summary: null field_daily_email_cta: { }