Gibt es ein HTTP-API-Paket zur Verwaltung von SSH-, FTP- und Apache-Servern?

Ich suche nach einem Open-Source-Paket, um eine HTTP-API einzurichten, um andere Servertypen in einem Linux-Server zu erstellen, zu ändern und herunterzufahren. Ich möchte administrieren können:

  • Ein SSH-Server (einschließlich SFTP)
  • Ein FTP-Server (einschließlich FTPS)
  • Ein Apache-Server

Ich würde zum Beispiel gerne sagen können:

  • Erstellen Sie eine Apache-Instanz, die 1.2.3.4:8080 mit docroot überwacht/var/www/mydocroot
  • Erstellen Sie einen SSH-Server, der 1.2.3.5:8081 überwacht
  • Listen Sie alle derzeit bekannten FTP-Server auf
  • Reißen Sie den FTP-Server ab, der auf 1.2.3.6:8082 lauscht

Ich habe eine HTTP-basierte API vorgeschlagen, da dies der vernünftigste Weg zu sein scheint, mit diesem System aus der Ferne zu kommunizieren. Ich könnte mir vorstellen, dass es auch RESTful wäre. Dies ist jedoch keine zwingende Voraussetzung – wenn es eine andere Möglichkeit gibt, auf standardbasierter Weise zu kommunizieren, könnte sie dennoch passen.

Falls es hilfreich ist, Antworten zu geben, ist mein Anwendungsfall eine Reihe von Integrationstests, die eine Anwendung testen, die Softwarebereitstellungen durchführt. Einzelne Tests müssen Webserver und verschiedene Dateitransportsysteme erstellen, um den Betrieb der Anwendung zu überprüfen. Derzeit teste ich nur in einer Docker-Umgebung und schalte die SSH/FTP-Server mit Shell-Befehlen ein und aus (das bedeutet, dass die aktuellen Tests nicht parallelisiert werden können, da sie alle eine einzelne Instanz jedes Dienstes verwenden).

Ich stelle mir vor, dass dieses Tool Server auf demselben Server verwaltet, auf dem es installiert ist, und dass es als Root ausgeführt werden muss. Es könnte jedoch stattdessen einen anderen Server verwalten.

Wenn es eine HTTP-API für etwas wie cPanel oder WebMin gibt, könnte das funktionieren. Ich habe diesen Dienst gefunden , aber er ist nicht Open Source und nur für einen gehosteten FTP-Dienst und nicht für ein Paket, das man selbst installieren kann.

Ich habe darüber nachgedacht, diesen Dienst selbst zu schreiben und ihn Open Source zu machen, aber es macht Sinn, zuerst zu sehen, ob er existiert. Meine Websuchen zeigen derzeit "Nein" an, aber es lohnt sich, sicherzugehen.

Antworten (1)

Es klingt sehr danach, als wollten Sie hier eigentlich eine Möglichkeit, die Handhabung des Konfigurationsmanagements und der Systembereitstellung zu vereinfachen. Meine persönliche Empfehlung wäre, dafür Ansible zu verwenden.

Ansible ist ein in Python geschriebenes Scale-out-Tool zur Konfigurationsverwaltung und Bereitstellungsautomatisierung. Es verwendet ein zentrales System für die Verwaltung, auf dem es installiert werden muss, erfordert aber auf keinem der verwalteten Systeme fast nichts. Ansible-Playbooks (ihr Äquivalent zu Skripten) verwenden eine wirklich einfache und leicht zu erlernende Syntax, die auf YAML und Jinja2 basiert, um anzugeben, welche Module (im Wesentlichen Befehle) auf welchen Systemen ausgeführt werden sollen.

Eine riesige Auswahl an verschiedenen Modulen wird mit Ansible bereitgestellt (siehe hier für die vollständige Liste), darunter solche für die Handhabung von Docker-Containern, die Verwaltung von Paketen, die auf einem Host installiert sind, die Handhabung, welche Dienste aktiviert sind oder nicht, die Bereitstellung von Software, die Änderung der Konfiguration und vieles mehr andere Dinge.

Etwas bemerkenswert ist die Tatsache, dass Ansible das unterstützt, was sie „dynamisches Inventar“ nennen, was so ziemlich bedeutet, dass Sie kurzlebige virtuelle Maschinen oder Container trivial hochfahren und verwenden können, ohne sich Gedanken über die Benennung machen zu müssen.

Sie können auch einzelne Module manuell aufrufen, was Konfigurationsänderungen im freien Format ermöglicht, wie Sie sie beschreiben.

Das Einzige, was angesichts Ihrer Einschränkungen wirklich fehlt, ist eine HTTP-API (sie wird über die Befehlszeile ausgeführt, und es ist weder auf dem lokalen System noch auf den verwalteten Systemen ein dauerhafter Dienst damit verbunden).

Danke für den Vorschlag. Das ist eine neue Art, über das Problem nachzudenken, und ich werde darüber nachdenken, wie man es anwendet. Ich habe ein bisschen Ansible-Erfahrung, obwohl ich es seit ein paar Jahren nicht mehr benutzt habe; Ich erinnere mich, dass ich es mochte. Ich zögere, wie eine Testbox mit parallelen Konfigurationsströmen fertig wird, die aus parallelen Tests kommen - meine Tests richten die Dinge derzeit so ein, wie sie sie brauchen, anstatt alles am Anfang einzurichten.
Teilweise ist dies auf die dynamische Natur der Tests zurückzuführen - zum Beispiel habe ich einen Code zur automatischen Transporterkennung, der entweder SFTP/FTPS/FTP auswählt, und daher muss ich die relevanten Server einrichten und dann einschalten /off, um sicherzustellen, dass der Erkennungscode die richtige Antwort erhält.