staging.inyokaproject.org

Hallo zusammen,

ich bin derzeit mit der Entwicklung eines Deploy-Systems unter Linux (Ubuntu) beschäftigt.

Die Software installiere ich über simple Bash-Scripte, die auf dem Client als root ausgeführt werden.

Mir stellen sich mit der Zeit jetzt einige Fragen ...

Welche Art der Kommunikation ist zu empfehlen?

1. über wget (cronjob) scripte laden und mit post logs, etc zum server schicken

2. per ssh (mit einem zertifikat) vom server auf dem client anmelden und dort die scripte ausführen 3. einen socket (ssl) zum server aufbauen und verbunden lassen und dort auf befehle warten

Was ist am elegantesten und auch von der last am besten? (wget request jede sekunde scheint es nicht zu sein xD) Ich tendiere zur 3. Möglichkeit und frage mich daher jetzt in welcher Programmiersprachen man etwas derartiges auf dem Client und Server am besten realisieren kann. Gibt es irgendwelche Sicherheitsaspekte die man noch stärker beachten sollte?

Gruß Anton

Nichts selber machen, einfach Ansible verwenden..

Das ist leider nicht möglich. Wir benötigen eine integrierte Lösung.

antonbracke schrieb:

Das ist leider nicht möglich. Wir benötigen eine integrierte Lösung.

Wie definierst du denn "integrierte Lösung"? Bzw. was passt dir an Ansible nicht (Was ist da nicht "integriert" genug, obwohl es genau deinen Anwendungsfall abdeckt?) Schonmal Puppet/Chef angesehen? Die machen auch nur das was du gerade mit Bash-Skripten selbst baust...

Wir verwenden ein Web-Portal als Cloud-Lösung, in die das System integriert werden muss.

Ok, beide von dir genannten Varianten werden von den von uns genannten fertigen Lösungen abgedeckt (Zumindest wenn die von mir im Text teilweise getroffenen Annahmen gelten, leider bist du, vermutlich um euren Business-Case zu schützen, sehr wortkarg was den genauen Einsatzzweck angeht, und sagst auch leider nicht warum die 3 genannten Tools nicht dazu passen):

• Skripte von Server laden und der führt die dann aus und meldet den Status zurück:

  • Puppet

  • Chef

• Per SSH verbinden und dann Befehle ausführen:

  • Ansible

Beide Varianten lassen sich sicher auch sauber in ein Web-Portal einbinden, für Puppet/Chef müssen nur entsprechende Manifeste/Rezepte erstellt werden, das sollte problemlos aus der WebGUI aus machbar sein, insbesondere wenn es um vorgefertigte Lösungen geht. Allerdings kenne ich mich mit den beiden nicht aus, da ich selbst Ansible verwende.

Ansible playbooks, die dann ensprechend ausgeführt werden, lassen sich durch entsprechende Rollen auch sehr einfach erstellen. Die Rollen sind dann die vorgefertigten Lösungen (z.B. Apache, MySQL o.ä.) und die schreibst du dann einfach alle in das Playbook für den neuen Rechner.

Beide Varianten haben den Vorteil das ihr Standardsoftware verwendet, für die man bei Bedarf externe Experten dazuholen kann. Bei eigener Software ist das immer schwer, insbesondere erfindet ihr damit das Rad nochmal neu.

Also: Wenn du explizite Beispiele hast wo du meinst das existierende Automatisierungstools nicht passen, dann nenne sie bitte und wir können gucken ob es nicht doch passt. Das dürfte nämlich ziemlich sicher der Fall sein 😉.

Wir haben eine selbst entwickelte Cloud-Lösung / Webseite über die wir unser System verwalten können (Administration + Benutzer-Zugriff: z.B. E-Mails und selbst entwickelte Module). Daher benötigen ich eine Lösung, die ich integrieren kann... 😉

Habt ihr damit Erfahrung, welches von den Systemen könnt ihr als Backend empfehlen? Wie sieht es mit der Problematik vom NAT-Routing aus? SSH benötigt ja einen Zugriff auf den Client!? Ist dort Puppet eher zu empfehlen? Welches System ist am leichtesten, also kein zusätzliches Web-Interface nur api etc?

Diese Fragen solltest du dir selbst stellen und bei einer Evaluation der 3 Systeme selbst beantworten können. Wir kennen nämlich die genauen Anforderungen nicht und ich selbst kenne nur Ansible genauer. Das wird über die Linux-Kommandozeile aufgerufen (Es gibt auch ein API, das kommt aber ohne Stabilitätsgarantie), mit der kommerziellen Lösung Ansible-Tower geht auch ein stabiles REST-API einher. Inwiefern es solche Lösungen auch für Puppet/Chef gibt muss dir jemand anderes oder eine eigene Recherche sagen. Ich gehe aber davon aus das dies der Fall ist da Puppet z.B. ein integraler Bestandteil von foreman ist, einer Virtualisierungs-WebGUI von Red Hat. Da Puppet und Chef eh einen Agent haben der auf der neuen Maschine laufen muss (und am besten schon im Master-Image oder bei der Basisinstallation installiert wird (Stichwort preseed/kickstart) sollte das hier problemloser sein. Bei Ansible musst du aber auch vorher am besten den entsprechenden SSH-Key hinterlegen, deshalb wirst du um preseed/kickstart eh nicht herum kommen.

Ansible kann z.B. problemlos mit JumpHosts umgehen, wenn du also einen SSH-Fähigen Host hast der das NATing macht (oder einen Host der in beiden Netzen sitzt) wirst du keine Probleme haben. Puppet und Chef sollten auch in der Lage sein mit segmentierten Netzen umzugehen. Wie das dort gelöst wird kann ich dir aber nicht sagen.

Du wirst aber nicht darum kommen selbst die notwendige Evaluierung zu machen, denn nur du kennst die genauen Anforderungen. Die Lernkurve von Ansible ist weniger steil als die von Puppet/Chef, aber auch hier muss man sich zwingend erst einmal gut einarbeiten bevor man zu etwas mehr als einem "Hello-World"-Äquivalent kommt.

Nach ein bisschen Nachdenken: Wenn du den Kunden nach dem initialen Deployment Kisten dahinstellen willst die nur noch von ihnen (und nicht mehr von euch) kontrolliert werden sollen müssen natürlich die entsprechenden Spuren gelöscht werden. Wenn die Kunden nur die Services bekommen sollen gilt das natürlich nicht. In ersterem Fall ist die Variante Shell-Skripte zu verwenden doch wieder sinnvoll, denn diese kann man zumindest beim preseeden problemlos ausführen (Kickstart vermutlich auch). Dann is das System im Zweifel schon direkt nach der Installation fertig.

antonbracke schrieb:

Wie sieht es mit der Problematik vom NAT-Routing aus? SSH benötigt ja einen Zugriff auf den Client!?

Wie das? Wenn ich mich per ssh mit einem Rechner verbinde, der für dieses Szenario der Server ist, gibt es keine Verbindung, die in der Gegenrichtung (also vom Server zum Client) aufgebaut wird. Das funktioniert natürlich auch, wenn der Client in einem Netz ist, das per NAT isoliert ist.

Wenn der Zielrechner (also der Server) hinter einem NAT sitzt, dann musst Du die Firewall halt so konfigurieren, dass ein Connect auf einen bestimmten Port auf Port 22 auf einem bestimmten Zielrechner geroutet wird. Dann kann es u.U. nur Ärger mit den Server-Zertifikaten geben - je nachdem, wie Ihr das aufgesetzt habt.

Einige unser Netzwerke liegen hinter einem Router. In diesem Fall müsste der "Cloud-Server" einen SSH-Verbbindung in das Netzwerk aufbauen und dann diese als Tunnel zu einem weiterem Rechner aufbauen. Da wir aber häufig keinen SSH-Server hinter dem NAT haben (keine Portfreigaben möglich / gewünscht etc.) müssen wir einen Reverse-Port-Tunnel auf einen außen liegenden Server aufbauen und diesen Tunnel dann nutzen. Das ist auf dauer sehr lästig denn jedes zusätzliche Netz benötigt einen Reverse-Tunnel und somit einen Port auf dem Public-Tunnel-Server. Daher meine Frage gibt es dort andere Möglichkeiten mit SSH oder ist es hier sinnvoller einen Daemon mit einer dauerhaften TCp Verbindung zu einem Public-Server aufzubauen, der dann über diese Verbindung pushen kann. Pullen führt ja bekannterweise zu sehr sehr viel Traffic.

ansible kann auch im pull mode arbeiten

Und bei ansible gibt es sogar schon ein Frontend, trägt den Namen "Ansible Tower". Wenn das eine Integration in ansible hat, dann sollte man ansible (warum auch immer) in eigene Lösungen integriert bekommen.

mfg Stefan Betz