Ansible is an agentless IT automation tool that unravels the mystery of how work gets done. Many sysadmins run Ansible ad hoc commands or playbooks daily to handle their automated tasks. They rely on Ansible's default command-line interface (CLI) output to visualize and understand what happens after their command or playbook finishes running.
Since Ansible's CLI standard output is clean and lean, one option for tracking runtimes, getting metrics, understanding resource consumption, and gathering other information is to modify the output to include more details through using callback plugins. This article explores how to use two different Ansible callback plugins to profile system activity and maximum memory usage of tasks and full execution using cgroups.
There is a lot of ground to cover with this topic. This article sets the stage by defining the environment and necessary components. A second article will cover playbook execution tests using the callback plugins.
Setting up the test environment
This scenario needs only a managed node and a target machine. It uses the managed node (ServerA) to set the configuration files and playbooks. It runs the tests in the target machine (ServerB), where the httpd service is installed and configured to act as a test web server. Both ServerA and ServerB have the following configuration:
- CPU: 1 vCPU
- Memory: 1GB
- Disk: 10GB
- OS: RHEL 8.4
- Ansible version: 2.9.26
[ Register for our free Ansible essentials online course. ]
All commands are executed on the managed node. Start by creating an inventory file with just the target machine's hostname:
[servera]$ cat << EOF > hosts
[demo]
serverb
EOF
Next, create a simple ansible.cfg
file with some access configuration information:
[servera]$ cat << EOF > ansible.cfg
[defaults]
inventory=hosts
remote_user=alexon
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False
EOF
As I mentioned earlier, the target machine is a basic web server. Create two simple playbooks. The first, deploy-webserver.yml
, installs, configures, and starts the httpd service on the target with a custom index.html
page. The second, remove-webserver.yml
, removes all of that configuration.
Here is the first playbook:
[servera]$ cat << EOF > deploy-webserver.yml
---
- name: Demo playbook to test callback plugin - Deployment
hosts: serverb
tasks:
- name: Install httpd package
dnf:
name: httpd
state: latest
- name: Start and enable httpd service
service:
name: httpd
enabled: true
state: started
- name: Create a custom index.html file
copy:
dest: /var/www/html/index.html
content: |
Enable SysAdmin Demo:
Ansible Profiling with Callback Plugin
Custom Web Page
EOF
And here is the second playbook:
[servera]$ cat << EOF > remove-webserver.yml
---
- name: Demo playbook to test callback plugin - Remove
hosts: serverb
tasks:
- name: Stop and disable httpd service
service:
name: httpd
enabled: false
state: stopped
- name: Remove httpd package
dnf:
name: httpd
state: absent
EOF
You should have the following four files in your demo
directory:
[servera]$ ls -1
ansible.cfg
deploy-webserver.yml
hosts
remove-webserver.yml
Testing the environment
First, test communication with the target machine by pinging it through an Ansible ad-hoc command:
[servera]$ ansible -i hosts -m ping serverb
serverb | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/libexec/platform-python"
},
"changed": false,
"ping": "pong"
}
Run the playbooks to verify that they work as expected. First, run the deploy-webserver.yml
playbook:
[servera]$ ansible-playbook deploy-webserver.yml
PLAY [Demo playbook to test callback plugin - Deployment] *******************************************************************************************
TASK [Gathering Facts] ******************************************************************************************************************************
ok: [serverb]
TASK [Install httpd package] ************************************************************************************************************************
changed: [serverb]
TASK [Start and enable httpd service] ***************************************************************************************************************
changed: [serverb]
TASK [Create a custom index.html file] **************************************************************************************************************
ok: [serverb]
PLAY RECAP ******************************************************************************************************************************************
serverb : ok=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Success! What about the remove-webserver.yml
playbook?
[servera]$ ansible-playbook remove-webserver.yml
PLAY [Demo playbook to test callback plugin - Remove] ***********************************************************************************************
TASK [Gathering Facts] ******************************************************************************************************************************
ok: [serverb]
TASK [Stop and disable httpd service] ***************************************************************************************************************
changed: [serverb]
TASK [Remove httpd package] ************************************************************************************************************************
changed: [serverb]
PLAY RECAP ******************************************************************************************************************************************
serverb : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
It works like a charm. But how do you know answers to things like: How long does it take each task to run? How many resources (memory and CPU) were consumed? What was the playbooks' total runtime? And how much of the total resources were consumed from the target machine? These look like questions for the second article!
Wrapping up
In this article, I defined the issue of tracking runtimes, getting metrics, and consuming resources in Ansible's CLI output when running playbooks. I covered basic adjustments for both Ansible configuration files and playbooks. I also established the infrastructure you'll use in the next article in the series, which goes into the tests for profiling resources and executing tasks with Ansible callback plugins.
執筆者紹介
Alexon has been working as a Senior Technical Account Manager at Red Hat since 2018, working in the Customer Success organization focusing on Infrastructure and Management, Integration and Automation, Cloud Computing, and Storage Solutions. He is a part of the TAM Practices LATAM team based in São Paulo, Brazil, where his job is partnering with, advocating, trust-advising, and supporting customers in their success goals while making use of the complete portfolio. He also contributes to produce and enhance documentation, knowledge-base articles, blog posts, presentations, webinars, and workshops. He is a member of numerous communities in addition to the Sudoers, like Red Hat Academy and Red Hat Accelerators. When he’s not at work, he enjoys spending quality time with his family (wife, daughter, and cat) and participating in several volunteer jobs.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit