community-topics
Ansible
| community-topics | Ansible | |
|---|---|---|
| 60 | 415 | |
| 34 | 68,888 | |
| - | 0.7% | |
| 5.0 | 9.7 | |
| about 2 years ago | 6 days ago | |
| Shell | Python | |
| GNU General Public License v3.0 only | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
community-topics
-
The Bullhorn #115 (Ansible Newsletter)
There is a community vote on a new policy for community.general on which ansible-core versions will be supported in new major releases. Basically support for ansible-core versions will be dropped if they were EOL at least a few weeks before the major release. For the upcoming community.general 8.0.0, that means that it will drop support for ansible-core 2.11 and 2.12 and require at least ansible-core 2.13. Details can be found in the associated issue.
-
The Bullhorn #114 (Ansible Newsletter)
As mentioned in The Bullhorn #113, we've opened a community / steering committee vote on declaring ngine_io.exoscale an effectively unmaintained collection and remove it from the Ansible 10 community package. Since then, there has been a new release. As a result, the vote ended with the decision to keep the collection in the community package.
-
The Bullhorn #108 (Ansible Newsletter)
2023-07-12: Community WG meeting, 18:00 UTC (propose topics here)
-
The Bullhorn #107 (Ansible Newsletter)
Hi everyone. We're working on making Ansible community documentation a separate project to ansible/ansible. The purpose is to benefit the Ansible community by decoupling community doc initiatives from core release cycles. This change also removes the Ansible Core team as the gate for other doc related efforts that will meet community needs, such as putting source content for docs.ansible.com under the direct control of the Steering Committee. Overall this change is a first step towards providing greater access and ownership of docs.ansible.com to the Ansible community.
-
The Bullhorn #106 (Ansible Newsletter)
Looking for your feedback on making community docs a separate github project to ansible/ansible, starting with moving /docs from ansible/ansible to ansible/ansible-documentation. See this issue for details.
-
The Bullhorn #105 (Ansible Newsletter)
It looks like the netapp.elementsw collection is effectively unmaintained. According to the current community guidelines for collections, we consider removing it in a future version of the Ansible community package. Please see Unmaintained collection: netapp.elementsw for more information or to announce that you're interested in taking over the maintenance of (a fork of) netapp.elementsw.
-
The Bullhorn #104 (Ansible Newsletter)
The netapp.aws collection is considered unmaintained and will be removed from Ansible 10 if no one starts maintaining it again before Ansible 10. See the removal process for details on how this works.
-
The Bullhorn #103 (Ansible Newsletter)
As mentioned in The Bullhorn #98, we consider netapp.aws an effectively unmaintained collection. Therefore, we've opened a community / steering committee vote on removing it from the Ansible 10 community package.
-
The Bullhorn #101 (Ansible Newsletter)
2023-05-10: Community WG meeting, 18:00 UTC (propose topics here)
-
The Bullhorn #100 (Ansible Newsletter)
Work continues combining several pytest plugins for ansible.
Ansible
-
Deploying Mercure alongside Caddy on a shared VPS
Mercure is a real-time push protocol built on server-sent events (SSE). It ships as a standalone binary that embeds its own Caddy server. If you already run Caddy as your web server, you now have two Caddy processes fighting over ports. This post covers how to deploy both on the same VPS using Ansible, with solutions for every gotcha that came up.
-
Ansible Has a Free API: Automate Everything Without Agents
GitHub
-
CLI agents make self-hosting on a home server easier and fun
So, what exactly is a CLI agent? In simple terms, it’s a command-line interface tool that automates tasks for you. It’s like having a personal assistant who doesn't complain when you ask it to perform mundane tasks repeatedly. For example, I’ve been using Ansible lately for automating the deployment of applications on my server.
- Top 12 Puppet Alternatives for Automation
-
SDK-Driven Development: A Litmus Test for Good Software Design
Also for systems administration and DevOps, I first used Ansible to streamline the management of our servers. Writing playbooks is OK, but going beyond that to convert them to roles is a good practice from collaboration perspective. This SDK approach worked quite well for me and my team. Now, I am developing NixOS modules for various services we deploy. In both cases, the goal is to compose well-defined and documented modules (SDK) into a complete system in a few lines of code (application).
-
Getting Started with DevOps
Ansible,
-
Again self-hosting! on k3s
You can use GitHub repos as RSS links and received notification about new releases. If you're using miniflux just past https://github.com/ansible/ansible/releases.atom
-
That's a Lot of YAML
That said, I can't readily imagine why you couldn't do exactly what you said because the AnsibleModule[1] contract is JSON over stdin/stdout (and one can write Ansible modules in any programming language[2] - they just default to Python)
1: https://github.com/ansible/ansible/blob/v2.18.4/lib/ansible/...
2: https://docs.ansible.com/ansible-core/2.18/dev_guide/develop... and https://github.com/ansible/ansible/blob/v2.18.4/test/integra...
- The Pain That Is GitHub Actions
-
Top 17 DevOps AI Tools [2025]
Ansible provides streamlined automation for IT orchestration and configuration management through its declarative language. Teams can efficiently define and execute automation tasks, ensuring consistent environment management. This tool provides simplicity and effectiveness making it a valuable tool for managing complex IT infrastructures at scale.
What are some alternatives?
transible - Convert existing cloud configuration to ansible playbooks
pyinfra - 🔧 pyinfra turns Python code into shell commands and runs them on your servers. Execute ad-hoc commands and write declarative operations. Target SSH servers, local machine and Docker containers. Fast and scales from one server to thousands.
awx - AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
SaltStack - Software to automate the management and configuration of infrastructure and applications at scale.
ansible-navigator - A text-based user interface (TUI) for Ansible.
Puppet - Server automation framework and application