Ansible 2.0

Ansible hat sich als noch junges Projekt – immerhin begann die Entwicklung erst Anfang 2012 – als Administrations- und Automationswerkzeug auf breiter Front neben den anderen bekannten Vertretern dieser Zunft, allen voran Puppet und Chef, durchgesetzt. Einer der wichtigsten Vorteile, die Ansible für sich verbuchen kann, ist die Unabhängigkeit von Agenten, die bei den meisten Mitstreitern auf den zu wartenden Maschinen installiert werden müssen. Ansible benötigt lediglich eine Möglichkeit, entfernte Systeme erreichen zu können – bei Linux-Servern typischerweise via SSH –, und ein dort installiertes Python ab Version 2.4.

Dies ermöglicht es, beinahe jeden Server unmittelbar nach Installation des Betriebssystems zu konfigurieren und mit Software zu bespielen, vorausgesetzt natürlich, die entsprechenden Zugangsdaten liegen vor und die Erreichbarkeit per Netzwerk ist gegeben.

Ansible 2.0 bügelt vergangene Sünden aus

Wie bei jedem Softwareprojekt bringen – insbesondere schneller – Erfolg und weite Verbreitung aber beinahe zwangsläufig Probleme mit sich. Durch das Bestreben, schnell auf Nutzerwünsche einzugehen und nicht antizipierte Einsatzgebiete zu unterstützen, begehen Entwickler oft technische Sünden, um Limitierungen einer ursprünglichen Architektur zu umgehen und neue Funktionen anzuflanschen.

Bei Ansible ist dies nicht anders: Laut Projektblog waren innerhalb von drei Jahren mehr als 1000 Autoren an verschiedenen Komponenten beteiligt. Als Open-Source-Projekt lebt Ansible davon, dass Nutzer ihrerseits Erweiterungen entwickeln und einbringen sowie Fehler melden, beheben und Feature-Wünsche beisteuern. Durch dieses schnelle und an vielen Stellen gleichzeitig stattfindende Wachstum stieg der Anteil an Hacks und Quick Fixes im Code, die wiederum die eigentliche Produktentwicklung behinderten und zu Kompatibilitätsproblemen führten.

Daher sollte für

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.