Credential-Zugriff
Reads SSH keys, vault files, inventories, cloud credentials, and environment variables.
brew
Prüfe Installationswege, Executables, Metadaten und Sicherheitshinweise für ansible in AI-Agent-Workflows.
Agent-Sicherheit
ansible automates hosts and infrastructure from local inventories and credentials.
Reads SSH keys, vault files, inventories, cloud credentials, and environment variables.
Can configure remote hosts, cloud resources, and application deployments.
Can roll out generated config, binaries, and service changes.
Gate playbook runs, vault decrypts, and inventory changes.
Allow syntax checks and dry runs; require approval for playbook execution against real targets.
Installation
brew install ansiblelocal Homebrew formula metadata
sudo port install ansibleMacPorts ports tree · sysutils/ansible/Portfile · Quelle: api.github.com
sudo apk add ansibleAlpine Linux edge package indexes · ansible · Quelle: dl-cdn.alpinelinux.org
sudo apt install ansibleDebian stable package indexes · ansible · Quelle: deb.debian.org
sudo dnf install ansibleFedora Rawhide package metadata · ansible · Quelle: dl.fedoraproject.org
nix profile install nixpkgs#ansiblenixpkgs package indexes · ansible · Quelle: raw.githubusercontent.com
sudo pacman -S ansibleArch Linux sync databases · ansible · Quelle: geo.mirror.pkgbuild.com
sudo zypper install ansibleopenSUSE Tumbleweed package metadata · ansible · Quelle: download.opensuse.org
Überblick
Automate deployment, configuration, and upgrading
Verlauf
Ansible is a radically simple IT automation system for configuration management, application deployment, cloud provisioning, ad hoc task execution, network automation, and orchestration. Its package history matters because the name `ansible` shifted from the original all-in-one project to the modern community package layered on `ansible-core` and collections.
Ansible was created as an agentless automation tool whose playbooks describe desired work in YAML and whose default transport avoids installing an agent on managed hosts. The current upstream source for the runtime is the ansible/ansible repository, while official documentation distinguishes the Ansible community package from `ansible-core`.
Red Hat announced an agreement to acquire Ansible in October 2015, framing it as an IT automation and DevOps platform that would complement Red Hat's management portfolio. That acquisition moved Ansible from a startup-backed open source project into Red Hat's broader automation product line while keeping the community project active.
The 2.10 era changed the packaging model. Official release documentation says the Ansible community package uses new versioning starting with 2.10 and then 3.0.0, while `ansible-core` continued the classic 2.x line. The community package includes the language, runtime, and selected collections; `ansible-core` contains the language, runtime, and builtin plugins.
Ansible's adoption came from a practical systems-administration sweet spot: SSH-first orchestration, readable YAML playbooks, no managed-node daemon, and a large module ecosystem. It spread through Linux distributions, Python packaging, Homebrew, MacPorts, Nix, and enterprise Red Hat channels because it fits both laptop-driven automation and CI/CD infrastructure workflows.
The split into `ansible-core` plus collections made package selection more nuanced. Many community users still install the `ansible` package because it includes broad batteries: official docs say it offers the functionality that existed in Ansible 2.9, with more than 85 collections containing thousands of modules and plugins. Developers and minimalists often choose `ansible-core` and install only the collections they need.
As Ansible matured, adoption expanded beyond server configuration into network automation, cloud provisioning, security, Windows administration, and platform orchestration. Red Hat Ansible Automation Platform, Automation Hub, AWX, Galaxy, and a large collection ecosystem grew around the core CLI model.
The Homebrew `ansible` formula installs the user-facing suite: `ansible`, `ansible-playbook`, `ansible-galaxy`, `ansible-doc`, `ansible-inventory`, `ansible-vault`, `ansible-config`, `ansible-console`, `ansible-pull`, and testing/community helpers. The everyday loop is inventory plus playbooks, with ad hoc commands for quick tasks and Galaxy for roles and collections.
Configuration is resolved from `$ANSIBLE_CONFIG`, `ansible.cfg` in the current directory, `~/.ansible.cfg`, then `/etc/ansible/ansible.cfg`; the first file found wins. Galaxy credentials can be provided through command-line API-key options or through the configured token path, whose default resolves from `ANSIBLE_HOME` to `~/.ansible/galaxy_token`.
Package users care about the distinction between `ansible --version` reporting an ansible-core version and the installed Python package named `ansible` representing the broader community package. That distinction explains why formula pinning, package-manager naming, and docs version matching can feel surprisingly non-obvious.
Ansible is one of the canonical infrastructure CLIs in package-manager culture: big enough to have versioned formulae, distro backports, Python package splits, and plugin/collection dependency concerns, but still shaped like command-line tools that can be scripted and vendored.
The package is also a case study in ecosystem packaging after modularization. `ansible-core` is the runtime center; `ansible` is the batteries-included community package; collections carry much of the domain-specific surface area; and tools like ansible-lint, ansible-creator, and ansible-language-server orbit the authoring workflow.
For users, the important packaging question is not just latest version but content set: does the install include the collections your playbooks expect, what Python versions are supported on control and target nodes, and which ansible-core line is underneath?
Sicherheitslage
Für ansible wurde kein passendes lokales Secret-Handling-Manifest gefunden. Nucleus-Paketmetadaten bleiben hier veröffentlicht, damit künftige Abdeckung eine stabile Paket-URL hat.
Prüfe vor unbeaufsichtigter Agent-Nutzung, ob das Tool Klartext-Credentials liest, Remote-Zustand schreibt, Artefakte veröffentlicht oder Plugins ausführt.
local files
These source-backed paths show where this package keeps local settings or durable credentials. Automic Vault can use them as review targets for secret scanning, migration, and command approval.
Config paths the tool may read or write during local use.
$ANSIBLE_CONFIG./ansible.cfg~/.ansible.cfg/etc/ansible/ansible.cfgCredential-bearing paths to review before unattended agent runs.
~/.ansible/galaxy_tokenExecutables
| Befehl | Art | Sichtbarkeit | Hinweis |
|---|---|---|---|
ansible | cli | globales Executable | |
ansible-community | cli | globales Executable | |
ansible-config | cli | globales Executable | |
ansible-console | cli | globales Executable | |
ansible-doc | cli | globales Executable | |
ansible-galaxy | cli | globales Executable | |
ansible-inventory | cli | globales Executable | |
ansible-playbook | cli | globales Executable | |
ansible-pull | cli | globales Executable | |
ansible-test | cli | globales Executable | |
ansible-vault | cli | globales Executable |
Aktualität
Diese Signale trennen das Alter der Seitengenerierung, Aktivität des Paketmanagers und Upstream-Release-Vergleich. Versionsrückstand wird nur gemeldet, wenn eine Evidenz-URL und vergleichbare Versionen vorhanden sind.
Installationsmetadaten
| Paketschlüssel | brew:ansible |
|---|---|
| Version | 14.1.0 |
| Paketmanager | Homebrew |
| Paketmanager-Seite | https://formulae.brew.sh/formula/ansible |
| Homepage | https://www.ansible.com/ |
| Repository | https://github.com/ansible/ansible |
| Upstream-Dokumentation | https://docs.ansible.com/projects/ansible/latest/index.html |
| Lizenz | GPL-3.0-or-later |
| Quellarchiv | https://files.pythonhosted.org/packages/fe/97/3aeeb9d199fd0f931452adebcf5336c01c739b1de2d4bada0744ff5d18e1/ansible-14.1.0.tar.gz |
| Zuletzt aktualisiert | 2026-07-02T19:52:46Z |
| Pulse | updated |
| Abhängigkeiten | certifi, cryptography, libsodium, libssh, libyaml, python@3.14, tree |
| Build-Abhängigkeiten | pkgconf, rust |
| Von macOS bereitgestellte Bibliotheken | krb5, libxml2, libxslt, openldap |
| Bottle | verfügbar (auf arm64_linux, arm64_sequoia, arm64_sonoma, arm64_tahoe, sonoma, x86_64_linux) |
| Homebrew post-install | nicht definiert |
| Dienst | keiner deklariert |
Registry-Fakten
| Source Database | Homebrew formula API |
|---|---|
| Tap | homebrew/core |
| Full Name | ansible |
| Aliases |
|
| Version Scheme | 0 |
| Revision | 0 |
| Head Version | HEAD |
| Bottle Stable Root URL | https://ghcr.io/v2/homebrew/core |
| Deprecated | no |
| Disabled | no |
| Keg Only | no |
| URL Keys |
|
Source-Datenbank-Treffer
Treffer stammen aus externen Paketmanager-Indizes und bleiben von lokalen Automic-Vault-Paketlinks getrennt.
ansible 12.0.0+dfsg-0+deb13u1
Configuration management, deployment, and task execution system
https://github.com/ansible-community/ansible-build-data/
sudo apt install ansibleansible
nix profile install nixpkgs#ansibleansible 9.2.0+dfsg-0ubuntu5
Configuration management, deployment, and task execution system
sudo apt install ansibleansible 14.0.0-r0
core components for Ansible
sudo apk add ansibleansible-pyc 14.0.0-r0
Precompiled Python bytecode for ansible
sudo apk add ansible-pycansible 13.7.0-2.fc45
Curated set of Ansible collections included in addition to ansible-core
sudo dnf install ansibleansible 14.0.0-1
Official assortment of Ansible collections
https://pypi.org/project/ansible/
sudo pacman -S ansibleansible 14.0.0-1.1
Radically simple IT automation
sudo zypper install ansibleansible
sudo port install ansibleansible-test 2.21.0-2.1
Tool for testing ansible plugin and module code
sudo zypper install ansible-testQuellspur
Diese Seite wird von av-web aus dem privaten Paket-SQLite-Artefakt bereitgestellt, das scripts/generate-pkg-sqlite.py erstellt.
View the package source record on GitHub.