I am very pleased to finally introduce Operon , the high-performance replacement for Ansible Engine. Operon is designed for large installations and is distributed by subscription. It launches existing playbooks, modules, plug-ins and third-party tools without modification, using an advanced engine, significantly increases the actual number of nodes addressed in one run, potentially saving hours with every call.
Operon is installed both separately and together with Ansible Engine: you can gradually transfer your projects to it or use it at startup if you wish.
Below is a graph of the run for 416 common.yml tasks from DebOps 0.7.2 deployed via SSH:
Compared to clean Ansible Operon, it reduces run time per node by about 60%. But with mass launches, the advantage is much greater. Take a look at how the operating time is growing (hardware: 24 GB, 8-core Xeon E5530; deployed to Google Cloud virtual machines via SSH in 18ms):
For each run, 416 tasks were performed on each node, including loop items. In a run of 1024 nodes, 540 496 tasks were completed in 54 minutes; average throughput - 151 tasks / second. Horizontal scaling is obvious: almost 4x, from 256 to 1024 nodes.
The 256-node Ansible run had to be canceled: for a long period of time it did not produce results, it had to be restarted many times, reducing the number of processes from 40 to 10 so that Ansible would not run out of RAM resources. It might have worked out with 13 processes, but we had to refuse further attempts: we already spent 2 days of machine time.
For the final run, before canceling, Ansible completed 89% of the tasks in 6 hours and 13 minutes:
Operon deployed to all nodes during each parallel run. Performing 1024 processes on 8 cores, it gives a barely noticeable increase in load, and on 24 cores the number of processes grows as much as 6144. If we ran the same number of tasks on that number of nodes, only with 16 cores, we think that we would run complete not in 54 minutes, but in 27.
Memory consumption is very predictable and largely detached from processes. With 256 processes, Operon consumes four times less than Ansible consumes with 10; at the same time, the processor consumes at least 15 times less processor time.
Here the curve is on the decline: Ansible runs on 64 nodes with 40 processes, while runs on 256 nodes run from 10. Ansible runs on 256 nodes took 1.6 Gb / process; so, regardless of the available RAM resources, a severe restriction was created on achievable parallelism.
Operon is a new step in the development approach that debuted with Mitogen for Ansible . It inherits the massive improvements in low-level performance needed by thousands of users:
Not only software
Productivity is a side effect of the cultural shift towards greater user orientation, compatibility and internalization of costs. We have something to show, but for you to fully experience the taste of the new product, I am pleased to announce: there will be a guarantee of playbook syntax with direct compatibility - in addition to restoring some outdated Ansible Engine constructs.
include :
- include: "i-will-always-work.yml"
"with" loops
- debug: msg={{item}} with_items: ["i", "will", "always", "work"]
"squash actions"
- apt: name: "{{item}}" with_items: ["i", "will", "always", "work"]
hyphens in group names
$ cat hosts [i-will-always-work.us.mycorp.com] host1
hash merge
# I will always work [defaults] hash_behaviour = merge
Operon shipments with Ansible 2.9 compatible syntax will receive ongoing support , and syntax disabling in Ansible Engine will not be affected by Operon in the future. Such changes harm work installations without improving their capabilities, and they are the main source of work to fix errors during updates.
Over time, this guarantee extends to the semantics of the engine and beyond.
How to join?
Initially, Operon will be distributed with support from Network Genomics , and this is an experience and commitment to a service that you will not get anywhere else. If your team is stuck in the deployment trap or tired of fixing updates for years, consider asking for an assessment , and without delay, write me an e - mail - for any questions and incomprehensible points.
The best software is in the public domain, so a public release will take place when we are able to provide a certain level of free support. Subscribe to our newsletter to be informed in time about future releases.
Will Operon Improve Windows Performance?
Yes. If you have performance issues during your Windows deployments, just stay tuned for now.
Will Operon Improve Network Device Performance?
Yes. Operon presents an architectural redesign that extends well beyond the transport layer and is equally applicable to all types of connections.
Is Operon an Ansible offshoot?
Not. Operon is an incremental rewrite of the engine, a small component of about 60k lines of code, of which about a quarter have been replaced. Each Ansible installation includes about 715k lines, of which the vast majority, like Operon, are independently supported by the large Ansible community.
Will Operon Ansible Engine Improve?
Yes. Operon is already promoting an improvement within Ansible Engine, and since it is a refinement, there is an incentive to make a contribution, to tweak the code where necessary.
Is Operon Freeware?
Yes. Operon is released under the same GPL license as Ansible, and you can freely use the code under this license.
Does Operon break compatibility?
Not. Operon does not violate compatibility with the standard set of modules, plug-in interfaces, or the surrounding Ansible ecosystem, and does not plan to violate it. Compatibility - first of all: you should not lag behind future improvements, as well as forget about backward compatibility, such as improved stability of the syntax of the playbook.
Do I need Operon if I have plans for just one node?
Operon will ensure the continued competitiveness of the skills in which you have invested so much. It offers increased flexibility that previously simply did not exist: freedom to choose an engine. With Operon, you win, even if you don’t use it directly.