Konfigurationsmanagement über versionierte Pakete

Für die von uns verwalteten Hosts hat mein Chef eine Vision des Konfigurationsmanagements über versionierte Pakete (in unserem speziellen Fall von fpm erstellte Debian-Pakete). Dies ist zu machen:

• Host-Bereitstellung einfacher
• einfacher, lokale Änderungen zu verfolgen
• Vereinfachen Sie die Fehlerverfolgung, da wir in den meisten Fällen eine Softwareversion mit einem Fehler versehen können, unabhängig davon, ob es sich um einen Funktions- oder einen Konfigurationsfehler handelt.

Die andere Alternative ist das Konfigurationsmanagement über Ansible mit dem empfohlenen Layout wie im Handbuch, das wir derzeit verwenden. Wir installieren versionierte Softwarepakete (so ziemlich alle Webdienste), die für die eigene paketspezifische Konfiguration verantwortlich sind, und überlassen Ansible der systemweiten Konfiguration. Beim Aktualisieren der Hosts-Software müssen lediglich die Versionsnummern erhöht und die Skripte erneut ausgeführt werden. Wir verlassen uns stark auf die "var_prompts" -Funktionalität von Ansible, um sicherzustellen, dass vertrauliche Informationen von der Konfiguration getrennt bleiben.

Im Fall "Konfigurationsverwaltung über versionierte Pakete":

Für die Bereitstellung rufen wir einfach einen minimalen Server (Proxys usw.) auf und verwenden einen Paketmanager (in unserem Fall passend), um ein einzelnes Umbrella-Paket zu installieren, das alle abhängigen Pakete installiert. Wenn Sie Änderungen an einem der abhängigen Pakete vornehmen, wird einfach die oberste Paketversion angezeigt, wodurch das Aktualisieren vorhandener Bereitstellungen vereinfacht wird.

Für die Konfiguration hätte jedes Softwarepaket ein zugehöriges "Konfigurations" -Paket, um nur Änderungen an der Konfiguration zuzulassen. Jedes Paket verfügt über unabhängige Konfigurationsdateien, um Konflikte zwischen Paketen zu vermeiden, wenn lokale Änderungen auf dem Host überprüft werden. Anstatt Befehle auszuführen, die config generieren, würden wir sicherstellen, dass wir die generierten Dateien als Teil des Pakets haben, aber dennoch das Ausführen von Befehlen über die Skripte vor / nach der Installation zulassen. AFAIK, es gibt nicht viele Fälle, in denen wir Pakete haben, die auf derselben Konfigurationsdatei basieren. Wenn dies jedoch der Fall ist (was bei der Systemkonfiguration der Fall wäre), hätten wir ein anderes Paket mit einem Abhängigkeit von beiden. Ich kann sehen, dass dieser spezielle Fall außer Kontrolle gerät. Dies könnte jedoch gesteuert werden, indem immer unabhängige Konfigurationsdateien sichergestellt werden. Am Ende hätte jeder Host sein eigenes Konfigurationspaket. Offensichtlich würden alle diese Dateien der Quellcodeverwaltung unterliegen, und wir könnten unser eigenes einfaches Template-System hochfahren, damit wir auch die Flexibilität von Ansible-Rollen haben können.

Ich bin gespannt, warum ich keine Informationen / Analysen zu dieser Art von Workflow zum Konfigurieren und Bereitstellen von Hosts finden kann. Vermisse ich etwas, das bei einem solchen Ansatz im Vergleich zu vorhandenen Konfigurationsmanagement-Tools grundlegend fehlerhaft ist?

Paketmanager sind aus mehreren Gründen für die Konfigurationsverwaltung nicht wirklich effektiv:

1. Die meisten Pakete enthalten bei der Installation eine Konfiguration, sodass Sie benutzerdefinierte Pakete erstellen müssen, bei denen sie entfernt wurden.
2. Paketmanager arbeiten unter der Annahme, dass das Paket eine Grundkonfiguration installiert, die innerhalb des Systems geändert werden kann. Wenn ein Paket neu installiert / aktualisiert wird, wird der Benutzer normalerweise gefragt, was mit der geänderten Datei zu tun ist (was für einen Konfigurationsmanager kein ideales Verhalten ist).
3. Der Paketmanager testet das System normalerweise nicht anhand des Paketinhalts. Einige haben diese Option, sie ist jedoch nicht effizient, da sie nicht häufig verwendet wird.
4. Ein Paketlebenszyklus ist komplexer und länger als die meisten automatisierten Konfigurationstools. Daher ist die Wartung eines solchen Setups aufwändiger.
5. Paketmanager kümmern sich nicht um die Reihenfolge der Installation. Wenn Sie also einen Fall von Paketabhängigkeit a->b->chaben und Paket c bereits installiert haben und Paket a installieren, wird Paket c nicht neu installiert und die Pakete a und / oder b überschreiben möglicherweise die Konfiguration von c.

Wenn Sie darauf bestehen, Paketmanager zum Verwalten von Konfigurationen zu verwenden, empfehlen wir Ihnen, die Option zu prüfen, ein eigenständiges Konfigurationsverwaltungssystem wie Puppet oder Chef im eigenständigen Modus mit einem Paket für die Konfiguration zu verwenden. Auf diese Weise haben Sie alles Ihrer Konfiguration in einem einzigen versionierten Paket, jedoch auf eine Weise, bei der der Paketmanager die Konfigurationen auf der Festplatte nicht verwalten muss, was zu Problemen führen kann, wie ich aufgelistet habe, und wahrscheinlich zu weiteren.

Zur Verdeutlichung sollte es möglich sein, das zu tun, was Sie geplant haben, nur der Paketmanager ist nicht das ideale Werkzeug dafür.