Linux-Systemkonfigurationsverwaltung: Versionierung und Bereitstellung

Question

Ich suche nach der besten Möglichkeit (für meine Zwecke und Situation), Systemkonfigurationsdateien zu versionieren und die Bereitstellung (Eigentümerschaft und Modus) zwischen nur zwei Maschinen (Live und Backup, beide sollten als „Produktion“ betrachtet werden) zu verwalten. Ich möchte dieses System verwenden können, um relevante und angegebene Konfigurationen auf der Backup-Maschine (einer EC2-Instanz) automatisch (aber selektiv) zu duplizieren und zu verwalten.

Derzeit sind diese Maschinen hauptsächlich Web- und SMTP-Server (wir speichern keine Benutzerpostfächer), aber unser Projekt wächst und wer weiß, welche zukünftigen Anforderungen es geben wird. Es besteht beispielsweise die Möglichkeit, dass wir irgendwann in der Zukunft Radio und webbasierten Chat implementieren.

Ich bevorzuge die herkömmliche Verwaltung des Servers (d. h. ich gehe rein und nehme bei Bedarf Änderungen am Live-Server vor) und speichere diese Änderungen dann (sobald sie abgeschlossen sind) im Verwaltungssystem. (Okay, wenn ich ehrlich bin, sollte ich sagenorganisch: Ich möchte nicht die Flexibilität verlieren, Dinge so zu tun, wie es die Bedürfnisse und Situationen erfordern.) Im Gegensatz zur Bereitstellung einer Konfiguration, die anderswo optimiert und getestet wurde, finde ich diesen Ansatz vorhersehbarer und er birgt weniger Überraschungen (abgesehen von der Möglichkeit, die Konfiguration auf einem Live-System zu vermasseln, versteht sich!)

Mir ist klar, dass das philosophisch gesehen ein kompletter Fehler ist und ich es wahrscheinlich andersherum machen würde, wenn ich die Ressourcen hätte (Testinfrastruktur und, noch wichtiger, Arbeitskräfte). So wie es ist, muss ich mit dem auskommen, was ich habe. Struktur gefällt mir zwar ganz gut, aber übermäßige Infrastruktur entwickelt ein Eigenleben und irgendwann geht ihr Wert verloren.

Ich habe meine Hausaufgaben gemacht und ein paar Optionen geprüft, aber keine davon scheint wirklich das zu tun, was ich möchte, also bin ich derzeit versucht, meine eigene Lösung zu entwickeln. Der Zweck dieser Frage besteht darin, zu sehen, woran ich nicht gedacht habe, und eine Plausibilitätsprüfung durchzuführen, bevor ich auf dem Holzweg bin.

Optionen

1. Deklarative Metakonfigurationssysteme wie Puppet,unter anderemsind wahrscheinlich eine gute Wahl, wenn viele Server beteiligt sind, die kaum oder gar nicht unterschieden werden, und insbesondere, wenn im Voraus klar ist, wie die Konfiguration aussehen soll. Ich denke nicht, dass es klug wäre, ein solches Tool ohne Staging-Infrastruktur einzusetzen.

   Es ist auch ein bisschen schwerfällig und übermäßig kompliziert. Ich bin der einzige Administrator, ich mache das in meiner Freizeit, und sollte mir etwas zustoßen, muss das, was ich hinterlasse, einigermaßen vernünftig für den glücklichen Kerl/die glückliche Frau sein, der/die nach mir einsteigt.

2. etckeeper könnte das tun, aber soweit ich das sehe, eignet es sich nicht wirklich dazu, etwas anderes als /etc zu verwalten. Das heißt, es wäre nicht geeignet, um benutzerdefinierte Skripte zu speichern, die traditionell in /usr/local/bin liegen. Außerdem verwaltet etckeeper vermutlichallevon /etc, wo ich glaube, dass ich lieber nur bestimmte Dinge versionieren möchte (z. B. Postfix, Apache, Fail2ban, SSH und möglicherweise Munin).

3. Ein einfaches Git- oder SVN-Repository reicht sicherlich nicht aus, denn Git verfolgt zwar die Berechtigungen, nicht aber die Eigentumsverhältnisse, und SVN verfolgt beides nicht.

   svn behält .svnin jedem verfolgten Verzeichnis ein Unterverzeichnis, während es .gitnur im Stammverzeichnis der Arbeitskopie existiert. In beiden Fällen gibt es Vor- und Nachteile. Das Vorhandensein eines .svnVerzeichnisses an einem bestimmten Ort kann an manchen Stellen in Ordnung sein (z. B. /etc/apache2/sites-enabled), aber an anderer Stelle hirnlose Skripte/Tools verärgern. (Ich bin sicher, ich habe vor einiger Zeit etwas gelesen: War es so, dass cron mit einem .svnVerzeichnis in /etc/cron.d einverstanden war, depmod jedoch nicht mit /lib/modules?)

   Andererseits .gitbetrachtet git mit einem in /allesein Kandidat für die Nachverfolgung, sogar (vermutlich) anderer Git-Repos!

Maßgeschneiderte Lösung

Ich schlage Folgendes vor: ein Subversion-Repo, das auf der primären Maschine gespeichert ist (z. B. /usr/local/sc-repo), und ein Verwaltungsskript, das inPysvndas Folgendes implementiert:

• add (aber standardmäßig nicht rekursiv), wodurch der Modus und die Eigentümerschaft der Datei als benutzerdefinierte Eigenschaften gespeichert werden. Außerdem mag ich $Id$Tags in meinen Konfigurationsdateien, sodass dies sicherstellt, dass svn:keywordsalles richtig eingestellt ist.

• begehen

• Update, das den Besitz und Modus anwendet, nachdem die Datei geschrieben wurde

• zurückkehren, dito

• Berechtigungen wie Diff, aber für Eigentum und Modus, mit Fix-Flag zur Korrektur, falls erforderlich.

Die Backup-Maschine greift per SSH auf das Repository zu und führt jede Nacht einen Aktualisierungsvorgang durch. (Sie wird auch andere Dinge tun, wie Site-SQL und Anwendungsdateisysteme aus dem Backup-Repository (S3) der Hauptmaschine wiederherstellen, und ich werde wahrscheinlich eine Hacker-Software schreiben müssen, die nach neuen Paketen sucht, die auf der Hauptmaschine hinzugefügt wurden, und sie auf der Backup-Maschine hinzufügt – aber das alles liegt außerhalb des Rahmens dieser Frage.)

Warum Subversion?

• Ich weiß, mag und binvielmit SVN kenne ich mich besser aus als mit Git. Ja, ich bin wahrscheinlich ein Dinosaurier.

• Pysvn ist einfach und ich habe es schon einmal verwendet.

• svn unterstützt versionierte benutzerdefinierte Eigenschaften, was bei git nicht der Fall zu sein scheint

• Dies ist keine verteilte Entwicklung: verteilte Repos verkomplizieren die Dinge ohne Nutzen. Die Verfügbarkeit von Remote-Repos ist irrelevant, da Commits vom Remote-Computer selten sind.

Ich wäre für Ihr Feedback dankbar. Ich habe mir so viel wie möglich Gedanken darüber gemacht, aber bestimmt habe ich etwas übersehen.

Answer 1

Erfinden Sie das Rad nicht neu. Die Werkzeuge sind vorhanden, um das zu tun, was Sie brauchen. Vielleicht möchten Sie sich ansehenbcfg2, zumal Sie sich anscheinend besonders auf Konfigurationsdateien konzentrieren. Denken Sie auch an Dienste. Wo muss das zentrale Repository im Verhältnis zum Produktionsserver sein?

Eine Zwischenlösung könnte eine vorsichtige Modifikation der Ausgabe desEntwurfWerkzeug. Ich verwende Blueprint, um bestehende Systeme zurückzuentwickeln. Die Ausgabe eines Blueprint-Laufs kann ein Shell-Skript, ein Puppet-Modul oder ein Chef-Kochbuch erstellen... Sobald Sie eine verifizierte Konfiguration auf dem Produktionsserver haben, können Sie mit diesem Werkzeug den Systemzustand erfassen und dann das Ergebnis markieren und versionieren. Lesendurch die Beispieleund melden Sie sich zurück, wenn es für Ihren Anwendungsfall geeignet scheint.

Answer 2

Deklarative Metakonfigurationssysteme wie Puppet sind wahrscheinlich eine gute Wahl, wenn viele Server beteiligt sind, die kaum oder gar nicht voneinander unterschieden werden, und insbesondere, wenn im Voraus klar ist, wie die Konfiguration aussehen soll. Ich denke nicht, dass es klug wäre, ein solches Tool ohne Staging-Infrastruktur einzusetzen.

Ich verwende Puppet (aber ja, es gibt auch Chef, Ansible, Salt und dergleichen), sogar für Einzelrechner-Setups. Ich habe noch nie eine Situation erlebt, in der irgendjemandem im Voraus klar war, wie die Rechnerkonfiguration aussehen sollte (vielleicht war vielen im Nachhinein nicht klar, wie die Konfiguration aussehen sollte, aber das ist ein ganz anderes Problem).

Was die "Staging-Infrastruktur" betrifft, so ist dasLandstreicherUndVirtualBox(oder eine andere unterstützende Virtualisierungstechnologie) - führen Sie es auf Ihrer Entwicklungsmaschine aus, ohne dass Sie dafür Geld ausgeben müssen. Ich mache keine Puppet-Manifest-Entwicklung ohne es. Auch automatisierte Tests mitTravis CI

Es ist auch ein bisschen schwerfällig und übermäßig kompliziert. Ich bin der einzige Administrator, ich mache das in meiner Freizeit, und sollte mir etwas zustoßen, muss das, was ich hinterlasse, einigermaßen vernünftig für den glücklichen Kerl/die glückliche Frau sein, der/die nach mir einsteigt.

Es erscheint inkonsequent, dies zu sagen und dann zu beschreiben, wie Sie eine selbst entwickelte Lösung planen, anstatt bestehende Lösungen mit viel Dokumentation, Beispielen, vorhandenen „Bibliotheken“ und aktiver Entwicklung einzusetzen.