A high-performance, C-based reimplementation of Ansible. It mirrors Ansible's declarative, YAML-based playbook interface, but re-engineers the backend for raw speed and minimal dependencies.
- High Performance: Pure C implementation for maximum speed and efficiency
- Minimal Dependencies: Lightweight design with few external dependencies
- Compatible Interface: Uses the same YAML playbook format as Ansible
- Inventory Management: Supports INI-style inventory files with groups
- Flexible Execution: Run commands locally or remotely via SSH
- Module System: Extensible module architecture (currently supports command/shell)
- State Tracking: Maintains execution state and results in JSON format
- Cross-Platform: Works on Linux, macOS, and other Unix-like systems
- Fast Startup: No Python interpreter overhead, instant execution
make./bin/ancible-playbook -i inventory.ini playbook.yml--help: Display help message-v, --verbose: Increase verbosity-c, --color: Enable Colored output-i INVENTORY: Specify inventory file (default: ./inventory.ini)
The examples/playbooks/ directory contains several sample playbooks:
1_simple.yml- Basic system commands (hostname, whoami, date)2_multiple_tasks.yml- Multiple system information tasks3_file_operations.yml- File creation and manipulation4_cpu_intense.yml- CPU-intensive operations5_network_operations.yml- Network connectivity checks6_system_admin.yml- System administration tasks7_security_checks.yml- Security auditing operations8_database_operations.yml- Database-related tasks9_conditions.yml- When Conditions in Playbooks10_blocks.yml- Blocks in Playbooks
Run an example with:
./bin/ancible-playbook -i examples/inventory_local.ini examples/playbooks/1_simple.ymlancible/
├── bin/ # Compiled executables
├── cli/ # Command-line interface code
│ ├── args.c # - Command-line argument parsing
│ └── main.c # - Main entry point
├── core/ # Core engine components
│ ├── context.c # - Execution context management
│ ├── condition.c # - Condition engine
│ ├── executor.c # - Task execution engine
│ ├── inventory.c # - Host inventory parser
│ ├── parser.c # - YAML playbook parser
│ └── state.c # - Runtime state management
├── examples/ # Example playbooks and inventory files
│ ├── inventory.ini # - Sample multi-host inventory
│ ├── inventory_local.ini # - Local-only inventory
│ └── playbooks/ # - Example playbook collection
├── include/ # Header files
│ ├── ancible.h # - Main header
│ ├── cli/ # - CLI headers
│ ├── core/ # - Core engine headers
│ ├── modules/ # - Module system headers
│ └── transport/ # - Transport layer headers
├── modules/ # Module implementations
│ ├── command.c # - Command module
│ └── module.c # - Module system core
├── runtime/state/ # Runtime state storage Per-Host
├── tests/unit/ # Unit tests
└── transport/ # Transport implementations
├── runner.c # - Command execution abstraction
└── ssh.c # - SSH transport
make testAncible has been benchmarked against Ansible for various playbooks. The results show significant performance improvements across different types of tasks.
| Playbook | Ancible | Ansible | Diff (1) | % Change (2) | Speedup (3) |
|---|---|---|---|---|---|
| #01 - Simple Echo | 0.113s | 1.454s | 1.341s | 1186.73% | 12.87x |
| #02 - Multiple Tasks | 0.115s | 1.897s | 1.782s | 1549.57% | 16.50x |
| #03 - File Operations | 0.141s | 2.087s | 1.946s | 1380.14% | 14.80x |
| #04 - CPU Intense Tasks | 0.363s | 2.126s | 1.763s | 0485.96% | 05.86x |
| #05 - Network Operations | 2.094s | 4.186s | 2.092s | 0099.86% | 02.00x |
| #06 - System Admin Stuff | 0.062s | 1.813s | 1.751s | 2825.81% | 29.24x |
| #07 - Security Checks | 0.019s | 1.157s | 1.138s | 5989.47% | 60.89x |
| #08 - Database Operations | 0.064s | 1.509s | 1.445s | 2257.81% | 23.55x |
| #09 - Conditions | 0.076s | 2.708s | 2.632s | 3463.16% | 35.63x |
| #10 - Blocks | 0.051s | 2.264s | 2.213s | 4349.02% | 44.39x |
(1) ansible - ancible
(2) ((ansible - ancible) / ancible) * 100
(3) ansible / ancible
The following features are planned for future implementation, some are necessary to fully replace Ansible's functionality, while others are more like an incentive to gain more features and improve the user experience.
Those features are necessary to run playbooks, they are not strictly necessary to run the command module, but they are needed to fully replace Ansible's functionality.
- Execute Basic Playbooks
- Conditional Execution: Support for
whenconditionals - Blocks: Support for task grouping and error handling with blocks
- Variable Registration: Support for
registerto capture command output
While using the command module, you can run any command on the remote host, you can copy, use git or create files. Thereby we only need them to fully replace Ansible's functionality, but they are not strictly necessary to run playbooks, since the command module can execute any command. However, you can see this as an incentive to implement these modules.
- Command module
- File module (create, delete, chmod)
- Copy module
- Template module
- Service module
- Package module
- Git module
Here are some features that are not strictly necessary to run playbooks, but they would improve the user experience and make Ancible more powerful. Like the Additional Modules, those are more like an incentive to implement them, to fully replace Ansible's functionality.
- Colored Output
- Better error handling and reporting
- Support for roles and includes
- Variable templating with Jinja2-like syntax
MIT