
One of the major networking features in Red Hat Ansible Engine 2.4 was the addition of aggregate resources to the networking modules. The Ansible networking team recently talked about this at the Ask an Expert webinar in November.
What are Aggregate Resources?
Simply put, aggregate resources are a better way to iterate (or loop) without the need to execute each task one by one. That is, you can now “aggregate” a collection as a single task instead of a collection of discrete loops.
Loop Method

Aggregate Method

Loop Method (with_items:) |
Aggregate Method (aggregate:) |
---|---|
|
|
503 steps |
4 steps |
Based on feedback from customers, partners and community members, this post provides more examples and more detail of this important new feature. The simplest way to showcase this is to compare the old way and the new way, and highlight the differences between each.
For this scenario we assume a network operator wants to configure 500 VLANs on a Arista EOS device. We can use the eos_vlan Ansible module to easily accomplish this. Refer to the following Ansible Playbook snippet.
Ansible 2.3 and older
The vlan_id parameter is where the actual 802.1q VLAN number is specified. The name parameter is a description that helps identify what this VLAN is for (i.e. printers, laptops, etc). Finally, the state parameter describes what the intended or expected state should be, which can be present, absent, active or suspend.
- eos_vlan:
vlan_id: "{{ item.vlan_id }}"
name: "{{ item.name | default('VLAN' + item.vlan_id|string) }}"
state: "{{ item.state | default('active') }}"
with_items:
- { vlan_id: 1, name: default }
- { vlan_id: 2, name: Vl2 }
- { vlan_id: 3, state: suspend }
View the full playbook: oldway.yml
Prior to integrating the aggregate resources feature, with_items was used as a loop and passed this criteria for multiple VLANs. Loops are very useful within Ansible, however in this particular example loops can have serious performance impacts. To highlight the execution time differences, we can use the Linux time command.
sean@rhel7 ~]$ time ansible-playbook oldway.yml
This particular playbook with just the one task took 18 minutes and 52 seconds to run over 500 VLANs. Ansible still provides parallelism across many different network switches, but this is far too slow for many large scale production environments!
Red Hat Ansible Engine 2.4 and newer
The new aggregate method allows us to pass the entire list of VLAN information without looping. The exact same list of VLANs shown in oldway.yml can be reused easily. Simply moving every line of the VLAN data from the task level to the module level (two spaces in) under the aggregate section (replacing with_items previously). Instead of looping each VLAN one at a time, we can send all the information at once. Keep in mind this example is only showing the first three VLANs, the full example contains 500 VLANs. This is what the updated task in the playbook looks like:
- eos_vlan:
state: active
aggregate:
- { vlan_id: 1, name: default }
- { vlan_id: 2, name: Vl2 }
- { vlan_id: 3, state: suspend }
The modified task with aggregate resources is also timed to compare:
sean@rhel7 ~]$ time ansible-playbook newway.yml
View the full playbook: newway.yml
This took 10 seconds to complete, which is significantly faster than the previous ~19 minute method. Another advantage is that you will also see all VLANs as either changed or OK at the task level (referring to Ansible’s ability to keep track of state) rather than VLAN by VLAN as with the loop method.
The Purge Ability
In conjunction with the aggregate feature, there is a purge parameter. The purge knob is defined as “Purge VLANs not defined in the aggregate parameter.” This means that VLANs not defined in the aggregate will be removed from the switch. So when the aggregate in this example is used all other VLANs will be deleted.
- eos_vlan:
state: active
purge: yes
aggregate:
- { vlan_id: 1, name: default }
- { vlan_id: 2, name: Vl2 }
- { vlan_id: 3, state: suspend }
View the full playbook: purge.yml
When it is not used, it only enforced that the VLANs exist in the state the aggregate sends them. What are potential use-cases for each?
purge: yes |
In this particular eos_vlan example turning the purge ability on allows us to enforce configuration policy. What that means is if another user or process adds a VLAN, we will revert the configuration to only contain the VLANs we provide in the aggregate parameter. |
---|---|
purge: no |
If the user running the playbook doesn’t care about the state of any VLANs not provided (i.e. he is working on VLAN10-50 and doesn’t care about VLAN200 which also happens to be configured). This allows playbooks to be written in a way where a temporary configuration could be supplied without affecting ongoing configuration. |
Going Further
Where else can I use aggregate? Other Arista examples include those such as the eos_user module and the eos_vrf module. Users and VRFs can be handled in a single aggregate rather than a collection of looped tasks. Instead of sending configuration user by user, or VRF by VRF with a loop it is now possible to use the aggregate. This will speed up configurations and give an alternative to using os_config modules with Jinja templating.
The aggregate feature is not limited to just the Arista EOS platform. Other networking platforms such as Cisco IOS, Cisco NX-OS and Juniper JunOS also have aggregate enabled in those respective modules. The Red Hat Ansible Engine Networking Add-on includes full support for use of aggregate in the supported platform modules. |
Ansible network modules that are capable of the aggregate feature are listed on their respective module documentation page. The aggregate keyword will appear under the parameter heading in the Options table. Click here for a complete list of modules.
All scenarios in this blog post are stored in a GitHub repo in our network automation community.
Follow the aggregate resources repository here.
To become a member of the growing community email us with your GitHub ID.
Have more questions? Join our next regularly scheduled Ask an Expert: Networking Webinar.
執筆者紹介
Sean is a Principal Technical Marketing Manager, Ansible, where he brings over 10 years of experience building and automating computer networks. Sean previously worked for both Cumulus Networks (acquired by Nvidia) and Cisco Systems where he helped customers deploy, manage and automate their network infrastructure. He resides in Chapel Hill, NC with his wife and children and tweets from @IPvSean.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する 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